Skip to content

board+plan: W0 custom-space census blocks the 0xC4 custom axis #1028

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
AdaWorldAPI merged 1 commit into from
Aug 25, 2026
+106 −1
Merged

board+plan: W0 custom-space census blocks the 0xC4 custom axis #1028

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
88 changes: 88 additions & 0 deletions .claude/board/EPIPHANIES.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,3 +1,91 @@
## 2026-08-25 — E-W0-THE-SPACE-ORDINAL-IS-A-RANK-RELATIVE-TO-A-TABLE-THE-CLASSID-NEVER-NAMES-1 — W0 run: zero custom spaces in 94,536 rows, so the defect is LATENT; but the mechanism is worse than the conjecture and blocks the mint's space axis anyway

**Status:** FINDING — [MEASURED] (census over the full 4-binary corpus)
+ [FALSIFIED IN CODE] (a test against the shipped `CustomSpaceTable` API,
written, run green, reverted — no source change landed).
Closes plan `r2il-machine-semantic-contract-v1.md` W0 and open item O3.
**Confidence:** High. The census is exhaustive over the corpus; the
collision is demonstrated, not argued.

### The census — the defect is LATENT, not live

Every `at` field of all 94,536 ore rows decoded (16-byte `VarnodeFacet`,
lo-u16 of the classid word):
Comment on lines +12 to +13

@chatgpt-codex-connector chatgpt-codex-connector Bot Aug 25, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Correct the census total

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 👍 / 👎.


| binary | rows | Ram | Register | Unique | Const | **Custom (≥4)** |
|---|---|---|---|---|---|---|
| `stress_test` | 10,003 | 3,423 | 2,461 | 3,064 | 1,055 | **0** |
| `stress_test_opt` | 7,554 | 2,826 | 2,364 | 1,485 | 879 | **0** |
| `vuln_test` | 4,409 | 1,488 | 1,231 | 1,242 | 448 | **0** |
| `build-script-build` | 72,567 | 26,886 | 19,370 | 18,011 | 8,300 | **0** |

Union of discriminants across all four: `{0,1,2,3}`. **No custom space
occurs anywhere.** 0 malformed `at` fields.

So W0's own kill condition — *"same `n`, different meaning across
binaries"* — is **unanswerable by census**: the population is empty. That
is a real result (the x86 lift never produces one here), not a null probe,
and it is why the question had to be taken to the code.

### ⊘ My §3 conjecture named the WRONG mechanism, and the real one is worse

The plan's §3 said `Custom(n)` is *"a per-binary ordinal lifted out of the
program"*. **Wrong.** The table is built by `CustomSpaceTable::from_arch`
from `ArchSpec.spaces` — per ARCHITECTURE, not per binary. Within one arch
every binary shares one table, so the ordinal IS stable across the four
binaries, exactly as a reading should be.

The actual defect is one level up. `ordinal_of` is
`CUSTOM_ORDINAL_BASE + binary_search_position(raw)` — **the lo-u16 is the
RANK of the raw id inside whichever table interned it**, and the classid
does not name that table. Demonstrated against the shipped API:

```
arch_a = from_ids([10,20,30]) arch_b = from_ids([20,30,40])
raw_of(4) = 10 raw_of(4) = 20 ← same ordinal, different space
ordinal_of(20) = 5 ordinal_of(20) = 4 ← same space, different ordinal
⇒ project(Custom(10), arch_a) and project(Custom(20), arch_b)
are BYTE-IDENTICAL VarnodeFacets.
```

And the raw `n` feeding that rank is itself order-dependent upstream —
two independent sources, both counters: `r2sleigh-lift/src/context.rs:147`
(`Custom(next_custom_space); next_custom_space += 1` — registration order
during ArchSpec construction) and `disasm.rs:91` (`Custom(idx)` — the raw
SLEIGH address-space table index, as a fallback). So the lo-u16 is a rank
over a counter: **two stages of order-dependence, zero of identity.**

### Verdict — the space axis is BLOCKED from the `0xC4` mint as carved

Not for the conjectured reason. The ratified law says *CLASSID SELECTS THE
READING*; a reading must be self-describing at the address. This one is
self-describing only **relative to an ArchSpec that is nowhere in the 16
bytes**. Two facets from two arches collide on the same classid while
denoting different spaces — the classid stops being an address.

