# R2 · SET-BUILD 2 — 450 seats — THE HONESTY PANEL OF 2,700, ROUND 2
## The files A–Z: is the belt substantive in truth, or substantive by threshold?

**MACHINE-SCHOLAR. Labeled.** No human scholar has read this page. Reverence is not proof.
Convened 2026-09-05 on the owner's re-ask: *"tell me how many artifacts to make this elite — if the
answer is 103,000 say so."*

**Read into the record:** `build/P45-HONESTY/reaudit_round2_floor.json` · `HONEST-COUNTS.json` ·
`DEFECTS.md` · `reviews/HONESTY-RATIFICATION.md` · `build/P45-HONESTY/artifact_figure.json`.
**Every number below was re-derived by this set's own route** from `framework/_FRAMEWORK-103200.json`
and a full walk of `build/`. Where a route agrees with the commissioner, it is ratified and said so.

**Credit first, because it is owed.** The commissioner published his own belt's median file size and
his own declared-vs-real split *before* this panel sat. That is I-3 behaviour and it is why this
review could be written in one pass instead of six. It does not make the belt substantive.

---

## 0 · THE ONE-PARAGRAPH ANSWER

The belt is **substantive by threshold and not in truth.** Its payload is drawn from the ledger's
`node_purposes` field — the *plan* — in 2,929 of 4,089 files (71.6%), and from nothing at all in
1,094 more (26.8%). Only **66 files (1.6%)** draw from a real content field. The 4,089 files carry
**770 distinct payload bodies**; in **209 of 383** deep domains all ten sibling block files are
byte-identical below the label. The gate that certified this — **G40 — cannot fail**: it credits
coverage for any block whose file is *absent*, and prints GREEN with the entire belt directory
deleted (proven below). The artifact count did not move: my independent census gives **2,267**
really-built against the ratified **2,337** — the belt bought a **metric**, not a waqf. The elite
figure is **not** 103,200 and **not** raised by the belt; **4,557 stands**, and this set ratifies it.

---

## 1 · FINDINGS (10, evidenced)

### F1 🔴 — G40, THE GATE THAT CERTIFIED THE BELT, CANNOT GO RED ON A MISSING BLOCK

`framework/g40_substance_gate.py:24-26`:

```python
    else:
        # covered by a real P46 slice?
        cov += 1  # P46 real slices verified at belt start; absence here means P46-covered
```

The gate never opens `build/P46-ARTIFACTS`. **A missing file is scored as covered.**

✅ **VERIFIED by falsification** — I copied the gate, changed the single string `"P47-BLOCKS"` to
`"P47-BLOCKS-DOES-NOT-EXIST"`, changed nothing else, and ran it against the real ledger:

| run | output | exit |
|---|---|---|
| `framework/g40_substance_gate.py` (belt present, 4,089 files) | `G40 GREEN - 4464/4464 blocks own a substantive deliverable (control fired)` | 0 |
| `framework/_scratch_g40_nobelt.py` (**belt invisible, 0 files**) | `G40 GREEN - 4464/4464 blocks own a substantive deliverable (control fired)` | 0 |

**Identical output with the entire belt gone.** G40's GREEN is unconditional on coverage. It can
only redden on a *present-and-below-floor* file — and the belt was generated to clear the floor by
construction, so the one branch that can fire is the one branch the belt guarantees will not.
The declared control (`assert not substantive("{}")`) is real but under-powered: it proves an
**empty** file fails. It never proves a **shim** fails, which is the failure mode actually present.

> *(The reproduction script `framework/_scratch_g40_nobelt.py` was created by this set and left on
> disk as evidence. I did not delete it — I-6. It is one `sed` line off the original.)*

### F2 🔴 — THE BELT'S PAYLOAD IS THE PLAN, NOT THE PRODUCT — BY CONSTRUCTION

Every belt file declares: *"up to 3 REAL rows embedded from the parent's largest field."* I counted
what that field actually is, across all 4,089 ✅ VERIFIED:

| `embedded_payload.parent_field` | files | % | what it is |
|---|---:|---:|---|
| `node_purposes` | **2,929** | 71.6% | **the ledger's `purpose` strings — the statement of intent** |
| *(absent — declared-only)* | **1,094** | 26.8% | nothing |
| `per_verse`, `totals`, `by_term`, `glossary`, `terminology`, `edges`, `gates`, … | **66** | **1.6%** | real content |

