Skip to content
This repository was archived by the owner on Aug 12, 2026. It is now read-only.

feat: a gate that asks whether the documentation tells the truth about the tree (audit claim F-06/F-07) - #21

Merged
sinkog merged 1 commit into
develfrom
feat/status-claims-gate
Aug 9, 2026
Merged

feat: a gate that asks whether the documentation tells the truth about the tree (audit claim F-06/F-07)#21
sinkog merged 1 commit into
develfrom
feat/status-claims-gate

Conversation

@sinkog

@sinkog sinkog commented Aug 9, 2026

Copy link
Copy Markdown
Member

Nothing asked that until an external audit did — and what it found was worse than stale numbers.

document said tree
SPEC.md (the declared authority) "normative, one implementation" two
SPEC.md "executed by one implementation" both
conformance/README.md "No implementation exists … Nothing here has passed" both run the whole corpus
docs/spec-vector-map.md Rust "does not exist yet"; agreement "still an untested claim" byte-identical on every vector
Makefile "mk/rust.mk is NOT present" included four lines below
README.md 44 invariants 46
docs/en/architecture.md 34 invariants, 27 vectors 46, 37

None of that was carelessness in the ordinary sense. Every one of those sentences was true when written, and nothing connected it to what it described.

A count copied into prose is a claim with no owner: it does not fail when it stops being true, it just stops being true.

The gate

Measures the tree — invariants from the §12 register, vectors from the corpus, implementations from has sources and has a conformance runner (a directory with a .gitkeep is not an implementation) — and compares it to what documents say.

Two kinds of check, because there are two ways a status claim goes wrong:

  • numbers — derived and compared
  • situations"one implementation", "never executed" — which cannot be derived, so they are listed and refused when the measurement contradicts them

Verified it can fail: 46 → 44 in README fails; two implementations → one implementation in SPEC fails; adding one vector directory fails two claims at once.

Two limits, printed in the tool's own output

It checks the claims listed in it and nothing else. Prose in a file it does not know about drifts silently — exactly as all of the above did. The lists are explicit rather than clever for that reason: every entry is a claim someone decided was worth binding.

The phrases are deliberately long. "one implementation" also matched "without the corpus and the other implementation noticing" and a sentence about why 0.1's bootstrap rule deadlocked — both correct prose. A check that fires on legitimate text gets switched off, and then it checks nothing.

docs/hu/architecture.md is registered for no count at all, because it states none. A document that makes no numeric claim has nothing to go stale — the cheapest fix available for this whole class.


make ci passes; status-claims runs in ci.gates. 10 of 37 audit findings closed.

…t the tree (audit claim F-06/F-07)

Nothing asked that until an external audit did, and what it found was worse than
stale numbers.

SPEC.md — the declared authority — said "normative, one implementation" and
"executed by one implementation". conformance/README.md said "No implementation
exists in this repository yet. Nothing here has passed — it has been authored."
Both were in the same commit as a second implementation that runs the whole
corpus and produces byte-identical output. docs/spec-vector-map.md said Rust
"does not exist yet" and that agreement between implementations was "still an
untested claim". The Makefile said mk/rust.mk is NOT present, four lines below
including it.

Counts: README said 44 invariants against 46, docs/en/architecture.md said 34
invariants and 27 vectors against 46 and 37.

None of that was carelessness in the ordinary sense. Every one of those
sentences was TRUE WHEN WRITTEN, and nothing connected it to what it described.
A count copied into prose is a claim with no owner: it does not fail when it
stops being true, it just stops being true.

So the gate measures the tree — invariants from the §12 register, vectors from
the corpus, implementations from "has sources AND has a conformance runner",
because a directory with a .gitkeep is not an implementation — and compares it
to what documents say. Two kinds of check, because there are two ways a status
claim goes wrong: numbers, which are derived and compared; and situations
("one implementation", "never executed"), which cannot be derived, so they are
listed and refused when the measurement contradicts them.

Verified it can fail: 46 -> 44 in README fails, "two implementations" ->
"one implementation" in SPEC fails, and adding one vector directory fails two
claims at once.

TWO LIMITS, both stated in the tool's own output rather than left to be
discovered.

It checks the claims listed in it and nothing else. Prose in a file it does not
know about drifts silently, exactly as all of the above did. The lists are
explicit rather than clever for that reason: every entry is a claim someone
decided was worth binding.

And the phrases are deliberately long. "one implementation" also matched
"without the corpus and the other implementation noticing" and a sentence about
why 0.1's bootstrap rule deadlocked — both correct prose. A check that fires on
legitimate text gets switched off, and then it checks nothing.

docs/hu/architecture.md is registered for no count at all, because it states
none. A document that makes no numeric claim has nothing to go stale, which is
the cheapest fix available for this whole class.

make ci passes; status-claims runs in ci.gates.

---
[signing-metadata]
key = cic-my-sign-key
signature = vault:v1:MEQCICAbj/Ry1VJTnSIc+dyuPkRLKafhlNMxN1Y6TuCPNtaUAiAwGVRlCMZvqwOI1CUWUmnIh1P9JlrzJ2jT1NStFGg8Hg==
hash-algorithm = sha256
digest = 5WQMRx0jTrHcZdQITxbMYn0YX8TRJ/fNPHkTo8RVsvU=

[certificate]
-----BEGIN CERTIFICATE-----
MIICBjCCAaygAwIBAgIUSnRMR6RPnEbg296XWPOqq/u5PCwwCgYIKoZIzj0EAwIw
QzELMAkGA1UEBhMCSFUxGTAXBgNVBAoMEENlbnRyYWxJbmZyYUNvcmUxGTAXBgNV
BAMMEENJQyBEZXZlbG9wZXIgQ0EwHhcNMjYwMzIwMTMyMjU5WhcNMjYxMjMxMTMy
MjU5WjBFMQswCQYDVQQGEwJIVTEZMBcGA1UECgwQQ2VudHJhbEluZnJhQ29yZTEb
MBkGA1UEAwwSR2Fib3IgWm9sdGFuIFNpbmtvMFkwEwYHKoZIzj0CAQYIKoZIzj0D
AQcDQgAEIG2CVmTfmLB9pLLclj7YmP2eedAjklpy4LGrU2ijoiy6Xqpuybv7OgJe
i+ez31s65NEV8+X/ByeX1cstR988z6N8MHowCQYDVR0TBAIwADAdBgNVHQ4EFgQU
yZN6AIX/TNnIJ9GwAa/NRN3ujHAwHwYDVR0jBBgwFoAUXn6CHYzPUqU4JVP8g+OS
WeDYjhcwDgYDVR0PAQH/BAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEF
BQcDBDAKBggqhkjOPQQDAgNIADBFAiEA+bFzXRoJ4PCQbhAAtpkcMjt0vNj5rEW0
lOMBGDNyaWkCIB1vmM7PcZzv/c9bIrxF5kqv6QXomouhByUfeNUTbpKW
-----END CERTIFICATE-----
@sinkog
sinkog merged commit 3a1a39d into devel Aug 9, 2026
2 checks passed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant