"Operations catalog SSOT"

Operations catalog SSOT

The canonical edit surface for first-party operation identity is:

Schema:

Human-edited (first-party operations): only this catalog YAML (including the nested capability: block for runtime builtin maps + capability exemptions). Generated — do not hand-edit:

vox ci operations-verify refuses drift: it compares those three files to fresh projections from the catalog (in addition to parity checks and MCP dispatch + input-schema + read-role governance coverage).

CI commands

  • vox ci operations-verify — validates catalog parity against committed MCP/CLI/capability registries, MCP dispatch + input_schemas.rs coverage, read-role governance profile vs catalog, derived-artifact strict match, and refreshes contracts/reports/operations-catalog-inventory.v1.json
  • vox ci operations-sync --target catalog --write — regenerates operation rows from live registries while preserving the catalog capability + exemptions roots (requires an existing catalog)
  • vox ci operations-sync --target mcp --write — writes MCP registry from catalog
  • vox ci operations-sync --target cli --write — writes vox-cli rows in the command registry from catalog
  • vox ci operations-sync --target capability --write — writes capability registry from catalog (capability: block + projected curated rows)
  • vox ci operations-sync --target all --write — runs mcp, then cli, then capability

Scope boundary

User @mcp.tool and @mcp.resource generated app surfaces remain outside this first-party catalog. They are represented by per-app contracts emitted by the compiler and may be federated later.

Implementation and producer-audit backlog (including catalog ↔ guard alignment): telemetry-implementation-backlog-2026.md.

Optional operator upload queue is catalogued as telemetry / telemetry.* in the same YAML; see ADR 023, telemetry-remote-sink-spec, and vox telemetry in cli.md.