FeatureTrust Review
One verdict per run. Computed once, by one function.
Last updated:
The outcomes
Three answers, no score
| Outcome | What it means | What you do next |
|---|---|---|
| Verified | The declared checks ran, the evidence is complete, and nothing forced a block. | Review the change on its merits. The mechanical questions are answered. |
| Verified with limitations | The run holds, but something is qualified: an attested rather than executed result, an inferred mission, an incomplete index. | Read the qualifier. It names the part of the picture that is weaker than the rest. |
| Blocked | A blocking condition fired: a protected path changed, a required result is missing, evidence capture failed. | Fix the cause. A green test suite does not clear it, and neither does an approval. |
The hard case
Green tests, and the run is blocked anyway
run-4f2a.verdict.txt
Example – illustrative, not real run dataverdict BLOCKED checks pytest -q -> exit 0 (executed by Reality Graph) reason protected path changed: alembic/versions/0031_add_index.py evidence changed files read from Git (7 files, 412 lines) note a passing suite does not clear a protected-path change
The evidence behind that line comes from Git, not from prose: the changed files and diffs are read by Reality Graph itself. Git is therefore required, and capture fails closed above 500 KB of scrubbed diff rather than reporting a partial picture.
Detection happens after the fact. Reality Graph finds the change in the repository; it never intercepts a write and never reverts anything. What it does with a protected path is covered on the approvals page.
For whoever asks later
One verdict is useful. Two hundred of them is an answer.
Every run and its review persist locally and resolve by exact ID, so the run from six weeks ago opens as readily as this morning’s. That turns three questions from archaeology into a lookup: how often do we ship blocked, which protected paths keep getting touched, and did the checks actually run the week we were under pressure.
The whole history is browsable in the local dashboard, which renders the same canonical projection the CLI prints, so the board a reviewer reads and the terminal an engineer read cannot disagree. Export is one command, in plain JSON or Markdown, scrubbed of home paths and secret-shaped strings first.
Afterwards
What is left on your disk once the run closes
What you keep
- Runs and reviews in a local store that survives restarts, readable from the CLI and the local dashboard.
- A validation receipt per check, each carrying a content digest that flags a later edit on disk.
- Every record as plain local JSON or Markdown, exported on demand and scrubbed of home paths and secret-shaped strings.
- An optional hash-chained log that detects edits, reordering, dropped and duplicated entries, and verifies offline.
What it is not
- A certificate. The verdict is a signal for your team, and it does not prove the code is correct.
- Signed or notarised evidence. Digests catch careless edits, not a determined local attacker.
- Shared history. It is a plain local file: no server, no retention policy, nothing synchronised between people or machines.
- A scheduled export. Export is one explicit command at a time, with no shared destination.
- Automatic audit logging. The chained log is opt-in, and every append is explicit.
Questions people actually ask
- Why three outcomes and no score?
- A number starts an argument about where the threshold sits. A named outcome forces a decision about the run in front of you. The resolver is one pure function with one call site in the whole product, so the same run cannot produce a different answer in the CLI than in the dashboard.
- Can a run be blocked with a completely green test suite?
- Yes, and that case is covered by a test that runs a real passing suite while mutating a protected file, then asserts the verdict is blocked. Blocking conditions are evaluated separately from check results, which is exactly why green tests cannot clear one.
- Can I override a blocked verdict?
- You can decide whatever you like about your own repository; Reality Graph blocks nothing and reverts nothing. What you cannot do is make the record say something else. The verdict and the reason for it stay in the run history, and your decision is recorded beside them.
- Are the validation receipts signed?
- No. Each receipt carries a content digest, so a receipt edited on disk afterwards is flagged rather than silently accepted. That detects careless edits, not a determined local attacker, and the receipts are neither signed nor notarised.
End a run with something you can point at
One outcome, the evidence behind it, and a record that is still readable when someone asks about it in six weeks.