# V8 — INDEPENDENT CLOSING VERIFICATION, BASELINE v2.0.0

I built none of this and I took no docstring, no checker PASS line and no defect-register closure note on trust. I read the 32 requirements out of `project_data.REQ` and then opened the artefacts. I extracted every paragraph and all 45 tables of the delivered study with python-docx, cell by cell, and separately extracted the delivered PDF with `pdftotext` and matched its 201 distinct dollar figures against the .docx one for one. I opened the workbook twice with openpyxl, once for formulas and once for cached values, and dumped all fourteen sheets. I read every run, every table and every raw `sz=` attribute in the Decision Pack. I printed `BUSINESS_PLAN_A3.html` in headless Chromium four ways, rasterised two of the PDFs at 110 dpi, **looked at the page**, and measured the ink bounding box against the paper edge to test for clipping. I then attacked C34 with five deliberately broken variants of the page, attacked C41 in a sandbox copy of the whole tree with three separate transcription attacks, attacked C42 with a stale register projection, and attacked C29's scope boundary by injecting a 6-point run and a nine-column table into a copy of the delivered study. I re-derived the whole cost-benefit case from `model_params` and `model_agedcare` without calling the builder's `build()`, re-derived the $16,200 halving threshold by fitting the model's own budget sensitivity, recomputed the open-item count from the CSVs rather than from `open_item_count()`, ran my own sub-10pt scan (explicit sizes, inherited paragraph styles and raw XML) over every Office file in `05_Outputs`, my own jurisdiction scan, my own secrets and PII scan over 103 files, and my own attribution measurement at two strictnesses. **And I recomputed every weighted score in all three trade studies by hand.** I viewed D5, D11 and D12 as images. I read `SYSTEM_BREAKDOWN.md`, `SOURCE_MANIFEST.json`, `Dashboard.html`, `README.md`, `09_Help_Hub/index.html`, `01_System/daily_audit_log.md`, all of `03_Registers/*.csv`, all of `00_Handover/`, and the source of C22, C26, C27, C29, C33, C34, C41 and C42. I ran `01_System/checkers/run_checks.py`. I did not run `build_all.py`.

The headline is that the two requirements V7 failed are now split: **REQ-BUS-01 is genuinely fixed** — I printed it, rasterised it and read the paper, and the whole plan is on one A3 landscape sheet with a 12 mm bottom margin and nothing clipped — and **REQ-CON-04 is not**. But a third requirement fails that nobody has looked at properly in three passes: **the registration-strategy trade study publishes weighted scores that cannot be produced from its own scoring matrix**, one of them out by 1.20 on a five-point scale. V6 and V7 both wrote "I recomputed A1 2.85, A2 4.05, A3 2.30 by hand and they are correct." They are not correct, and they are not close.

## Did the V6 and V7 fixes hold?

