13. Constitutional and Self-consistency Audits
A config that grows without constraint eventually contradicts itself. Rule A says "always use ESLint for formatting". Rule B says "prefer Biome for speed". A new developer reads both and does neither, because the rules conflict and the system gives no signal that they conflict. Constitutional audits catch this before it compounds.
Constitutional Audit
Before each Curator PR lands, run a constraint check against two targets: the proposed change vs. the existing rule set, and the proposed change vs. an explicit constitution.md.
# .claude/constitution.md (example)
invariants:
- id: no-auto-commit
rule: "Never commit without explicit user request"
rationale: "2024-incident: automated commit bypassed review gate"
- id: no-destructive-without-confirm
rule: "Never run rm, DROP, or force-push without confirmation"
rationale: "Production safety baseline"
- id: diff-before-merge
rule: "Always show diff before applying multi-file changes"
rationale: "Preserves human review in the loop"The constitutional check is two queries: does the proposed rule contradict any invariant, and does it conflict with any existing rule in .claude/rules/? Both queries can run as Claude prompts with the constitution and rule list as context. This costs a few hundred tokens per Curator run and prevents rule conflicts from silently accumulating.
The lineage of this pattern is Constitutional AI (Anthropic, 2022) and RLAIF: using a high-level value document to constrain a lower-level generation process. The transposition here is from output alignment (checking a model's responses) to config alignment (checking a rule system's internal consistency). The mechanism is simpler because the inputs are shorter and fully deterministic.
Self-consistency Check
Systems that modify themselves accumulate a specific failure mode: the documentation claims a state that no longer matches reality. On a production ACE installation, the file ace-improvement-loop.md claimed "skills versioning 100% complete as of 2026-03-04". The actual state, measured six weeks later, was 20 out of 114 skills versioned (17%). The gap persisted because nobody audited the claims the system made about itself.
The self-consistency check runs weekly, separately from the Curator. It reads the claims in your ACE documentation and verifies them against the measured state:
| Claim type | How to verify |
|---|---|
| "N rules active" | find .claude/rules -name "*.md" | wc -l |
| "Skills versioning X% complete" | grep -l "^version:" .claude/skills/*/SKILL.md | wc -l divided by total skills |
| "Last curator run: date" | Check the most recent Curator PR creation date in git log |
| "Friction trending down" | Compare 4-week moving average from signal store |
When a claim diverges from the measured state by more than 10%, the check appends a "Self-consistency violations" section to the next Curator report. This is not a failure state; it is the system doing its job. Documentation rot is normal. Catching it weekly is not.