docs: W4-EFFECTS-1 — scope the admissible-effects recorded-product ABI - #628
Conversation
The scope-before-build deliverable for the last open item of queue order 2
('one physical packet family with admissible effects'). No code.
States the admissibility criterion explicitly — a recorded product pi(E) is
sound iff (R) replay is BIT-IDENTICAL, not merely distributional, and (C)
E's write-set is confined to values pi names — and argues why both halves
are needed: (R) alone admits an op that reproduces its own value while
corrupting a neighbour's state; (C) alone admits an op that touches nothing
but returns different numbers.
Per-class verdicts, each with its enabling fact measured rather than
assumed:
* keyed RNG ADMISSIBLE — the S4 generator is counter-based, so a draw is a
pure function of its key. Measured: bit-identical replay (max abs diff
0.0), child streams distinct with max |corr| 0.032 inside the 3/sqrt(n)
= 0.047 noise band, zero collisions over 800 derivations, per-rank
disjoint, KS vs N(0,1) p=0.55. Unkeyed stays closed: no product exists.
* mutation ADMISSIBLE by reusing state_buffer_lineage.v1 rather than a
second schema (#31) — with a measured PRECONDITION: the identity
separates version/shape/access/parents/role but hardcodes dtype=f32,
so mixed-precision recorded state would alias. Same defect class as the
MegaMoE schedule-digest fix in #625.
* ordered collectives ADMISSIBLE as identity only; a mock mesh may not
stand in for a multi-rank numerical claim.
* I/O NOT ADMISSIBLE, by argument rather than as an unfinished item: an
external read is not a function of any recorded value, so no product
satisfies (R). The existing assertion carve-out is observational and
stays narrow.
* alias-sensitive work CONDITIONAL on known alias facts (W2.1 + #625).
Five delivery slices with acceptance bars that a distributional check
cannot satisfy, and an explicit list of what the plan refuses to do.
Registered in the compiler README authority chain.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 69165611b7
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
… README table, assess four backends Two of the four findings are substantive corrections to the plan's own criterion; I had stated (R) and then not applied it rigorously. P1 mutation. Binding lineage id + version does NOT establish (R). _buffer hashes name/role/shape/dtype/version/access/parents and NOT contents, so two buffers with identical metadata and different bytes share an id: a replay binding 'version N' can bind different bytes and produce a different gradient silently — the exact failure the gate exists to prevent. The product now binds a content digest (or an immutable snapshot, with a version-to-content store as the alternative design), and E3's acceptance gains a negative test: bytes changed under an unchanged lineage id and version must be REJECTED. Metadata identity is necessary, not sufficient. P1 collectives. Issue order alone does not give (R) either: floating-point addition is non-associative, so the reduction tree is part of the value. Measured and recorded as §5.3 — 1024 f32 values, identical inputs, identical issue order, three DIFFERENT bit patterns for sequential (-50370.79), pairwise (-50370.76) and ring (-50370.758), with the ring result changing again with rank count. LANGUAGE_AND_IR_SPEC §11 already required 'fixed collective ordering and reduction trees'; the first draft bound only the first half. pi now binds the reduction tree/algorithm and topology, E4 fails closed on a changed tree, and bit-identity of a collective RESULT is explicitly deferred to native deterministic evidence rather than the mock. P2 README. My insertion matched the first occurrence of the FORGE anchor, which was in the routing table, splitting the epilogue-fusion row into two malformed cells and pointing that question at the effects plan. Routing row restored verbatim; the inventory entry now sits in the inventory table. P1 backends. Sync key W4-EFFECTS-1-2026-08-25 in all four queues with architecture-specific outcomes: rocm and x86 follow-up required as the two named E5 acceptance hosts (rocm owns the hardest class — native RCCL determinism), nvidia and apple follow-up-on-adoption with what each inherits (NCCL deterministic algorithm selection; Apple's no-third-representation constraint). No code and no device claim in this PR. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
All four fixed in 6e6fbc6. Two of them are corrections to the plan's own criterion — I stated (R) and then failed to apply it rigorously in exactly two places. P1 (mutation binds metadata, not contents) — correct, and it defeats the criterion. P1 (collective reduction tree) — correct, and I've made it measured rather than argued. Floating-point addition isn't associative, so the tree is part of the value. Same 1024 f32 values, identical inputs, identical issue order:
Three distinct bit patterns, max gap 3.1e-2, and the ring result changes again with rank count. You're right that P2 (README) — my bug. The insertion matched the first occurrence of the FORGE anchor, which was in the routing table, splitting the epilogue-fusion row into two malformed cells and pointing that question at the wrong plan. Routing row restored verbatim; the inventory entry moved to the inventory table. P1 (backends) — added. Sync key Still no code and no device claim in this PR — it remains the scope-before-build deliverable. 🤖 Generated with Claude Code |
The scope-before-build deliverable for the last open item of queue order 2 — "one physical packet family with admissible effects." No code; this is the plan you asked for before implementation, with every load-bearing claim measured rather than assumed.
The criterion, stated explicitly
A recorded product
π(E)is sound iff:E's write-set is contained in valuesπnames.Both halves are load-bearing: (R) alone admits an op that reproduces its own value while corrupting a neighbour's state; (C) alone admits an op that touches nothing but returns different numbers on replay. And both must be verifier-checked, not producer-asserted.
Per-class verdicts, each with its enabling fact measured
state_buffer_lineage.v1πsatisfies (R)Measurements (§5)
RNG — the facts §3.1 rests on: bit-identical replay (max abs diff 0.0); child streams distinct with max |corr| 0.032 inside the
3/√n = 0.047noise band; zero collisions over 800split/fold_inderivations; per-rank disjoint across 8 ranks; KS vs N(0,1) on 200k draws p = 0.55.Mutation — a precondition found while scoping: the lineage identity separates
version,shape,access,parents,role(each verified individually) but hardcodesdtype="f32"with no caller override. Nothing collides today since every lineage is f32, but mixed-precision recorded state (bf16 master weights, fp8 optimizer state) would alias two materially different buffers. That's the same defect class as the MegaMoE schedule-digest fix in #625, so it's listed as a precondition of the slice, not a follow-up.Five slices
E1 product ABI + verifier → E2 keyed RNG (dropout) → E3 mutation on the existing lineage → E4 collective identity → E5 one physical family end to end on x86 + gfx1151. Acceptance bars are set at bit-identity of replay, which a distributional check cannot establish.
§6 lists what the plan refuses to do — notably, no gate is weakened to make a family fit, and mock execution never stands in for a multi-rank numerical claim.
Registered in the compiler README authority chain;
test_audit_docs.pygreen (it caught a missing map link, which is now fixed).🤖 Generated with Claude Code