[Substrate Engineering · Phase 2] Accept a DomainSubstrate as policy input (deny/guard rules only)

[dgenio]

Context

Part of the cross-repo Substrate Engineering roadmap (proposal in weaver-spec).

The kernel already enforces I-01/I-02/I-06 and evaluates policy deterministically, top-down, first-match-wins. A DomainSubstrate declares invariants and admissible states; the kernel is the right place to enforce them at runtime.

Scope

Let a DomainSubstrate be an optional input to policy evaluation. Its invariant + admissible-state facets are compiled into generated deny/guard rules, evaluated before hand-written rules.

Constraints (security-critical)

• Substrate-derived rules MUST be deny/guard rules, never allow rules — this respects the documented ordering trap (an allow rule placed before a sensitivity check silently bypasses it). See docs/agent-context/invariants.md.
• No weakening of I-01 (firewall), I-02 (authorized + auditable), I-06 (token binding). Keep determinism: no randomness in evaluation.
• Consult docs/agent-context/invariants.md before touching policy ordering.

Acceptance criteria

• Policy engine optionally consumes a DomainSubstrate; substrate → deny/guard rules evaluated ahead of hand-written rules.
• Conformance tests still pass against weaver-contracts; new tests cover substrate-derived denials and the ordering guarantee.
• make ci passes; invariant docs updated if behavior surface changes.

Dependency / phase

Phase 2. Depends on the DomainSubstrate contract from dgenio/weaver-spec#167.

🤖 Generated with Claude Code