# PANEL WAVE P32 — SEAT PW3 · THE TREEBANK LANDING + THE W4 UNLOCK **Seat**: PW3 · MACHINE-SCHOLAR, labeled · REVIEW ONLY (nothing in this pass wrote to any build layer) **Date**: 2026-09-04 **Laws applied**: `10-WAQF/skills/deep-audit/SKILL.md` — all 19 **Scope**: `00-CORPUS/acquired/irab_treebank/` · `10-WAQF/build/P32-SHAHADAT/W4-S1` + `W4-S3` · `10-WAQF/build/P31-MIZAN/W7-M1/strata_layer.json` (STR-ids) · `10-WAQF/framework/p32_w4_s1.py` **Method**: every count below was re-derived by this seat streaming the sealed CSV with an independent parser (`csv.reader`, UTF-16, tab), written **before** the layer's claims were read (I-2: the baseline must be independent of the check, or the check cannot fail). --- ## VERDICT **The treebank landing is REAL, the acquisition is LAWFUL, and the transmission is FAITHFUL.** Every substantive count in W4-S1 reproduces **exactly** under independent re-derivation — all 25 relation-census values, the case census, the verse coverage, the relation cardinality — and a five-verse content-gate sample matches the source field-for-field, in order, with zero drift. This is the strongest transmission fidelity this seat has measured in the P32 wave. The engine is not fabricating. **But the layer's *declarations* overstate what the engine actually found, in five specific ways** — and every one of them is a law already written in this waqf's own skill file. The headline token count includes 11,157 rows that are not Qur'ānic tokens; a layer titled "the five maf'ūls" publishes three and declares nothing about the two that returned zero; the `source_sha` presented to readers as the provenance seal is the hash of a file the layer never opened; the ids advertised as "stable" are array indices; and the strata total contains at least 30 provably duplicated rows. None of these is fabrication. All five are **honesty-of-declaration** defects, and all five are cheap to fix. A seal placed today would bless the overstatements along with the good work. **SEAL BLOCKED.** Items and remedies below; four are one-line fixes to the builder. --- ## FINDINGS ### 🔴 F1 — `source_sha` seals a file the layer never read (SYSTEMIC: 164 layers) **Severity: HIGH — provenance/CHAIN LAW (10), SINGLE-SOURCE LAW (11)** **File**: `10-WAQF/framework/p32_w4_s1.py:49,67` → `10-WAQF/build/P32-SHAHADAT/W4-S1/irab_source_layer.json:5`, `W4-S3/five_mafuls_layer.json:5` The builder reads **only** `00-CORPUS/acquired/irab_treebank/noorbayan/Quranic.csv` (`p32_w4_s1.py:15`). It then stamps `"source_sha": SI._sha(SI.RAW)`. `SI.RAW` is `00-CORPUS/_morphology_raw.txt` (`sighah_index.py:24`) — the QAC morphology file, **not** the treebank. ``` layer source_sha = fbc8744a98b36edb2362ee63a72d77c2079e929b2128dad96b41269c6ba199bb sha256 00-CORPUS/_morphology_raw.txt = fbc8744a98b36edb2362ee63a72d77c2079e929b2128dad96b41269c6ba199bb ← this is what it seals sha256 .../noorbayan/Quranic.csv = 38c82933b41bff10dfd65c26a71e1ac7e424a7142b3520ca5541cfea012818e1 ← this is what it read ``` Not isolated. The same constant appears in **164 layer JSONs** under `10-WAQF/build/` (`grep -rlo fbc8744a… --include=*.json 10-WAQF/build/ | wc -l` → `164`), including `P28-SIRAH-X/X2/maghazi_registry.json`, `P30-SIGHAH/*`, `LENS-AUDIT/E1–E8`, and `P31-MIZAN/W7-M1/strata_layer.json` — layers built from tafsīr, sīrah and ḥadīth corpora that never open the morphology file either. `source_sha` is boilerplate, not a seal. This is reader-facing. `PAGES/W4-S3--five_mafuls_layer.html` prints `source_sha fbc8744a98b36edb` in its footer directly beneath the promise *"every number below … can be re-derived by anyone running the same engine"*. A reader who hashes that value to verify the source will hash the wrong file and get a false green. **Remedy**: `source_sha` must hash the file the layer actually streamed. Where a layer reads several sources, carry a `sources: {path: sha}` map. One line in each builder. --- ### 🔴 F2 — The W4 source file carries no seal anywhere in the build **Severity: HIGH — CHAIN LAW (10)** **File**: `00-CORPUS/acquired/irab_treebank/_META.json:7-32` The `files` block seals six artifacts. All six reproduce exactly ✅ VERIFIED: | file | _META sha256 (first 16) | measured | verdict | |---|---|---|---| | Quran.csv | 9b0634666225ee38 | 9b0634666225ee38 | ✅ | | RelLabels.csv | dfd0e9bfd1ceb9b1 | dfd0e9bfd1ceb9b1 | ✅ | | pos.csv | 83ba9c9ec18279d3 | 83ba9c9ec18279d3 | ✅ | | LICENSE | 67fecc5f5049dedc | 67fecc5f5049dedc | ✅ | | nho.py | 8a7ee40b15d72d56 | 8a7ee40b15d72d56 | ✅ | | iirab.py | 98baa11d2acf73f0 | 98baa11d2acf73f0 | ✅ | **`Quranic.csv` is not among them** — the 57,475,290-byte file that *is* the treebank and *is* the entire W4 unlock. Also unsealed: `Quranic.rar` (4,120,767 B), `templates.py`, `README.md`, and both `quranic-corpus-morphology-0.4.*` files at the acquisition root. Combined with F1: the W4 source has **no cryptographic seal in the acquisition manifest and no correct seal in the layer meta**. It could change on disk and nothing in the build would notice. **Remedy**: add `Quranic.csv` (and the remaining files) to `_META.json:files`. Measured now for convenience — `38c82933b41bff10dfd65c26a71e1ac7e424a7142b3520ca5541cfea012818e1`. --- ### 🔴 F3 — "the five maf'ūls" publishes three and declares nothing about the missing two **Severity: HIGH — GRADE-VERBATIM LAW (9): *absence is declared, never filled* · MEASURED-FLOOR (6) · KNOWN-POSITIVE (5)** **File**: `10-WAQF/build/P32-SHAHADAT/W4-S3/five_mafuls_layer.json:8-14`; builder `p32_w4_s1.py:26-27,41-45,73` The layer is titled *"W4-S3 the five maf'uls v1"* and its `law` field reads *"the **five** objects censused from the treebank's own relation labels."* It publishes three: ``` "maf'ul bihi": 10960 , "maf'ul mutlaq": 412 , "maf'ul li-ajlihi": 90 ``` The builder **did** search for all five (`MAFUL` dict, `p32_w4_s1.py:26-27`). This seat's census of `rel_label_ar` confirms why two are absent: ``` مفعول به 10960 ✅ مفعول مطلق 412 ✅ المفعول لأجله 90 ✅ مفعول فيه 0 ← ZERO مفعول معه 0 ← ZERO ``` `collections.Counter.most_common()` (`p32_w4_s1.py:70`) silently omits zero-count keys. The two zeros were **searched for, found to be zero, and then vanished from the published layer** — the exact shape of defect law 9 exists to prevent. The reader-facing page `PAGES/W4-S3--five_mafuls_layer.html` repeats the title "five" over a three-row table. **And the answer to the panel's question is that the data is richer than the silence suggests.** *Maf'ūl fīhi* is genuinely present in this treebank — it is simply carried on a **different axis**. It is not a relation label; it is a **part-of-speech** label, and this seat measured it: ``` pos_ar containing ظرف : 1,844 ( ظرف زمان 1,172 · ظرف مكان 672 ) most under rel_label_ar = متعلق (ظرف مكان 618 · ظرف زمان 512), then root 454+7, معطوف 59+31, … ``` So the honest declaration is: *"the treebank does not label maf'ūl fīhi as a relation; it marks the ẓarf on the POS axis (1,844 tokens, 1,172 temporal / 672 locative), predominantly bearing the relation muta'alliq. Maf'ūl ma'ahu is not labelled in this resource at all."* That is a **finding worth publishing**, and the layer currently publishes nothing. The selftest cannot catch this: `assert … maful.get("maf'ul bihi", 0) > 3000` (`p32_w4_s1.py:73`) floors one class only. Law 5, verbatim: *"A floor alone passes false zeroes."* **Remedy**: emit all five keys including explicit zeros; add the ẓarf/POS-axis note; extend the selftest to assert on the full five-key shape. --- ### 🟠 F4 — `"tokens": 139,376` counts 11,157 rows that are not Qur'ānic tokens **Severity: MEDIUM-HIGH — I-1 / MEASURE THE ARTIFACT (I-2) · SCHEMA-FIRST (2)** **File**: `W4-S1/irab_source_layer.json:10`; builder `p32_w4_s1.py:32` (`tok_total += 1` on every data line) Independent stream of `Quranic.csv`: ``` data rows total 139,376 ← the layer's "tokens" rows with location == '_' (synthetic) 11,157 rows with a real (s:a:w:t) location 128,219 ← actual Qur'ānic token rows distinct locations 128,219 (0 duplicates, 0 malformed) ``` The 11,157 synthetic rows are the treebank's *taqdīr* apparatus — reconstructed/elided elements and per-sentence root nodes. Cross-tab: ``` location='_' & token='(*)' : 4,484 location='_' & token≠'(*)' : 6,673 (e.g. (نحْنُ) , (أَنْتَ) — supplied implicit pronouns) real location & token='(*)' : 0 ← '(*)' is perfectly correlated with synthetic ``` So the headline is inflated **8.7%**, and the inflation is not random noise — it is grammarian reconstruction counted as revealed text. The same number is carried into the commit message ("139,376 tokens") and onto `PAGES/W4-S1--irab_source_layer.html`. Note `verses_covered: 6236` is **unaffected and correct** ✅ — the builder keys `per_verse` on `chapter_id:verse_id`, and this seat's independent derivation from the `location` field returns the same 6,236 across 114 chapters. The Qur'ān is fully covered. **Remedy**: report both, never blended (law 1) — `"tokens_quranic": 128219, "taqdir_rows": 11157, "rows_total": 139376`. --- ### 🟠 F5 — `irab_per_verse.json` commingles reconstructed elements with revealed text, unflagged **Severity: MEDIUM-HIGH — the waqf-specific risk in F4 · CONTENT-GATE (12)** **File**: `W4-S1/irab_per_verse.json` (9.9 MB); builder `p32_w4_s1.py:39-40` The per-verse container schema is `{t, p, rel, ref}`. The builder **drops `location`** — the only field that distinguishes a Qur'ānic token from a grammarian's supplied element. Verified in the sample: ``` 1:5 → 7 rows, 2 synthetic e.g. {'t':'(نحْنُ)','p':'ضمير','rel':'فاعل'} ← not in the verse 2:255 → 90 rows, 11 synthetic e.g. {'t':'(*)','p':'اسم','rel':'خبر لا'} ← Āyat al-Kursī 112:1 → 5 rows, 1 synthetic e.g. {'t':'(أَنْتَ)','p':'ضمير','rel':'فاعل'} ``` A consumer of this layer **cannot** tell which rows are Qur'ān. The only signal is an undocumented orthographic convention (parentheses / `(*)`). For a waqf whose purpose is durable, checkable transmission of the Book, publishing 11,157 unmarked reconstructions inside the per-āyah i'rāb containers is the highest-consequence item in this review, notwithstanding that the data itself is transmitted perfectly. **Remedy**: carry `location` (already in hand at `p32_w4_s1.py:39` — zero extra cost), or add `"muq": true`. Document the `(*)`/`(…)` convention in `_meta`. --- ### 🟠 F6 — STR-ids are complete and unique but **not stable**; the layer says "stable" **Severity: MEDIUM-HIGH — I-1 (the claim must match the artifact)** **File**: `10-WAQF/build/P31-MIZAN/W7-M1/strata_layer.json:1` (`ids_law`) Everything the panel asked, measured: | property | result | |---|---| | complete (14,961) | ✅ 14,961 rows, **0** missing `row_id` | | unique | ✅ 14,961 distinct ids, **0** duplicates | | well-formed `STR-\d{5}` | ✅ **0** malformed | | contiguous 0…14,960 | ✅ **0** gaps | | declared totals vs actual | ✅ rows 14,961=14,961; companion 8,256, prophetic 2,337, successor 4,368 all exact; distinct_verses 3,842 exact | | **stable** | ❌ **`row_id` == array index for all 14,961 rows** | The `ids_law` reads: *"stable row_id on every transmitted row — joins happen on ids, never names (I-1)."* The id is a pure ordinal of array position. Any upstream harvest that inserts, drops or reorders a single row **renumbers every id after it**, silently repointing every external citation. An ordinal is exactly the thing I-1's "join on IDs, never on names" was written to replace — and it inherits the same failure mode. **Remedy**: derive the id from content — e.g. `STR-` + first 10 hex of `sha256(verse|edition|type|attributor|window|quote_src)` — and retain the ordinal as a separate `seq` field if ordering matters. --- ### 🟠 F7 — ≥30 provably duplicated rows inside the 14,961 total **Severity: MEDIUM — I-1 (the total is inflated)** **File**: `10-WAQF/build/P31-MIZAN/W7-M1/strata_layer.json` Comparing every field **except** `row_id`: ``` duplicate groups : 57 (58 extra rows) quote_src < 400 chars → complete → provably identical : 30 groups, 30 extra rows ← CONFIRMED quote_src == 400 chars → truncated → indistinguishable: 27 groups, 28 extra rows ← UNRESOLVABLE from this file all 57 groups are era_stamp = 'companion' by edition: tabari 16 · qurtubi 12 · miqbas 11 · nurthaq 6 · mizan 5 · wasit 4 · tabrisi 2 · tusi 1 ``` Confirmed example — the same Ṭabarī athar emitted twice per āyah across four consecutive verses: ``` STR-10465 / STR-10466 38:55 tabari mawquf (quote 325 chars, complete, byte-identical) STR-10468 / STR-10469 38:56 tabari mawquf STR-10472 / STR-10473 38:57 tabari mawquf STR-10475 / STR-10476 38:58 tabari mawquf ``` So `totals.rows: 14961` and `by_era.companion: 8256` are inflated by **at least 30**, at most 58. A secondary observation: **4,144 rows (27.7%)** sit exactly at the 400-char truncation cap, so the published layer cannot distinguish rows whose first 400 characters coincide — the 27 unresolved groups are a direct consequence. **Remedy**: dedupe on a content key before assigning ids; re-state the totals. This finding and F6 resolve together — a content-derived id (F6) makes duplicates collide and self-report. --- ### 🟡 F8 — `_META.json` declares one licence for a two-licence directory **Severity: MEDIUM — licence honesty (the panel's question 1)** **File**: `00-CORPUS/acquired/irab_treebank/_META.json:4` **The MIT claim itself is TRUE** ✅ VERIFIED. `noorbayan/LICENSE` is the verbatim MIT text, `Copyright (c) 2025 NoorBayan`, sha-sealed and reproducing exactly. The `_META` wording *"MIT (LICENSE file preserved verbatim)"* is accurate, and the file is genuinely preserved. **The official-draft respect note is also accurate** ✅ VERIFIED, and this seat tried to falsify it. The note claims the corpus.quran.com download *"contains MORPHOLOGY only."* Confirmed by inspection: `quranic-corpus-morphology-0.4.txt` carries four tab-separated columns (LOCATION, FORM, TAG, FEATURES) and terminates at `(114:6:3:3)` with no dependency arcs — POS and morphological features only, exactly as `FORMAT_NOTE.txt` states. NoorBayan/Quranic is a genuinely distinct, separately published, MIT-licensed resource. **The no-redistribution wish is respected, and the note is honest.** **The defect is scope.** `_META.json` sits at the acquisition root and its `licence` key carries no qualifier — but the directory it describes also contains, at that same root: ``` quranic-corpus-morphology-0.4.txt 6,309,503 B quranic-corpus-morphology-0.4.zip 1,028,754 B header: "Copyright (C) 2011 Kais Dukes / License: GNU General Public License" terms: "copy and distribute verbatim copies … but CHANGING IT IS NOT ALLOWED" "provided its source (the Quranic Arabic Corpus) is clearly indicated, and a link is made to http://corpus.quran.com" ``` 7.3 MB of the acquisition is **GPL, not MIT**, and carries an **active attribution obligation** (name the source, link corpus.quran.com) that `_META.json` nowhere records. The MIT LICENSE lives in `noorbayan/` and correctly scopes to it; the root-level `_META` flattens two licences into one. A second, softer note: MIT is a *software* licence granting rights over *"the Software and associated documentation files."* Applying it to a 57 MB CSV dataset is standard practice for a repo shipping one root LICENSE, and this seat does **not** call it dishonest — but a waqf that intends to redistribute would be safer stating *"MIT as published by the upstream repository, covering code and data as distributed."* **Remedy**: make `licence` a per-file map, or split the GPL artifacts into their own directory with their own `_META`; record the corpus.quran.com attribution duty explicitly. --- ### 🟡 F9 — three of six published maf'ūl exemplars are placeholders, not verse tokens **Severity: MEDIUM — CONTENT-GATE SAMPLING (12)** **File**: `W4-S3/five_mafuls_layer.json:15-46`; builder `p32_w4_s1.py:44` The exemplar picker takes the first two rows encountered with no filter on `location`: ``` maf'ul mutlaq : {"verse":"2:13","token":"(*)"} ×2 ← BOTH location='_' — neither is in 2:13 maf'ul li-ajlihi : {"verse":"2:19","token":"(*)"} ← location='_' {"verse":"2:19","token":"حَذَرَ"} ← location=(2:19:15:1) ✅ genuine, and textbook-correct ``` A reader sees *"maf'ūl muṭlaq, verse 2:13"* and cannot know the token is not in the verse. Verified against source: both 2:13 muṭlaq rows are `('_', '(*)', 'مفعول مطلق')`. **CHECK THE CHECKER (law 18) — one candidate finding withdrawn.** This seat first flagged the duplicated `maf'ul bihi` exemplar `1:5 / إِيَّاكَ` appearing twice as a picker bug. It is **not**. Āyah 1:5 is `إِيَّاكَ نَعْبُدُ وَإِيَّاكَ نَسْتَعِينُ` — two distinct tokens sharing a surface form, both genuinely `مفعول به`. The engine is correct; the checker was wrong. Recorded per law 18. **Remedy**: `if r[IX["location"]] != "_"` before appending an exemplar; or carry the location and label taqdīr exemplars as such. --- ### 🟢 F10 — builder robustness: silent row-skip and a hand-rolled parser **Severity: LOW — no present impact, latent** **File**: `p32_w4_s1.py:30-31` `line.rstrip("\n").split("\t")` with `if len(r) < len(hdr): continue` — a raw split rather than a CSV parser, and a skip with no counter. Any future field containing a quoted tab or embedded newline would corrupt silently, and any dropped row would vanish without trace. **No present harm** ✅: this seat's independent `csv.reader` pass returns 139,376 rows against the builder's 139,376 — **zero rows skipped, zero malformed locations, zero duplicate locations**. The finding is latent, not active. **Remedy**: count skips and assert zero (CHAIN LAW prefers exit codes over silence). --- ## MECHANICAL TABLE | # | Item | Layer claim | PW3 independent measurement | Verdict | |---|---|---|---|---| | 1 | data rows in `Quranic.csv` | 139,376 | 139,376 | ✅ EXACT | | 2 | **Qur'ānic token rows** | *(claimed as "tokens": 139,376)* | **128,219** (+11,157 taqdīr) | ❌ F4 | | 3 | verses covered | 6,236 | 6,236 (114 chapters) | ✅ EXACT | | 4 | distinct relations | 121 | 121 (`rel_label_ar`) | ✅ EXACT | | 5 | relation census, all 25 values | see layer | all 25 reproduce byte-for-byte | ✅ EXACT | | 6 | case census | GEN 12,629 / ACC 10,331 / NOM 8,954 | GEN 12,629 / ACC 10,331 / NOM 8,954 | ✅ EXACT | | 7 | 5-verse content gate (1:5, 2:255, 12:4, 55:13, 112:1) | — | 5/5 field-for-field, order preserved | ✅ EXACT | | 8 | `مفعول به` | 10,960 | 10,960 | ✅ EXACT | | 9 | `مفعول مطلق` | 412 | 412 | ✅ EXACT | | 10 | `المفعول لأجله` | 90 | 90 | ✅ EXACT | | 11 | `مفعول فيه` | *(omitted)* | **0** — lives on POS axis as ẓarf, 1,844 tokens | ❌ F3 | | 12 | `مفعول معه` | *(omitted)* | **0** — unlabelled in this resource | ❌ F3 | | 13 | maf'ūl exemplars | 6 published | 3 are `location='_'` placeholders | ❌ F9 | | 14 | `_META` sealed hashes | 6 files | 6/6 reproduce | ✅ EXACT | | 15 | `Quranic.csv` sealed? | — | **not in `_META.files`** | ❌ F2 | | 16 | `source_sha` | fbc8744a… | = `_morphology_raw.txt`, not the CSV (38c82933…) | ❌ F1 | | 17 | MIT licence claim | "MIT, verbatim" | verbatim MIT, © 2025 NoorBayan | ✅ TRUE | | 18 | official-draft respect note | "morphology only, wish respected" | confirmed — 4 columns, no arcs | ✅ TRUE | | 19 | licence scope | "MIT" (directory-level) | 7.3 MB of it is **GPL © Kais Dukes** | ❌ F8 | | 20 | STR-ids complete | 14,961 | 14,961, 0 missing | ✅ EXACT | | 21 | STR-ids unique | implied | 14,961 distinct, 0 dup, 0 malformed, 0 gaps | ✅ EXACT | | 22 | STR-ids **stable** | "stable row_id" | `row_id == array index`, all 14,961 | ❌ F6 | | 23 | strata declared totals | 14,961 / 8,256 / 2,337 / 4,368 / 3,842 | all five reproduce exactly | ✅ EXACT | | 24 | strata row uniqueness | implied by total | **≥30 provably identical rows** (≤58) | ❌ F7 | | 25 | `source_sha` blast radius | — | **164 layer JSONs** carry the same constant | ❌ F1 | **Score: 13 exact ✅ · 12 defects ❌ (0 fabrications).** --- ## WHAT THE COMMISSION ITSELF MISSED (law 13 — GAP-HIGHLIGHT DUTY) The panel briefed four attacks. These went unasked and matter: 1. **`RelLabels.csv` and `pos.csv` were never consulted by the builder.** `_META.json:5` calls them *"the keys"* to the custom transliteration, and they are sealed — but `p32_w4_s1.py` reads neither. The layer transmits raw `rel_label_ar` strings without ever validating them against the published label inventory. A 122nd label appearing upstream would pass silently. **The decode path the acquisition note calls "the W4 unlock path" is not actually being used.** 2. **`ref_token_id` — the dependency head — is transmitted but never validated.** It is carried into every `per_verse` row as `"ref"`. No check that heads resolve to real tokens, that the graph is acyclic, or that each sentence has exactly one root. This seat measured a smell worth a follow-up: **14,184 rows carry `rel='root'` but only 11,157 rows are synthetic root rows** — a 3,027-row excess, and `distinct sentence_id` is 11,693, matching neither. The dependency graph is the treebank's central asset and nothing in W4 tests its integrity. 3. **`Quran.csv` (5.35 MB) is sealed but unused.** It is not read by any builder in this scope. Either it is a redundant acquisition or a layer is missing. 4. **The constituency layer is untouched.** README documents `is_constituent`, `constituent_label`, `constituents`, `constituent_position` — the "hybrid Constituency and Dependency" framing that is the resource's headline contribution. W4-S1 reads none of these columns. The waqf has landed a hybrid treebank and is using half of it. 5. **No verse-level reconciliation against the waqf's own `00-CORPUS/quran.json`.** Both assert 6,236 āyāt, but no builder asserts the two agree verse-for-verse. The treebank uses imlāʾī and Uthmānī forms that may not align with the sealed corpus at token boundaries. An anchored cross-boundary check (I-2) is missing at exactly the join where drift would enter. 6. **`nho.py` / `iirab.py` were acquired and sha-sealed but never executed or reviewed.** They are 28 KB and 15 KB of third-party Python sitting inside the corpus tree. Not a present risk — nothing imports them — but they are unreviewed executable code inside a sealed acquisition. --- ## COUNSEL The engineering here is sound and the transmission is honest at the byte level — this seat tried hard to break the counts and could not. The gap is entirely between **what was measured** and **what was written down about it**. Four of the twelve defects are one-line builder fixes (F1, F3, F9, F10), two are `_META` edits (F2, F8), and F6+F7 resolve together with a content-derived id. F4 and F5 are the two that touch the Book directly and should be fixed first: a waqf must never publish a grammarian's supplied pronoun inside an āyah's token list without a flag saying so. The one finding to carry forward beyond this seal is **F3's positive discovery** — *maf'ūl fīhi* is in the corpus, 1,844 ẓarf tokens strong, on the POS axis. The layer should publish that, not omit it. The panel's question was "is the declaration honest"; the answer is that the declaration is silent where the data is generous. --- ## SEAL VERDICT **SEAL BLOCKED BY:** 1. **F1** — `source_sha` seals `_morphology_raw.txt`, not the source read (systemic: 164 layers; reader-facing on the W4 pages) 2. **F2** — `Quranic.csv`, the entire W4 source, is absent from `_META.json:files` — no seal anywhere in the build 3. **F3** — "the five maf'ūls" publishes three; `مفعول فيه` and `مفعول معه` returned zero and were silently dropped, contra GRADE-VERBATIM LAW; the ẓarf/POS-axis finding (1,844 tokens) is undeclared 4. **F4** — `"tokens": 139,376` overstates the Qur'ānic token count by 11,157 taqdīr rows (true figure 128,219) 5. **F5** — `irab_per_verse.json` commingles 11,157 reconstructed elements with revealed text with no distinguishing field 6. **F6** — STR-ids declared "stable" are array indices 7. **F7** — ≥30 provably duplicated rows inflate the 14,961 strata total and the companion bucket **Not blocking, remedy at convenience:** F8 (licence scope), F9 (placeholder exemplars), F10 (parser robustness). **Explicitly cleared and not to be re-litigated:** the MIT claim is true; the official-draft respect note is true and was tested; the acquisition is lawful; all six sealed hashes reproduce; the relation census, case census, verse coverage and relation cardinality reproduce exactly; the five-verse content gate is exact; the strata declared totals reproduce exactly; STR-ids are complete, unique, well-formed and gapless. --- *PW3 · machine-scholar, labeled · human review invited, never waited. Review only — no build layer was written by this seat. Every count above is re-derivable by streaming `00-CORPUS/acquired/irab_treebank/noorbayan/Quranic.csv` (UTF-16, tab-delimited, 51 columns).*