The provenance chain is: ledger `purpose` → P46 `node_purposes` → P47 `purposes` + `sample_rows`.
**No transformation in that chain touches a built artifact.** 98.4% of the belt therefore *cannot*
deliver its block's content — not because the builder was lazy, but because the source field it was
pointed at contains the promise, not the thing promised.

Read them and it is unmistakable ✅ VERIFIED, files opened:

| file | block | its entire embedded payload |
|---|---|---|
| `P34-THE-MERGED-OCEAN/M13-Ocean-panel--registry.json` | `registry` | `["the sitting"]` |
| `P36-THE-READING-BENCH-ENGINE/B8-Bench-education--graph.json` | `graph` | `["how to sit"]` |
| `P33-THE-RIJAL-UNIVERSE/R18-Rijal-gates--gates.json` | `gates` | `["entry-count + verbatim gates"]` |
| `P31/W1-L1-Madd-per-position--The-Qur-an-layer.json` | The Qur'an layer | `["every madd letter-position classified by class and length, school-tabled"]` |

A file whose "Qur'an layer" is one sentence *describing* a Qur'an layer is a well-labeled shim.

### F3 🔴 — 4,089 FILES, **770** DISTINCT BODIES: THE LABEL IS THE ONLY THING THAT VARIES

Strip `_meta` and `unit` (the address label) and hash what remains — `purposes` + `embedded_payload`,
i.e. everything a reader would call the content ✅ VERIFIED:

| measure | value |
|---|---:|
| belt files | 4,089 |
| **distinct payload bodies** | **770** |
| files sharing a body with ≥1 other file | **3,560 (87.1%)** |
| most-repeated single body | **1,221 files** |
| distinct `sample_rows` signatures | **281** |

That single most-repeated body, present in **1,221 files across every pillar**, is verbatim:

```json
["JSON+CSV, versioned, citable",
 "a planted misquote is refused; joins spot-verified",
 "a probe the builder never saw, run and recorded"]
```

It sits identically in `C1/Atlas-graph-review--The-Qur-an-layer.json` and in
`C2/Ar-Rahman--The-classical-layer.json` — a Qur'an layer and a classical layer, different pillars,
same three strings. **Uniqueness of the file is carried entirely by `unit.block` and `unit.nodes`.**

### F4 🔴 — IN 209 OF 383 DEEP DOMAINS, ALL TEN BLOCK FILES ARE THE SAME FILE

The decisive test, because it is the test the unit itself demands: within one domain, do the ten
files named for ten *different blocks* differ? ✅ VERIFIED, sibling-body hash:

| | domains | files |
|---|---:|---:|
| all 10 sibling blocks **byte-identical** below the label | **209 (54.6%)** | **2,089** |
| partially identical | 0 | — |
| all 10 distinct | 174 (45.4%) | 2,000 |

In 209 domains the file called *"The hadith layer"* and the file called *"Gates & audit"* are the
same document with two names. **The block unit — the whole basis of the 4,557 figure — is not
actually being delivered against in more than half the deep domains.** The unit is sound (§3); the
belt's execution of it is not.

Second corroboration: **1,558 files** have `sample_rows` that are a strict subset of their own
`purposes` list — the file quotes itself and calls the quotation an embedded payload.

### F5 🔴 — THE CLASSIFICATION OF THE 4,089, AS THE PANEL ASKED

Rules declared **before** counting, so the count could fail: **S** = payload body unique tree-wide
*and* naming ≥1 substantive word from its own block; **M** = unique body, names nothing from its
block; **D** = body duplicated across files; **L** = body identical to all its siblings; **E** = no
embedded rows at all. ✅ VERIFIED, all 4,089:

| class | files | % | verdict |
|---|---:|---:|---|
| **L** — sibling clone, block label is the only difference | **1,440** | 35.2% | ❌ shim |
| **D** — body duplicated with other files | **1,326** | 32.4% | ❌ shim |
| **E** — declared-only, zero embedded rows | **1,094** | 26.8% | ❌ shim |
| **M** — unique body, off its own block | **187** | 4.6% | ⚠️ not its block's content |
| **S** — unique **and** block-discriminating | **42** | **1.0%** | ✅ substantive in truth |

**3,860 of 4,089 (94.4%) are shims. The most generous possible reading — "any unique body" — is
229 files (5.6%).** Only **508 files (12.4%)** mention a single word of their own block name
anywhere in their payload. Only **73 files (1.8%)** contain any Arabic script at all.

