To enforce an architectural decision in CI, identify a consequence with objective evidence, declare the scope and expected condition, run a deterministic check against the changed code or full tree, and report the result with a citation to the accepted decision.
Start with a checkable consequence
An ADR may contain several consequences, only some of which can be evaluated mechanically. 'The service must not import the UI package' is checkable. 'The architecture should remain elegant' is not. Classify the former for enforcement and leave the latter for review.
Trying to automate the whole paragraph with an LLM judge makes the gate difficult to reproduce and easy to overstate.
Make scope explicit
A changed-files check answers a different question from a full-tree certification. The first can block a patch from introducing a new violation; the second can claim that the current repository satisfies the rule. Report which mode ran and avoid presenting incremental coverage as global compliance.
Return evidence a reviewer can inspect
A useful failure names the governing record, the check, the affected file and the observed condition. A useful pass says what was examined. This lets a reviewer distinguish a real guarantee from a green status with ambiguous scope.
- Decision: ADR-014 — preserve the restoration window.
- Constraint: no direct hard-delete call in account closure paths.
- Scope: files changed by this pull request.
- Evidence: matching file and line, or an explicit clean result.
Version the check with the decision
When a decision is superseded, the corresponding constraint must be updated or retired through review. Relating the two prevents abandoned policy code from enforcing a rule the team no longer accepts.