| Defect | Fix claimed | Verdict | What you actually checked |
|---|---|---|---|
| DEF-035 | Every verdict carries a baseline; C41 fails on a stale one; retired verdicts show as STALE | **YES** | `IV_VERDICT_RAW` is `{rid: (result, baseline)}`; all 32 verdicts carry `v2.0.0`; the 26 `v1.0.0` verdicts are kept and reported as retired rather than deleted. `03_Registers/REQ.csv` and `00_Handover/REQ.csv` both read 30 Verified / 2 Open, the dashboard reads "30 of 32 verified", the study's DoD gate 1 reads "FAIL — 30 of 32", and every one of those agrees with `IV_VERDICT`. I bumped `BASELINE_VERSION` to v2.1.0 in a sandbox and every requirement correctly fell back to Open. The staleness condition V7 found on the surfaces is gone. One flaw: with a baseline that has no `IV_SOURCES` entry, C41 does not report "no verdict source for this baseline" — it raises `FileNotFoundError: ''`. It fails, so it is fail-safe, but the message names nothing. |
| DEF-036 | The A3 page fits one sheet by fitting, not clipping; C34 extracts the printed text and requires every heading, the verdict block and the footer | **YES on the artefact** | `overflow:hidden` is gone; the layout is three explicit generator-filled columns. I printed with C34's exact call (`prefer_css_page_size=True`), with `format='A3', landscape=True`, with zero margins and with browser defaults: **1 page every time, 420 × 297 mm**. I diffed the DOM `innerText` against the printed PDF text token by token: 2,652 DOM tokens against 2,646 in the PDF, and every one of the twelve differences is a hyphen (`one-off,` → `oneoff,`). I rasterised at 110 dpi and read the page: all nine sections, the verdict block and the footer are on the paper, three columns, legible. The ink bounding box stops 52 px from the bottom edge and 18 px from the right — **nothing touches any edge**. This is a real fix and V7's clipping is genuinely gone. The check that certifies it is a different matter — see D-V8-2. |
| DEF-037 | One computed net, `cba.net_benefit`, read by every consumer | **PARTLY** | The net itself is fixed: `$144,386.98` in `business_plan.json` (twice), on the A3 page (twice), in the study (twice), in ASM-029, and computed live by `trade_study._three_year_net()` from `build()['cba']['net_benefit']`. I re-derived it without the builder: 21,948.60 + 66,258.00 + 7,520.00 + 180,000.00 = 275,726.60; 11,110 NDIS hours × 6.69692875 + 345 aged care client-months × 1,002.06 = 420,113.58; net **144,386.98**; ROI 52.366% → 52.4. Exact. The `$145,621` and `$144,421.10` still in the study are all inside the Appendix B2 defect history, quoting what was wrong — legitimate. **But the fix stopped one register row short.** ASM-028, in `03_Registers/ASM.csv` and `00_Handover/ASM.csv`, states the $90,000 case as "total cost $365,726.60 against the same **$420,147.70** of benefit, a net of **$54,421.10**". The benefit is $420,113.58 and the net is $54,386.98 — which ACT-013 and the study's section 1 box both state correctly, one register away. Two delivered artefacts still state different values for the same named quantity. DEF-037's verification note reads "One value, $144,386.98, in every artefact that states it": true of the net, false of the two figures it is derived from. |
| DEF-038 | The parked-decision match is on substance; the published count moved 47 → 49 | **YES** | I counted from the delivered CSVs, not from `open_item_count()`: RQ 3 open of 6, ACT 14 of 14, CR 1 of 7, DEF 0 of 41, RSK 16 of 16, ISS 1 of 1, BKL 12 of 12, plus 3 parked decisions (DEC-003 "Parked-Zaid", DEC-007 and DEC-008 "Parked with Zaid"). **50.** The dashboard publishes 50 with the breakdown "RQ 3, ACT 14, CR 1, RSK 16, ISS 1, BKL 12, DEC parked with Zaid 3" and the README publishes 50. The number in DEF-038's own note (49) is one behind because ACT-014 was added afterwards; the published figure is right and the breakdown reconciles. |
| DEF-039 | C41 parses the verifier's machine-readable block and compares it line by line | **NO — I defeated it, in a way that leaves the verifier's own verdicts untouched** | The line-by-line comparison is real and it works against the obvious attacks: I transcribed REQ-CON-04 as PASS without touching the report and got "REQ-CON-04: the project transcribed PASS, the verifier's report says FAIL"; I deleted REQ-BUS-01 from the transcription entirely and got "the verifier recorded REQ-BUS-01=FAIL and the project transcribed nothing for it". Both caught. **But the regex is `##\s*MACHINE-READABLE VERDICTS\s*```(.*?)```` and it takes the FIRST match in the file.** In a sandbox copy I inserted a decoy block reading all-PASS two lines below the report's title, left V7's real block at the bottom saying `REQ-CON-04=FAIL` and `REQ-BUS-01=FAIL`, flipped the two transcriptions to PASS, and ran the suite: **C31 "32 of 32 requirements independently verified; 0 recorded as still failing", C41 "32 of 32 requirements carry a verdict taken against the CURRENT baseline v2.0.0".** Only C40 and C42 objected, and both only because I had edited `project_data.py` without rebuilding — a normal `build_all.py` run clears them. The verifier's actual verdicts were never read. The deeper problem: **the verification report is not under hash control.** C40 gates 20 sources of truth and the V7 report is not one of them, so C41 now compares two artefacts the builder can write, and the only evidence that the second one is a verifier's is that it is filed in a scratch folder. |
| DEF-040 | C42 compares source and artefact modification times and fails on a stale deliverable | **NO** | C42 compares the **clock**, not the content, so a stale artefact with a fresh timestamp is invisible to it. I proved it: in a sandbox copy I deleted DEF-039, DEF-040 and DEF-041 from `03_Registers/DEF.csv` — a register projection three rows behind its source, which is exactly the DEF-040 condition — then `touch`ed the file. **ALL CHECKS PASSED — 42 of 42.** Two further gaps in its lists. Its five "sources" omit every build script: edit `build_study.py` and never rebuild the study and C42 is silent. Its fourteen "generated" artefacts cover 3 of the 27 register projections, none of `00_Handover/*.csv`, none of the twelve diagrams, not `Project_Registers_v2.0.xlsx`, not the delivered study PDF and not `SOURCE_MANIFEST.json`. The single artefact V7 named as carrying the false "26 Verified" — `00_Handover/REQ.csv` — is not in C42's list at all. It happens to be correct today; C42 is not why. |
| DEF-041 | Four false statements corrected | **PARTLY — two of four are fully fixed** | (a) The $90,000 sensitivity **is** fixed in the study: "At $90,000 the three-year return falls from 52.4 per cent to 14.9 — a net of $54,386.98 rather than $144,386.98". I recomputed: 365,726.60 cost, 54,386.98 net, 14.87% → 14.9. True. But see DEF-037 — ASM-028 states the same sensitivity with two stale figures. (b) The classification sentence **is** fixed in `business_plan.json` and on the A3: "$302.14 a client a month at the BOTTOM ongoing classification of $10,731". **But the study's RSK-012 mitigation still reads "The model brackets the whole classification range from $348 to $2,749 a client a month"** — $348 is the contribution at a $12,000 budget, which the study's own Appendix B2, forty pages later, says "is not a classification". The fix reached four surfaces and missed the fifth. (c) SRC-074 **is not** cited where the figure is used. It exists and carries $63.85 / $47.75 / $16.10. Every actual citation is still SRC-068: study finding 5 "[SRC-068, SRC-069, RSK-011, V4]", study Table 15.1a same, RSK-011's mitigation "[SRC-068]", deck slide 9 footer "SRC-068 sector results". Only `business_plan.json` and the A3 page cite SRC-074. This is DEF-031, closed a second time with the same partial reach. (d) The 717,000 market figure **is** gone — no occurrence anywhere outside the defect history — and the row now cites SRC-043 and SRC-044 without restating a figure. **But the row immediately below it still says "Around 300,000 home-care recipients nationally", cited to SRC-064, which is the classification-budget schedule and contains no population; no register row anywhere in the project carries 300,000.** The fix took one of the two rows in the same table. |

## Verdict table

