Status vocabulary
Two approved models. Do not invent parallel scales on product or integrator pages.
1. Implementation status (capabilities and routes)
Use on capability tables, endpoint maps, and engineering walkthroughs.
| Label |
Meaning |
| IMPLEMENTED |
Code path exists and is wired for the documented trigger |
| PARTIAL |
Some of the behaviour is wired; the gap is named on the page |
| PLANNED |
Described in a design comment or doc; not implemented in code |
| DEPRECATED |
Exists but must not be used for new integrations |
| DEAD |
Exists in tree but nothing calls it |
| UNKNOWN |
Repositories do not contain enough evidence |
2. Product readiness (gates)
Use only via the Product readiness summary. Product pages link there; they do not keep a private scale.
| Gate |
Evidence required |
| Code |
Routes or entry points implemented on the branch that is deployed (or clearly named) |
| Integration Verified |
Real consumer or producer–consumer contract test |
| Ops Ready |
Deploy config and monitoring/alerting and a runbook |
| Security Approved |
Enforced authz on product routes, no open blocking findings, owner sign-off |
| GA |
All four gates MET and owner declares general availability |
| Value |
Meaning |
| MET |
Required evidence exists |
| PARTIAL |
Some evidence exists; notes say what is missing |
| NOT MET |
Evidence shows the gate fails |
| UNKNOWN |
No evidence either way |
| Phrase |
Use |
| provisional / non-production |
Policy not compliance-approved |
| Requires confirmation |
Owner or programme must supply a fact docs cannot invent |
| OWNER DECISION REQUIRED |
Internal decision packets awaiting named approver |
Disallowed status language
- “Code: Yes/No”, “mostly ready”, “production-ish”
- Softening UNKNOWN into implied success
- Mixing readiness gate names into capability rows without the readiness page