entity-core-keystone — Conformance & Status Matrix

The transparency contract for adopters. Before you pull a generated peer, check its row here. A peer being a spec-version behind, or lacking Ed448 agility, or carrying a known gap, is a documented, tracked state — not a surprise. "This peer doesn't do X yet" lives here, in the open, with a tier that tells you when it'll be caught up.

Cohort: 46 peers in the tree · 46 measured · all 46 at ONE pin — the 756-check set d30c3dd0… · 46 of the 46 at 0-FAIL (2026-09-01). Every number in §1 is a fresh measurement at that pin — nothing is carried forward. The pin is a content digest, not a commit — see The pin for the full anchor set and how to reproduce a number without access to our dev branch.

The Larger, INVALID MEASUREMENT and Not measured rows are gone because the peers in them are gone, not because the categories were retired. cobol was 30F; the asm/ISA trio were quarantined starved runs; apl was carried as unmeasurable. None of the three turned out to be what it was filed as — see the 2026-08-30 blocks below, §1a and §1d.

This table has now been wrong twice in the same shape. It was one pin behind between 2026-08-28 and 2026-08-29 — reading 0-FAIL (13) with 23 fixed peers filed under 3F, four lines below a headline that already said 39. It then read 45 of 45 · 1 unmeasurable for one day while the 46th was measurable and had simply not been run. The per-peer rows in §1 were correct throughout; the summary above them was not, both times. A summary table is a second copy of a number and rots on its own schedule — and the second occurrence landed in the very commit that wrote the first one down.

The headline is one sentence: every peer in the cohort passes --profile core at 0-FAIL — 46 of 46, with no exclusions and no unmeasured row. --profile core gained three capability checks at the 2026-08-21 re-pin and every unfixed peer failed exactly those three; that uniformity was the finding, and it held all the way through. The fix shape did not vary across thirty-seven languages — the same five places every time (capability mint, codec salvage decode, wire 400, read loop, policy lookup) — and that invariance is the evidence the spec reading is right, not merely that the tests pass.

What that sentence does NOT say, and the distinction is the whole point of this document. These 46 peers share a generation lineage and pass one author's vectors at one pinned check set: cohort-consistent, not independent convergence ([ADR-0012]). The three ISA peers are one design ported twice on top of that. And several of the defects closed on 2026-08-30 had been passing checks for months for reasons unrelated to what those checks test — a green row is evidence about the wire, not a proof about the peer.

One row carries a disclosed gap behind a 0-FAIL verdict, named here rather than left to be found. cobol executes 108 of the 755 checks as skips against the cohort's 106: two concurrency probes stage payloads (256 KiB, 16 KiB) that its 65535-byte frame cap and 8192-byte per-entity ceiling cannot accept, and it now refuses them with 413 rather than crashing.

The ISA trio's type-registry over-publication is CLOSED (2026-08-30). It was the second disclosed gap here, and for as long as it stood the three peers read 594-595P/53-55W against the cohort-standard 312P/337W. src/typestore.s is now filtered to the 53-name core floor, and the three rows read 312-313P/336-337W — the pass count FELL by 282 and that is the fix, not a regression. Those 282 type_system checks are matched-if-present, so publishing extension vocabularies had been converting WARNs into PASSes; the higher number was the scope violation. All three stayed 755 · 0F and the change touched nothing outside type_system (verified per-check, before against after, on each peer). asm-x86_64 reads one PASS above the other two for the unrelated reason in ⁹. Detail: ⁹ and §3.

A documented wire divergence sits behind these green rows, and it is named here rather than left to be found. §4.7's status table contradicts itself about an authenticate that arrives before any hello: row 6 says 401 invalid_nonce (restating §4.6 step 1, with the citation), row 10 says 400 connection_sequence_error. No check exercises that input, so no row below moves and the 46-of-46 stands exactly as measured — but a 0-FAIL verdict says nothing about a surface the suite never asks about, and it should not be read as if it did.

Measured on the wire 2026-08-30, 45 of 46 peers (csharp could not be built offline): 38 answer 401 invalid_nonce, 6 answer 400 connection_sequence_error, prolog answers 401 authentication_failed. The split is not 38 implementations endorsing one reading — asked the same authenticate after a hello, only those 6 give a different answer. The other 39 give the same answer either way, i.e. they never model the pre-hello case at all and reach row 6's status as a by-product of the nonce check. Cohort weight is much weaker than 38–6 makes it look, and an argument from it should carry that caveat. Raised by entity-core-formalization; the normative question is architecture's. Full census, method, and the three probe defects the controls caught: prehello-authenticate-wire-census.md.

And one gap is cohort-wide rather than per-row: r3_connection_flood WARNs on 42 of 46 peers — only asm-x86_64, asm-arm64, riscv64 and pd self-bound admission — because §4.10(c)'s connection-admission cap is a SHOULD that most peers delegate to the supervisor. It never gates. It is named here because until 2026-08-30 it was disclosed only as something two ISA peers owed a third, which had it exactly backwards (§3). (It was 44 WARN / 2 PASS earlier that day; asm-arm64 and riscv64 received the port and moved to PASS, which is why all three ISA rows now read 313P/336W.)

Three peers in the count were never broken. rust-wasm, rust-wasm-wasmtime and node-red were reported at 3F against build artifacts older than the sibling source they compile — they had inherited their parents' 2026-08-22 fix and nothing had re-measured them (§3). (Pre-2026-08-28 this paragraph read "32 peers remain unfixed … 25 of those 29 fail nothing but those checks"; correct when written, closed by the propagation pass.)

Reading a row. Each --profile core cell is total · NF — P/W/F/S, measured at the oracle's default 10-minute global -timeout. The NF figure is the gate; the total is extension-inflated and non-gating (it moves between oracle builds without any verdict changing). A skip counts as a failure unless it is an explicit --profile core extension carve-out. Per [ADR-0012] these peers are cohort-consistent, not independent convergence — they share a generation lineage and, for the FFI-hybrid peers, one codec .so; a cohort of generated peers all passing one author's vectors is not 40 independent confirmations.

The pin — content-anchored, and why there is no commit here

Every number in this document is anchored by a digest of the oracle's own content. None is anchored by a commit hash, and that is deliberate — [ADR-0012] Amendment 1 (2026-08-23): "a published conformance number is anchored by a CONTENT DIGEST of the oracle's check set … a commit SHA is a non-normative convenience and, where given, MUST be reachable from the published branch."

Full values, provenance, and the movement history of each: tools/oracle-pin.env.

Why not a commit. [ADR-0027] authors every published commit fresh at the release boundary, so public master is a different history from dev — not a rewrite, just two lines that were never the same line. A dev SHA has therefore never resolved for a public reader and never will. Measured 2026-08-23: entity-core-go's public master HEAD is cc1970f (the v0.8.0 release) and its dev is 514 commits past it, so the oracle this cohort was measured on exists on no public branch under any name. There is no publicly-resolvable commit to cite that would not also be a different oracle from the one that produced these numbers.

This is not hypothetical and it is not new. The figures in this file's historical note blocks include 665·0F @ e8524ed — and e8524ed stopped resolving anywhere on 2026-07-10 when go's mirror rewrote history. What carried the verdict across that death was the fingerprint, already recorded beside the dead commit in tools/oracle-pin.env:

retired_ref_4 = e8524ed (unreproducible after mirror history rewrite; same fingerprint)

The commit died; the content anchor did not. Publishing the anchor rather than the commit is that lesson applied ahead of the next occurrence instead of after it.

Reproducing a number with no access to our dev. Clone entity-core-go at whatever ref carries the same oracle content — after the release that is a commit on public master with a hash we have never seen and do not need to know. Run tools/oracle-bootstrap.sh: it prints core_gate_fingerprint and check_set_digest for whatever it built and requires both to match tools/oracle-pin.env before it will call the oracle current. If both match, it is the same gate — then run the cohort and compare each report's core_executed_check_set_digest (tools/check-set-gate.py). Identity by content was always the mechanism the tooling used; until 2026-08-23 only the documentation still led with the SHA.

Honest limit, stated rather than implied. Until entity-core-go publishes a master carrying this oracle, an outside reader can verify an oracle they have but cannot obtain the one these numbers were produced on. That is go's release to make, not something a digest fixes, and it is disclosed here rather than papered over. Where a dev commit still appears below — in the dated build-log note blocks and the closed-items ledger — it is internal provenance for us, not a citation for the reader, and those figures are already marked historical.

Spec surface: Entity Core v0.8.2 is the pinned snapshot (protocol-generator/shared/spec-data/v0.8.2/, SHA-256-pinned per file in that snapshot’s MANIFEST.md) — but no peer has been regenerated against it yet. Every peer below was generated against v0.8.0 and measured at the 755-check pin 95edd774… (all 46 of them; there is no unmeasured row). That gap is deliberate and tracked: the oracle is what gates the wire, and a snapshot reaching a peer is a regeneration question with its own cadence. (A prior revision of this paragraph named a consequence that does not survive checking: it said pd still carries F37's pre-rename system/identity/peer-id in 3 files. Re-measured 2026-08-30: it is 2 files with one live code site — src/ecodec/ecodec.c:2399, plus comments and its own ambiguity log — and it is not pre-rename debt. pd registers the type under BOTH names deliberately, because ENTITY-NATIVE-TYPE-SYSTEM.md v0.8.0 itself names it two ways and both are live type_refs in one spec version; the peer's A-PD-012 says so and escalates it as F33, awaiting arch's choice of canonical name. Registering both is the more spec-complete reading, not a gap. pd is tier M3 and 0-FAIL.) Standard extensions are out of scope — every peer below is a core peer. The core wire contract is byte-unchanged across the V7→V8 cutover (see that dir's MANIFEST.md). The oracle's core category set + type floor (cmd/internal/validate/profile.go) is what gates --profile core; its committed anchors — core_gate_fingerprint and check_set_digest — are in tools/oracle-pin.env. Both must match for a verdict to carry forward: the fingerprint alone tracks which categories run, never what they assert (established at the af8a582 cutover, where four hard-FAIL vectors landed inside existing core categories under a byte-identical fingerprint).

Conformance gate: validate-peer --profile core — the extension-free categories (connectivity, encoding, type_system, origination, resource_bounds, concurrency, + the §10.1 register / §7a conformance-handler gates).

Where §1's numbers come from, and what is not in the repo — read this before citing a cell. Every --profile core figure in §1 is generated from the centralized census, output/scratch/census/<peer>.json. output/ is gitignored, so those artifacts are not committed — the numbers are reproducible from the pin (tools/oracle-bootstrap.sh rebuilds the oracle at tools/oracle-pin.env's ref; tools/run-cohort-census.sh re-runs the cohort), not archived in the tree.