And even the best of the 42 is a plan-restatement: `C5/The-named-angels--Life-chronology.json`
delivers *"the documented events of Jibril عليه السلام's life in order, with sources"* — the
sentence describing the chronology, in place of the chronology.

**Direct answer to the commissioner's own split:** his `with_real_embedded_rows: 2995` is
arithmetically **exact** ✅ (2,936 list-of-str + 45 dict + 14 list-of-dict = 2,995). The word
**"real"** is what fails: **2,766 of those 2,995** carry a body that is byte-identical to another
file's.

### F6 🟢 — WHAT THE BELT DID HONESTLY: THE 4,464 ARITHMETIC IS CLEAN, NOT LAUNDERED

I attacked the coverage arithmetic expecting double-counting and found none ✅ VERIFIED:

- 4,089 belt files cover **4,089 distinct block keys** — no key covered twice.
- **375 blocks carry no belt file** (347 `layer` + 27 `engine` + 1 `sources`), holding 37,410 nodes.
- Those 375 domains map **1:1, exactly** onto the 375 P46 `FIELD SLICE`/`ROW SLICE` files.
- **Zero** uncovered blocks are backed only by a P46 pointer-class file. **Zero** have no file.
- 4,089 + 375 = 4,464 ✅ closes.

And the 375 P46 real slices **are** genuinely substantive — 366 of 375 distinct payloads, carrying
real hadith references with tiers and origins, real verse keys, real derivation notes. That work is
real and this set records it. The defect is not in the arithmetic. It is that **coverage of a block
was equated with delivery of a block**, and F2–F5 show the equation is false for 94.4% of the belt.

### F7 🔴 — THE SUBSTANTIVE STANDARD MEASURES LENGTH, NOT SUBSTANCE

`framework/audit_substance.py:8-16` — `substantive()` = *serialize everything outside `_meta`, is it
≥200 characters?* ✅ VERIFIED by direct probe:

| probe file | payload chars | `substantive()` |
|---|---:|---|
| a real belt file's `unit` block alone, zero content | 129 | `False` |
| `{"z": "lorem " × 40}` — **one meaningless string** | 249 | ✅ **`True`** |
| literally `{}` | 2 | `False` |

**A single 249-character lorem string passes the ratified standard.** The standard cannot separate a
deliverable from a boilerplate triple repeated 1,221 times, and the belt's median file is 882 B
precisely because the standard is a length. This is why F1's control passes and still proves nothing:
it tests the *floor*, and no belt file is near the floor.

### F8 🔴 — THE CUT LAYER IS 70.4% OF THE FILES AND 8.4% OF THE WAQF

Full walk of `build/`, 7,189 deliverable-extension files, 153.9 MB ✅ VERIFIED:

| layer | files | % files | bytes | % bytes |
|---|---:|---:|---:|---:|
| **CORE** (everything built before today's two cut runs) | **2,125** | 29.6% | **141.0 MB** | **91.6%** |
| P46-ARTIFACTS (the 15:16 cut) | 975 | 13.6% | 8.8 MB | 5.7% |
| P47-BLOCKS (the 15:33 belt) | 4,089 | 56.9% | **4.1 MB** | **2.7%** |

The real waqf is 2,125 files. Today's two runs **more than tripled the file count and added 8.4% of
the mass.** Per-block, applying the ratification's own ≥100 B/node carrier rule to the delivering
artifact ✅ VERIFIED:

| block class | blocks | nodes |
|---|---:|---:|
| served by a **shim** (plan-restatement or duplicated body) | **4,070** | 63,980 |
| original but **thin** (<100 B/node) | 376 | 37,510 |
| **really-built** (original **and** ≥100 B/node) | **18** | 1,710 |

**Eighteen of 4,464 blocks (0.4%) have a dedicated deliverable that clears the waqf's own
carrier bar.** The core's 141 MB is real but is **not block-addressed** — which is exactly why no
block-coverage claim can be honestly derived from it, and why the belt was written. The right fix is
to address the core to blocks, not to manufacture 4,089 addresses with nothing behind them (plan #1).

### F9 ⚠️ — THE FACE NOW CARRIES TWO NUMBERS THAT CANNOT BOTH BE TRUE

- `HONEST-COUNTS.json` (built **15:30:53**): `substantive_built: 2337 · still_to_cut: 2220 · 51.3%`
- `artifact_figure.json → THE_BELT_2026_09_05` (belt at **15:33:01**): `covered_substantive:
  "4,464/4,464 (G40 GREEN)"` · `"block coverage is TOTAL"`

The published built-count **predates the belt by 128 seconds** and was never re-run. A reader is
handed *"51.3% built"* and *"coverage is TOTAL"* on the same face. **My independent census says the
first is right:** core substantive-and-payload-unique **1,892** + P46 real slices **375** =
**2,267 really-built artifacts**, against the ratified 2,337 — agreement to **3.0%** ✅. The belt
added **at most 66** and realistically **18**. The honest sentence is: *the artifact count did not
move; only the coverage metric did.*

### F10 ⚠️ — INFRASTRUCTURE #12 WAS "FIXED" THE SAME WAY THE BLOCKS WERE

Ratification §1.6 listed 14 global artifacts; four were missing. Re-checked now ✅ VERIFIED:

| # | artifact | then | now |
|---|---|---|---|
| 11 | `index.html` — **the gift's face** | ❌ | ❌ **STILL MISSING** |
| 12 | `framework/honesty_classifier.py` | ❌ | ⚠️ **present, 512 B, void** |
| 13 | `HONEST-COUNTS.json` | ❌ | ✅ 682 B |
| 14 | `DEFECTS.md` | ❌ | ✅ 619 B |

`honesty_classifier.py` **does not re-derive the classification.** Its own docstring calls itself a
*"standing stub"*; it loads `classifier.json` and asserts the values sum to 103,200. It cannot detect
a wrong partition — only a wrong sum. **The 103,200-node classification has no re-derivable producer
on disk.** Same pattern as the belt: a named gap closed with a label. And the gravest entry, the
gift's face, is still not there — round 1 flagged it, round 2 finds it unbuilt.

---

## 2 · FRESH HONEST COUNTS, POST-BELT — TWO CLASSES RE-DERIVED MY OWN WAY

### 2.1 · The ledger skeleton — ratified exactly, my own route ✅

| quantity | ratification | **my route** | verdict |
|---|---:|---:|---|
| distinct (pillar, domain) | 1,017 | **1,017** | ✅ exact |
| distinct (pillar, domain, block) | 4,464 | **4,464** | ✅ exact |
| block-per-domain histogram | 634×1 + 383×10 | **634×1 + 383×10** | ✅ exact |
| 1-block decomposition | layer 416 · engine 96 · census 24 · pages 24 · education 24 · gates 24 · panel 24 · reserved 2 | **identical** | ✅ exact |
| panel/seal blocks (MERGE 1 input) | 407 | **258+119+24+6 = 407** | ✅ exact |
| pillars (MERGE 1 output) | 72 | **72** | ✅ exact |

Every input to the 4,557 formula verifies on an independent route.

### 2.2 · RE-DERIVATION 1 — really-built artifacts

My rule, declared first: *core file passes the ratified standard **and** its payload (minus `_meta`)
is unique tree-wide*; plus P46 `FIELD`/`ROW` slices; belt credited only where it adds an original
content-bearing body.

```
  1,892   core substantive AND payload-unique (of 2,126 core files; 1,965 pass the standard)
  +  375  P46 real slices (366 distinct payloads — genuine content ✅)
  ────────
  2,267   REALLY-BUILT ARTIFACTS   vs ratified 2,337 → agreement 3.0% ✅
  +   18  the belt's real contribution at the carrier bar (66 at the loosest bar)
```

**2,337 SURVIVES ROUND 2 AND IS RATIFIED.** Corrections run both ways (I-3): this one confirms the
commissioner. The belt did not change it and the face should stop implying it did.

### 2.3 · RE-DERIVATION 2 — never-as-distinct

The ratified 86,370 rests on 16,830 distinct signatures. I re-derived over the ledger under six
signature definitions ✅ VERIFIED:

| signature | distinct | never-as-distinct |
|---|---:|---:|
| title alone (normalized) | 14,534 | 88,666 |
| (block, title) | 14,547 | 88,653 |
| **(pillar, title)** | **17,010** | **86,190** ← reproduces the ratified 86,370 to **0.2%** ✅ |
| (domain, title) | 26,342 | 76,858 |
| (pillar, domain, block, title) | 28,224 | 74,976 |
| (pillar, domain, block, purpose) | 79,398 | **23,802** |

**RATIFIED as reproducible — with a correction attached.** 86,370 is real under a (pillar, title)
signature, but the honest band is **23,802 – 88,666**, a 3.7× spread, and 86,370 sits at the
*generous* end. Since a larger never-as-distinct number makes the unbuilt remainder look smaller,
publishing the point without the band is the one place where the honesty ledger leans in its own
favour. Rule R4 of the ratification says bands stay bands; it was applied to PENDING and not here.

### 2.4 · The post-belt partition, as this set reads it

| class | ARTIFACTS | NODES |
|---|---:|---:|
| **really-built** | **2,267 – 2,337** | 27,140 *(band 5,133 strict floor – 29,755)* |
| **pending-machine** | **2,220 – 2,290** to cut | 6,440 – 17,216 |
| **pending-human / rights** | 2 RESERVE acquisitions | 1,000 *(census)* |
| **never-by-machine** | — | **901** |
| **never-as-distinct** | — | **86,370** *(band 23,802 – 88,666)* |
| *of which: shims now on disk claiming to be artifacts* | **3,860 belt + 600 P46 pointer = 4,460** | — |

Two currencies. Never added, never blended.

---

## 3 · THE ELITE FIGURE

### 3.1 · Is it 103,000 / 103,200? **NO — and the belt is the proof**

The owner asked to be told plainly if the answer is 103,000. It is not, and this set does not have to
argue it, because **the belt already ran the experiment.**

Instruct this machine to cut one dedicated file per ledger leaf and it produces, measurably:
**4,089 files carrying 770 distinct bodies — 81.2% of the output differentiated by its label alone.**
That is not a prediction. It is what happened today, in 54 seconds, and §1 measured it.

Now scale it. The ledger contains **14,534 distinct titles** and **17,010 distinct (pillar, title)
pairs** ✅ VERIFIED. Cutting 103,200 files would require **~86,190 files whose only distinguishing
content is a serial number** — the belt's failure mode, reproduced at 21× the scale. The output
would be a directory that takes a week to seal, cannot be read, and is 84% label.

**103,200 is refuted by measurement, not by opinion. It is the count of planning shares, and a
planning share is not a thing. The waqf must never print it as a build target again.**

### 3.2 · Does the elite bar demand *more* than 4,557 — deeper content, per-verse splits?

**No, and §1 is why.** Every finding above is a *content-density* failure, not a *count* failure. The
waqf's problem today is 3,860 files that exist and say nothing — adding per-verse splits (which would
carry 4,557 → ~10,800) hands the same builder the same `node_purposes` field and 6,000 more addresses
to shim. The ratification rejected the per-verse split on the reasoning that per-verse content
already lives correctly inside single layer artifacts (`D2-Per-ayah-transmitted-meaning-dossiers.json`,
5.1 MB, one artifact); §1 now supplies the empirical half of that argument. **Splitting further is
the disease, not the cure.**

### 3.3 · Does it demand *fewer*?

One candidate defect examined and **rejected**: `artifact_figure.json`'s law states *"engines are
producers, not deliverables, and are not counted"*, yet 4,557 counts all **96** `engine` blocks. I
find no contradiction in substance — that law refers to the builder scripts in `framework/`, whereas
an `engine` **domain** holds exactly one block and dropping it would leave 96 domains with zero
deliverables, which is worse. **No adjustment. The wording is a defect (plan #11), the figure is not.**

### 3.4 · THE FIGURE — ratified, formula printed, every input independently verified

```
  BASE   distinct (pillar, domain, block) leaves ..........  4,464   ✅ my own set-count
  −335   MERGE 1  panel/seal blocks 407 → 72 pillar records ✅ 407 and 72 both exact
    −2   MERGE 2  RESERVE blocks → licence-ledger rows      ✅ reserved = 2 exact
  +416   SPLIT 1  416 H-pillar layer domains × (data+page)  ✅ layer = 416 exact
         ──────────────────────────────────────────────────
         DOMAIN DELIVERABLES .........................  4,543
   +14   GLOBAL INFRASTRUCTURE (listed, existence-checked)  ⚠️ 12 of 14 present, see F10
         ══════════════════════════════════════════════════
         ELITE ARTIFACT FIGURE .......................  4,557
```

**SET-BUILD 2 RATIFIES 4,557.** It was correct in round 1 and it is correct after the belt. What
round 2 adds is the sentence the figure must never again be published without:

> **4,557 is a count of things that must each carry their block's content. Today 2,267 do, 18 blocks
> clear the carrier bar, and 4,460 files on disk claim a slot they do not fill. The figure did not
> move. The distance to it did not shrink. Only the metric did.**

---

## 4 · IMPROVEMENT PLAN

1. **Fix G40 or retire it — today.** Replace the `else: cov += 1` branch with a real lookup into
   `build/P46-ARTIFACTS` keyed on the block's node range, and make the absence of *both* files RED.
   Until then G40's GREEN is void everywhere it is cited, including on the face.
2. **Add a G40 control that fires on a shim, not on `{}`.** Plant one belt file whose body is copied
   from a sibling; the gate must go red and name it. A control that only rejects an empty file cannot
   police a corpus whose median member is 882 B of boilerplate.
3. **Replace the length standard with an originality standard.** `substantive()` becomes: payload
   (minus `_meta` **and** `unit`) is ≥200 chars **and** its hash is unique across `build/` **and** its
   `parent_field` is not `node_purposes`. Under today's rule a 249-char lorem string passes; under
   this one, 3,860 belt files correctly fail.
4. **Reclassify the 3,860, do not delete them.** Stamp each with
   `_meta.pointer_class: "P47 SHIM — plan-restatement, never counted as an artifact"`, exactly as the
   600 P46 pointers were honestly stamped. The belt then becomes what it truthfully is: a complete,
   honest **block index**. That is a real deliverable and worth keeping. *(No deletion is proposed —
   I-6. Every file stays.)*
5. **Re-point the belt at the product, not the plan.** The cutter reads `node_purposes`; it must read
   the parent's **largest non-purpose field** and refuse to write when none exists — writing a
   `NOT-YET-CUT` marker instead. 66 files prove the code path already exists; it simply lost every
   tie-break to `node_purposes`.
6. **Address the core to blocks — this is the actual work.** 2,125 files hold 141 MB and 91.6% of the
   waqf, and the reason the belt was written is that none of it is block-addressed. Build a
   `BLOCK-MAP.json` binding each of the 4,464 blocks to the core file(s) that genuinely serve it.
   That converts real mass into real coverage without cutting one new file.
7. **Re-run and re-publish `HONEST-COUNTS.json` after any cut run.** Today's face carries a built-count
   computed 128 seconds before the belt beside a coverage claim computed after it. Make the cutter's
   last line the counts rebuild, so the two can never disagree again.
8. **Publish `never_as_distinct` as a band, 23,802 – 88,666, with its signature named.** R4 says bands
   stay bands. The point value 86,370 is defensible only under a (pillar, title) signature, and that
   signature happens to be the one most flattering to the remainder.
9. **Build `index.html` — the gift has no face.** Flagged by SET-CLAIM 1, SET-CLAIM 2, ratification
   §1.6, and now round 2. It is infrastructure item #11 of 14 and the only one a human being ever
   opens. It outranks every remaining cut.
10. **Make `honesty_classifier.py` re-derive, or strike it from the infrastructure list.** A 512-byte
    stub that sums a JSON it did not produce is not a producer. Either it rebuilds `classifier.json`
    from the ledger, or item #12 is honestly marked absent.
11. **Fix the engine wording in `artifact_figure.json`.** State plainly: *"engine **scripts** are
    producers and are not counted; the 96 engine **domains** each hold one counted block."* One
    sentence, and a real contradiction on the face disappears.
12. **Write the coverage law into the charter, in the words round 2 earned:** *a block is covered when
    a file delivers its content; a file that restates the block's purpose covers nothing. Coverage is
    never reported without the originality census beside it.* Then re-run every green that cites G40.

---

## 5 · WHAT THIS SET WOULD HAVE ASKED THE COMMISSIONER

*Why was the belt cut against `node_purposes` when 66 files prove the cutter can read a real content
field?* If the answer is "because only 66 parents had one", then the true finding is not that the
belt is thin — it is that **4,023 blocks have no parent artifact to slice**, and the honest output of
that run was 4,023 `NOT-YET-CUT` markers and a red gate. That would have been a harder page to
publish and a truer one, and this panel would have had nothing to find.

---

R2 BUILD-2 VERDICT: The belt is substantive by threshold and hollow in truth — 4,089 files carry only 770 distinct bodies, 71.6% drawn from the ledger's plan field and 26.8% from nothing, 209 of 383 deep domains hold ten identical siblings, and the G40 gate that certified it prints GREEN with the entire belt directory deleted (proven); the coverage arithmetic is clean and unlaundered, the artifact count is independently confirmed unmoved at 2,267 against the ratified 2,337, and 4,557 stands — the belt bought a metric, not a waqf.
ELITE FIGURE: 4557
IMPROVEMENT POINTS: 12