Skip to content

Schema Reference

Canonical JSON Schemas are stored in docs/reference/schemas:

  • workspace registry;
  • managed assets manifest;
  • provider profile;
  • declarative plugin manifest;
  • MCP server definition.
  • enterprise change-readiness scorecard.
  • documentation catalog and lifecycle metadata.
  • documentation impact analysis and synchronization evidence.
  • visual freshness, accessibility, and source-dependency evidence.
  • allowlisted executable-example evidence.
  • version specifications, feature traceability, and evidence requirements.
  • foundation authority maps and resolved version bundles.

The change-readiness scorecard schema defines the retained machine-readable evidence used by push, merge, and release gates. The canonical scoring rules and applicability profiles are documented in the Enterprise Change Readiness Scorecard.

The documentation catalog schema defines classification, authority, ownership, lifecycle, freshness, related evidence, and security/privacy/accessibility relevance for the complete documentation corpus.

The documentation impact schema defines deterministic change classification, affected components, implementation/test/documentation coupling, mandatory blockers, and the push or merge decision used by documentation CI.

The documentation evidence bundle schema defines checksummed pull-request and release synchronization reports. The visual evidence schema and executable example schema prevent stale images, inaccessible visual claims, unsafe command execution, and unverifiable examples.

The release retrospective schema defines immutable, evidence-aware evaluation of historical stable tags. It separates historical assurance from current-rule certification and fails future releases closed when prospective governance evidence is missing.

Schema v2 enforces profile-specific domain targets and separate module-criticality targets: standard modules require 90%, important modules 95%, and critical modules 100% at merge and release. An overall score cannot compensate for a failed domain or module.

Capability governance adds dedicated profiles for capability packages, host adapters, agent teams, orchestration, rules and guardrails, knowledge and memory, Capability Studio and publishers, and marketplace or registry distribution. These profiles are readiness contracts only; they do not authorize runtime schemas.

Schemas document public persisted contracts. Runtime validation remains authoritative, and schema changes require migration, compatibility review, and release notes.

The version-documentation schemas are version spec, version feature, evidence requirements, foundation map, and resolved bundle. They govern planning metadata and do not fabricate future implementation or certification evidence.