Capability Index

The comparative report says what each system does. This page answers the other question — which systems actually have X — for the seven mechanisms whose absence causes a failure the system cannot detect.

Marks come from each report's frontmatter, so this table cannot disagree with what a report declares. It cannot independently confirm what a report declares: the frontmatter is the reviewer's assertion, and while a growing share of marks carry an evidence record naming the file and symbol they rest on, the rest are checked for shape rather than re-derived from the tree. A tick means the mechanism was found in code at that report's pinned commit; a dash means it was not found, which is different from impossible, planned, or badly built. The definitions, the evidence threshold, and why these seven rather than others are on the atlas rubric.

Read the of 7 column as a shape, not a score. Around half of the systems here carry none or one — the exact share is computed per report and printed in the strip at the top of each one — so a low number is the ordinary case rather than a poor one, and most of these columns are outside what most of these systems set out to do. A local coding agent that never claimed to arbitrate truth is not failing by carrying one mark. The column is worth sorting on only when you already know which mechanism you need.

Filters combine with and — "tombstone and scope enforced" is the question worth asking, and it is the one a per-column view cannot answer.

Which one you need depends on where your memory breaks, and the seven do not intervene at the same place. Three of them guard the write, two describe what the store is able to say, one guards the read, and one is the test that keeps the other six honest. Read as a row of seven equal boxes they look like a scorecard; read against the path a memory takes they are seven different answers to seven different questions:

%% caption: where each of the seven marks sits on the write, store and read path — three guard what enters, two what the store can say about it, and two what comes back
flowchart TD
    EV["Evidence<br/>messages, files, tool output"] --> WR{"Write path"}
    WR --> ST[("Store")]
    ST --> RD{"Read path"}
    RD --> CX["Context<br/>what the model sees this turn"]
    CX -.->|"that is wrong, forget it"| CO["Correction"]
    CO --> WR

    T["Rejected-value tombstone<br/>refuses the value, not the row"] -.-> WR
    H["Human review surface<br/>a person adjudicates, not just views"] -.-> WR
    A["Append-only mutation audit<br/>what changed, in the system's own store"] -.-> WR
    TS["Explicit trust state<br/>may this be acted on"] -.-> ST
    BT["Bi-temporal validity<br/>true-when, apart from recorded-when"] -.-> ST
    SC["Scope enforced in retrieval<br/>the filter that is actually applied"] -.-> RD
    NE["Negative retrieval assertion<br/>a committed test that this must not come back"] -.-> RD

The loop is the part worth staring at. A correction re-enters through the same write path that created the belief, which is why a mark on the write side is worth more than it looks: it is the only place that sees both the original claim and the attempt to reassert it after you thought it was gone.