Household pilot
Tests appliance-style setup, pairing, local dashboard, status comprehension, recovery, support export, and ordinary usability.
Pilot Program
Evidence before expansion.
RelayHub pilots exist to test local-first communication, onboarding, recovery, trust, documentation, hardware classes, support boundaries, accessibility, and real community usefulness before anything is treated as broadly supported.
Pilot purpose
A pilot is not a launch.
A RelayHub pilot is a bounded learning activity. It should prove what works, reveal what fails, capture evidence, test recovery, improve documentation, and prevent unsupported claims from becoming product promises.
Pilot types
Different pilots test different risks.
A good pilot is small, observable, recoverable, documented, and honest about what is being tested.
Community pilot
Tests local-first communication, trust, documentation, recovery, coordination, community roles, and practical group workflows.
Hardware pilot
Tests hardware classes, boot behaviour, storage, power, thermal behaviour, Reticulum operation, and recovery paths.
Field pilot
Tests degraded operation, intermittent connectivity, local-only workflows, portability, support expectations, and real-world constraints.
Education pilot
Tests workshop material, onboarding guides, recovery cards, status explanations, and non-technical learning paths.
Developer pilot
Tests RelayOS concepts, future APIs, validation tooling, documentation, integration boundaries, and implementation assumptions.
Pilot phases
Every pilot needs a path and a decision point.
RelayHub pilots should move through clear phases so participants know what is happening, what evidence matters, and what happens next.
Interest
Collect participant details, location, use case, hardware, technical comfort, and expected value.
Scope
Define what will be tested, what will not be tested, who participates, what hardware is used, and what safety limits apply.
Prepare
Prepare guides, recovery instructions, status cards, test checklists, support process, and evidence capture templates.
Run
Test setup, local-only operation, trust, recovery, support export, documentation, degraded states, and participant comprehension.
Review
Analyse evidence, issues, failures, confusion, risks, support burden, recovery results, and readiness for the next step.
Decide
Continue, revise, expand, pause, stop, or return to lab validation based on evidence rather than enthusiasm.
Evidence
Each pilot should produce artefacts.
If a pilot produces no evidence, it cannot safely guide the product. Evidence may be public, private, redacted, or internal depending on the people, risks, privacy, and deployment context.
Setup notes
Photos where appropriate
Screenshots
Issue list
User feedback
Recovery drill result
Support export result
Status comprehension notes
Hardware notes
Connectivity notes
Degraded-operation notes
Next-step decision
What pilots test
Human comprehension matters as much as technical function.
A RelayHub pilot should prove whether real people can understand setup, status, trust, recovery, support, hardware limits, and product boundaries.
- Can people understand what RelayHub is?
- Can non-technical users find the first step?
- Can users complete setup without terminal instructions?
- Can users explain Ready, Local-Only, No Peers, Degraded, and Recovery?
- Can recovery be found without internet access?
- Can trust and discovery be explained clearly?
- Can support information be shared without exposing secrets?
- Can participants distinguish current features from planned features?
- Can hardware limitations be understood before they create false expectations?
- Can pilot evidence produce a clear decision instead of vague optimism?
Success and failure
A failed pilot can still be a successful learning result.
The purpose of a pilot is not to prove RelayHub is ready. The purpose is to find the truth early enough to improve the system safely.
Pass
The tested flow works, users understand it, recovery is available, risks are acceptable, and evidence supports progression.
Partial pass
The core idea works, but usability, documentation, recovery, hardware, or support needs revision before expansion.
Fail
The test exposes serious technical, recovery, usability, safety, or trust problems that must be fixed before another pilot.
Stop
The pilot should stop if participants may rely on unsupported behaviour, misunderstand risk, or exceed safe boundaries.
Revise
The concept remains useful, but the flow, hardware, documentation, policy, or support process must be redesigned.
Return to lab
The test should move back to controlled validation if field conditions reveal unresolved architecture or recovery issues.
Safety boundaries
Pilots must not create false confidence.
A pilot is a learning and validation activity. It should not be marketed as a supported release, certified deployment, emergency service, privacy guarantee, or replacement for critical communication.
A pilot is not a product-supported release.
A pilot must not be used as an emergency-service guarantee.
Experimental hardware must be labelled experimental.
Recovery must be tested before expansion.
Support boundaries must be clear before participants rely on the system.
RelayHub must not be described as providing perfect anonymity.
Radio transmit must not be assumed lawful merely because hardware exists.
No participant should depend on RelayHub as their only communication path during a pilot.
A pilot may stop safely if the system is not ready.
Who should apply?
Early pilots need patient, practical testers.
The best early participants understand that pilots are about learning, validation, feedback, recovery, and safe improvement — not polished product promises.
- Community organisers
- Local resilience groups
- Households willing to test setup and recovery
- Reticulum users
- NixOS users
- Hardware builders
- Documentation contributors
- Accessibility testers
- Regional community groups
- People comfortable giving detailed feedback
Current limitations
The pilot programme is not open as a formal release yet.
RelayHub is currently collecting interest and preparing public foundations. Product builds, hardware certification, validation runs, and formal pilots come later.
- No public RelayOS images are available yet.
- No certified hardware programme is active yet.
- No partner directory is active yet.
- No formal community federation programme is active yet.
- No emergency service guarantee exists.
- No supported product release exists yet.
Apply for a future pilot
Tell us what you want to test.
RelayHub is looking for practical interest from households, communities, builders, developers, educators, and organisations that understand the difference between a pilot and a supported product.
Useful details
- Who you are
- Where you are located
- Whether you are a household, community, developer, builder, or organisation
- What you want to test
- What hardware you already have
- Your technical comfort level
- How many people may participate
- What outcome would make the pilot useful