The committed per-peer records now agree with §1 for every peer we publish. All 45 publishable peers' protocol-generator/<lang>/status/CONFORMANCE-REPORT.{md,json} are at the pinned 755-check set and each reproduced its §1 row exactly — 13 re-measured on 2026-08-22, 26 as the propagation reached them on 2026-08-28, and turbowarp on 2026-08-29 (measured twice, by two destinations of the same tool, agreeing byte-for-byte); make lint runs tools/check-set-gate.py --tracked, which fails if a peer published as 0-FAIL carries a committed report from an older check set. One peer's committed report is behind the pin — apl, at the retired 682-check set, because it cannot be measured at all (§3); the gate reports it without failing on it. (Through 2026-08-29 this read "the remaining 6": cobol and wasm-wat at 740, the asm/ISA trio at 682. All five were behind on the FIX, not the paperwork, and all five are now current.) (Until 2026-08-22 this was true of all 45, including the publishable ones: a clone showed each peer's own report contradicting its row here. §1 was never wrong; nothing gated those files.) §1 remains authoritative for the cohort; a peer's status/ report is that peer's own last measurement. Refresh one with tools/run-cohort-census.sh --to-status <peer> — it is a measurement, never a copy of the census JSON.

The previous header block — the accreted cc1970f-era cohort paragraph — is archived verbatim at docs/archive/CONFORMANCE-MATRIX-header-pre-de8f807.md. Do not cite figures from it.

✅ CURRENT (2026-08-21 · extended 2026-08-22) — re-pinned to the 755-check oracle + spec v0.8.2; M1 and M2 both fixed, re-pin LANDED

Read this before pulling any peer. It supersedes the 2026-08-17 banner below. Both anchors were re-pinned on 2026-08-21: the spec snapshot to v0.8.2 (SHA-256-pinned per file in its MANIFEST.md) and the oracle to the 755-check set 95edd774… (entity-core-go HEAD at the time; see The pin). Tier M1 was re-run, came back 0 of 5, was fixed, and is now 5/5 at 755 · 0F — 312P/337W/0F/106S — identical across all five. tools/tier-status.py --gate exits 0. The full 45-peer census then ran, so every row in §1 is a fresh measurement at that pin.

Extension, 2026-08-28 — the propagation is complete: 39 of 45 peers are publishable, up from 13. Tier M3 is 12/13 (only cobol), the probes are 13/18, and the six that remain are named in the headline above — none of them is the CAP feature. Two peers turned out to be carrying more than the CAP trio, and both were found the same way: fixing a wrong denial made the FAIL count go UP, and the new FAILs were the truth. sql went 2F → 7F → 0F (a §5.5a handlers over-scoping had been standing in for a missing chain-attenuation rung AND a missing §6.2 mint-bound); datalog the same shape via an entity:// URI-parsing defect. nim was the only peer that already HAD a §5.6 ceiling, and having a wrong one was worse than having none. All three lessons are ratcheted in AGENTS.md.

Extension, 2026-08-22 — tier M2 is now 8/8 and 13 of 45 peers are publishable. typescript (84F → 0F) and csharp (INVALID → 0F) turned out to be the same §6.3 defect in its two presentations (§1b/§1c), not two problems; rust python java kotlin elixir common-lisp then took the same CAP fix and all landed 0F. The fix shape did not change once across thirteen languages — ~200 lines over 5–6 files, the same five places — and that invariance is the evidence the spec reading is right, not just that the tests pass. Two lessons appeared only past the M1 sample and are ratcheted in AGENTS.md: CAP-6a's fail-open has two mechanisms (null-collapse, and an arithmetic fail-open involving no null at all — one grep does not catch both), and §6.3 is not optional even when a peer is already at 0F (rust, common-lisp were 0F while still scoring CAP-6a WARN).

What moved in the gate, attributed BY CATEGORY (never by commit message): 18 declared checks added between the two pins (8537d875… → 95edd774…); each resolved to its declaring file, that file's category constant read, and the constant tested against coreProfileCategories. 5 gate --profile core, all catCapability — CAP-5 request_mint_temporal_ceiling, CAP-6 request_ttl_zero_and_overflow, CAP-6a ingest_rejects_unrepresentable_expiry, CAP-2/3 configure_empty_grants_withdrawal, CAP-7 configure_rejects_base58_partial_prefix. The other 13 are extension-only. core_gate_fingerprint stayed byte-identical (8261a033…) for the fourth consecutive time in this shape.

These were never regressions — they are a spec feature nobody had implemented. §5.6's MIN_DEFINED temporal ceiling was absent in every peer: mintToken set no expires_at at all, so a request-minted ROOT token had no lifetime bound of any kind. No vector exercised it until this pin. §3 carried this as "Deferred — do not start" since 2026-08-17, correctly at the time (the normative text landed 44 minutes after that decision) — and the bill came due here.

Three defect classes came out of the M1 fix, each now ratcheted in AGENTS.md with an enforcement point:

1. §6.3's rejection is a STATUS, not silence. "Rejection returns 400 non_canonical_ecf" is the second half of the sentence and all five peers ignored it — dropping or closing on an undecodable frame instead of answering. On a peer that closes, one bad frame takes the connection: that is where lean's 81 cascade FAILs came from, and typescript's 81 (§1b).
2. CAP-6a failed OPEN in three peers. Uint/uint_field/uintField/uintAt all answer "nothing" for BOTH an absent field and a present non-uint one, so a capability with expires_at: -1 skipped the expiry check and was honored with 200. §6.2 CAP-6a names it: a verifier "MUST NOT treat the unrepresentable field as absent."
3. swift only: §5.5a's per-link granter frames scope the RESOURCE dimension ONLY. Applying them to all four dimensions is identical to correct whenever child and parent share a granter — every self-issued path — and makes a universal parent grant cover no child grant the moment a delegated cap arrives. 745 of 755 checks passed while every delegated cap returned 403.

The cohort result is one number repeated: 31 of the 40 unfixed peers fail nothing but the new CAP checks — 29 at exactly 3F with a byte-identical P/W/F/S, and 2 (sql, wasm-wat) at 2F because they already refuse CAP-6a correctly. This is one missing feature measured 40 times, not 40 defects. typescript additionally carries lean's §6.3 cascade (81 of its 84). cobol carries its standing 27. — As measured on 2026-08-21. After the M2 pass the counts are 32 unfixed / 25 CAP-only; typescript's cascade is fixed. See the 2026-08-22 extension above and §1's header line. The finding is unchanged; only the counts moved.

Four peers produced INVALID MEASUREMENTS — csharp (698/755), asm-x86_64/asm-arm64/riscv64 (714/755) — all with budget_exhausted categories. They are quarantined, not scored (§1a). csharp was new at this pin and is now ROOT-CAUSED (2026-08-22): it is defect class 1 above in its hang-form, not a separate problem — same three real FAILs at the same indices as typescript, but it drops the frame and holds the connection open instead of closing, so downstream checks time out rather than fail fast and the budget expires (§1c). Fixing §6.3 should restore a valid measurement and take it to 0F.

Publication is unchanged: "no green report → no publish." Today that means the five M1 peers, and only those.

Full session record, including the fix shape for each defect class and one recorded-not-hidden intermittent: .

⛔ SUPERSEDED (2026-08-17) — oracle re-pinned to de8f807; §6.2 register-reserved-pattern gate CLOSED cohort-wide

Read this before pulling any peer — it supersedes the 2026-07-28 banner below. tools/oracle-pin.env re-pinned fceb61f → de8f807 (2026-08-16; arch's — the vector set is final, no further arch-side vector work is queued). core_gate_fingerprint stayed byte-identical (same 16 core categories) but check_set_digest moved, which per standing policy re-triggered a full census regardless of the unchanged fingerprint — see tools/oracle-pin.env's de8f807 entry for the full accounting.

Finding, universal at first census (2026-08-16): core_register_reserved_refused / core_register_reserved_publishes_nothing FAILed on all 45 measured peers. ENTITY-CORE-PROTOCOL.md §6.2 (normative, pre-existing text — not a new rule) requires a handler register at a reserved system/* pattern to be refused with 403; no peer enforced it because the oracle's negative-half check for this rule didn't exist until Go's 2026-08-11 commit. Full finding + reference fix shape: (the original finding) and (the 31-peer first pass). (Note: the reference oracle's own citation for this rule, "V7 §6.6", is stale under the de-versioned v0.8.0 spec — the rule is actually at §6.2. Filed to arch as v7-section-citation-drift.md; every keystone peer fix below uses the corrected §6.2 citation, not the stale one.)

Closed 2026-08-17: 44 of 45 measured peers now enforce the guard, confirmed by a fresh centralized tools/run-cohort-census.sh run. apl remains unmeasurable (unchanged, upstream-blocked, excluded per standing policy). turbowarp — the exploratory, non-deployable, "delegates the whole §6.5 engine" probe (§1, never a real peer, never in scope for this fix) — still FAILs both checks, unchanged, out of scope by design.

Of the 44 fixed, 40 are fully --profile core 0-FAIL. The other 4 carry a separate, pre-existing FAIL — confirmed byte-identical by check name before/after in each fix's own commit, not touched or made worse by this pass: cobol (standing liveness-crash cascade, 27 FAILs) and asm-arm64/asm-x86_64/riscv64 (1 FAIL each, t2_2_connection_churn).

Correction (2026-08-17, later same day): the asm trio's "1 FAIL" was NOT the whole story, and the "peer-latency flake" label this banner previously used was wrong in kind. See §1a — that one FAIL consumed the entire global -timeout budget, which silently suppressed 7 whole categories including the core resource_bounds, hiding 2 further real core FAILs. Measured, not inferred.

Process finding worth reading if you're about to trust a census run right after a worktree-based fix: the first full census after all 45 fixes landed showed 3 false FAILs (rust-wasm, rust-wasm-wasmtime, node-red) — not a fix regression, but tools/run-cohort-census.sh's deliberate NOBUILD=1 / build-only-if-missing reuse of on-disk build artifacts silently testing stale, pre-session binaries left over in the primary tree, because the actual fixes were verified inside isolated git worktrees with their own separate gitignored build caches that a source-only git merge never touches. Root-caused via build-artifact mtime vs. fix-commit-time comparison (not assumed), fixed by forcing a rebuild in the primary tree, re-verified 0 FAIL on all three. Ratcheted in AGENTS.md.

Fixed peers (44): go python rust rust-wasm rust-wasm-wasmtime typescript · elixir prolog common-lisp lean unison datalog · crystal nim odin php forth rexx tcl · smalltalk oz io julia sql pd wasm-wat · dart ruby node-red · ada cobol fortran haskell ocaml swift · c cpp csharp java kotlin zig · asm-x86_64 asm-arm64 riscv64.

The per-peer rows in §1 are now refreshed against this pin (2026-08-17). Every --profile core cell below is a fresh de8f807 measurement carrying its own P/W/F/S, generated mechanically from the centralized census (output/scratch/census/, plus the post-rebuild re-verification for node-red/rust-wasm/rust-wasm-wasmtime). Two peers that had never had a row of their own — asm-arm64 and riscv64 — were added in the same pass.

⛔ SUPERSEDED (2026-07-28) — every 682·0F @ cc1970f verdict below is HISTORICAL

Read this before pulling any peer. The cohort has been re-measured three times since cc1970f: af8a582 (bucket-B: RT-6 hard-FAIL + the F40 exclude/include rows), fceb61f (arch's F40 control-row + RT-6 class-split response), then a same-day remediation pass fixing every peer the fceb61f measurement found non-compliant, every peer inside its own pinned containers/<toolchain>/ image under podman. Current result, post-remediation:

44 of 45 measured peers (turbowarp untouched this pass) · 40 pass --profile core · 4 FAIL · 1 not measurable (apl, unchanged). Passing (new, beyond the fceb61f 6): ada c common-lisp cpp crystal csharp dart datalog elixir forth fortran haskell io java julia kotlin lean node-red ocaml odin oz pd php prolog rexx ruby smalltalk sql swift tcl typescript unison wasm-wat zig, plus the unchanged go python rust rust-wasm rust-wasm-wasmtime nim. nim still carries a non-gating RT-6 WARN (401, wrong code); rust-wasm/rust-wasm-wasmtime are still thin transport seams over rust.

F40 (§5.2 typed scope matching): CLOSED cohort-wide. forth and smalltalk — the only 2 peers left with a real, attributable canonicalization defect — converted to the id-scope literal matcher (shared/scope-matching/), same shape as the other 34 peers. All three oracle vectors now PASS on both. scope_subset (§5.5a, F50) deliberately left unconverted in both, pending the still-open arch ruling. New, unrelated finding surfaced by both fix agents independently: neither peer's check_permission evaluates the peers grant dimension at all — not touched, needs its own investigation (session doc §5).

RT-6 (§4.6 nonce single-use): CLOSED cohort-wide — handshake_nonce_single_use now PASSES on every one of the 44 measured peers. 31 "wrong-status" peers fixed with the pinned-status mechanical fix (401 invalid_nonce, matching each peer's own existing idiom for that status); the 7 "replay-accepted" peers (the actual anti-replay security hole — a replayed authenticate was silently re-verified and re-accepted with 200) got a real missing established-state check added. The af8a582/fceb61f census's standing "status=0" mystery on csharp/node-red/typescript was NOT a decode-outcome ambiguity as suspected — it was an unsolicited §4.1 "leg 3" reverse- authenticate, independently implemented (and independently buggy) in all three, sent proactively to every accepted connection in violation of the spec's explicit MUST NOT for a client-style initiator. Root-caused live (not from a source read) and fixed in all three, plus a second, distinct connect-path routing bug found alongside it in the same three. A fourth bug — unrelated to RT-6/F40 — was found and fixed along the way: a Pd route-object outlet-shift wiring defect in pd's canvas that had silently starved its entire authz/dispatch stage. Full detail, including the batch-run-flakiness methodology note (isolate before trusting a mid-batch FAIL), in the session doc below.

Remaining 4 FAILs are pre-existing, unrelated to RT-6/F40 (confirmed via their own handshake_nonce_single_use now reading PASS): asm-arm64/asm-x86_64/riscv64 (the standing, already-documented t2_2_connection_churn peer-latency class) and cobol (the standing, already-documented liveness-crash class). Neither touched this pass.

The 682·0F @ cc1970f figures below are retained as a historical record of what that pin certified. They are not a claim about this tree. cc1970f/af8a582/fceb61f all share an identical core_gate_fingerprint — the fingerprint tracks which categories run, not what they assert, so "the verdict carries forward at the same fingerprint" is withdrawn (established at the af8a582 cutover). tools/oracle-pin.env carries a check_set_digest for exactly this reason.

Per-peer table, per-vector breakdown, the leg-3/Pd root-cause writeups, and the still-open punch list: (successor to protocol-generator/shared/findings/fceb61f-cohort-remeasurement.md, itself successor to protocol-generator/shared/findings/af8a582-cohort-remeasurement.md).

⛔ Superseded — "Reading the conformance numbers" (the cc1970f carry-forward note). This note asserted that every peer's gate verdict was certified at cc1970f and that the 665 totals carried forward unchanged. Both halves are withdrawn. The carry-forward argument rested on the core-gate fingerprint alone, which tracks which categories run and not what they assert — disproven at the af8a582 cutover, where four hard-FAIL vectors landed inside existing core categories under a byte-identical fingerprint. The cohort has since been re-measured at af8a582 → fceb61f → de8f807. Current numbers are the §1 table and footnote ²; the header's "Reading a row" replaces this note. Kept as a marker so a reader who remembers this paragraph learns it was retired, not moved.

Wire-conformance corpus — F29/F30 re-vendor (2026-07-12). The ECF codec corpus (the lower-bar wire-conformance axis, distinct from the validate-peer --profile core gate above) advanced 69 → 71 vectors: arch added F29's nested.5/nested.6 (array-of-maps ≥24/≥256-byte inner-text head boundary) and regenerated F30's tag_reject.1/2/3/5 (now canonical-except-the-mt6-tag, genuinely gating the §6.3 tag scanner). Vendored from entity-core-protocol @ be54baf as 9695b1f1… (supersedes 41d68d2d…), artifact decode-verified per the F16 lesson (71 vectors, all canonical bytes matched .diag, nested pins exact). Cohort codec re-run: 71/71 (0 FAIL) across all 27 codec peers (cobol: 70 pass / 1 documented C-ABI carve-out skip on content_hash.4; go independently tallied 66 encode_equal + 5 decode_reject). F29 + F30 CLOSED (SPEC-FINDINGS-LOG.md). This closes the alien-substrate discovery sweep (Tcl/Rexx/Fortran/Forth/Smalltalk/APL): F29/F30 were the last corpus asks it produced; the spec-discovery well is dry on the current wire surface — steady state is re-running this cohort against each amendment, not adding language #N. (F31 CLOSED the same day: 4 peers (elixir/csharp/cobol/typescript) had a peer-layer unit test fail while codec-green + S4-conformant. Bisected to two stale-test causes, both test-side — no handler/peer code was wrong: (A) the §7a dispatch-outbound reentry tests sent the value field as a bare scalar instead of the {value:X} echo-shape entity-data map the §7a.1 contract requires (per the Go oracle + the passing kotlin test); (B) cobol's dispatch skeleton test expected 404 for an unauthenticated unknown-handler EXECUTE, but §6.5 authenticates before resolving → correct status is 401. All four now green; details in SPEC-FINDINGS-LOG.md F31.)

1. Primary status table

How to read this section. The table is the live state, and as of the 2026-08-21 full census it spans one pin: every row is a fresh measurement on the 755-check set 95edd774…, with the M2 rows re-measured after their 2026-08-22 fixes. Nothing is carried forward from the retired 740-check pin. (This note previously described a two-pin split — 5 fresh M1 rows against 40 stale 740-check ones. That was accurate for the few hours between the M1 fix and the full census, and was left standing after the census closed it. Corrected 2026-08-22.) The dated > note blocks that follow are a build log — each records what a peer's arrival established at the pin current on that date, and the figures in them (682·0F @ cc1970f, 665 @ e8524ed, …) are historical, not claims about this tree. Where a note and the table disagree, the table wins. §1a covers the one case where a table row needs more than a number.

The commit hashes in those note blocks do not resolve, and several never will. They are entity-core-go dev SHAs, kept as our provenance trail; e8524ed in particular died in a 2026-07-10 mirror history rewrite and exists nowhere. Do not try to resolve one, and do not cite one — every live claim in this file is anchored by a content digest instead (The pin). The note blocks are left as written rather than back-edited, because a build log that gets rewritten stops being evidence of anything.

New peer — asm-x86_64 (2026-07-13, hand-written). The lowest-level substrate probe: a hand-authored x86-64 assembly peer (GAS/AT&T), not /entity-rosetta-generated — the ultimate "can the wire+authority interior be built in the barest language" stress test. Transport + the envelope/data-map CBOR + the entire dispatch/authority interior are hand-written asm; entity codec + Ed25519/SHA + peer-id are FFI via libentitycore_codec. Measured natively at cc1970f → 682·0F (Result: PASS, 583P/3W/0F/96S, deterministic), matching the reference entity-peer on every check it passes. Notable: it implements the full write-op surface (tree put/get/CAS/listing/delete, register/unregister, configure, revoke), genuine §5.5 K-of-N multisig accept, §6.2 dispatch-entity normalization, AND §7a.2a concurrent reentrant dispatch-outbound — the last via a single-threaded fork + request/response frame router + pending_tab demux (no threads/epoll; the reentry is one-socket, validator-as-B). The 3 WARNs are benign (r3_connection_flood matches the reference's WARN). Cohort counts reconciled at the 2026-07-14 branch merge — headline was 33 gate-green peers then (this row included; 40 now — see the top Cohort line). Per-peer detail: protocol-generator/asm-x86_64/status/. (Honesty: FFI-hybrid, oracle-pinned --profile core, cohort-pinned to one author's vectors — not full-profile, not independent convergence.)

L2 update (2026-07-15) — native canonical codec. The peer's canonical ECF codec is now hand-written x86-64 asm (src/codec.s): the shortest-float ladder, integer/length minimization, definite-length + recursive tag-reject, length-then-lex key sort, ec_content_hash, and peer-id format/parse (native base58 + LEB128) — only Ed25519 + SHA-256 remain FFI (the L2 boundary). Cross-checked differentially against the 3-way-locked corpus (make diff → 71 corpus + 4 synthetic, 0 FAIL) and integrated into the live peer: run-s4.sh --profile core → 682·0F (Result: PASS, 583P/3W/0F/96S) @ cc1970f, identical pass set to L1 — only the codec provider changed (FFI→native). Symbol-verified (nm bin/host): codec symbols T (ours), ec_sha256/ec_ed25519_* U (FFI). Parse accept-path (oracle-invisible) covered by make parse-test (11·0F). Detail: status/PHASE-L2.md. The asm probe's discovery arc is complete at L2 — L3 (hand-written asm crypto) is deferred indefinitely (per-ISA, high-risk crypto boundary, ~zero discovery value; crypto stays linked-compiled — ISA-MAP point 5). The one remaining optional item — a RISC-V L1 port — is now DONE (2026-07-16, riscv64): a first-class-riscv64 distro (Debian trixie) sysroot under qemu-riscv64-static confirmed the earlier "block" was a Fedora-secondary-arch packaging gap, not a riscv problem. See its note below.

New peer — asm-arm64 (2026-07-15), the first ISA port. The x86-64 asm peer transliterated to aarch64 (GAS native ARM syntax) — the first port off the hand-written asm template, and the test of the ISA-MAP Axis-A thesis: with the codec/crypto/peer-id behind the FFI, is the protocol interior a mechanical register/syscall swap? Answer: yes, end-to-end. All 75 dispatch functions + the 4 shell modules ported by the codified register/ABI/syscall map (rdi..r9→x0..x5, cursor r15→x24, svc #0, bswap→rev, logical-immediate workaround, push/pop→stp/ldp frames) with zero protocol-logic change. Runs under qemu-aarch64-static; the native Go oracle runs beside it. Codec .so cross-built for aarch64 (FFI×ISA cost: cross-libsodium via --forcearch). Measured --profile core at cc1970f → 682·0F (Result: PASS, 583P/3W/0F/96S) — byte-identical to the x86-64 sibling's verdict, same 3 benign WARNs; §7a validate_echo_dispatch + concurrency 5/5 + §5.5 multisig accept all pass. Substrate findings: fork→clone(SIGCHLD) (no fork in the aarch64 generic table; A-ARM64-001), cross-sysroot shape (A-ARM64-002), and one porting-discipline bug — per-function store-helper length-register ABI (A-ARM64-003). Per-peer detail: protocol-generator/asm-arm64/status/. (Honesty: corroboration, not independent convergence — shares the x86-64 peer's generation lineage + FFIs the same codec; the real signal is the substrate mechanics. FFI-hybrid, oracle-pinned --profile core, cohort-pinned.)

New peer — riscv64 (2026-07-16), the third ISA (second port). The asm peer transliterated to riscv64 (GAS, RV64GC) — ported off asm-arm64, NOT x86-64, because aarch64 and riscv64 share the kernel's generic syscall table (so arm64 pre-adapted every generic-table quirk). All 75 dispatch functions + the 4 shell modules ported by the codified aarch64→riscv64 map (x0-x5→a0-a5, cursor x24→s6, svc→ecall nr-in-a7, rev→hand-rolled bswap*, flag-less fused compare-branches, stp/ldp→addi sp+sd/ld) with zero protocol-logic change — the dispatch port ran as a 9-way parallel fan-out along function boundaries. Runs under qemu-riscv64-static; the native Go oracle runs beside it. Codec .so cross-built for riscv64 against a Debian trixie riscv64 sysroot (the FFI×ISA cost — riscv64 is a Fedora secondary arch with no forcearch path, so glibc+libsodium come from Debian's first-class riscv64 port, assembled from .debs with no foreign-arch execution / no host binfmt; A-RISCV-002, retiring the "BLOCKED" finding). Measured --profile core at cc1970f → 682·0F (Result: PASS, 583P/3W/0F/96S) — byte-identical to the x86-64/arm64 siblings, same 3 benign WARNs; §7a validate_echo_dispatch

• concurrency 5/5 + §5.5 multisig 11/11 accept all pass. Landed 0-FAIL on the first full run — the A-ARM64-003 inter-function seam bug did NOT recur, because the arm64→riscv64 map is a clean bijection (no register-pressure divergence; A-RISCV-004). Other findings: hand-rolled byte-swap (no base-ISA rev8; A-RISCV-001), Debian libsodium 1.0.18 vs fedora 1.0.22 (A-RISCV-003). Per-peer detail: protocol-generator/riscv64/status/. (Honesty: corroboration, not independent convergence — shares the x86-64/arm64 generation lineage + FFIs the same codec. FFI-hybrid, oracle-pinned --profile core, cohort-pinned.)

New peer — wasm-wat (2026-07-15), the interpreted-substrate probe. The peer is hand-authored WebAssembly text (host.wat transport + poll loop, wire.wat/dispatch.wat envelope + §5.2 + handlers); the Rust codec is compiled to wasm32-wasip1 and wasm-merged as the seam (canonical CBOR + Ed25519/SHA). Measured under WasmEdge 0.17 → 682·0F (Result: PASS, 291P/294W/ 0F/97S @ cc1970f), full §7a --validate parity, no -allow-skip — including the reentrant dispatch-outbound dialer (t1_2 M=8 concurrent + validate_echo_dispatch), authored as a same-connection §6.11 reentry (outbound echo rides the inbound fd; a pending[echo_rid → dispatch_rid] table on one socket, no client dialer/threads). The crypto execution mode is load-bearing: WasmEdge's interpreter runs one Ed25519 verify at ~9 ms so §6.11 T2.1 times out; --enable-jit (~84 µs, 109×) is the working lever and part of this peer's conformance contract. AOT is inert on 0.17 (the wasmedge compile artifact runs without engaging its native code — t2_1 FAILs at 22.9 s, confirmed 2026-07-15). Multisig accept-path + --name keypair load deferred (local-env). Detail: protocol-generator/wasm-wat/status/; findings F33/F34/F35 + execution-mode analysis in protocol-generator/shared/findings/concurrency-latency-floor-and-cap-sig-coverage.md and protocol-generator/shared/findings/wasm-dialer-parity-F35-and-execution-mode.md. (Honesty: seam-hybrid, oracle-pinned --profile core, cohort-pinned to one author's vectors — not independent convergence.)

New peer — rust-wasm (2026-07-15), the COMPILED-wasm sibling of wasm-wat. The generated Rust peer's library (../rust) cross-compiled unmodified to wasm32-wasip1 (LLVM), behind a 336-line single-threaded poll_oneoff transport seam (src/main.rs) — the whole ~4,000-line interior (codec, §5 authz, §6 dispatch, §9.5 floor, ed25519-dalek + sha2) compiles with zero source changes; Peer::dispatch is byte-identical to native, the seam ports the same single-fd §7a reentry-demux as wasm-wat/asm. Measured under WasmEdge 0.17.1 --run-mode=jit → 682·0F (Result: PASS, 291P/294W/0F/97S @ cc1970f), full §7a --validate parity, no -allow-skip — byte-for-byte the same P/W/F/S as wasm-wat, same runtime. Same-runtime codegen head-to-head vs the hand-authored WAT peer: compiled Rust is −29% module size (242 KB vs 340 KB) and −28% JIT warmup, at a fraction of the authoring cost (reuse a whole peer + one host file); hand-authored WAT is ~1.8× faster per request (10k sustained-load) — the abstraction-tax vs hand-tuned-loop trade. The decisive control: the same Rust peer as native ELF vs wasm runs within ~1% — portable compute is nearly free; the per-substrate cost is the transport-ABI seam. Full analysis: protocol-generator/shared/evaluations/wasm-codegen-comparison.md; folded into SUBSTRATE-TAKEAWAYS §4. Two transport lessons bit as on wasm-wat: single-send framing (Nagle/delayed-ACK churn stall) + JIT crypto execution mode. Multisig accept-path + --name keypair deferred (local-env), as wasm-wat. (Honesty: shares the native Rust peer's generation lineage AND crypto crates — NOT independent convergence; the independent datapoints are the unmodified-interior-cross-compiles result + the codegen comparison.)

New peer — rust-wasm-wasmtime (2026-07-15), the wasmtime-AOT production sibling. The SAME rust-wasm wasm32-wasip1 module, run under wasmtime and precompiled to native Cranelift code (wasmtime compile → .cwasm, run --allow-precompiled) — the compile-once-run-native production story WasmEdge 0.17's inert AOT couldn't give. Deliberately wasip1 (not wasip2): wasmtime compile is WASI-version-agnostic, so this isolates ONE variable (runtime + exec-mode) against the WasmEdge column; wasip2 would add a second (a different socket ABI) and cost the no-rustup rule (fedora ships no wasip2 std) — a deferred forward-ABI probe. Interior byte-identical to rust-wasm; only the socket seam changed — WasmEdge self-bind (sock_open/bind/listen) → a host-preopened listener (-S tcplisten) + standard wasip1 sock_accept/poll_oneoff (the wasi crate); framing + §7a reentry pump port verbatim. Measured running the AOT .cwasm → 682·0F (Result: PASS, 291P/294W/0F/97S @ cc1970f), full §7a --validate parity, no -allow-skip — byte-for-byte the same P/W/F/S as rust-wasm/wasm-wat, §6.11 t2_1/t2_2 churn passing at native speed (the "experimental" -S tcplisten held). AOT warmup ~5.7 ms (native engages) vs WasmEdge JIT's ~3 s — but honestly the big win is WasmEdge→wasmtime (Cranelift JIT is already ~ms); AOT removes the residual per-boot compile AND yields a deploy-time native artifact. Sizes: .wasm 242 KB (portable) / .cwasm 904 KB (native, wasmtime-46.0.1-pinned — a deploy-time recompile artifact, not portable across wasmtime versions). wasmtime v46.0.1 is a checksum-pinned upstream release (not in fedora; S11). Full analysis: protocol-generator/shared/evaluations/wasm-codegen-comparison.md (third column); SUBSTRATE-TAKEAWAYS §4. (Honesty: shares rust-wasm's generation lineage + crypto crates — cohort-consistent, NOT independent convergence; the independent datapoint is the AOT-native-engages + warmup result.)

New peers — Crystal + Odin (2026-07-12, provisional). Two T3 corroboration / generator-robustness peers added this session, both native-codec (the LANDSCAPE "ffi" predictions were overturned: Crystal binds libsodium directly for Ed25519; Odin's crypto is native pure-Odin core:crypto), both measured natively at cc1970f → 682·0F (--profile core, 292P/294W/96S). Crystal is the Ruby-overfit check (compiled/typed/ fixed-width/CSP-fiber Ruby-like); Odin is the no-exceptions / no-GC / no-package-manager systems probe. Reconciled at the 2026-07-14 branch merge (A-CRY-006 / A-ODIN-005): the Julia + Nim parallel branch merged with this one, and the headline cohort count reached 33 gate-green peers at that 2026-07-14 merge (Crystal + Odin + asm-x86_64 folded into the alien/mainstream sweep; 40 now — see the top Cohort line). No spec finding surfaced (well is dry); the only net-new code was a shared NUL-byte path check and a Crystal graceful-shutdown hardening.

New peers — Oz/Mozart + Io (2026-07-15). Two paradigm probes, each closing one open substrate axis, both NATIVE-transport + FFI-hybrid-crypto and both 682·0F Result: PASS @ cc1970f (--profile core, incl. origination-core 3/3 + a genuine 2-of-3 multisig accept-path unit). Oz / Mozart (285P/301W/0F/96S) is the 4th §7b structural-concurrency shape — dataflow variables: the §6.11 handler-outbound demux collapses to one single-assignment dataflow variable per pending request (reader routes frames, never blocks on dispatch — no correlation map, no locks; A-OZ-006). Installs from the 2018 Mozart 2.0.1 RPM (no source build); crypto/CBOR seam is the entity-codec-daemon Open.pipe co-process (RPM ships zero headers → native-functor FFI out; the Rexx ecnet precedent). Io (291P/295W/0F/96S) is the pure prototype-based object model — §6.6 handler resolution rendered as Io's own delegation (a DispatchNode proto network where longest-prefix resolution is the proto-chain lookup); native Socket + an in-process EntityCodec C addon, built on the permanently-frozen 2026.04.20-native-final tag (upstream master pivoted to WASM). Io's S4 initially FAILed concurrency t2_1/t2_2 and was misdiagnosed as a single-threaded throughput ceiling; the Oz sibling passing the same checks with slower co-process crypto ruled that out — bisection found two fixable bugs (A-IO-025 per-request try-coroutine leak; A-IO-026 blocking send stalling the single event loop under slow readers), and the ceiling claim was retracted → clean 0-FAIL, t2_1 0/10000 dropped. Honesty: both FFI-hybrid, oracle-pinned --profile core, cohort-pinned to one author's vectors — not full-profile, not independent convergence. Per-peer detail: protocol-generator/{oz,io}/status/.

New peers — SQL + Datalog (2026-07-16), the authority-as-query frontier probes — CLOSING the declarative-query/logic corner. Two spec-discovery probes (not substrate probes) built in parallel S1→S5, both NATIVE-transport-via-host + FFI-hybrid-codec and both 682·0F Result: PASS @ cc1970f (SQL 291P/295W/0F/96S; Datalog 292P/294W/0F/96S), origination-core dispatch_outbound_reentry 3/3, genuine live 2-of-3 multisig accept, 71/71 wire corpus. The whole point is the authored authority interior: the §5.2 verify ladder, §5.5 delegation chain-walk, §3.6 K-of-N, and §6.6 resolution are authored in the query/logic language (SQL: recursive CTE + HAVING count DISTINCT + ORDER BY length DESC; Datalog: recursive Ascent rules to least fixpoint + counting aggregate + stratified negation), with a thin host (C / Rust) owning only what the substrate genuinely can't do (sockets/CBOR/crypto/store). The wrapper-guard held through S4 on both — completing the S4 handler surface added zero imperative allow/deny; the verdict never left the authored interior. Finding (co-equal with the gate): authority IS a query, the protocol around it is a state machine — everything pure-function-of-the-projected-facts fits (often more legibly than the prose), everything stateful-sequential leaks to the host. Two spec-shaped results routed to arch: F40 (§3.6 scope matching is typed — id dims literal, path dims canonicalized — surfaced by SQL as a real ALLOW bug) and F41 (the §5/§6.6 decision surface is a monotone deductive system → an authority-as-derivation appendix makes fail-closed + the §5.5a within-grant conjunction structural invariants). Honesty: both seam-hybrid, cohort-consistent (shared C-ABI codec lineage) NOT independent convergence (ADR-0012), probe-tier — genuine gate-green peers, not visual/illustrative (no ‡). Synthesis: protocol-generator/shared/evaluations/authority-as-query.md; arch routing: protocol-generator/shared/findings/authority-as-query.md; per-peer: protocol-generator/{sql,datalog}/status/.

‡ Node-RED (#31) + TurboWarp (#32) are exploratory visual-paradigm probes — NOT real, deployable peers, and distinct from the alien-substrate language probes (Tcl/Rexx/Forth/…) which are full gate-green peers. Pure Data (#33) is the third visual probe (reactive-patch, the paradigm's lone open representative) and the exception on measurement: it runs on the REAL Pd runtime over REAL TCP and clears the full core gate (682·0F Result: PASS @ cc1970f, genuine 2-of-3 multisig accept + origination 3/3) — a real conformant peer by the gate's standard, kept in the probe class because its purpose is paradigm-visualization (cohort-consistent lineage, shared C-ABI codec, ADR-0012). They exist to answer "can the protocol be authored in a visual paradigm?" and to serve as readable references for those communities (a Node-RED or Scratch author can study the dispatch logic in their own idiom), not as something you would deploy. Node-RED delegates the entire §6.5 engine to the TS peer (a flow-graph wrapper); TurboWarp authors the dispatch + all handler bodies as Scratch blocks but delegates crypto to a bundled @noble seam, runs sandboxed (no raw TCP → oracle-reachable only via a WS↔TCP bridge, the browser-Rust/WASM pattern), and is measured by a faithful block-interpreter of the real project.json pending a real-TurboWarp-VM run. Neither is independent convergence (shared TS/@noble lineage, ADR-0012). Full synthesis of what the substrate sweep taught — what translates, what needs a seam, what doesn't — is in research/SUBSTRATE-TAKEAWAYS.md.

Update 2026-07-15 — Pure Data (#33) close-out: the first visual-paradigm probe to clear the FULL core gate. validate-peer --profile core @ cc1970f: 682 · 287P/299W/0F/96S — Result: PASS, every remaining skip a §9.0 extension carve-out (0 fail-counting), measured natively on the real Pd runtime over real TCP (no interpreter harness, no bridge). Genuine 2-of-3 multisig accept-path (§3.6/§5.5 M3/M4/M6 K-of-N verification in the chain walk, persistent EC_NAME identity) + origination-core dispatch_outbound_reentry 3/3 over real two-peer TCP (run-origination-core.sh). Authored on the canvas: the §6.5 pattern-first dispatch spine (one named unit per handler, per-handler op-switch), the §5.2 verify ladder, the §4.6 auth ladder, and the §6.6 longest-prefix walk; [ecodec] (a Pd C external on the C-ABI codec) owns bytes/CBOR/crypto/store and the TCP transport — stock [netreceive] broadcasts every reply to all sockets with no per-connection id (A-PD-002, proven at Pd source level), so transport is a legitimate seam on this substrate. The §6.11 reentry on a single-threaded canvas is a bounded synchronous send+wait on the one inbound fd (non-response frames hand back to the connection's assembler). Cohort-consistent (shared C-ABI codec + generation lineage), not independent convergence (ADR-0012). Per-peer detail: protocol-generator/pd/status/; survey verdict updated in protocol-generator/shared/evaluations/visual-paradigms.md.

Update 2026-07-13 — both peers reworked to author the protocol IN the paradigm, not wrap it (supersedes the "both delegate the §6.5 engine / both 249·2F" description below). Node-RED's §6.5 is now the visible 16-node flow-graph (still 249·2F — leaf crypto delegated + the throughput boundary). TurboWarp was rebuilt, then completed: the §6.5 dispatch, the full §5.2 verify sequence, and ALL FIVE handler bodies (§4 connect / echo / §6.3 tree / §6.2 handlers / §6.2 capability) are now authored as Scratch blocks (502 blocks) — reorganized from one 400-block tower into a short dispatch spine + one define dispatch-<handler> custom-block procedure per handler for legibility — with only the socket / canonical-CBOR / Ed25519-SHA / chain-verdict / token-mint / seed-cap / store mechanics behind the ecutils seam (deliberately no dispatch block). The §6.6 handler resolution is authored as the actual tree WALK (a repeat until that walks the dispatch path longest-prefix-first for the matching system/handler registration == HandlerRegistry#resolve) — not a hardcoded pattern list; the per-prefix store lookup + path slice are the only seam bits, and the final pattern→body match is just body-selection (Scratch can't call a procedure by dynamic name; resolved-but-un-authored handlers delegate). Measured 291 P / 294 W / 0 F / 97 S — Result: PASS @ cc1970f, solid 5/5 full-marathon runs including both §6.11 robustness tests (t2_1_sustained_load + t2_2_connection_churn), via the headless block-interpreter harness (turbowarp/src/harness/run-blocks.mjs, which runs the real project.json block graph against the oracle). The earlier flakiness was a harness-scheduling bug, now fixed (not the old A-TW-throughput label, and not the connect authoring): the interpreter drained the inbound queue in one serial burst without yielding, so under §6.11 connection churn (t2_2) responses didn't flush before the oracle tore connections down → dropped requests → a downstream cascade. Yielding to the event loop between hats (await setImmediate — the cooperative per-tick model real Scratch already uses) resolved it; verified by reverting connect to delegated (which also failed t2_2 → proved the serial drain, not the authoring, was the root). A real-TurboWarp-VM run is the remaining confirmation. Still cohort-consistent (shared bundled @noble + generation lineage), not independent convergence (ADR-0012). Consolidated survey + when-to-stop verdict: protocol-generator/shared/evaluations/visual-paradigms.md. See .

The historical description below (both 249·2F, both delegating the §6.5 engine) is retained for the Node-RED throughput finding. Both delegate codec/crypto to the TS peer (Node-RED require()'d, TurboWarp esbuild-bundled), so a green result would be cohort-consistent, not independent (ADR-0012). validate-peer --profile core @ cc1970f for BOTH: 249 P / 293 W / 2 F / 101 S — all correctness categories green (connectivity 22/22, type_system 108P, multisig 11 w/ genuine 2-of-3 accept-path, security 28, capability 12, §6.11 concurrency correctness t1_2/t1_3). The 2 identical FAILs are §6.11 sustained-load/churn robustness (t2_1/t2_2) — a documented throughput boundary (A-NR-throughput / A-TW-throughput): they pass standalone and fail only under the full ~640-test marathon. That the LEAN TurboWarp harness hits the SAME boundary as Node-RED shows it is engine-level (the shared delegated §6.5 engine's full-suite sustained-load behavior on pure-JS crypto), not a per-runtime artifact — not a correctness defect, not memory-bound. Per "no green → no publish," unpublished. Value is visualization + generator-robustness, not a conformance claim. See protocol-generator/{node-red,turbowarp}/. The peer is authored as a Node-RED flow-graph (§6.6 dispatch ↔ wire routing); codec/crypto/§6.5-engine are delegated (interop) to the TypeScript peer, so a green result would be cohort-consistent, not independent (ADR-0012). validate-peer --profile core @ cc1970f: 249 P / 293 W / 2 F / 101 S — all correctness categories green (connectivity 22/22, type_system 108P, multisig 11 w/ genuine 2-of-3 accept-path, security 28, capability 12, §6.11 concurrency correctness t1_2/t1_3). The 2 FAILs are §6.11 sustained-load/churn robustness (t2_1/t2_2) — a documented Node-RED-substrate throughput boundary (A-NR-throughput): they pass standalone and fail only under the full ~640-test marathon (event-loop saturation + visual-runtime per-request overhead on pure-JS crypto), not a correctness defect, not memory-bound. Per "no green → no publish," unpublished. Value is visualization + generator-robustness, not a conformance claim. See protocol-generator/node-red/. ² Every --profile core cell is a fresh measurement at the 755-check pin 95edd774… (2026-08-21) — total · NF — P/W/F/S, from the centralized tools/run-cohort-census.sh over all 46 peers. Nothing in this column is carried forward from an earlier pin: 755 ≠ 740, so a figure from the retired 740-check pin (8537d875…) is not comparable to one here even when the F-count matches. As of 2026-08-30 every measured peer executed the full 755 and no row is quarantined — the peers that did not are in §1a, which is now a retraction rather than a live quarantine. (Four peers were quarantined at the 2026-08-21 census: csharp, fixed 2026-08-22 — §1c; and the ISA trio, fixed 2026-08-30 — §1a.)

⁴ Maint. is the MAINTENANCE tier — how often this peer is re-measured, nothing else. M1 lockstep · M2 priority catch-up · M3 on-demand · probe paradigm probe · exploratory not a deployable peer. Defined per-peer in tools/peer-tiers.tsv (the roster) and explained in §4; current per-tier state is tools/tier-status.py. These are NOT research/LANDSCAPE.md's tiers 1–5, which classify the language landscape ("what is worth building") rather than re-measurement cadence — the two were previously both written as bare 1/2/3 and were routinely confused, which is why these carry the M prefix. A maintenance tier never affects whether a peer may be published; it affects only how promptly it is re-measured after an oracle re-pin.

³ ⚠ INVALID MEASUREMENT — no row carries this marker as of 2026-08-30; the definition is kept because §1a's historical record uses it and because the next starved run will need it. This peer did not execute the same checks as the rest of the table, so its P/W/F/S cannot be compared to any other row and is not a verdict. The cause is always the same: the oracle's global -timeout expired mid-suite, after which whole categories are never run and are recorded at severity SKIP — the same severity as a deliberate --profile core extension carve-out — so summary reads as a near-clean run. Treat the numbers as a floor and read §1a.

Every peer in this table is required to execute the identical check set (756 checks, digest d30c3dd0…, pinned as core_executed_check_set_digest in tools/oracle-pin.env). This is enforced, not assumed: tools/check-set-gate.py validates every report in a census against that pin and hard-fails on any deviation or any budget_exhausted category, and tools/run-cohort-census.sh runs it automatically and exits non-zero when a census is not comparable. This census: 46 of 46 conforming, and tools/check-set-gate.py --tracked reads the same over the committed reports. (It read 41 of 45 until 2026-08-30; the 4 that deviated are in §1a, and the gate is what found them. The 46th, apl, was not a deviation — it was excluded from the census entirely, which no gate could see. §1d.)

Crypto-availability tiers (the per-ecosystem story an adopter most needs): native = ships with runtime/stdlib or an in-language audited lib, no FFI; managed = a managed-code crypto package on the language's package manager; FFI-hybrid = native floor, Ed448 via libentitycore_codec; FFI = whole crypto surface via C-ABI; deferred = Ed25519+SHA-256 floor only, Ed448 not yet wired.

⁷ wasm-wat is 755 · 0F as of 2026-08-29 — and on the way there its FAIL count went UP twice, both times because a measurement got more honest. Kept because the sequence is the evidence, not the endpoint. Until 2026-08-29 this was the only peer in the cohort whose run-s4.sh never provisioned ~/.entity/peers/conformance/keypair, so four checks could not build their fixtures and SKIPped — reading as substrate limits rather than a missing setup file. Provisioning it (the peer hardcodes that same seed already) resolved three and converted the fourth into a real FAIL: it refused a valid 2-of-3 multisig capability it had co-signed, because $verify_cap hard-refused a map-valued granter. Tracing the remaining capability refusals then showed they were never the §5.6 ceiling — the peer had no §5.5 delegation chain at all, so a delegated cap was refused two gates before the mint was reached. 304P/339W/2F/110S → 306P/339W/3F/107S → 312P/337W/0F/106S: four fewer skips, then the chain walk (ef7affe) and §3.6 K-of-N quorum roots (905ce0f). Never read the 2F→3F step as a regression — nothing about the peer changed at it. This peer then became the reference port for the same missing chain in all three ISA peers.

⁶ Oracle pin is a content digest, not a commit. d30c3dd0… is core_executed_check_set_digest — the sha256 over the sorted <category>/<name> list a --profile core run actually executed, 756 checks. Two rows may share this column only if both reports carry that exact digest; tools/check-set-gate.py enforces it, and a peer that deviates is an invalid measurement, not a low score (§1a). A commit hash is deliberately absent: published commits are authored fresh at the release boundary, so a dev SHA resolves for nobody outside this tree — see The pin for the full anchor set, the reproduction recipe, and the one limit that a digest does not fix. The retired pins, where they appear below, are the 755-check set 95edd774… and the 740-check set 8537d875….

⁸ cobol's 30F was 24 cascade + 5 real + 1, and the cascade came from a memory-safety defect. tree-handler's put path copied the wire entity into a fixed 8192-byte field with no size test; a 16 KiB tree.put — the oracle's own t1_4 staging payload — overflowed it and glibc's _FORTIFY_SOURCE terminated the peer, so every check after that point reported connection-refused. Two more copies of the same shape were reachable from the wire (store-put/store-bind into a 4096-byte slot, cap-resolve into an 8192-byte one). All three are now bounded before the copy and answer a status. With the peer alive, five real defects surfaced: no §5.6 mint ceiling, a created_at that was a compile-time constant, a CAP-6a fail-open, and the F40 id-scope pair — which failed in both directions at once (an operations include of /{local}/get authorized the bare get, an exclude of /*/get denied it) because an id-scope dimension was being canonicalized. Skips are 108, not the cohort's 106, and that is disclosed rather than worked around: two concurrency probes stage 256 KiB and 16 KiB payloads that this peer's 65535-byte frame cap and 8192-byte per-entity ceiling cannot accept. Its harness now passes --validate by default as every other peer's does; without it four concurrency checks SKIPped rather than ran.

⁹ The type-registry over-publication is CLOSED (2026-08-30) — and the fix made the pass count FALL by 282, which is the whole point. This footnote used to read "the ISA trio's 594-595P/53-55W is NOT better conformance than the cohort's 312P/337W", and it was right: src/typestore.s published ~200 type entries including whole standard-extension vocabularies (compute/*, system/registry/*, clock/*, continuation/*, relay/*, query/*, …), the oracle scores those matched-if-present, and publishing them converted 282 type_system WARNs into PASSes. The store is now filtered to the 53-name core floor and the rows read 313P/336W (asm-x86_64) and 312P/337W (asm-arm64, riscv64), all three still 755 · 0F.

The number to hold onto is that a correct fix here LOWERS a published pass count, which is the exact shape a reviewer reverts by reflex. Verified per-check on each peer, before against after: exactly 282 checks changed, every one of them type_system, every one PASS→WARN, and nothing outside that category moved. The enforcement grep AGENTS.md names — grep -rl 'system/type/compute/apply' protocol-generator/*/src/ — now returns nothing.

Two things were found in the doing, both worth more than the fix. The scope filter belongs in the generator, not the harvest. These peers have no data model to reflect a registry over, so typestore.s is harvested byte-exact from the reference peer — which is a FULL peer and serves the extension vocabularies. The harvest is left intact (it is evidence of what the reference peer serves) and gen-typestore.py now carries CORE_FLOOR as a keep-list, not a drop-list: a drop-list fails open, publishing any vocabulary a future harvest adds, while a missing floor type fails closed as a hard type_system FAIL on the next run. And riscv64's reference/typestore/ had never been committed — 0 files tracked, not gitignored, simply absent — so its generator could not run from a clean clone and src/typestore.s was an artifact with no in-tree input. That is the forth bin/peer.fs shape one level up, and it is why all three now regenerate byte-identically from their own committed harvest.

One disclosed gap remains for these rows: all three are corroboration, not independent convergence — one hand-written design ported twice.

Second, asm-arm64 and riscv64 WARN on r3_connection_flood where asm-x86_64 PASSes — ported 2026-08-30; all three now PASS and all three read 313P/336W. The sentence is kept because the correction attached to it is the durable part. It used to stop at that clause, which reads as an ISA-pair parity gap and is backwards: measured across all 46 committed reports, r3_connection_flood was 44 WARN with only asm-x86_64 and pd passing (now 42 WARN / 4 PASS). The two ISA peers were exactly where the rest of the cohort is; asm-x86_64 was the outlier ahead of it. Every other peer carries the same WARN with the same message — "admitted all 256 connections without refusal and kept serving — no self-imposed bound, so admission is delegated externally." Disclosing it as something those two rows owed, while 42 rows owing the identical thing said nothing, was a misattribution in the pessimistic direction, and this file's rule against unfair-looking-good cuts both ways. The real state is unchanged by the port: a cohort-wide unimplemented SHOULD, now with four peers ahead of it, tracked in §3. Porting it was ISA parity, not catch-up.

What went across were asm-x86_64's four host.s/dispatch.s hardenings: the child closes the inherited listen fd, a 30 s socket idle deadline on a served connection (a socket-level deadline on a connection one child owns exclusively — deliberately NOT the §6.11(c) per-request deadline, which §6.11 forbids implementing as a connection-wide primitive), the §4.10(c) admission bound at 64 with refusal by close, and the §4.10(a) oversize path answering 413 immediately instead of draining the declared body first. The admission counter must be reaped twice — once before the blocking accept4 and again after it returns — or every child that exits while the parent is parked still counts as live and the bound presents as a dead peer. On RISC-V the bound is a value comparison, not a compare-then-branch-on-flag, since the ISA has no condition-flags register; that is the same restatement §5.6 rule 3's overflow test needed. Exactly one check moved on each peer (r3_connection_flood WARN→PASS), verified per-check before against after.

¹⁰ apl was never unmeasurable — see §1d. Its image had built successfully on 2026-08-28; nobody ran the peer against it. One harness invocation on 2026-08-30 produced a valid 755-check measurement in 109 s, and the 8 FAILs it exposed were closed the same session. Seven of the eight were cohort defect classes this peer had sat out because the label kept it out of every propagation pass.

⁵ Tier M1 — fixed this session, and the reference for everyone else. These five went 3F/2F/83F → 0F at the 755-check pin. Three defect classes, all in the banner above and ratcheted in AGENTS.md: §5.6's MIN_DEFINED mint ceiling (absent in every peer, not merely wrong), CAP-6a's absent-vs-unrepresentable fail-open, and §6.3's missing 400 non_canonical_ecf rejection status. swift needed a fourth — §5.5a frame over-scoping — which was the actual cause of its capability failures rather than a symptom. lean's 83F was 2 real + 81 cascade from one §6.3 defect; fixing it returned it to 0F, which is what confirmed the diagnosis. These five diffs — plus M2's eight, landed 2026-08-22 — are the reference fix for the remaining 32 (§3): author it once from the spec, propagate, do not rediscover it 32 times. (This footnote read "the reference fix for the other 40" before the M2 pass.)

1a. INVALID MEASUREMENTS — closed 2026-08-30, and the diagnosis was wrong

✅ CLOSED (2026-08-30) — all three ISA peers are 755 · 0F, and "the connection-pressure family" never existed

asm-x86_64 755 · 0F — 595P/54W/0F/106S in 1.4 s, against 549P/53W/1F/111S in 599 947 ms. asm-arm64 and riscv64 755 · 0F — 594P/55W/0F/106S, severity-identical to each other on all 755 checks. tools/check-set-gate.py reports 45/45 conforming and exits 0.

The cause was a §4.9(c) silent drop, not resource pressure. The op-routing ladder compares an operation's LENGTH before its bytes. ping collides with echo at length 4; the byte compare failed and the branch returned without writing any frame — not 501, not 400, nothing. hello (5) and authenticate (12) had the same hole. Every connection-churn cycle ends with a ping, so every cycle cost the caller its full 20 s read deadline; t2_2_connection_churn reached cycle 29 of 100, consumed the entire 10-minute budget, and starved nine categories including three core ones. concurrency went from 599 s to 1.1 s, 6/6.

Everything §1a says below about accumulation, stuck children and a "connection-pressure family" is retracted as a diagnosis. The measurements were real and are left in place: the 2026-08-17 stuck-children dump was accurate, the 2026-08-29 re-measurement that showed a completely healthy peer at the moment of failure was accurate, and the three defects fixed on 2026-08-29 were real defects. None of them was the cause. A §4.9(c) drop is billed entirely to the CALLER's timeout, so it presents as the peer being slow or under-resourced rather than wrong — which is why five separate investigations of the peer's health found nothing and why the label survived for months. The diagnostic that closed it asks the opposite question: set a flag in the frame WRITER, clear it at the top of dispatch, and print which operation returned without having written.

r1_payload_over_limit and r3_connection_flood — filed here as the same "family" — were never separate: both ran and passed the moment the budget was no longer being eaten.

The trio also gained the full §5.5 delegation chain, §5.6 attenuation, §5.5a framing, §3.6 K-of-N and the §6.2 mint ceiling in the same pass, ported from wasm-wat. The CAP-5/CAP-6 failures they carried were never the mint: both checks present a delegated capability and were refused two gates earlier by a fail-closed root-trust placeholder.

What is NOT closed: §1a.4 below. The trio still over-publishes extension type vocabularies, which is the entire reason they read 594-595P/53-55W against the cohort-standard 312P/337W. A 0-FAIL row does not retire that finding.

Everything from here to the end of §1a is the historical record of the wrong diagnosis, kept verbatim because the measurements in it are sound and only the conclusion was not. Do not cite it as current state.

Status at the 755-check pin, 2026-08-21 to 2026-08-30: asm-x86_64 · asm-arm64 · riscv64 (714/755). All three had budget_exhausted categories. None of the three was listed with a P/W/F/S anywhere in §1, because a run measured on a different set of checks is not a worse score — it is not a score.

tools/check-set-gate.py reported 42/45 conforming and exited non-zero on exactly these three; tools/run-cohort-census.sh did the same. That was the gate working as designed — a non-zero exit from the cohort gate was the expected, documented state, not a regression — and it was attributable in full to this section.

csharp was the fourth until 2026-08-22 — it is now FIXED and fully comparable. It was a clean 740 · 0F at the retired 740-check pin, then came back at 698 of 755 checks with 9 starved categories at this pin. Root-caused 2026-08-22: it was typescript's §6.3 defect in its hang-form — see §1c. Same 3 real FAILs at the same indices, same cascade onset, but the peer dropped the frame and left the connection open instead of closing, so each downstream check waited out a timeout (CAP-6a alone: 120 s) until the global budget expired. Fixing the missing 400 non_canonical_ecf restored both a valid measurement and 0F in one change: 755 · 0F — 313P/336W/0F/106S, run time 18 m 20 s → 7.2 s. Nothing had regressed. (This paragraph read "it has not been root-caused" until 2026-08-22, and "one fix should restore both" until that fix was measured.)

The asm/ISA trio — what the "1 FAIL" was actually hiding. Traced and measured 2026-08-17, still unfixed, and the reason this section exists:

asm-x86_64, asm-arm64 and riscv64 each report 699 · 1F in §1. That single visible FAIL (concurrency/t2_2_connection_churn) is not the whole state, and the "peer-latency flake" label this matrix used until 2026-08-17 was wrong in kind. What the census actually measured:

1. One hung check starves seven whole categories, including a core one. t2_2_connection_churn does not fail fast — it hangs and burns 599 s of the oracle's 600 s global -timeout (the whole rest of the suite runs in ~0 ms). The oracle then records seven categories as budget_exhausted, and its human output says so loudly — !! WHOLE CATEGORIES NEVER RAN … this is coverage loss, not a slow peer. The JSON summary does not: the starved categories land in skipped, so a reader of summary alone sees 1 failed and a slightly high skip count. Starved: authz, crypto_agility, format_agility, negotiation, peer_canonicalization, resource_bounds (a core gate category), universal_address_space.

2. Running the starved categories directly surfaces 2 more real core FAILs. Driven one category at a time so concurrency cannot eat the budget (-category <name>, asm-x86_64):

So the honest count is 3 core FAILs (t2_2_connection_churn, r1_payload_over_limit, r3_connection_flood) — and all three are one failure family: the peer stops serving under connection pressure.

3. What the failure is — and what it is not. Measured directly rather than inferred from the accept-loop source:

• Not qemu, not emulation. asm-x86_64 runs natively and fails identically to the two emulated ports.
• Not a full-marathon-only flake. -category concurrency alone reproduces it.
• Not deterministic. It hits cycle 29 of 100 in the full run and cycle 7 standalone — a random draw, so the previously-recorded "cycle 29" was never a meaningful constant.
• Not resource exhaustion. Sampled once per second across a full run: parent fds flat at 4, RSS flat at 1792 KB, live children steady at 3–7. Nothing grows. 60 rounds of bare TCP connect/close produce zero accumulation, so the accept/fork/reap path itself is sound.
• What it is: a subset of forked children block forever in read(2) on their connection fd (/proc/<pid>/syscall → syscall 0 on fd 4, wchan=wait_woken, state S, unchanged 8 s later). Those children never time out and never exit; the oracle's request on such a connection times out as peer refused or hung. Two contributing defects are visible in the same dump: no idle/read deadline on a served connection, and the listening socket is leaked into every child (all stuck children share fd 3 → the same socket inode as the parent's listen fd).

5. Update 2026-08-29 — the three defects above are FIXED in asm-x86_64, and the family did not move. That is itself the finding. The child now closes the inherited listen fd, carries a 30 s socket-level idle deadline, and the peer bounds admission at 64 connections and refuses the rest by close (§4.10(c) names close as an allowed refusal). A fourth defect not listed above was found by re-reading §4.10(a) rather than the check: the oversize path drained the entire declared body — up to the 4 GiB a 32-bit length header can name — before answering, which is precisely the "fully buffering" that section forbids; it now answers 413 and closes, and the oracle's verdict moved from "connection terminated without a 413 frame" to "413 payload_too_large frame returned (spec-preferred: coded frame + close)". r3 moved from "admitted all 256 without refusal" to "admitted 63/256 and refused the rest (self-bounded)". No check flipped, t2_2_connection_churn still consumes the whole 10-minute budget, and the peer remains an INVALID MEASUREMENT. What that rules out is worth more than what it fixed. Sampled every 3 s through a full churn run, the peer is completely healthy at the moment of failure: parent flat in accept4, parent fds flat at 4, 2–4 live children, zombies reaped promptly, nothing accumulating anywhere. The stuck-children mechanism this section identified in August is gone, and the check fails anyway. So the remaining cause is not accumulation, and the 2026-08-17 characterisation — correct about what it measured — was not the whole cause. The surviving symptom is narrow and identical in all three checks: a tree.get on a fresh connection whose write times out, while the peer is demonstrably accepting.

Root cause is characterised, not fully traced — the specific path on which a child blocks instead of completing or closing has not been isolated to an instruction. Flagged at the same standard as A-OZ-008 / A-IO-025 (report what is measured, do not over-invest ahead of a fix session). The fix shape is known from the cohort: a per-connection read deadline plus the §4.10(c) connection-admission cap that r3_connection_flood says outright is missing — the same pairing Rexx landed as A-RX-014.

4. Separately: the asm trio's higher raw PASS count is an artifact, not better conformance. ✅ CLOSED 2026-08-30 — see footnote ⁹ for the fix and the current numbers. The finding below was correct and is kept verbatim; only its numbers are of their pin (545P/42W vs 307P/327W, later 594-595P/53-55W vs 312P/337W). typestore.s is now filtered to the 53-name core floor, the enforcement grep returns nothing, and the three rows read 312-313P/336-337W at 755 · 0F. The fix LOWERED the pass count by 282 — that is the correct direction. Their 545P/42W next to the cohort's 307P/327W does not mean they pass more. 283 type_system checks that WARN for every other peer PASS for these three, because src/typestore.s publishes ~200 type entries — including whole standard-extension vocabularies (system/type/compute/*, content/*, clock/*, continuation/*). The oracle treats those as matched-if-present, so publishing them converts WARN→PASS. This is not an oracle violation, but it is a deviation from this repo's own standing rule for core peers — "scope to core + operational + the type-system bootstrap only; a core peer never pre-publishes extension vocabularies" (AGENTS.md). Only these three peers do it (grep -rl 'compute/apply' over protocol-generator/*/src/ hits asm-* and riscv64 and nothing else). Do not read the asm trio's P count as comparable to the rest of the table.

Full trace, probe scripts and raw output: .

1b. typescript's 84F was 3 real FAILs and 81 cascade — the same defect lean had — FIXED 2026-08-22

Resolved. typescript is now 755 · 0F — 312P/337W/0F/106S. This section is retained because the diagnosis is the reusable part: the 84 was never a measure of how bad the peer was, and reading it that way would have sent the fix in the wrong direction. The analysis below is as-measured before the fix.

Do not read 84 as "typescript is the worst peer in the cohort." It was a 3F peer with one connection-killing bug, and the bug was lean's, already fixed and verified there.

Measured, not inferred. typescript's failure sequence is byte-for-byte the shape lean had before its fix: the first FAIL of all 755 is capability/configure_empty_grants_withdrawal (idx 558), followed immediately by request_mint_temporal_ceiling (559) and request_ttl_zero_and_overflow (560) — those three, and only those three, are real. The last check before the first transport error is capability/ingest_rejects_unrepresentable_expiry (a WARN whose own message reports a transport-drop rather than the §5.2 capability_denied disposition), and from idx 563 onward every category fails on a dead connection — tree_operations 20, security 29, multisig 12, authz 10, universal_address_space 7, peer_canonicalization 3.

(This paragraph named idx 559 / request_mint_temporal_ceiling as the first FAIL until 2026-08-22. Off by one check: 558 is configure_empty_grants_withdrawal. The real-FAIL count of 3 and the idx-563 cascade onset were both correct; only the identity of the first was wrong.)

That is §6.3's missing rejection status (banner item 1): an undecodable frame is refused by dropping or closing instead of answering 400 non_canonical_ecf, and on a peer that closes, the refusal takes the whole connection with it. lean went 83F → 0F on exactly this fix, and its 81 cascade vanished — which is what turned the diagnosis from plausible into confirmed.

CONFIRMED 2026-08-22 — the prediction held exactly. typescript is now 755 · 0F — 312P/337W/0F/106S, byte-identical to the M1 five, and the run fell from a cascading 84F to a clean PASS in 33.9 s. All 81 cascade FAILs vanished with the one §6.3 change; the 3 real FAILs took the §5.6 ceiling + CAP-2 fix. No transport error at idx 563 any more.

1c. csharp's INVALID measurement was the SAME defect as typescript's — ROOT-CAUSED and FIXED 2026-08-22

Resolved. Both peers are now 755 · 0F (csharp 313P/336W, typescript 312P/337W). Retained because the differential is the reusable part: it is how a starved run gets attributed to a known defect instead of being filed as a harness problem. Analysis below is as-measured before the fix.

csharp was not an unexplained new failure. It was typescript's §6.3 defect with the other failure mode: typescript closes on an undecodable frame, csharp hangs. That single difference is what turned an 84F score into a starved, unscoreable run — and it meant one fix addressed both the FAILs and the INVALID status, which is exactly what happened.

This supersedes the "not root-caused" note carried in §1a and §3 since 2026-08-21.

The evidence, measured from the census reports, not inferred:

The mechanism. Both peers reject an undecodable frame without answering 400 non_canonical_ecf (§6.3, banner item 1). typescript closes the connection, so every later check fails instantly — 81 cascade FAILs, but the suite still completes and the measurement stays valid. csharp instead drops the frame and leaves the connection open, so the oracle blocks until its own timeout on every subsequent request. The CAP-6a check alone burns 120 s (six field×shape variants × a 20 s block) — that is AGENTS.md's documented symptom (a), "the sender blocks until its own timeout, so a refusal is indistinguishable from a dead peer." security then burns 600 s and tree_operations 380 s, the 10-minute global budget expires, and authz · concurrency · crypto_agility · format_agility · multisig · negotiation · peer_canonicalization · resource_bounds · universal_address_space never run.

So the starvation is a symptom, not an independent problem. csharp was a clean 740 · 0F at the retired 740-check pin because CAP-6a did not exist as a check then — the drop-form defect was always present and simply had nothing to expose it. Nothing regressed.

CONFIRMED 2026-08-22 — and the timing is the proof. csharp is now 755 · 0F — 313P/336W/0F/106S, a fully comparable measurement (check-set-gate.py PASS, zero budget_exhausted). The whole run went from 1 100 556 ms (18 m 20 s) to 7 198 ms — a ~150× collapse from one change to the read loop. That is the diagnosis proving itself: if the starvation had been latency, slowness, or a resource problem, answering 400 non_canonical_ecf instead of falling silent would not have touched it. Nine categories that had never run now run. The precise mechanism, confirmed in the source: csharp did not merely drop the frame — it breaked out of the read loop without closing the socket, so the oracle's every later write went to a socket nobody was reading. Functionally identical to a hang, and a shape worth recognising on its own: a peer that stops reading but stays connected is indistinguishable from a slow peer.

Generalizable, and the reason this got its own section: a hang and a close are the same §6.3 bug, but they present as two completely different failure classes — one as a large FAIL count on a valid measurement, the other as a quarantined INVALID with a small FAIL count. The diagnostic that unified them is cheap and should be run first on any starved peer: compare the first-FAIL index and the first-transport-error index against a known peer with the same defect. Here they matched exactly (558 / 563), which is what turned "csharp is a mystery" into "csharp is typescript."

1d. apl was never unmeasurable — the exclusion outlived its reason by three days

✅ CLOSED (2026-08-30) — 755 · 0F — 311P/338W/0F/106S, digest 95edd774…, 109 s, zero starved categories

Measured twice by two destinations of the same tool — the peer's own harness and run-cohort-census.sh — agreeing byte-for-byte on all five summary figures. tools/check-set-gate.py --tracked now reads 46 / 46 at the pinned set.

The claim that stood for three days was: "UNMEASURABLE — upstream-blocked (1.9→2.0 cool-down); excluded from census by standing policy." Three things in that sentence were false, and each was checkable in under a minute.

1. "GNU deleted apl-1.9.tar.gz." It did not. GNU reorganized the flat gnu/apl/ directory into per-version subdirectories when 2.0 shipped. https://ftp.gnu.org/gnu/apl/apl-1.9/apl-1.9.tar.gz answers HTTP 200, and the directory beside it also holds the .sig and the Debian source. The 2026-08-27 investigation checked six mirrors and ftp.gnu.org, found the flat path 404 on every one, and concluded deletion — but every mirror carries the same reorganization, so six agreeing sources were six copies of one observation. A path change and a deletion are indistinguishable from a single URL, and mirrors do not make that sample independent.
2. "The image is unbuildable." It was force-bumped to APL 2.0 on 2026-08-27 and built successfully on 2026-08-28 — the image was in local storage the whole time, and apl --version runs. Whatever justified the label stopped being true the day after it was written.
3. "Excluded from census by standing policy." tools/run-cohort-census.sh hard-coded apl) echo "SKIP: ... blocked" ; rc=125. So the one peer nobody could measure was also the one peer the census would not attempt — the exclusion made itself permanent by removing the only thing that could have falsified it.

