FeatureApprovals
A protected path is not a warning. It is a wall.
An AI coding approval gate is only worth having if it holds. A declared off-limits file that changes forces a block that green tests, an approval and a passing pre-run check cannot clear. And an approval is bound to the run it was given for, so it does not quietly follow the branch forward.
Last updated:
Protected paths
A path you kept off limits is not a warning
Most tools treat a scope violation as a note in a report. Here it is the one condition with no dial on it.
run-record.txt
Example – illustrative record, not real run datarun 4f2a verdict BLOCKED checks pytest -q exit 0 (executed by Reality Graph) approval granted by operator at 14:22 blocked forbidden_files matched: src/payments/gateway.py note approval and green checks do not clear this condition
Reality Graph itself does not write your source, stage your index, commit or push. Validation runs as an argv list from an allowlist, never through a shell. That is a statement about Reality Graph: the coding agent working beside it does edit files, which is precisely why the boundary is checked afterwards.
Staleness
An approval is recorded against one run, not stored as a permission
The failure this prevents is quiet: a decision made on Tuesday still counting on Thursday, after the branch, the scope and the checks have all moved.
| What moved | What the approval was bound to | Effect |
|---|---|---|
| New commits | The HEAD the decision was made against. | Stale. The code you approved is not the code in front of you now. |
| The declared scope | The allowed and forbidden paths at approval time. | Stale. The boundary the decision assumed no longer holds. |
| The validation set | The fingerprint of the checks that were going to run. | Stale. The evidence the decision rested on is a different set. |
| Nothing | The same run, HEAD, scope and checks. | The approval stands and is recorded beside the run. |
Approval modes sit on top of this: one mode per project, balanced, review or strict, with a fixed set of high-risk action classes that always require a human decision regardless of mode. That set is derived from structured evidence rather than from prompt wording. It is consulted at a small number of call sites today and is not yet wired into the governed run.
By design
A warning, a gate and a sandbox are three different promises
Reality Graph makes the middle one and makes it completely. Pretending to make all three is how a control layer becomes decoration.
What you get
- Force a block when a declared off-limits file changed, whatever else the run produced.
- Bind an approval to the run, HEAD, scope and validation fingerprint it was given for, and mark it stale when any of those move.
- Keep one approval mode per project, with high-risk action classes that always require a human decision.
- Leave your working tree alone: no writes to your source, no staging, no commit, no push.
What it is not
- Prevent a write. There is no interception and no revert; the change is found afterwards in the repository.
- Prove who approved. It is a local attestation, with no accounts, no identity and no signature.
- Share anything. Approvals are local to one operator and one machine; nobody else can see or countersign them.
- Govern every path yet. Guarded approvals are consulted at a small number of call sites and are not wired into the governed run.
- Replace your CI or your branch protection. Reality Graph installs no Git hooks and calls no GitHub API.
How a block reaches the final outcome is covered on the verdict page, and the file that declares the off-limits paths is the mission contract.
Questions people actually ask
- What exactly happens when a protected path changes?
- The run is blocked. Green tests do not clear it, an operator approval does not clear it, and a passing pre-run check does not clear it. There is no severity dial on this one, which is the point of declaring a path off limits in the first place.
- Does Reality Graph stop an agent from writing to a protected path?
- No. It does not sit between your coding agent and the filesystem, so the write happens and Reality Graph finds it afterwards in the repository. Preventing is a sandbox's job; detecting is this one's, and conflating the two would be the more comfortable lie.
- Does an approval expire?
- Not on a timer. It is bound to four things at once: the run, HEAD, the declared scope and the validation fingerprint. When any of them moves, the approval is marked stale, so a decision cannot quietly follow a branch forward.
- Is an approval proof that a person decided?
- No, and this is worth being blunt about. It is a local attestation, not an identity or a signature. Reality Graph has no accounts and no way to verify a human, so what you get is a record of a decision, not proof of who made it.
Name the three files you never want touched
Put them in the contract, then find out afterwards whether they stayed untouched. That is the whole gate.
Keep going
Step 6 of 9