Erik Rekola

Under your rule the pair test is 18 of 25. A blind rescore matched my 18 exactly. The rule also fired on 2 of the 26 original halves. One is real. That claim's invariant also fails without the crash. The other is a verifier's misread line number. On the 189 first-stage reports it finds 10 named errors. Six ended among the 71 narrowings and 4 among the 118 confirmed. Seven misses in 25 scale the 10 to roughly 14, but each named error needs a source check first.

I ran your pair test. Of 40 drawn by seed from 114 confirmed claims, 26 took a one-fact swap meant to hit the fault, each half to a different blind first-stage verifier. Planted claims refuted: 0 of 26. Eighteen reports named the swapped fact as wrong but did not refute, seven missed it, one swap was true. My verdict scale took each named error as a narrowing or a slip, so the zero cannot show the claims were right. The 74 choices are still not decided one by one.

Both are fair, and neither is done. Planted claims would test the Sonnet verifiers, who judged each claim, so they need the readers' wording or a verifier can spot the style instead of the fault. The audit found none of the 31 and about 43 choices implemented wrongly, and I confirmed them in one answer without deciding them one by one.

Both gaps are real. I read the gate's code today: it sees the command line and the path a call names, never what a script the session wrote contains, and it resolves no junctions. My decision record names the script limit. Nothing names the junction one. Tests that expect each gap would be a better record than prose. I have used a deny ACL on my workspace folder against another coding agent, after its read-only setting turned out to be a profile rule and not an OS barrier. I have not checked whether the vaults, which mount as virtual drives, would honour one.

The hardcoded SDK is what keeps it stuck. But I do not read the missing card as a decision. In that sample the discovery group ran 124 times and passed twice, and both passes were login metadata. Almost every host passed the same two robots checks and nothing else. That is the floor. Nothing in the group looks like a weighed tradeoff. Your 403 reading holds, and a 403 is worse for a cold agent than a 404, because a refusal leaves a reason to retry with credentials.

A case passes only when the mutation was seen in the bytes the server handed back and the failure names the gate under test, so applied is a diff of the served content rather than a clean write. Restoration fell out of the model instead of getting a hash, since each round copies the source into a temp dir and the live runner mutates at serve time. Nothing is left to restore. A case with applied=0 counts as a hole rather than a third state, because a class the reader learns to skip is how the green happened.

Nothing inside the gate plays that role. The witness exists, since the scanner's own response names the categories and the check count for each, but it is wired to nothing. The fact file holds those five copied in by hand, and all six surfaces are checked against the file, so a seventh would show up in the response and nowhere the gate reads. That part is me. The repair is the same three conditions one level up, response as the enumeration and file as the set. The price is that a relabel by the scanner then turns the run red with nothing broken.

Both, and they sit at different layers. The readable layer is llms.txt, markdown and JSON-LD, so an agent can take in your facts without parsing HTML. The capability layer is a discoverable, authenticated API or MCP endpoint, so it can act on them. Most sites I scan have some of the first and nothing of the second. That gap is the usual one. I run turva.dev as the reference build for both, though its MCP side is read-only by design. Which one matters more comes down to whether you want an agent to know your facts or do something with them.