Unified enforcement engine.

Governed HALT decisions used to be distributed across Make, Python scripts, and MCP surfaces with mixed primitives — return codes, RuntimeError, local JSON DENIED payloads, and ad-hoc sys.exit calls. This produced drift between surfaces and allowed report-only paths in some failure cases.

The new model collapses that to a single control flow:

emit event
  → enforce(event, state, skill_context)
  → HaltException
  → adapter-specific halt surface

All execution surfaces resolve governance through enforce(event, state, skill_context), but no single agent is the authority surface. Each agent executes governance independently under identical invariant sets.

Adapter-specific halt surfaces

The system does not execute enforcement against raw events. It executes governance skills, which compile into enforceable invariants. The compilation path:

SKILL → invariant set → enforce(event, state, skill_context)

Each skill defines:

• Trigger conditions → event generation
• Inputs → state surface
• Workflow → ordered invariant checks
• Failure modes → HALT mappings
• Ambiguity protocol → escalation or halt

All governance skills must be agent-independent, execution-surface invariant, and reproducible across environments. Violation results in system-level non-determinism.

governance/invariants_v1.json is the compiled invariant registry. It maps invariant ids and numeric codes to predicate keys. runtime/governance/enforcement_engine.py holds the predicate dispatch table and performs fail-closed load validation.

HALT-7XX · governance symmetry

HALT-8XX · portability & consistency

HALT-602 · meta-state hallucination

referenced_artifact not in registry and not explicitly null. Class: halt.

The supported event types are fixed. Unknown event types fail closed with HALT-999.

tool_call          memory_write       finalize
seal_verify        cross_phase_ref    authority_claim
schema_validate    boot_verify        artifact_activate
role_transition

Meta-state hallucination · HALT-602

Definition: the system produces or relies on artifacts that do not exist in the execution substrate.

Observable proxy

• Missing artifact referenced in state
• Inconsistent artifact registry
• Unverifiable provenance

Invariant

All referenced artifacts must resolve to a registry entry, a cryptographic seal, or an explicit null classification.

Enforcement

HALT-602: unresolved or fabricated execution state.

Epistemic failures are not directly enforceable. They must be compiled into process constraints by binding each failure mode to a required artifact and a corresponding invariant.

Epistemic Failure → Required Artifact → Invariant

HALT-P numeric mapping

HALT-P301 → 3010
HALT-P401 → 4010
HALT-P601 → 6010

These mappings are enforced in the invariant registry and in subprocess rematerialization (KNOWN_HALT_CODES, halt_from_exit_code).

The system operates across two planes with strict authority separation.

Compilation path

archive → failure extraction → invariant definition → runtime enforcement

Two metrics define whether the engine is meaningfully enforcing.

Required values

• For all HALT-S invariants: detection completeness = 1.0, enforcement completeness = 1.0.
• For HALT-P invariants: detection completeness must be maximized through process constraints.

Any invariant not tested under violation conditions is considered non-enforcing.

Governed runtime depends on a valid invariants registry at startup. A missing or malformed governance/invariants_v1.json causes an intentional fail-closed halt. When migrating or refactoring, the registry and enforcement_engine.py must be established and tested before any governed call site is wired to enforce(...).

On a fresh checkout, the first governed run either succeeds with a valid registry or fails with an explicit bootstrap error. There is no ambiguous intermediate state.

Migration notes for new governed surfaces

1. Normalize request and context into one of the supported event types.
2. Call enforce(event, state, skill_context).
3. Do not implement local allow / deny policy in the adapter.
4. Catch HaltException only at the outer adapter boundary.
5. Convert once via halt_from_exception(...) for the target surface.

HaltException does not cross process boundaries directly. Instead:

• The child or subprocess surface exits with sys.exit(exc.code) after recording required artifacts.
• The parent process rematerializes known halt codes with halt_from_exit_code(returncode, context).
• Unknown non-zero codes are treated as non-governance runtime errors.

Known downstream compatibility

The previous /mcp/call HTTP 403 shape (from the old runtime/scripts/agent_tools/mcp/server.py) used FastAPI HTTPException(detail=...), so clients received { "detail": "HALT-301: mutation_blocked_in_frozen_state" }. The new shape is { "halt_code": <code>, "reason": <reason> }. runtime/src/frontend/src/services/apiService.ts needs to read halt_code / reason when wired to a live backend; this is currently non-breaking because the frontend runs against MSW mocks.