Operations
Roadmap Status
Separate implemented, validated, and roadmap claims.
Use precise status language whenever docs mention support, runtime behavior, providers, cryptography, Filecoin, policies, or mobile key storage.
Status Labels
| Label | Meaning |
|---|---|
| Implemented | Source code exposes the behavior |
| Documented | Public docs explain how to use it |
| Validated | A command or test proves it in a named environment |
| Experimental | Available but interface or support may change |
| Roadmap | Planned or discussed, not a current user promise |
| Not supported | Known absent or intentionally out of scope |
Required Evidence
| Claim | Evidence needed |
|---|---|
| Package is installable | Published package or local pack smoke output |
| Provider is production-ready | Live validation output for write, read, proof, and metadata |
| Filecoin persistence works | Bridge validation plus retrieval strategy |
| Policy-backed share works | Policy provider validation and fail-closed behavior |
| Mobile vault is secure | Production build bridge evidence, not only API presence |
| FIPS/PQC support exists | Release note, implementation, tests, and migration docs |
Wording Rules
- Say "implemented" when code exists.
- Say "validated" only when there is evidence for the environment.
- Say "roadmap" for future work.
- Say "not a current guarantee" for claims that would change user risk.
- Link to the guide that users need, not just to an internal review.
Common Drift
- README or docs using an old unscoped package name.
- Runtime pages omitting current support caveats.
- Provider pages implying Kubo alone is enough for MeshKit metadata.
- Security pages overstating FIPS/PQC status.
- Filecoin pages implying deal status guarantees retrieval.