The 8 FAILs, and what they say about the cost. Seven of eight were defect classes already closed elsewhere in the cohort; apl missed them because the label kept it out of every propagation pass:

Two of the fixes are worth their own note.

The F40 pair reproduced cobol's two-defects-holding-each-other-up shape exactly. CapMatchesScope canonicalized both the value and the patterns for handlers, operations and peers — all three ID-scope, all three literal per §5.2/F40 — so an operations include of /{local}/get authorized the bare get while an exclude of /*/get denied it: overgranting and over-denying in one run. Removing the canonicalization alone takes every CAP check to 403, because the handlers dimension was separately being compared as the absolute resolved path (/{peer}/system/capability) against grants that name handlers relatively. Neither defect is visible while the other stands.

CAP-6a needed the §6.3 answer to score at all, and apl already had the 400 branch — unreachable. The peer reached 0-FAIL with CAP-6a still WARN: "3 capability_denied, 3 transport-drop." OnFrame had a correct 400 non_canonical_ecf response ready, but the WirePeek that recovers the request_id used the strict decoder, so a tagged frame returned ok=0 two lines earlier and the frame was dropped on the floor. The fix is the cohort-standard salvage decode — strict decoder byte-unchanged, salvage used only to recover the id — and it moved CAP-6a to PASS on all six variants and cut the run from 149 s to 89 s, because the dropped frames had been billing the caller a full timeout each. A refusal that exists but cannot be reached is a §4.9(c) silent drop, and this is the third time in three days that shape has been the finding.