- **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.
Comment on lines +66 to +68

@chatgpt-codex-connector chatgpt-codex-connector Bot Aug 25, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Keep fixed discriminants out of the app-prefix half

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 👍 / 👎.

- **The custom axis must not be minted at `0xC4` in its current carving.**
Options, none decided here: name the arch in the address; use the raw
SLEIGH space id rather than a rank; or move the custom space out of the
classid into the payload/edge. That is an OGAR mint question, not a
ruff-local one.

**Prior art credited, not claimed:** `facet.rs:18-20` already carries a
`⚠ Known tension` doc comment recording that the space discriminant is a
shape ordinal in the lo half against OGAR's rule, and defers the carving
to PR 3. This entry supplies what that note lacked — the measurement, the
mechanism, and the collision.

### Why this matters NOW rather than later

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
Comment on lines +83 to +86

@chatgpt-codex-connector chatgpt-codex-connector Bot Aug 25, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Verify the claimed 6502 collision

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 👍 / 👎.

says the time is before the mint, not after.

## 2026-08-25 — E-R2IL-MACRO-VOCABULARY-TRANSFERS-ACROSS-COMPILER-AND-LANGUAGE-1 — a macro vocabulary learned from two gcc binaries fires in unseen gcc code at −0.6% density and in unseen rustc code at −4.7%, both outside a marginal-preserving null

**Status:** FINDING — [MEASURED] (held-out transfer + two pre-registered
Expand Down
19 changes: 18 additions & 1 deletion .claude/plans/r2il-machine-semantic-contract-v1.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -118,6 +118,23 @@ The open item O3 currently reads *"does `Custom(u32)` fit the 16-byte
projection?"*; under this reading the question is not whether it fits but
that it does not belong. **CONJECTURE** — the falsifier is in §6.

> **⊘ RESOLVED 2026-08-25 by W0 — and the conjecture above named the WRONG
> mechanism.** `Custom(n)` is NOT per-binary: the table is built by
> `CustomSpaceTable::from_arch` from `ArchSpec.spaces`, i.e. per
> ARCHITECTURE, so within one arch the ordinal is stable across binaries.
> The real defect is one level up — `ordinal_of` returns
> `CUSTOM_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. Two facets from two arches are byte-identical
> while denoting different spaces (demonstrated against the shipped API).
> Census: **0 custom spaces in 94,536 rows across all four binaries** — the
> case is LATENT on x86 and fires first on the 6502/C64 arc. Verdict: fixed
> spaces 0–3 stay; the custom axis is BLOCKED from the `0xC4` mint as
> carved. Full entry:
> `E-W0-THE-SPACE-ORDINAL-IS-A-RANK-RELATIVE-TO-A-TABLE-THE-CLASSID-NEVER-NAMES-1`.
> Prior art: `facet.rs:18-20`'s own `⚠ Known tension` note flagged the
> shape-ordinal problem first; W0 supplies the measurement and mechanism.

---

## §4 — THE ANSWER: how a session should store R2IL
Expand Down Expand Up @@ -190,7 +207,7 @@ per workspace rule (grindwork → Sonnet; accumulation/orchestration/gates

| 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 |

@chatgpt-codex-connector chatgpt-codex-connector Bot Aug 25, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Enforce the custom-space verdict in the W2 gate

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 👍 / 👎.

| **W1** | the R2IL V4 tenant spec: ClassView carving of the 12 bytes for Op / Varnode-ref / macro-ref rows, written against `le-contract.md` §3 | field-isolation matrix test (I-LEGACY-API-FEATURE-GATED): write each field, assert all others unchanged. Any aliasing ⇒ re-carve |
| **W2** | the `0xC4 BinaryLifting` mint (ruff PR3 arc, O5) — container concepts only, gated on W0's verdict for the space axis | mint request names concepts; a concept that encodes per-binary content is rejected by W0's rule |
| **W3** | palette wiring: macro-id byte → `{Learned,Explore}Palette[id]` → R2IL×BPE microcode, `ogar-loco` routing | B4-equivalent byte-exact round-trip through the palette; admission stays MUL's/the triangle's, NEVER the wiring's |
Expand Down