Content and Capability Status
The UbID Documentation Center separates classifications that answer different questions. A page can be editorially complete while describing a planned capability, or describe an available capability while still awaiting specialist review of its wording.
Capability status
| Status | Meaning |
|---|---|
| Available | Approved for general use within the stated product, region, and conditions |
| Limited availability | Available only to named customers, regions, environments, or controlled deployments |
| Preview | Available for evaluation; interfaces, behavior, support, or evidence may change |
| Planned | Approved direction, but not represented as currently available |
| Conceptual | Architecture or research concept without a product commitment |
| Partner access | Capability or documentation provided only through controlled onboarding |
A page must not infer availability from the presence of source code, a prototype, an architecture diagram, or an internal service.
Editorial status
| Status | Meaning |
|---|---|
| Outline | Scope and boundaries are defined; complete public copy is pending |
| Foundation | A substantial baseline explanation is available; specialist and language review may continue |
| Approved | The stated version completed editorial, subject-matter, exposure, and publication review |
All pages created through Phase 3 remain foundation until formal review is complete.
Architecture source state
Institutional sources may classify material as:
- CURRENT — capability evidenced in the validated environment at the source date;
- REFERENCE — durable architecture rule, boundary, or product responsibility;
- TARGET — intended evolution, not represented as already implemented.
These source states do not automatically map to product availability. Product, operations, security, and commercial owners must approve the public capability status.
Exposure level
The editorial governance model uses:
| Level | Publication rule |
|---|---|
| Public | Suitable for the public portal after normal review |
| Public reviewed | Publicly explainable but requires specialist review because claims involve security, privacy, regulation, biometrics, cryptography, or high-impact automation |
| Partner | Controlled documentation for authorized integrators |
| Internal | Architecture, operations, risks, procedures, and evidence for authorized staff |
| Restricted or secret | Keys, credentials, recovery material, sensitive findings, privileged access, and other material that must never enter the public source tree |
Only public and public-reviewed pages are permitted under docs/.
Source hierarchy
Public content should be supported in this order:
- current official law, regulation, authority guidance, or normative standard;
- approved UbID controlled architecture and policy documents;
- validated implementation and operational evidence;
- approved product and availability decisions;
- explanatory material clearly labeled as non-normative.
When sources conflict, the page should not silently reconcile them. The conflict must be routed to the responsible owner and the public claim limited until resolved.
Page review metadata
A mature page should be able to identify:
- content owner;
- subject-matter reviewers;
- source versions and research cut-off;
- last reviewed date;
- capability status where relevant;
- jurisdictions and products in scope;
- known limitations;
- next review or change trigger.
Not every field must be displayed publicly, but the approval record should exist.
Change and deprecation
Material changes should update:
- page content and review record;
- documentation changelog;
- capability status;
- affected partner guidance;
- migration or deprecation notice;
- external references;
- translations after the source language is approved.
Deprecated content should state the replacement and effective date. It should not disappear when historical users still require migration information.
Publication safety
The public build verification checks front matter, exposure values, referenced files, static assets, and common secret or internal-address patterns. Automated checks reduce mistakes but do not replace human security, privacy, legal, architecture, and product review.
The portal remains non-indexed until the approved publication milestone.
See the Documentation Changelog and Governance and Accountability.