The generalizable rule, and it is about the exclusion rather than the peer: an exclusion is a claim with an expiry date, and it must be wired to the thing that justifies it or deleted. This one asserted a fact about an upstream server, was never re-checked, survived the repair of its own cause, and was enforced by the tool that would have disproved it. It also silently converted the published headline from a measurement into an assumption — 45 of 45 measurable reads as complete and was one unrun command away from 46 of 46. Enforcement: tools/run-cohort-census.sh no longer carries any per-peer exclusion, and roster_peers() no longer filters the roster — every peer in tools/peer-tiers.tsv is measured, so a peer can only leave the census by leaving the roster, where tier-status.py reports it.

2. Capability & parity table

Feature parity is not uniform — the 5 T2 peers (C, Ada, Ruby, Prolog, Go) were built on a separate track and folded in later, so some normalization is still outstanding. This table makes the gaps visible; the catch-up items are in §3.

Standard host CLI surface (the cohort convention): --name NAME (load Ed25519 identity from ~/.entity/peers/NAME/keypair) · --port N · --validate (bootstrap §7a system/validate/* conformance handlers, OFF by default) · --debug-open-grants (deprecated; degenerate default→* seed policy) · --help. Go uses the same surface with Go-idiom single-dash flags. C/Ada currently expose identity via -seed only.

3. Maintenance state & catch-up backlog

Standing maintenance loop (the steady state): when a spec amendment lands and Go ships the corresponding validate-peer update, re-vendor the oracle, re-run M1 immediately and converge to 0-FAIL, then catch up M2/M3 as capacity allows. (This paragraph said "Tier-1/Tier-2/Tier-3" until 2026-08-21 — the exact bare-numeral spelling §4 warns is routinely confused with research/LANDSCAPE.md's selection tiers. Corrected to the M prefix.) As of 2026-08-30 the loop has run to completion for this re-pin and the cohort is closed: the oracle is re-vendored, M1 converged 5/5 (2026-08-21), M2 8/8 (2026-08-22), M3 + the probes closed the propagation on 2026-08-28, turbowarp took exploratory to 2/2 on 2026-08-29, and the last five — cobol, the ISA trio and apl — landed 2026-08-30. All 46 peers are at 0-FAIL, with no exclusions. What is left below is not conformance debt: it is one cohort-wide unimplemented SHOULD, one withdrawn exculpation that needs measuring, and standing demand-driven work. (This sentence also named "one open scope violation behind a green row (type-registry over-publication)" until 2026-08-30, when the ISA trio's typestore.s was filtered to the core floor — closed, and the pass count fell by 282 in the process.) (This read "40 of 45 … five independent defects in five peers" until 2026-08-30, then "45 of 45 … one unmeasured peer" for part of that day — see §1d. Before that, "mid-cycle and stalled at step two … M1 has not converged", which was true on 2026-08-21.) This is the engine of spec refinement now — not new languages: the discovery well has been dry on the current wire surface since ~15 peers, per synthesis-reconciliation.md. (This sentence and the one in §4 cited "§5" of this file until 2026-08-30. There is no §5 — the section was folded out at some point and two published cross-references outlived it, resolving to nothing for any reader. Found by hand-walking the tree, which is the only thing that asks this question. A gate now covers part of what the walk was catching: tools/coherence-gate.py, in make lint, checks all 46 §1 rows and all 46 per-peer prose banners against the committed reports, so a published number cannot silently disagree with the report it is published from. It does not catch the §5 defect that motivated half of it — there is no way to tell "§5 of this file" from "§5 of the spec", and this file cites the spec at §5–§7b 24 times, correctly. The walk stays mandatory.)

4. Maintenance tiers — the workflow contract (ACTIVE)

Status: active, and enforced by tooling. From 2026-08-17 an oracle re-pin does not mean a 45-peer census. It means: re-run M1, converge it to 0-FAIL, and the re-pin is landed. Lower tiers catch up behind it, and their lag is tracked in the open rather than being either hidden or treated as an emergency.

This existed as prose before and drifted — §4 named 17 peers while the cohort had grown to 46, so "re-run Tier-1" had no unambiguous meaning and every re-pin became a full census anyway. It is now a data file plus two commands.

These are MAINTENANCE tiers — re-measurement cadence only. They are not research/LANDSCAPE.md's tiers 1–5, which classify the language landscape and answer "what is worth building". Both used to be written as bare 1/2/3; the M prefix exists so they can never be confused again. A maintenance tier never decides whether a peer may be published — "no green report → no publish" is unchanged and applies to every peer regardless of tier.

The contract

M1 is go · haskell · lean · ocaml · swift — chosen for spec-discovery capability and axis coverage, not popularity: OCaml is the proven headline finder (A-OC-007), Haskell brings the STM substrate and the cleanest record, Swift is the sharpest string/grapheme instrument, Go is the clean-room generator-independence check, and Lean is the proof vector — the only formal-methods discovery channel we have, kept in M1 deliberately despite higher upkeep.

M1 is a default, not a cage. Pull any peer up temporarily when an amendment touches its axis — a memory-model change → add c; a numeric-model change → add rexx or fortran; a capability/authority change → add sql or datalog, which author that surface in the query language and read it most sharply.

Standing open question, carried forward: rust and python sit in M2, and that placement is provisional — a steward may promote them to M1 alongside the clean-room go peer as same-language generator-independence checks against the hand-written siblings entity-core-{rust,py}. Not done yet; it would take M1 from 5 peers to 7.

Where the assignment lives

tools/peer-tiers.tsv is the single canonical home — all 46 peers, one tier each, plus the oracle pin each peer's current verdict was measured at. The §1 Maint. column mirrors it. Nothing else defines a tier.

The two commands

tools/tier-status.py                      # where every peer stands, per tier
tools/tier-status.py --full               # + every peer's P/W/F/S
tools/tier-status.py --gate               # exit non-zero unless M1 is current AND 0-FAIL

tools/run-cohort-census.sh --tier M1      # the lockstep gate — 5 peers
tools/run-cohort-census.sh --tier M1,M2   # after M1 converges
tools/run-cohort-census.sh --stale        # only peers behind the current pin
tools/run-cohort-census.sh                # everything (pre-release)

A tier run gates only the peers it ran — otherwise --tier M1 would exit non-zero because of a probe nobody re-ran, and the exit code would stop meaning anything.

Current state — 2026-08-30 @ the 755-check pin 95edd774… (cohort closed, 46/46)

Every tier is current on the pin, nothing is stale, and the cohort is closed at 46 of 46. What the lower tiers carried was one debt (§5.6's MIN_DEFINED mint ceiling, absent everywhere), and propagating it took the cohort from 13 publishable to 41. The rest were different problems, not one: cobol's memory-safety cascade, the ISA trio's §4.9(c) silent drop, two hand-authored substrates missing §5.5 chains, and one peer excluded from measurement by a stale claim. (This table read probe 13/18 · exploratory 1/2 and the paragraph read "41 of 45 … six different problems" until 2026-08-30 — stale in the same commit that closed the work it described. Before that, "25 of the 29 scored unfixed peers fail nothing but the new CAP checks"; that finding was right and is now history.)

This is the tier policy paying for itself in both directions. Running M1 first (5 peers) found the entire gating delta and produced a verified fix; running the full 45 afterwards is what established that the gap is uniform rather than 40 separate problems — and it caught two things M1 alone could not: typescript's cascade and csharp's invalid measurement, which the M2 pass then proved were one defect, not two. Tiering governs the cadence between releases; a release still runs everything, and this one did.

What M2 added that M1 could not have taught. Thirteen languages took the same ~200-line fix over the same five places, unchanged — and that invariance is the evidence the spec reading is right, not merely that the tests pass. But two lessons only appeared past the M1 sample: CAP-6a's fail-open has two mechanisms, not one (null-collapse and an arithmetic fail-open that involves no null at all, so the grep that catches one misses the other — AGENTS.md carries both), and §6.3 is not optional even at 0F (rust, common-lisp). Pattern-matching off M1 alone would have missed both.

Why this is on now

The cohort is at 46 peers while the spec is still in flux — arch cb5df2c landed four §6.2 capability rulings the same week, and entity-core-go implemented two of them within a day. Running 45 peers per change is not affordable at that rate and produces nothing M1 wouldn't have caught: the discovery well has been dry on the current wire surface since ~15 peers (synthesis-reconciliation.md), so peers 16–46 are corroboration and generator-robustness, not new findings. M1 is where a real regression shows up first; the rest is breadth, and breadth can lag by design as long as the lag is visible.

Deliberately unchanged: the release gate. Before a release, run everything (run-cohort-census.sh with no arguments) — tiering governs the cadence between releases, not what a release claims.

Companion evidence: the per-peer protocol-generator/<lang>/status/ records (CONFORMANCE-REPORT, ARCHITECTURE-REVIEW, SPEC-AMBIGUITY-LOG) and the cross-language findings register research/stewardship/SPEC-FINDINGS-LOG.md.