board+plan: W0 custom-space census blocks the 0xC4 custom axis - #1028
Conversation
…the classid never names
Census over the full four-binary corpus (94,536 rows, every 16-byte
facet decoded): zero custom spaces anywhere, union of discriminants
{0,1,2,3}. W0's own kill condition is therefore unanswerable by census,
which is a real result and the reason the question went to the code.
There the conjecture in section 3 turned out to name the wrong
mechanism, recorded as a correction rather than a silent fix: the table
is per-architecture (from_arch over ArchSpec.spaces), not per-binary, so
the ordinal is stable across the four binaries exactly as a reading
should be. The defect is one level up — ordinal_of returns base + rank,
so the lo-u16 is a rank inside a table the classid never names, over a
raw id that is itself an upstream registration-order counter. A test
against the shipped API (written, green, reverted) shows two varnodes in
genuinely different spaces from two tables projecting to byte-identical
facets.
Verdict: fixed spaces 0-3 stay, being architecture-invariant by
construction; the custom axis is blocked from the 0xC4 mint as carved,
with the carving options named but undecided since that is an OGAR mint
question. The latent case fires first on the 6502/C64 arc, which is why
the timing matters. Credits facet.rs's own prior tension note rather
than claiming the discovery.
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_5db4cb71-dadd-4760-9090-744cdd65d61c) |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1274bffa0a
ℹ️ 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".
| - **Fixed spaces (0–3) are fine and stay.** They are architecture-invariant | ||
| by construction (`facet.rs:23-27` says so), self-describing, and are the | ||
| only ones this corpus uses. |
There was a problem hiding this comment.
When these facets are minted under 0xC4, preserving fixed-space values 0–3 in the low u16 does not make them safe: crates/lance-graph-contract/src/ogar_codebook.rs:267-290 assigns those exact values to Core, OpenProject, Odoo, and Woa, and render_classid treats that half as the app prefix. Any generic render/app-prefix consumer would therefore interpret Register/Ram/Const/Unique as application identities. The verdict should block the whole space-discriminant carving, or explicitly establish and enforce an internal-only exception that never reaches the render path.
Useful? React with 👍 / 👎.
| Every `at` field of all 94,536 ore rows decoded (16-byte `VarnodeFacet`, | ||
| lo-u16 of the classid word): |
There was a problem hiding this comment.
The four reported row totals add up to 94,533 (10,003 + 7,554 + 4,409 + 72,567), not 94,536; each category breakdown also sums to its displayed row total. Since this entry labels the census exhaustive and uses the total again in the plan, either the corpus total or one of the table rows is wrong and the measured result is not reproducible as written.
Useful? React with 👍 / 👎.
| | wave | deliverable | falsifier / kill condition | | ||
| |---|---|---| | ||
| | **W0** | `Custom(n)` census (closes §3's defect + O3): over the 4-binary corpus, count distinct `Custom(n)` and whether the same `n` denotes the same thing across binaries | same `n`, different meaning across binaries ⇒ `Custom(n)` is CONTENT ⇒ it moves OUT of classid into payload/edge before ANY mint. Same meaning everywhere ⇒ reading, stays | | ||
| | **W0** | ~~`Custom(n)` census~~ **RUN 2026-08-25 — see the ⊘ note in §3.** Census: 0 custom spaces in 94,536 rows / 4 binaries (latent). Mechanism falsified in code: the lo-u16 is a rank in an unnamed table; two arches collide byte-identically | **VERDICT: fixed spaces 0–3 stay; the custom axis is BLOCKED from the `0xC4` mint as carved.** The kill condition fired on a third possibility the row did not anticipate — neither "content" nor "reading", but a reading relative to a table absent from the address | |
There was a problem hiding this comment.
The plan now marks W0 complete with a table-relative reading as the reason to block the custom axis, but the unchanged W2 kill condition only rejects concepts that encode per-binary content. Because this finding explicitly classifies the defect as neither content nor an autonomous reading, an executor following the wave table can pass W2 and mint the same custom discriminator this row says is blocked. Update W2's status or falsifier to reject the unnamed-table dependency explicitly.
Useful? React with 👍 / 👎.
| The 6502/C64 arc is precisely where the latent case fires: a second | ||
| ArchSpec means a second table, and ordinal 4 would denote one space in the | ||
| x86 corpus and another in the 6502 corpus with nothing in the address to | ||
| tell them apart. The census says there is time to fix it; the mechanism |
There was a problem hiding this comment.
A second ArchSpec creates another table, but it does not by itself prove that both tables contain ordinal 4 or that their first custom entries denote different spaces. The synthetic from_ids([10,20,30])/from_ids([20,30,40]) example establishes that a collision is possible, not that the x86 and 6502 tables actually collide. Inspect those two shipped tables before stating that the C64 arc is precisely where the defect fires, or describe this as a risk rather than a measured outcome.
Useful? React with 👍 / 👎.
2 participants
One commit (
1274bff). Opened separately from #1027 because it changes W2's status: from "W0 decides howCustom(n)is carved" to "the custom axis must not enter the0xC4mint in this form at all." #1027 merged at35f10aeand cannot carry it.No source change, no mint, no layout change, and deliberately no proposed fix. This PR is a traffic cone in front of the spot where W2 would otherwise keep walking — not a head start on the OGAR decision.
MEASURED
Every
atfield of the four-binary corpus decoded (16-byteVarnodeFacet, lo-u16 of the classid word):stress_teststress_test_optvuln_testbuild-script-build94,536 rows, union
{0,1,2,3}, 0 malformed. Latent in the current x86 corpus — which makes W0's own kill condition ("samen, different meaning across binaries") unanswerable by census, since the population is empty. That is why the question went to the code.FALSIFIED IN CODE
Against the shipped
CustomSpaceTableAPI (test written, run green, reverted — nothing landed):CORRECTION
The plan's §3 conjecture said
Custom(n)is "a per-binary ordinal lifted out of the program". Wrong, and recorded as a correction rather than a silent fix. The table is built byCustomSpaceTable::from_archfromArchSpec.spaces— per architecture, so within one arch the ordinal is stable across binaries exactly as a reading should be.The defect is one level up:
ordinal_ofreturnsCUSTOM_ORDINAL_BASE + rank(raw), so the lo-u16 is a rank inside a table the classid never names — over a raw id that is itself an upstream registration-order counter (r2sleigh-lift/context.rs:147increments a counter;disasm.rs:91uses the raw SLEIGH table index). Two stages of order-dependence, zero of identity.VERDICT
facet.rs:23-27), self-describing, and the only ones this corpus uses.0xC4mint as carved. CLASSID SELECTS THE READING requires a reading that is self-describing at the address; this one is self-describing only relative to an ArchSpec absent from the 16 bytes.NOT DECIDED HERE
Name the arch in the address? Use the raw SLEIGH space identity instead of a rank? Move the custom space out of the classid entirely? An OGAR mint decision — listed, not chosen.
Why the finding is stronger than the original kill condition
It did not answer "content vs reading". It found a third category the W0 row did not anticipate: a reading whose meaning depends on context the address does not carry. Exactly the defect class you want visible before a mint; afterwards it is archaeology with a jackhammer.
The latent case fires first on the 6502/C64 arc — a second ArchSpec means a second table, and ordinal 4 would denote one space in the x86 corpus and another in the 6502 corpus with nothing in the address to separate them.
Follow-on status (not changed in this PR)
Prior art credited rather than claimed:
facet.rs:18-20already carried a⚠ Known tensionnote that the space discriminant is a shape ordinal in the lo half against OGAR's rule. W0 supplies the measurement, the mechanism, and the collision it lacked.Test plan
CustomSpaceTablefalsifier and the probe instrumentation used for the census were both reverted before commit — working tree verified clean.🤖 Generated with Claude Code
https://claude.ai/code/session_01AGVLyRZNEKKBSfBDJfbY3V
Generated by Claude Code