Prevent confusion
Certification helps users distinguish compatible, experimental, supported, certified, and official ecosystem participation.
Certification
Certification turns claims into evidence.
RelayHub certification is a future governance and validation pathway for hardware, software, integrations, documentation, vendors, and communities. It exists to prevent confusion, protect users, and make support boundaries clear.
Why certification exists
Ecosystems need clear status language.
RelayHub should encourage open participation without allowing misleading claims. Certification helps distinguish what merely works, what has been checked, what is supported, and what is official.
Improve interoperability
Certified products, applications, services, and guides should meet published expectations for safe interoperability.
Increase trust
Certification provides evidence that something has been tested against defined requirements rather than merely claimed.
Define support boundaries
Certification should make clear what is supported, what is limited, what is excluded, and what recovery path exists.
Reduce fragmentation
Certification helps the ecosystem grow without creating incompatible terminology, unclear claims, or misleading product status.
Protect users
Certification should prevent unsupported or unsafe configurations from being presented as product-ready.
Certification levels
Four labels, four different meanings.
These labels should not be mixed. Each one carries a different level of evidence, authority, and support expectation.
Works with RelayHub in some defined way. Not necessarily tested by RelayHub and no support guarantee is implied.
Basic validation evidence has been provided for a limited scope, version, hardware class, or integration path.
Validation is complete for the stated scope. Recovery, documentation, compatibility, and support boundaries are defined.
Built, governed, maintained, or formally adopted by RelayHub as part of the official ecosystem.
What can be certified
Certification can apply beyond hardware.
RelayHub certification may eventually cover devices, software, integrations, documentation, communities, vendors, and services — but only within a clearly defined scope.
Hardware
Home Nodes, Infrastructure Nodes, Radio Nodes, Mini PC Nodes, power profiles, storage profiles, and enclosure builds.
Software
RelayOS applications, local web UI modules, companion tools, local services, and community software.
Integrations
Reticulum integrations, marketplace integrations, directory integrations, community tools, and future API integrations.
Documentation
Deployment guides, recovery guides, training materials, community onboarding guides, and operator procedures.
Communities
Community deployments, field pilots, local operating groups, federation participants, and support-ready community hubs.
Vendors
Commercial builders, kit makers, service providers, hardware suppliers, and support partners.
Requirements
Certification should require more than a badge.
A certified item should have documented scope, validation evidence, recovery expectations, security review, privacy review, and support boundaries.
- Defined certification scope
- Hardware or software version identified
- Compatibility expectations documented
- Validation evidence provided
- Recovery behaviour tested
- Security posture reviewed
- Privacy claims reviewed
- Support boundary defined
- Documentation reviewed
- Known limitations declared
- Retest triggers defined
- Revocation path documented
Lifecycle
Certification is not permanent.
Certification should apply to a specific version, scope, hardware class, integration path, documentation set, or community deployment. It must be reviewable and revocable.
- Certification is version-specific.
- Certification may be limited to one hardware class.
- Certification may expire.
- Certification may be revoked.
- Major updates may require retesting.
- Changed hardware may require retesting.
- Changed radio behaviour may require legal and technical review.
- Changed support claims may require documentation review.
Relationship to compatibility
Compatibility, certification, and official status must stay separate.
Clear separation prevents ecosystem confusion, accidental endorsement, false support expectations, and misleading marketplace or vendor claims.
Compatible ≠ Certified
A device or tool may interoperate without passing RelayHub certification.
Certified ≠ Official
A certified third-party product may meet requirements without being built or governed by RelayHub.
Official ≠ Required
The ecosystem should remain open to compatible participation where safe and clearly labelled.
Experimental ≠ Supported
Working once in a test does not make a feature, device, or integration product-supported.
Future registry
A certification registry is planned, not implemented.
A future certification registry could show which hardware, software, integrations, partners, documentation, and communities have been certified, along with their scope, status, version, and limitations.
Planned
certification.relayhub.tech
This registry concept is not yet implemented. It should only appear once certification standards, review process, evidence requirements, and governance procedures are ready.
Certified hardware
Certified software
Certified integrations
Certified documentation
Certified partners
Certified communities
Certification scope
Version and expiry status
Known limitations
Support boundary
Interested in certification?
Ask before using certification language.
RelayHub certification is not yet open as a formal programme. If you are building hardware, software, documentation, or a community pilot, describe the scope and the claim you want to make.
Certification enquiries
Include the product, version, hardware class, integration path, validation evidence, documentation, support expectations, and known limitations.