| Requirement | Verdict | Evidence you personally opened | If FAIL, exactly what is wrong |
|---|---|---|---|
| REQ-SYS-01 | PASS | Study Table 5.1: core supports $9,110–$12,786 (base $10,791) cited "[Financial Model, Costs sheet; SRC-025 to SRC-041]", support coordination $3,673, SIL/SDA $8,600–$16,900 "[DEC-005; SRC-016, SRC-034, SRC-036]". Table 18.1 gives aged care $11,157.80 and combined $21,948.60. I traced the NDIS lines to workbook `Costs` and the aged care one-off to `model_agedcare.ONE_OFF_COSTS`; `Structure!B6` caches 21,948.60. SIL/SDA is excluded by DEC-005 and named. | — (but Table 5.1's $8,757 cites a workbook sheet that does not contain it — D-V8-15) |
| REQ-SYS-02 | PASS | Study Table 7.0 (table index 15), four rows, four models: core supports "About 4 months" [ASM-015]; support coordination "About 2 months"; SIL/SDA "9 to 12 months at the earliest" [SRC-021]; aged care "About 4 months, on a registration whose lead time is not published — which is why ACT-011 exists" [SRC-065]. Every row carries a source. | — |
| REQ-SYS-03 | **FAIL** | Study Table 6.1 (table index 12), read cell by cell from the .docx: weights 30/25/25/20; A1 scores 2,5,5,2; A2 5,3,5,3; A3 5,3,1,5; published WEIGHTED SCORE row 2.85 / 4.05 / 2.30. DEC-004 records the same three totals. Weights timestamped 2026-08-20T09:40, scores 11:05 — ordering correct. | **The published weighted scores cannot be produced from the published matrix.** I computed them by hand and in code: A1 = 0.6+1.25+1.25+0.40 = **3.50** against a published 2.85; A2 = 1.50+0.75+1.25+0.60 = **4.10** against 4.05; A3 = 1.50+0.75+0.25+1.00 = **3.50** against **2.30** — out by 1.20 on a five-point scale, over half its own published total. There is no integer score vector under these weights that yields all three published totals; they belong to a different matrix. The stated sensitivity, "A2 leads A1 by 1.20", is 0.60 on the matrix, and the stated flip point, "addressable market weighted above about 55%", is not reproducible under any donor criterion (37% from capital, 65% from operational burden, 85% from durability). The scores are hard-coded strings in `build_study.py` line 506; nothing computes them and no checker tests them. C09 compares twelve figures across artefacts and these are not among them. Second, independent ground: the criterion requires ">=3 alternatives, none of which breaches a legal obligation stated in the study", and alternative A3 is "Remain unregistered **indefinitely**", which the study itself eliminates because "mandatory registration reaches personal care and daily living supports in July 2027 (SRC-015), so this option has a known expiry date". Two lawful alternatives, not three. **Note for the record:** V6 and V7 both wrote that they had recomputed 2.85 / 4.05 / 2.30 by hand and found them correct. Trade study 2 (3.30 / 3.70 / 2.20) and trade study 3 (3.70 / 3.55 / 3.20 / 2.45) both recompute exactly; only trade study 1 is broken. |
| REQ-SYS-04 | PASS | Study Table 7.1 (index 13), six identical weighted criteria across all three models. I recomputed every total: core 4,5,3,2,2,4 → **3.30**; support coordination 5,4,2,4,3,5 → **3.70**; SIL/SDA 1,1,3,4,2,1 → **2.20**. Exact. The stated flip — regulatory stability 25%→40% giving 3.45 against 3.40 — reproduces exactly when the 15 points come from margin resilience, which I found by solving for the donor. D5 renders the same matrix correctly. | — (the sensitivity does not say which criterion donates the weight; I had to solve for it) |
| REQ-SYS-05 | PASS | `UnitEconomics!B11 = SUM(B5:B10)` → 21.30424, with `B5 = Inputs!$B$5` (73.58, SRC-002) and B6:B9 each `-Inputs!$B$8` times `Inputs!$B$10/$B$11/$B$12/$B$13` (SRC-009, SRC-011, SRC-012, SRC-013, ASM-003). `B14 = B11+B13` → 6.69692875. Not one constant in the chain; I read the formulas, not the values. | — |
| REQ-SYS-06 | PASS | Study Table 4.1 (17 rows) and Table 4.2 (12 rows), both six columns — Obligation / Authority / Cost / Frequency / Lead time / Source. I tested every cell of both programmatically: **zero empty cells**, and every data row's last column carries a SRC-###. The ACQSC registration lead time is recorded as "NOT PUBLISHED … ACT-011 closes it" rather than invented. | — |
| REQ-SYS-07 | PASS | `Scenarios` rows 37–45 carry a formula-driven month-by-month cumulative cash line, `B45 = B44-Costs!$C$14` → −11,638.13, ending at `N45 = MIN(B45:M45)` → **−20,958.80**, which reconciles to 10,790.80 + 847.33 × 12 as I computed independently. Study Table 8.2 states −$20,959. | — |
| REQ-SYS-08 | PASS | Study Table 9.1, five items, each naming a register ID — ASM-008, ASM-002, SRC-002, ASM-015, SRC-049 — and three naming the checkable party ("a real provider", "you", "government publishes"). Section 19 carries a second such box (Table 39) with four more, each naming a register ID. | — |
| REQ-SYS-09 | PASS | Study Tables 10.1 (12 sequenced rows) and 10.2 (8 rows), both under "This roadmap is CONDITIONAL". I walked all 27 obligations from Tables 4.1 and 4.2 against the roadmap text: WorkCover and portable long service leave are sequenced in both entity roadmaps at "Weeks 5-7 **BEFORE ANY PAY RUN"; the WWCC, ABN, TFN, GST, PAYG, myID, business name, insurance, first aid and the Worker Orientation Module (SRC-042) all appear; the two that do not — voluntary disability worker registration and the annual company review — are named in the caption with the reason. | — |
| REQ-SYS-10 | PASS | `BreakEven!B6 = Costs!$C$28/UnitEconomics!$B$16` → 39.77; `B7 = Costs!$C$28/UnitEconomics!$B$14` → 126.53; `SupportCoordination!B13 = Costs!$C$28/Inputs!$B$7` → 8.46; aged care 1.0 client from `model_agedcare.breakeven_clients()`. Every figure resolves through input cells. SIL/SDA excluded by DEC-005 and named in Table 5.1. | — |
| REQ-SYS-11 | PASS | `BreakEven!B12 = Drivers!$B$14*(Inputs!$B$8*(1+Inputs!$B$10+$B$11+$B$12+$B$13))*(Drivers!$B$6/30)` → 7,318.61, with B13 giving 15,682.73 at 30 days. Wage rate, hours driver and the ASM-007 payment lag are all live references. Aged care $4,173.20 from `model_agedcare.working_capital()`; combined $11,491.81 = 7,318.61 + 4,173.20, which I checked against the dashboard tile. | — |
| REQ-SYS-12 | PASS | Study Table 7.0 fourth column answers July 2027 for all four models and pairs each with a cost to be ready: core supports "$3,500 to $6,000 verification audit plus $649 to $1,825 policy manual"; support coordination "$0 audit and $0 manual TODAY … and that is the absence of a cost, not a cost of zero", with the cost if the pause lifts priced; SIL/SDA "$8,600 to $16,900" and "Already in force"; aged care "$600 to $3,000 … plus a $4,997 Standards manual" and "Not affected by the NDIS change". No model is silent. | — |
| REQ-SYS-13 | PASS | 12 PNGs on disk and 12 `word/media/*.png` embedded. I read `build_study.py`'s twelve `figure()` calls and confirmed placement: D2/D6 in section 3, D1 in section 4, D10/D3 in section 5, D5 in section 7, D9/D7/D8/D4 in section 8, **D11 in section 15** and **D12 in section 17**. I viewed D5, D11 and D12 at full size: all three legible, nothing clipped, nothing overlapping except D11's average label, which the dashed line strikes through. | — (the aged care critical path, Table 10.2, is still the only sequenced roadmap in the study with no diagram, and it is the one the study recommends running first — V7 raised it and it is unchanged) |
| REQ-SYS-14 | PASS | I read the troubleshooting table row by row out of the raw HTML. Nine symptom/cause/check/fix rows, all present: dead links, link not found, chart empty, dashboard blank, register will not open, two documents disagree, #NAME?/#VALUE?, wrong version, phone view, dead source URL. Count = nine, and none tells the reader to ask anyone first. | — (three of the nine rows contain false facts — see D-V8-8. The criterion counts symptoms, so it passes; a reader following the "chart is empty" fix would conclude D11 and D12 are debris) |
| REQ-SYS-15 | PASS | `Dashboard.html` carries "GENERATED FILE … Rebuilt from `01_System/project_data.py` by `01_System/build_web.py`"; it is the only dashboard in the tree; all twelve tiles project from register or model values. I independently recomputed the two I could most easily falsify — open items (50, from the CSVs) and combined capital ($44,483 = 32,991.60 + 11,491.81) — and both match. | — |
| REQ-SYS-16 | PASS | I extracted the twelve `data-metric` attributes from the HTML myself and matched them against `03_Registers/METRIC_LINEAGE.csv`: 18 lineage rows, **zero** tiles without a row, and **zero** empty cells across 18 rows × 6 fields. | — |
| REQ-SYS-17 | PASS | I ran the suite. C22 "15 pack files re-derive from their sources"; C23 "C22 detected a deliberate one-line tamper in HANDOVER.txt and the file was restored". I also diffed all nine shared CSVs between `00_Handover/` and `03_Registers/` and they are identical modulo line endings. | — (V7's D-V7-6 stands: C22 hashes the pack against a `MANIFEST.txt` written by the same generator in the same moment. It proves the pack has not been altered since it was written; it does not re-derive anything. The criterion asks only that it run, report zero and demonstrate it can fail, and it does all three) |
| REQ-SYS-18 | PASS | I parsed `03_Registers/SRC.csv` myself: 74 rows, 51 below High (42 Medium, 9 Low), and the 'Why below High' field is non-empty on all 51. I tested for emptiness, not for the checker's word. | — |
| REQ-CON-01 | PASS | C05 reports 0.967 over 301 material figures with 10 unmatched — 123, 403, 406.39, 1,849, 5,325, 6,797, 9,997, 16,200, 16,900, 20,959 — every one internal arithmetic or an HTTP status code, which I checked individually (16,200 is the halving threshold I re-derived; 20,959 is the downside runway I recomputed). Zero material external claims without a SRC-### reference. | — (the criterion is about the presence of a reference and it is satisfied. Three references resolve to rows that do not contain the figure they carry — SRC-068 for $16.10, SRC-064 for 300,000 — and one cites a workbook sheet that does not contain the figure. That is D-V8-7 and D-V8-9, and it is the third pass in a row on which this survives on the criterion's wording) |
| REQ-CON-02 | PASS | I extracted the study, the deck and the A3 page to text and scanned for New South Wales, Queensland, South Australia, Western Australia, Tasmania, Northern Territory, NSW, QLD, WA and SA: **zero hits** in all three. 47 occurrences of Victoria in the study, 8 on the A3. Every jurisdiction-dependent obligation in Tables 4.1 and 4.2 names Victoria or the Commonwealth. | — (the Decision Pack never names Victoria at all, in 9,170 characters. No obligation in it is stated for another state, so the criterion holds, but the artefact most likely to be read alone does not carry its own jurisdiction) |
| REQ-CON-03 | PASS | I parsed the accessed dates myself: 74 rows, 53 at 2026-08-20 and 21 at 2026-09-07, against a currency date of 2026-09-07. None later than the currency date; the oldest is 18 days earlier, inside the 90-day window. The workbook README and the Help Hub both state that distribution correctly. | — |
| REQ-CON-04 | **FAIL** | I ran my own scan over every Office file in `05_Outputs`, measuring explicit run sizes, inherited paragraph-style sizes and raw XML `sz=` attributes. **The 10-point clause is genuinely met**: 0 sub-10pt effective runs across 3,359 study runs (the template defines `Body Text 3` at 8pt and `Caption` at 9pt and no paragraph uses them; effective sizes are 10.0/10.5/11.5/13/14/16/17/26); 0 across 194 deck runs, minimum 10.0pt; 0 across 1,229 workbook cells, whose only font sizes are 10, 11 and 14. Document tables: 45 in the .docx and 2 in the .pptx, **none above six columns**. I also injected a 6-point run and a nine-column table into a sandbox copy of the study and C29 caught both — the check can fail. | The workbook's worksheet grids are **Scenarios 14 columns, Costs 7, TradeStudy3 7**. The requirement says "zero tables of more than six columns" and the criterion is a flat count "measured by a script over the delivered file". The count is 3. It reads as zero only under DEC-008, whose own Scoring field says "Interpreted by the project on 2026-09-07. **NOT RATIFIED BY ZAID**" and whose Rationale says "a waiver cannot be self-granted". The WVR register is empty by design. Under GOV-C3.2 the builder's reading of its own requirement carries zero weight with me, and a requirement met only by an unratified reinterpretation is not met. The project has behaved correctly here — it refused to self-grant the waiver, escalated it, and made C29 print the widest worksheet in every run — and that honesty is precisely why the requirement is still open. One decision from Zaid closes it; a builder cannot. |
| REQ-CON-05 | PASS | I parsed `03_Registers/ASM.csv` myself: 31 rows, zero with an empty Confidence field, zero with an empty 'What breaks if it is wrong' field. 26 Low, 5 Medium. | — (ASM-028's failure-consequence field is populated and **wrong** — see D-V8-5. The criterion tests presence, not truth) |
| REQ-CON-06 | PASS | I ran my own regex scan for email addresses, Australian mobile numbers, ABN- and TFN-shaped identifiers, API-key and password assignments, AWS access keys and PEM private-key headers across 103 `.py/.md/.csv/.json/.html/.txt/.js` files in the controlled set. **Zero hits**, including zero false positives this time. | — |
| REQ-MOE-01 | PASS | I read all fourteen rows of `03_Registers/ACT.csv`. Every one carries a due date in the Due column: ACT-001 to 004 at 2026-08-27, 005/006/009 at 2026-09-05, 007/008 at 2026-09-20, ACT-010 "2026-10-31 (or before the sixth client, whichever comes first)", ACT-011 and ACT-014 at 2026-09-21, ACT-012 "2026-12-19 (or before the tenth client)", ACT-013 at 2026-09-14. The owner is carried by the register's own column header, "Action owed by Zaid", for all fourteen. | — (seven of the fourteen are already past their stated due date as at 2026-09-07; the criterion does not test that) |
| REQ-MOP-01 | PASS | I re-implemented the unit extraction independently. With the checker's exemptions: 156 units carrying a dollar figure, 151 attributed, ratio **0.9679**. With **no exemptions at all**: 162 units, 154 attributed, ratio **0.9506**. Above 0.90 on either reading. The eight unattributed units under the strict reading are three table captions, the DEF-001 legacy quotation and four defect-history rows quoting what was wrong. | — |
| REQ-AC-01 | PASS | I rebuilt $1,002.06 from scratch without the model: $30,000/12 = $2,500; less 10% (SRC-063) = $2,250 service revenue; ÷ $103.11 (SRC-060) = 21.82136 hr; × ($43.03 × 1.1545) = $1,084.04; + $250 pool; less 1.5 × ($50.61 × 1.1545) = $87.64; less $318.75; less $7.50 = **$1,002.06**. And $435.30: 65 hr × $73.58 = $4,782.70; less 65 × $52.27576; less $949.48 = **$435.30**. Ratio 2.302. `AC_ClientEconomics!B17` and `C17` are live formulas caching 1002.06053495854 and 435.300368749999. Both figures are in study Table 15.3. | — |
| REQ-AC-02 | PASS | Study Table 15.2 and `AC_ClientEconomics!A22:D27` span **$10,731 (Level 1, 1.80 hr, $894.25, $302.14)** to **$78,106 (Level 8, 13.11 hr, $6,508.83, $2,749.44)**. I opened all 18 value cells in formula view: every one is a live formula over `A22:A27`, `AC_Inputs` and `Inputs`. I fitted the model's own six points and confirmed the relation is linear, then solved it for the halving threshold and got $16,207 against the study's "about $16,200". | — |
| REQ-AC-03 | PASS | $606.50 / $7,278.00 / $22,578.00 appear in study Tables 3 and 17.1, in `Structure!D5` (`=B5-C5`), `D7` (`=D5*12`) and `D8` (`=D5*36+D6`), and in `business_plan.json`. All derive from `model_agedcare.structure_comparison()`. I recomputed 606.50 = 1,840.50 − 1,234.00 and 22,578 = 606.50 × 36 + 744, and checked 744 = 21,948.60 − 21,204.60. D12 carries the same three figures. | — |
| REQ-AC-04 | PASS | Study section 15.1 states the mechanism (dual care-management 15–20% plus package-management 10–15% replaced by a single 10% pool, landing on cost bases built for the old structure), cites the pass by name ("an independent verification pass was run specifically to resolve it (V4)"), and names the falsifier ("the DIRECT-SERVICES line turning negative in the quarterly sector report — not the total result, which is already negative and already explained"). I opened `V4_agedcare_margin_verification.md` and confirmed $16.10 is derived there as $63.85 − $47.75 from quoted text. | — (in the study, the deck and RSK-011 the figure is still cited to SRC-068, whose Value field is a document title with no figure in it, while SRC-074 — created for exactly this and carrying all three numbers — is cited nowhere outside the business plan. D-V8-7) |
| REQ-BUS-01 | **PASS** | Four clauses, all four tested. **Twin exists**: `business_plan.json`, 21,285 bytes. **Twelve checks**: I loaded the generator and ran `validate()` in-process — 12 of 12. **A3 no staler than the twin**: `business_plan.json` 07:40:59.228, `BUSINESS_PLAN_A3.html` 07:40:59.256 — the page is newer. **Fits one A3 landscape sheet as measured in a browser**: printed in headless Chromium four ways, 1 page at 420 × 297 mm every time; DOM text against printed text is 2,652 tokens to 2,646 with all twelve differences being hyphens; rasterised at 110 dpi and read — sections 1 to 9, the value-validation verdict block and the footer are all on the paper in three legible columns; ink bounding box rows 16–1235 of 1287 and columns 16–1802 of 1820, so **nothing touches any edge and nothing is clipped**. I also re-derived the whole CBA independently and it reconciles to the cent. This is the fix V7 asked for and it is real. | — (the check that certifies it is defeatable — D-V8-2 — and the plan's own footer still says a verification pass that has run has not run — D-V8-13. Neither is a property of the artefact the criterion tests) |
| REQ-WEB-01 | PASS | `SYSTEM_BREAKDOWN.md` section 5 declares the slot with an explicit status — "**Status in this project: SLOT DECLARED, NOT BUILT**" — names GOV-B7.1/B7.2/B7.4 and states the three constraints that bind regardless. BKL-011 carries it against REQ-WEB-01. COMPONENTS.csv scopes it to C1. My own credential scan across 103 files returned zero hits. | — (its evidence record EVD-032 says "Produced by: PENDING V6" — D-V8-11) |

## New defects found

**D-V8-1 (Major). Trade study 1 publishes weighted scores that cannot be produced from its own scoring matrix, and three verification passes have said the opposite.**
Study Table 6.1 and DEC-004 both record A1 = 2.85, A2 = 4.05, A3 = 2.30. From the weights and scores printed in the same table — 30/25/25/20 against A1 2,5,5,2; A2 5,3,5,3; A3 5,3,1,5 — the totals are **3.50, 4.10 and 3.50**. A3 is out by 1.20 on a five-point scale: more than half its published value. No integer score vector under these weights produces all three published totals, so the matrix and the totals are two different trade studies printed as one. The consequences run downstream: the stated sensitivity "A2 leads A1 by 1.20" is 0.60 on the matrix, and the stated flip point "addressable market weighted above about 55%" is 37% if the weight comes from capital, 65% if from operational burden and 85% if from durability — reproducible from nothing. The scores are hard-coded strings at `build_study.py:506`; no function computes them, and no checker compares a published weighted total against its own matrix, which is why C09's twelve cross-artefact figures miss it entirely. The recommendation does not change (A2 still wins on either reading), so this is a defect of evidence rather than of conclusion — but a trade study is *only* evidence. Both V6 and V7 wrote that they had recomputed these three totals by hand and found them correct, which is the more troubling half of this finding: the same wrong number has now been independently "verified" twice.

**D-V8-2 (Major). C34 cannot detect a page that was never generated whole, because its sentinel list is scraped from the file it is testing.**
`sentinels = re.findall(r"<h2>(.*?)</h2>", src_html)` — the check reads the headings out of `BUSINESS_PLAN_A3.html` and then confirms those same headings appear in the PDF printed from it. I deleted the entire section 9 card ("9 · Efficiency audit (SP07)" — the options table, the build-or-buy note and the dated recommendation) from a copy of the page and ran C34's exact logic: **PASS, "1 page (420, 297), all sentinels present"**. Nothing else covers it: C33 validates the JSON twin and compares mtimes and never reads the HTML, so no check in the suite compares the A3 page's content against the twin it projects. Separately, the sentinel test measures the PDF *content stream*, not what is visible: I added `@media print{ .col:nth-child(2), .col:nth-child(3), .verdict, footer { color:#fff } }` and got **PASS** on a sheet where sections 5 to 9, the verdict block and the footer are invisible white-on-white — I rasterised it to be sure. To C34's credit, it does catch the failures it was built for: content pushed off the page, a zero-height column, sub-pixel type and a fourfold content increase all fail it. The gap is upstream of print, not in print.

**D-V8-3 (Major). C41 reads the first machine-readable block in the report, not the verifier's, and the report is not under hash control.**
In a sandbox copy of the whole tree I inserted a decoy verdict block — the same heading the check looks for, followed by a fenced block — reading all-PASS two lines below the title of `V7_baseline_v2_reverification.md`, left V7's real block at the bottom of the file untouched and still saying `REQ-CON-04=FAIL` and `REQ-BUS-01=FAIL`, and flipped the two transcriptions in `project_data.py`. Result: **C31 "32 of 32 requirements independently verified; 0 recorded as still failing", C41 "32 of 32 requirements carry a verdict taken against the CURRENT baseline v2.0.0"**, and after a manifest re-gate the suite is green. The verifier's actual verdicts sit in the file, in full, unread. The direct attacks are properly caught — transcribing a PASS the report does not carry, and dropping a FAIL the report does carry, both produce a precise C41 failure — so the fix is real; it is the parse that is soft. Behind it sits the structural point: C40 hash-gates 20 sources of truth and the verification report is not one of them, so C41 now compares two files the builder can write, and nothing distinguishes a verifier's report from a builder's. Minor: with a `BASELINE_VERSION` that has no `IV_SOURCES` entry, C41 does not report the missing source — it raises `FileNotFoundError: ''`.

**D-V8-4 (Major). C42 compares clocks, so a stale artefact with a fresh timestamp passes, and its two lists miss most of what is generated.**
I deleted DEF-039, DEF-040 and DEF-041 from `03_Registers/DEF.csv` in a sandbox copy — a register projection three rows behind its source, which is verbatim the DEF-040 condition — and `touch`ed the file. **ALL CHECKS PASSED — 42 of 42.** `touch` is not an exotic attack; it is what any copy, sync, archive extraction or partial rebuild does. Nothing in the suite re-derives a register CSV from `project_data` and compares it. Two further gaps: C42's five "sources of truth" omit every generator (`build_study.py`, `build_web.py`, `build_financial_model.py`, `build_registers.py`, `build_handover.py`, `build_diagrams.py`, `build_deck.js`), so editing a build script and never rebuilding is invisible; and its fourteen "generated artefacts" cover 3 of the 27 register projections, none of the twelve diagrams, none of `00_Handover/*.csv`, not the delivered study PDF, not `Project_Registers_v2.0.xlsx` and not `SOURCE_MANIFEST.json`. The one file V7 named as publishing the false "26 Verified" — `00_Handover/REQ.csv` — is not in C42's list at all.

**D-V8-5 (Moderate). ASM-028 states the $90,000 sensitivity with a benefit and a net that no longer exist.**
Both delivered assumption registers read "total cost $365,726.60 against the same **$420,147.70** of benefit, a net of **$54,421.10**". The benefit is $420,113.58 and the net is $54,386.98 — figures that ACT-013 in the action register and the study's own section 1 box both state correctly. $420,147.70 is the pre-DEF-033 benefit computed on the rounded $6.70; it appears nowhere else in the project. This is the DEF-026 / DEF-037 defect, still live, one row above the ASM-029 that was fixed for it.

**D-V8-6 (Moderate). The study still brackets the classification range at a figure it says elsewhere is not a classification.**
RSK-012's mitigation, in the delivered study: "The model brackets the whole classification range from **$348** to $2,749 a client a month against the published schedule [SRC-064, ASM-020]". $348.24 is the contribution at a $12,000 budget. Table 15.2, forty pages earlier in the same document, spans $10,731 → $302.14 to $78,106 → $2,749.44, and Appendix B2 says in terms that "the classification-range table started at $12,000, which is not a classification". DEF-032's fix reached Table 15.2, the workbook, deck slide 9, diagram D11 and `business_plan.json`; DEF-041's fix reached the business plan sentence; neither reached this one. ASM-020's own consequence field also still ends "At $12,000 it falls to $348".

**D-V8-7 (Moderate). SRC-074 is still cited by nothing that uses the figure.**
The row exists, carries "$63.85 per client per day against direct cost $47.75 … a positive margin of $16.10", and is the answer to DEF-031. Every place the figure is actually used still cites SRC-068, whose Value field is a document title: study finding 5 "[SRC-068, SRC-069, RSK-011, V4]", study Table 15.1a the same, RSK-011's mitigation "about $16.10 per client per day [SRC-068]", deck slide 9 footer "SRC-068 sector results". Only `business_plan.json` and the A3 page cite SRC-074. DEF-041's corrective action reads "the reconciliation figure now cites SRC-074 which carries its two components" — true of two surfaces out of six. This is the figure that carries the whole of REQ-AC-04.

**D-V8-8 (Moderate). V7's D-V7-4 was not fixed at all, and one of its instances is inside the study's own compliance audit.**
The Help Hub says "the ten slides" three times and "10 slides" once — the deck has **12**. It says "Live workbook, **398 formulas**, zero hard-coded results" — I counted **455**, and the workbook's own README, rewritten for DEF-030, now says explicitly that two sheets *are* typed-in results, so two delivered surfaces contradict each other on a point one of them was fixed to make true. It says "check that **D1 to D10** are all present" and "D1 to D10 as PNG" — there are twelve, so a reader following that troubleshooting fix concludes D11 and D12 are debris. It calls the study "**32 pages**" in one entry and "**the 47-page study**" two entries later; the delivered PDF is **73 pages**. Its reading route ends "study sections 1 and 9 → **the four ACT items**"; the study's section 1 box names six (ACT-001, 002, 003, 010, 011, 013). The README says "**ten slides**". And the study's own Appendix B compliance audit, lines 33-37, cites as evidence "**ten diagrams D1 to D10, all embedded (C12)**" — while C12 in the same build reports "12 diagrams on disk, 12 images embedded". Every one of these was named by V7 and none was touched.

**D-V8-9 (Moderate). The second market-size row is the defect DEF-041 closed for the first one.**
`business_plan.json` and the A3 page state "Around 300,000 home-care recipients nationally", cited to **SRC-064**, whose Claim is "Support at Home classifications and budgets — eight ongoing levels, Level 1 $10,731.00 a year to Level 8 $78,106.35 a year" and whose Value is a schedule title. It contains no population figure, and I searched every register: **no row anywhere in the project contains 300,000**. The row directly above it, which stated 717,000 against SRC-001, was correctly fixed under DEF-041 to cite SRC-043 and SRC-044 and to stop restating a figure. The fix took one row of a two-row problem in the same table. C-BP3 passes because it only tests that `size_source` is non-empty; C05 never reads the A3 or the JSON; C36 only tests that the identifier exists.

**D-V8-10 (Moderate). The daily audit log is a single day-one entry wearing today's date, and the study cites an entry in it that does not exist.**
`01_System/daily_audit_log.md` opens by quoting GOV-H3.5 — "one entry per day on which any work was done" — and then contains exactly one entry, headed **2026-09-07**, whose content is the 20 August record: "Project stood up from nothing under Governance Standard v3.7", "26 requirements, 9 components and 15 interfaces recorded", "53 sourced claims and 15 assumptions registered", "DEF-001 to DEF-003", "this is the first cycle", "All 49 Part I audit lines pass". The project now has 32 requirements, 74 sources, 31 assumptions, 41 defects and a Part II. The entry contradicts itself twice: "**14 actions owed by Zaid (ACT-001 to ACT-008)**" — the count was updated, the range was not — and "**Six HIGH risks are open**" nine lines below its own "16 risks open, **10 rated HIGH**". It does not mention DEC-007 or DEC-008. And the study's compliance audit cites as evidence "Daily audit entry for **2026-08-20** in 01_System/daily_audit_log.md" — the file contains no 2026-08-20 entry. Work was done on at least two days; there is one entry, and it describes neither of them accurately.

**D-V8-11 (Moderate). Six evidence records attribute their proof to a verification pass the register itself calls PENDING.**
`03_Registers/EVD.csv`, Produced-by column: EVD-027 (REQ-AC-01), EVD-028 (REQ-AC-02), EVD-029 (REQ-AC-03), EVD-030 (REQ-AC-04), EVD-031 (REQ-BUS-01) and EVD-032 (REQ-WEB-01) all read "**PENDING V6**". V6 ran, V7 ran, and five of those six requirements are currently marked Verified on the strength of V7. So the evidence chain for every aged care requirement — the half of the study the recommendation actually rests on — names a pass that the register says has not happened. C30 checks that the cited artefact paths resolve; nothing checks the producer against `IV_VERDICT_SOURCE`. The project's own backlog names this gap ("Add a checker that an evidence record may not assert proof for a requirement the independent verdict fails") and it is still open.

**D-V8-12 (Minor). C29's scope boundary is a builder-writable field.**
The exclusion set is `{basename(ci[4]) for ci in P.CI if ci[2].lower() == "zaid"}`. It is correctly derived today — the three Zaid-owned rows are the v3.7 Standard, v3.9 and the v4.0 Business Layer, all inputs filed under GOV-F5.7, and the docstring's justification is honest. But the owner column lives in `project_data.py`. I changed CI-005's owner from "Master Brain" to "Zaid" in a sandbox copy of a study I had already injected a 6-point run and a nine-column table into: C29 went from **FAIL** ("1 text runs below 10pt; 1 tables wider than six columns") to **PASS** ("2 delivered Office artefacts measured … Excluded as not this project's output: … NDIS_and_Aged_Care_Business_Enabling_Study_v2.0.docx"). C24 did not object. The check prints the exclusion, which is to its credit, but a scope that a builder can widen is not a scope.

**D-V8-13 (Minor). The business plan's footer says a verification pass that has run has not run.**
`business_plan.json` and the A3 page both carry `verified_by: "PENDING — independent verification pass V5 has not yet run against this plan"`. V5 has run: `02_Work/scratch/V5_negative_tests_business_layer.md` exists, is hash-gated in `SOURCE_MANIFEST.json` as evidence, and is cited by name in DEF-036's own verification-of-fix field. V6, V7 and this pass have each re-derived the plan and printed the page. On the one field in the plan whose entire purpose under GOV-C3.2 is to record who verified it, the plan is wrong.

**D-V8-14 (Minor). C29 never measures the Decision Pack's table text.**
Its `.pptx` branch iterates `sh.has_text_frame` only. A table shape has no text frame, so every run inside a slide table is skipped. C29 reports 148 runs in the deck; my scan, which walks `sh.table` as well, finds **194**. The 46 it misses are the two slide tables, including slide 9's classification table. Nothing sub-10pt is hiding there today; the check simply cannot see it.

**D-V8-15 (Minor). Assorted, each verified individually.**
Study Table 5.1 still cites "[SRC-018; **Financial Model, SupportCoordination sheet**]" for "$8,757 with zero drawings"; I dumped every cell of that sheet and the figure is not in it, nor anywhere in the workbook — V6 and V7 both raised this. Diagram D12 pairs "$847 a month fixed · **break-even 126.5 hours**", which is the paid-administration break-even, with a red box saying the owner does the administration **unpaid**, under which the break-even is 39.8 hours; two bases in one picture. D11's orange "the modelled average, 5.04 hr [ASM-020]" label is still struck through by the dashed line it annotates, and its subtitle asserts "most buy under five" — a claim about the distribution of assessed budgets that no source in the project supports. The Decision Pack never names Victoria, in any form, anywhere. The owner's name is spelled two ways in delivered artefacts — "Zaid Al Dabbag" on the deck cover, "Zaid Aldabbag" on the A3 page, six occurrences of each across the tree. `SupportCoordination!B14` is `=636+108+Drivers!$B$9+139.2+290`, four typed constants inside a formula, on a sheet the workbook README does not list among its two declared typed-value sheets. The CBA uses the rounded $1,002.06 for aged care while DEF-033 established the principle of not using the rounded $6.70 for NDIS; the effect is $0.65 over three years, but the principle is the project's own. Study recommendation 4 says July 2027 is "about eleven months away"; as at the currency date it is about ten.

## What I could not verify, and why

- **Whether any external fact is true.** I verified internal consistency, derivation and citation, not the world. I opened none of the 74 source URLs. Nothing here is evidence that $103.11, $73.58, $45.28, $43.03, $10,731, $78,106, $63.85, $47.75 or the July 2027 date are correct. Fifty-one of the 74 sources sit below High confidence with the reason stated, and that is the honest position rather than a verified one.
- **Which trade study 1 is right.** I have proved that the matrix and the totals in Table 6.1 disagree. I cannot say which was intended, because nothing in the project computes either. The scores are typed strings and there is no second record to reconcile them against; DEC-004 carries the same totals and not the matrix.
- **The trade study judgements themselves.** Every weighted total in trade studies 2 and 3, the 0.15 margin and all four flip points recompute exactly. Whether option A's capital deserves a 3 and option C's a 5 is a judgement no verification pass can settle, and the project is right to escalate it.
- **Print behaviour on any engine but Chromium.** I measured with headless Chromium via Playwright, which is what C34 drives, and I rasterised the output and looked at it. I did not test Word, Safari, Firefox or a physical printer.
- **Whether the Decision Pack renders as designed.** I read every run, table and font size through python-pptx and the raw XML. I did not render the twelve slides, so I cannot speak to overflow, overlap or contrast.
- **Whether my own verdicts survive transcription.** C41 now compares this report's machine-readable block line by line against what the project transcribes, which is a genuine improvement — but I defeated it in five minutes with a decoy block, and this file is not hash-gated. Nothing mechanically prevents a builder from editing the block below.
- **The nine diagrams I did not open.** I viewed D5, D11 and D12. D1, D2, D3, D4, D6, D7, D8, D9 and D10 I confirmed only as files on disk and as embedded images in the package; I did not check their figures against the model.

## Closing verdict

**30 of 32 requirements PASS.**

REQ-BUS-01 is closed and closed properly — the page fits because it fits, and I looked at the paper to say so. REQ-CON-04 needs one decision from Zaid on DEC-008 or a restructured workbook, and the project's refusal to self-grant that waiver is the right behaviour, not a failure of it. REQ-SYS-03 is a new failure and the most serious finding in this pass: a trade study whose published scores do not follow from its published matrix, sitting in the delivered study and in the decision register, twice certified as correct by verifiers who did not do the arithmetic. Read the defects before reading the count: three of the four checkers built in the last two fix rounds — C34, C41 and C42 — are defeatable, and I defeated all three in a sandbox in under an hour.

## MACHINE-READABLE VERDICTS
```
REQ-SYS-01=PASS
REQ-SYS-02=PASS
REQ-SYS-03=FAIL
REQ-SYS-04=PASS
REQ-SYS-05=PASS
REQ-SYS-06=PASS
REQ-SYS-07=PASS
REQ-SYS-08=PASS
REQ-SYS-09=PASS
REQ-SYS-10=PASS
REQ-SYS-11=PASS
REQ-SYS-12=PASS
REQ-SYS-13=PASS
REQ-SYS-14=PASS
REQ-SYS-15=PASS
REQ-SYS-16=PASS
REQ-SYS-17=PASS
REQ-SYS-18=PASS
REQ-CON-01=PASS
REQ-CON-02=PASS
REQ-CON-03=PASS
REQ-CON-04=FAIL
REQ-CON-05=PASS
REQ-CON-06=PASS
REQ-MOE-01=PASS
REQ-MOP-01=PASS
REQ-AC-01=PASS
REQ-AC-02=PASS
REQ-AC-03=PASS
REQ-AC-04=PASS
REQ-BUS-01=PASS
REQ-WEB-01=PASS
```