Documentation Status and Evolution

Separate documented intent, implementation evidence, and live runtime availability.

Three different questions

Intent: Is this an accepted boundary, a proposal, or a deferred direction?
Implementation: Which concrete parts exist in source and which remain missing?
Availability: Can this Workspace use the capability now? Only the authoritative runtime can answer this.

A published page is not proof of implementation. An implemented capability is not proof of installation, activation, credentials, permissions, or successful execution.

Capability status vocabulary

The current capability metadata schema accepts these values independently for documentation, contract, runtime, security, and tests:

Value	Meaning
`implemented`	The named surface exists; explain its verified scope and evidence.
`partial`	Some parts exist; list missing parts explicitly.
`designed`	A design exists but the named surface is not implemented.
`proposed`	An option under consideration, not an accepted commitment.
`uncertain`	Evidence has not been established. Never interpret as available.
`deferred`	Deliberately postponed; state the revisit trigger.
`retired`	No longer authoritative; link its replacement if one exists.

These are not an ordered maturity score. A runtime may be implemented while its public documentation is incomplete. Tests should identify the checked behavior and revision, not promise that every later build passes.

Evidence and ownership

Capability metadata can link evidence.code, evidence.tests, and evidence.docs. A path is a traceability link, not proof that the test passed. Report execution evidence separately, including scope and relevant revision.

The schema lives in apps/site/lib/agent/capability-schema.ts. Runtime availability remains outside this static schema. Preserve existing capability IDs and numeric versions; navigation groups are not capability identities.

Evolving the knowledge base

Update a subject in its existing owner page instead of creating a second reference with conflicting authority.
Keep proposals and missing implementations visible as such; do not publish speculative execution instructions as working tutorials.
When ownership or a contract changes, record the decision, replacement, affected consumers, and retirement condition.
Human pages, raw Markdown, capability manifests, and Docs MCP must describe the same limitations. No documentation surface grants runtime permissions.
Group changes must validate duplicate slugs, localized links, machine-readable URLs, component previews, and production builds.

Current rollout limitation

The capability status schema exists, but explicit evidence-backed status coverage across all pages is not yet complete. Missing status must not be upgraded to a positive implementation or security claim. A single complete state matrix for every product surface is not yet available.