status definitions.
Consistent lifecycle labels separate design intent, code existence, qualification progress and actual network availability so public documentation does not imply more readiness than has been verified.
planned
Architecture or product scope is defined, but implementation should not be assumed to exist. Planned components may change before implementation and should not be treated as available interfaces or dependencies.
implemented
Code exists in the project and may have tests or internal integration, but production deployment, public availability and operational readiness are not implied.
qualifying
The implementation is undergoing integration, security, deployment, compatibility or operational checks before it can be treated as canonical. Qualification may include testnet operation without implying production readiness.
deployed
A qualified release is available on a named network with verifiable deployment information. The status should be accompanied by the relevant network, version, address or endpoint reference rather than used as a standalone claim.
deprecated
The component remains available for compatibility or transition purposes, but new integrations should use the documented replacement. Deprecation should identify the replacement and any expected support or migration window when known.
retired
The component is no longer supported for active use. Historical records remain available when needed to interpret past transactions, releases or application behavior.
status transitions
Status changes should be based on observable project state. A component moves to deployed only when a qualified release can be tied to a verifiable environment; documentation wording alone does not establish deployment.