Override Corpus — Your Enforcement Policy Memory
The override corpus is the mechanism that turns every human decision into binding enforcement policy. It is the feature that makes Mergen more valuable the longer you use it — a policy corpus that compounds with every incident, every approval, every override.
What it is
When an on-call engineer overrides a Mergen block or approves a HITL hold, that decision is encoded as an entry in the override corpus. The next time the same agent action is attempted in the same service context, Mergen checks the corpus and:
- If the action was previously approved for this context → routes it to HOLD for review (not auto-approved, but one click instead of filling out a form)
- If the action was previously overridden (engineer said "skip this block") → the corpus entry is staged as a policy proposal:
GET /policy-suggestionsfor one-click approval
The corpus is never used to auto-approve or auto-block. It only changes routing: PASS → HOLD for human review. The architectural invariant is enforced.
How entries are created
1. Via HITL "Remember for this service"
When approving a HITL hold, pass remember=true:
curl -X POST "http://127.0.0.1:3000/hitl/approve?token=TOKEN&remember=true" \
-H 'x-mergen-secret: your-secret'
Or click "✅ Approve & Remember" in the Slack message (if using Mergen ≥ 1.1.0).
2. Via the override API (manual)
curl -X POST http://127.0.0.1:3000/overrides \
-H 'Content-Type: application/json' \
-H 'x-mergen-secret: your-secret' \
-d '{
"incidentTag": "INC-2024-503",
"proposedCommand": "kubectl scale deployment auth-api --replicas=0",
"overrideReason": "on-call-discretion",
"note": "Scale down auth-api during maintenance window",
"rationale": "Planned maintenance — not an AI agent action",
"service": "auth-api",
"environment": "production",
"actor": "developer"
}'
3. Via the Slack override loop (MERGEN_SLACK_OVERRIDE_LOOP=true)
When enabled, Mergen scans your incident channel every 6 hours looking for postmortem threads that contain override decisions. It extracts commands and context automatically and builds corpus entries.
MERGEN_SLACK_OVERRIDE_LOOP=true mergen-server start
4. Via git history / ADR records (MERGEN_GIT_ADR_SYNC=true)
Mergen scans git commit messages and Architecture Decision Records daily for operational constraints phrased as overrides ("never deploy to production on Fridays", "always run with --dry-run in staging").
MERGEN_GIT_ADR_SYNC=true mergen-server start
Inspect the corpus
# Full corpus
curl http://127.0.0.1:3000/override-corpus \
-H 'x-mergen-secret: your-secret'
# Pending policy proposals (from auto-corpus-propose)
curl http://127.0.0.1:3000/policy-suggestions \
-H 'x-mergen-secret: your-secret'
Corpus entry shape:
{
"id": "ovr_abc123",
"incidentTag": "INC-2024-503",
"proposedCommand": "kubectl scale deployment auth-api --replicas=0",
"overrideReason": "on-call-discretion",
"service": "auth-api",
"environment": "production",
"actor": "developer",
"note": "Scale down auth-api during maintenance window",
"createdAt": "2024-07-06T14:22:00.000Z",
"reviewedAt": null,
"promotedToPolicy": false
}
Promote a corpus entry to a live policy rule
When a pattern has been overridden repeatedly, Mergen stages it as a policy proposal:
# See proposals
curl http://127.0.0.1:3000/policy-suggestions -H 'x-mergen-secret: your-secret'
# Approve a proposal (creates a HOLD rule for this pattern)
curl -X POST http://127.0.0.1:3000/policies/proposals/PROPOSAL_ID/approve \
-H 'x-mergen-secret: your-secret'
# Reject a proposal
curl -X POST http://127.0.0.1:3000/policies/proposals/PROPOSAL_ID/reject \
-H 'x-mergen-secret: your-secret'
Note: Auto-corpus proposals only ever generate
HOLDrules — neverBLOCKrules. A human must explicitly write aBLOCKrule to create an unconditional block. This is enforced by three independent guards in the proposal pipeline.
The corpus as a competitive moat
After six months of use, your override corpus encodes:
- Your Friday settlement windows (never execute during these windows)
- Your compliance holds (PCI scope services — always require two approvals)
- Your hard stop patterns (never scale auth-api to zero without a change ticket)
- Your environment-specific rules (staging = PASS, production = HOLD)
This corpus is impossible to replicate from a standing start. It is the institutional memory of every time your engineers trusted or distrusted an AI action. A competitor product or a fresh install starts from zero — your corpus starts from your team's history.
Override corpus vs. policy rules
| Override Corpus | Policy Rules | |
|---|---|---|
| Created by | Human decisions during incidents | Engineers writing JSON rules |
| Enforces | Routing (PASS → HOLD) only | PASS, HOLD, or BLOCK |
| Promoted to policy | Via POST /policies/proposals/:id/approve |
Written directly |
| Persistence | SQLite (~/.mergen/overrides.db) |
~/.mergen/enterprise-policy.json |
| Inspectable | GET /override-corpus |
GET /policies |
| Tamper evidence | No (corpus is an advisory signal) | Yes (HMAC-signed policy file) |
Backfill from GitHub PR history
# Pull override decisions from merged PRs containing "mergen-override" label
mergen-server backfill github --label mergen-override
# Pull from a specific repo
mergen-server backfill github --repo your-org/your-repo --since 2024-01-01
Requires GITHUB_TOKEN.
Related docs
- HITL_SETUP.md — How to set up the Slack HITL approval workflow
- AARM_CONFORMANCE.md — How the override corpus maps to AARM R4 (DEFER decision type) and R7 (historical decision memory)