Enforcement map

Generated by bash gate-sdk/bin/run-gates.sh --emit enforcement-map; do not hand-edit — check-enforcement-fresh byte-compares this page against the emitter.

Every governed surface in the repository this map is generated from is held by one enforcement class, ordered here from hardest to softest:

• A blocking gate fails the commit (or, at the align-only tier, the consistency audit) — the pre-commit hook is its local reach, the CI workflow its server-side backstop. Owner: gate-sdk/SPEC.md §Enforcement tiers.
• An advisory KPI never blocks; it reports a drift trend into the session-context line. Owner: drift-kit/SPEC.md §The KPI plugin contract.
• A guard intercepts a harness event — a tool call before it runs, a turn end before it completes — and can refuse it. Owner: guard-kit/SPEC.md §The shell guard.
• A session warning surfaces context when a session opens. Owner: context-kit/SPEC.md §The session-context hook.
• A validate suite holds a test baseline that a per-run evidence manifest attests. Owner: evidence-kit/SPEC.md §Baseline manifest.
• A monitor watches deployment truth rather than tree truth, so it reds a scheduled run, never a merge. Owner: site-kit/SPEC.md §The monitor boundary.

The rows below derive from the class registries — the gate registry, the KPI registry, the harness settings hooks, the evidence-suite config, and the # enforce: markers a non-gate surface declares itself with — so this map cannot drift from what actually runs. A registry a consumer has not adopted leaves its section absent. A surface that lives under no kit directory, the repository’s own rather than a kit’s, is grouped as (consumer).

Blocking gates

Advisory KPIs

Guards

Session warnings

Validate suites

Monitors