Hardware class validation
Each node class must be tested against its real capability ceiling. A small radio node, home node, and infrastructure node should not be treated as equivalent.
Validation
Claims must be proven before they become promises.
RelayHub should only treat a capability as supported when it has been tested, observed, reproduced, documented, and given a realistic recovery path.
Release discipline
Supported means more than technically possible.
RelayHub should distinguish between ideas, prototypes, experimental features, release candidates, and supported product behaviour. This keeps users safe and prevents marketing from outrunning reality.
Recovery validation
Rollback, safe reset, degraded boot, identity preservation, and support export must be tested before being promoted as supported behaviour.
Operational mode validation
Local-only, internet-assisted, offline, degraded, and recovery modes should be tested as distinct states, not assumed from normal operation.
Privacy claim validation
Privacy claims must be realistic. RelayHub must not imply perfect anonymity, invisible metadata, or immunity from physical or radio observation.
Release gates
A feature should pass gates before broad release.
Release gates help ensure that capability, recovery, documentation, support, and limitations are ready before users rely on a feature.
- Build works reproducibly.
- Core operation is validated.
- Recovery path is validated.
- Rollback behaviour is validated.
- Degraded operation is tested.
- Documentation is complete enough for users.
- Known limits are clearly stated.
- Support boundary is defined.
Supported status
“Supported” should be earned.
A supported RelayHub capability should have known requirements, tested behaviour, clear documentation, visible status, defined recovery paths, and a realistic support boundary.
Concept
The idea is being explored. It should not be relied upon.
Experimental
The feature may work in limited conditions, but behaviour, recovery, and support are not yet complete.
Supported
The feature has been validated, documented, bounded, and given a recovery and support path.
Experimental boundaries
Experiments should be visible as experiments.
Experimental features may be shown as concepts or prototypes.
Experimental features must not be described as product-supported.
Experimental features must have visible limits.
Users should know when something is unvalidated.
Recovery and safety risks should be named before field trials.
A feature is not supported merely because it works once.
Validation principle
Test normal operation, recovery, and failure.
A system is not validated merely because it works on a good day. RelayHub must test degraded operation, failed updates, lost transport, limited hardware, recovery paths, and user comprehension.
Credibility rule
No major claim is complete unless it is testable, observable, reproducible, recoverable, and backed by evidence.