V9 — INDEPENDENT FINAL VERIFICATION, BASELINE v2.0.0

I built none of this and I took no docstring, no register closure note and no green checker line on trust. I read the 32 requirements out of project_data.REQ, then opened the artefacts myself. I extracted all 48 tables and every paragraph of the delivered .docx with python-docx, and separately extracted the delivered PDF with pdftotext and read the trade-study sections out of the PDF as well as the Word file, because the PDF is what a reader receives. I opened the workbook twice with openpyxl — once for formulas, once for cached values — and dumped all fourteen sheets. I read every run and every table cell of the Decision Pack through python-pptx, including the table shapes C29 cannot see. I recomputed every weighted total in all three trade studies by hand from the matrices printed in the delivered study, and I recomputed every published sensitivity flip point by hand as well, which is where trade study 1 comes apart. I re-derived the aged care contribution ($1,002.06), the NDIS contribution ($435.30), the structure comparison ($606.50 / $7,278 / $22,578) and the unit economics from first principles without calling the builder's functions, and read the workbook formulas rather than its values. I printed BUSINESS_PLAN_A3.html in headless Chromium two ways, rasterised it at 100 dpi and looked at the paper. I then attacked C34 with five mutations, C41 with V8's decoy-block attack, C42 with four stale-artefact substitutions, and C43 and C44 with direct forgeries — all in disposable copies of the whole tree under /tmp/v9, never in the project. I viewed D11 and D12 as images. I read SYSTEM_BREAKDOWN.md, Dashboard.html, README.md, 09_Help_Hub/index.html, 01_System/daily_audit_log.md, 02_Work/scratch/V5_negative_tests_business_layer.md, all of 03_Registers/*.csv, all of 00_Handover/, business_plan.json, and the source of C29, C33, C34, C41, C42, C43 and C44. I ran run_checks.py only inside sandbox copies, so the project's own checker_run_log.txt is untouched. I did not run build_all.py.

The headline: two of the four defects the builder claims to have closed are not closed, and one of them was closed with a statement in a delivered register that is simply false. DEF-042 fixed the arithmetic and left the prose, the decision register and the sensitivity intact — the exact false sentence DEF-042 records as corrected is still sitting in DEC-004 in three delivered artefacts. DEF-043 claims C41 "refuses a report carrying more than one verdict block"; no such code exists, and I defeated C41 in four minutes with V8's own attack, verbatim. And the two brand-new checkers are both defeatable: I put the wrong trade-study totals V8 found — 2.85 / 4.05 / 2.30 — back into the delivered study and got ALL CHECKS PASSED, 44 of 44 from the check written specifically to prevent that.

Did the V8 fixes hold?

Attacks on the checkers

Every attack below was run in a full disposable copy of the tree under /tmp/v9. Nothing was done inside the project.

C34 — defeated twice. The sentinels now come from business_plan.json rather than from the page, which is a real improvement: deleting a section that carries a sentinel now fails, and visibility:hidden on the third column fails ("2 element(s) never reached the paper"), and 0.4px type fails. But the check reads the PDF content stream, not what is visible.

• White-on-white. I added @media print{ .col:nth-child(2) *, .col:nth-child(3) *, .verdict *, footer * { color:#fff !important; background:#fff !important } }. C34 PASS: "exactly 1 page, 420mm x 297mm, and all 12 sentinels ... present. Fitted, not clipped." I then printed that page and rasterised it, and two thirds of the sheet is blank: sections 5 to 9, the value-validation verdict block and the footer are gone. This is V8's D-V8-2, unchanged.

• Gutted tables. The twelve sentinels are drawn from the first element of each list — target_market[0], benefits[0], running_costs[0], revenue_model[0], areas_of_concern[0]. I deleted every table row after the first in every table on the page — 26 rows removed, the running-costs table, the revenue model, the target market and the concerns list all reduced to a single line. C34 PASS. A page can lose most of its content and still "match the thing it projects".

• Wrong content. I replaced all 97 dollar figures on the A3 page with $999,999, re-gated the manifest, and ran the suite: ALL CHECKS PASSED — 44 of 44. Nothing in the suite compares a number on the A3 page against the twin it is a projection of. C33 validates the JSON and compares mtimes and never reads the HTML.

C41 — defeated, with the fix's own description of itself being false. See DEF-043 above. The decoy-block attack works exactly as it did for V8. Underneath it sits a larger hole that no attack is needed to see: IV_SOURCES["v2.0.0"] still points at V7's report. V8 ran against the same baseline, recorded REQ-SYS-03=FAIL and REQ-BUS-01=PASS, and the project simply did not transcribe it. C41 only tests that a verdict was taken against the current baseline; it has nothing to say about a later pass against the same baseline. So 03_Registers/REQ.csv, 00_Handover/REQ.csv, the dashboard and the study's DoD gate 1 all publish REQ-SYS-03 = Verified on the strength of a pass that a subsequent independent verifier overturned in writing. The project chose which verifier counts.

C42 — the register half holds, the rest does not. Truncating DEF.csv and touching it is now caught (proven above). But replacing D5, D11 and D12 — the trade-study chart, the budget-constraint chart and the two-entities chart, all three cited as evidence in EVD and all three linked from the Help Hub — with a copy of D1, and touching them, produces 44 of 44 PASS. Replacing 03_Registers/Project_Registers_v2.0.xlsx with the v1.0.0 workbook is caught only incidentally by C14 (text projection age), not by C42. Replacing the delivered study PDF with the v1.0.0 PDF is caught only by C44's page count and C14, not by C42.

C43 — defeated. The check is very nearly tautological: it computes recomputed = sum(scores × weights) and compares it against TSM.study_weighted(), which computes the same expression from the same data. Those two can never disagree. The only test that touches the delivered artefact is if ("%.2f" % total) not in text — a bare substring search over the whole study. All three TS1 totals appear a second time in the Appendix B defect history, in the sentence describing the bug: "The correct totals are 3.50, 4.10 and 3.25." So the narrative of the fix satisfies the check that the fix worked. I proved it: I opened the delivered .docx with python-docx and rewrote Table 6.1's WEIGHTED SCORE row to 2.85 / 4.05 / 2.30 — the precise figures V8 found — re-gated the manifest and touched the PDF. ALL CHECKS PASSED — 44 of 44, with C43 reporting "10 trade study totals across 3 studies recomputed from their own scores and weights and found in the delivered study". C43 cannot see the number on the page. It also never looks at DEC-004, never checks that an alternative is described where it is scored, and never tests a sensitivity statement — which is why (b), (c) and (d) of DEF-042 above survived it.

C44 — defeated. Its three regexes require the generator's exact punctuation. I edited the Help Hub to say the decision pack has 40 slides, the workbook 1,200 formulas in total, the study running to 5 pages and the diagrams D1 to D3, 3 in all, then re-gated: ALL CHECKS PASSED — 44 of 44. The three false counts I found still in the live Help Hub and FAH register ("47-page study", "ten slides" ×3, "the four ACT items") are the same failure at rest.

Neither C43 nor C44 has a negative test. The project's own rule, stated at the top of V5_negative_tests_business_layer.md, is GOV-E2.4: "a check is only a check once it has been PROVEN able to fail." Both were written in this round, both are cited as the mechanism closing a Major defect, and neither appears in that file — which was last written before they existed. I have now proven that both are incapable of failing on the defect they were written for.

Verdict table

Is REQ-CON-04 the right call, or is the project hiding behind an escalation?

Both, and the second more than the first.

The escalation itself is honest. GOV-A1.3 reserves waivers to Zaid, DEC-008 refuses to self-grant one, WVR.csv is empty, and C29 prints "Widest WORKSHEET grid: Scenarios at 14 columns" in every single run so the fact is never buried. That is the right instinct and it is rare.

But the instrument is wrong and the reasoning inside it is wrong, and together they let a requirement sit open that the project could close or correctly retire this afternoon.

• A waiver was never the right instrument. A waiver excuses a breach. The question here is what a word in the project's own requirement means, and requirement wording is a change-control matter. The project already knows this: REQ-CON-03's own rationale records that its original wording "was satisfiable only while the project had a single research wave" and that it was amended from an equality test to a staleness window because that is "the test GOV-F1.16 actually describes". That is exactly the species of problem REQ-CON-04 has, and the project fixed one and parked the other. CR-004 shows the route is available without Zaid: it changed the acceptance criteria on four requirements — REQ-CON-04 among them — on an independent verifier's evidence, "Approved by the Master Brain".

• The interpretation is wrong on the merits. GOV-F4.5a is the rule REQ-CON-04 implements, and it reads: "Office and PDF artefacts (.xlsx, .pptx, .docx, .pdf) ... MUST be MOBILE-LEGIBLE — readable on a phone without horizontal scrolling". It names the spreadsheet first, and it names horizontal scrolling as the failure. DEC-008's rationale — "a spreadsheet is a grid that scrolls and freezes panes rather than a table that reflows" — offers the prohibited behaviour as the ground of exemption. Whatever else is true, the six-column limit was not written to exclude the artefact its parent rule names first.

• The premise of the chosen option is false. DEC-008 rejects applying the limit to worksheets because "a twelve-month cash projection cannot be six columns wide and remain a twelve-month cash projection, so the requirement would be unsatisfiable rather than demanding." Transpose it. Months down the rows, three columns across, same projection, phone-legible. The same is true of Costs (7) and TradeStudy3 (7). The requirement is demanding, not unsatisfiable, and the option the decision dismisses as impossible is a morning's work in build_financial_model.py.

So: the requirement genuinely fails, the failure is real rather than clerical, and the escalation — while procedurally correct — is being used to hold open a requirement the project could satisfy by restructuring three sheets, or retire honestly by the same change-control route it has already used once. One decision from Zaid closes it; so does one transposed sheet.

New defects found

D-V9-1 (Major). The delivered study scores an alternative it has just told the reader it eliminated, and never introduces the one it actually scored. Section 6.1 lists "A3 — Remain unregistered indefinitely. Eliminated on evidence, not on opinion", and Tables 6.1 and 6.2 then score an A3 worth 3.25 that is a different option entirely — support coordination during the registration window — which appears nowhere in the study's prose. The callout below the table, "THE ALTERNATIVE THAT WAS SCORED AND SHOULD NOT HAVE BEEN", renders the eliminated option without its A4 label, so the same identifier names two different things on facing pages. DEF-042's fix reached trade_study.py and the two tables it drives and stopped at build_study.py:533, which is a hard-coded bullet list. The compliance appendix then certifies "all three trade studies carry at least three lawful alternatives" against a section that says the opposite. This is the whole of REQ-SYS-03's first element, and it is a defect of the delivered document rather than of the engine.

D-V9-2 (Major). DEC-004 still carries the false sensitivity that DEF-042 records as corrected, in three delivered artefacts. "Not close for core supports: A2 leads A1 by 1.20 on a 5-point scale. The result would flip only if addressable market were weighted above about 55%." From the matrix now printed one table above it, A2 leads A1 by 0.60, and the flip is at 37% taken from capital — the study's own §6 sensitivity says so in the same build. This row is in 03_Registers/DEC.csv, 00_Handover/DEC.csv and 03_Registers/Project_Registers_v2.0.xlsx. Its alternatives field still reads "A3 Remain unregistered indefinitely"; its rationale still says A3 is eliminated; its scoring field gives A3 3.25. DEF-045 is the defect whose entire content is "a correction applied where the defect was found rather than everywhere the fact appears is half a correction", and it was closed in the same commit that left this.

D-V9-3 (Major). DEF-043's fix for C41 was never written, and C41 is defeated by the same attack, unchanged. The register states "C41 refuses a report carrying more than one verdict block, because a second block can contradict the first." run_checks.py:1258 is _re.search(...) — first match, no multiplicity test. In a sandbox I reproduced V8's attack move for move and got 44 of 44 PASS with "32 of 32 requirements independently verified" while the verifier's real block, in the same file, recorded two failures. Behind it: IV_SOURCES["v2.0.0"] still names V7's report. V8 ran against the same baseline, recorded REQ-SYS-03=FAIL, and the project neither transcribed it nor recorded a reason. REQ.csv (both copies), the dashboard, the study's DoD gate 1 and C31 therefore all publish REQ-SYS-03 as Verified on a verdict a later independent pass overturned in writing. C41 tests staleness against a baseline; it does not test that the source it reads is the latest pass, so a builder chooses which verifier counts.

D-V9-4 (Major). C43 and C44 cannot fail on the defects they were written for, and neither has a negative test. C43 recomputes sum(score × weight) and compares it against study_weighted(), which is the same expression over the same data — the two cannot disagree. Its only contact with the delivered artefact is a bare substring test, "%.2f" % total in text, and all three TS1 totals occur a second time inside the Appendix B sentence describing the bug, so the narrative of the fix satisfies the test of the fix. I rewrote Table 6.1's totals in the delivered .docx to 2.85 / 4.05 / 2.30 and got ALL CHECKS PASSED — 44 of 44. C44 matches three fixed punctuation patterns; I set the Help Hub to say 40 slides, 1,200 formulas, 5 pages and 3 diagrams and got 44 of 44. Both are cited as the mechanism closing a Major defect. Neither appears in V5_negative_tests_business_layer.md, which is the project's own record of GOV-E2.4 and which still ends "ALL CHECKS PASSED — 42 of 42".

D-V9-5 (Moderate). DEF-043's verification-of-fix cites evidence that is not in the file it names. "C34 proven able to fail by deleting section 9 from the page; C42 proven by an unforced content difference in DEC.csv on its first run. Recorded in 02_Work/scratch/V5_negative_tests_business_layer.md." That file was last written at 07:37, before the fixes; it contains no occurrence of "section 9" and none of "DEC.csv"; its closing standing is 42 checks, not 44. The record of the negative test does not exist.

D-V9-6 (Moderate). The project's entire rollback and provenance story points at two empty folders, and a compliance gate is certified PASS on it. 06_Archive/_versions/ is empty and has not been written to since it was created on 20 August. 04_Inputs/ is empty. Yet: the Help Hub's recovery section says "Every superseded file is in 06_Archive/_versions/ with a date stamp. Nothing in this project is ever deleted (GOV-D1.7)" and three troubleshooting rows send the reader there to restore; the Dashboard carries a live link to 06_Archive/_versions/ labelled "You want the four superseded working files"; the README describes 04_Inputs/ as "What was given to the project, including the four superseded working files"; DEF-001's corrective action reads "Files moved to 04_Inputs/legacy_unsourced and archived to 06_Archive/_versions"; CR-004 and CR-007 both name 06_Archive/_versions/ as their archive snapshot; and the study's Appendix B compliance audit certifies lines 11-16 PASS partly on "Legacy files archived to 06_Archive/_versions before being moved; nothing deleted." The v1.0.0 snapshot that does exist is in 06_Archive/_superseded/v1.0.0_20260907/. The four legacy working files are nowhere in the tree. C32 passes because the folder resolves; C07 passes because the link target exists; nothing checks that an archive contains anything.

D-V9-7 (Moderate). DEF-044 is closed on three phrasings and left three false counts standing. 03_Registers/FAH.csv and the Help Hub (twice) still describe the function as "Brief the decision in ten slides"; the deck has twelve. The Help Hub deliverables map still calls it "The 47-page study with every source"; the delivered PDF has 77 pages, and the Help Hub says so correctly four lines away. The reading route still ends "study sections 1 and 9 → the four ACT items"; there are fourteen open and the study's section 1 box names six. C44's regexes require the exact strings (N slides), (N pages) and N formulas across and match none of these.

D-V9-8 (Moderate). D-V8-10 is untouched: the daily audit log is still a day-one entry wearing today's date, and the compliance audit still cites an entry that does not exist. One entry, headed 2026-09-07, describing the 20 August work: "26 requirements, 9 components and 15 interfaces recorded", "53 sourced claims and 15 assumptions registered", "DEF-001 to DEF-003", "All 26 REQ. All 53 SRC. All 15 ASM.", "this is the first cycle", "All 49 Part I audit lines pass". The project has 32 requirements, 74 sources, 31 assumptions and 45 defects. It contradicts itself twice inside itself: "14 actions owed by Zaid (ACT-001 to ACT-008)", and "16 risks open, 10 rated HIGH" nine lines above "Six HIGH risks are open". It does not mention Part II, the aged care business, DEC-007, DEC-008, CR-004 to CR-007, or DEF-004 to DEF-045. And study Appendix B lines 38-41 are certified PASS on "Daily audit entry for 2026-08-20 in 01_System/daily_audit_log.md". There is no such entry.

D-V9-9 (Moderate). Six evidence records had their pending pass renumbered rather than resolved. EVD-027 to EVD-032 read "Produced by: PENDING V8", where they read "PENDING V6" before. V8 ran, is on disk, is the pass whose findings created DEF-042 to DEF-045, and ruled PASS on five of those six requirements. The evidence chain for every aged care requirement — the half of the study the recommendation rests on — still names a pass the register calls pending. DEF-045's fix statement, "updated to name the pass that will actually rule on them", describes incrementing a number.

D-V9-10 (Minor). Trade study 1's two published flip points are dead ties resolved by declaration order. At addressable market 37% (from capital) A1 = A2 = 3.86; at regulatory durability 45% (from capital) A1 = A2 = 4.10. The winner in both cases is A1 only because sorted(..., key=lambda r: -r[2]) is stable and A1 is declared first in TS1_OPTIONS. The sentence "The result changes hands if ..." is true of neither point. study_sensitivity() steps the weight by 0.01 from the base and breaks on the first non-strict lead, so it will always report the tie rather than the first genuine lead (38% and 46% respectively).

D-V9-11 (Minor). Two sensitivity methods coexist and the project publishes both. trade_study.sensitivity() fixes the donor criterion; study_sensitivity() searches every donor for the smallest movement. The study renders TS1 and TS2 with the new method and TS3 with the old one, so Table 37 says four of the five criteria flip trade study 3 while the new method finds all five (contribution flips at 0.33 to C). 02_Work/scratch/T3_trade_study_results.md, which is the trade study's own results record, publishes "Contribution per client per month — no weight up to 0.60 changes it" and three flip points that the current engine no longer produces. Nothing checks it.

D-V9-12 (Minor). Assorted, each verified individually. Study Table 5.1 still cites "Financial Model, SupportCoordination sheet" for $8,757; I dumped every cell of that sheet and of the whole workbook and the figure is not there (it is computed, correctly, in model_export.json). TS1's A2 market score cites SRC-016 for "agency-managed ... are a large part of the cohort"; SRC-016 is about SIL and digital-platform registration commencing 1 July 2026 and contains no cohort figure — no register row in the project does. Study §6 still opens "Both trade studies in this study meet that standard"; there are three. Recommendation 4 still says July 2027 is "about eleven months away"; from the currency date it is ten. business_plan.json and the A3 page still say verified_by: "PENDING — independent verification pass V5 has not yet run against this plan". The Dashboard's "THE NEXT ACTION" banner still names only ACT-001 to ACT-008 when fourteen are open and six are past due. C29 still measures only 148 of the deck's 194 runs, because its .pptx branch iterates sh.has_text_frame and a table shape has none — nothing sub-10pt is hiding there today, but the check cannot see it. C29's scope exclusion is still {basename(ci[4]) for ci in P.CI if ci[2].lower() == "zaid"}, a builder-writable owner column. 01_System/BUSINESS_PLAN_A3.html.probe.pdf — a 144 KB one-page A3 print probe — is sitting in 01_System/, is referenced by no generator, is not a configuration item, and matches none of tidy.py's eight debris patterns, so both tidy and C35 report the tree clean.

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 74 sources sit below High confidence with a stated reason, which is honest rather than verified.

• Whether the trade-study judgements are right. I proved the arithmetic of all three studies reproduces and that TS1's supporting record does not. Whether A1's capital deserves a 2 and A2's a 5 is a judgement no verification pass can settle, and the project is right to escalate DEC-003 and DEC-007 rather than decide them.

• Whether the new A3 alternative is the best available third option. It is lawful, it is credible, and it is scored on the same criteria with figures I could trace ($3,673 and $8,222 both live in SupportCoordination). Whether some other strategy — staged registration, a partnership, contracting to an existing provider — would have been a stronger third alternative is not something I can test.

• Print behaviour on any engine but Chromium. I measured with headless Chromium via Playwright, which is what C34 drives, 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, every table cell and every font size through python-pptx. I did not render the twelve slides, so I cannot speak to overflow, overlap or contrast.

• Nine of the twelve diagrams. I viewed D11 and D12 and read D5's underlying matrix. D1, D2, D3, D4, D6, D7, D8, D9 and D10 I confirmed only as files on disk and as embedded images — and, as D-V9-4/C42 shows, nothing in the suite would notice if they were the wrong pictures.

• Whether my own verdicts survive transcription. C41 compares this file's machine-readable block line by line against what the project transcribes, which is worth something — but I defeated it in four minutes with a decoy block, this file is not hash-gated, and the project is at present ignoring the previous verifier's block entirely. Nothing mechanically prevents a builder from editing the block below, or from leaving IV_SOURCES pointed at an older report and never reading this one.

Closing verdict

30 of 32 requirements PASS.

The count is the same as V8's and it is not the same 30. REQ-BUS-01 is properly closed — I printed the page, rasterised it and read the paper, and it is one complete, legible A3 landscape sheet. REQ-SYS-03 still fails, and it fails for reasons V8 named: the arithmetic was repaired and the sentence, the register row and the timestamp were not, so the delivered study now scores an alternative it declares eliminated, and the decision register still publishes "A2 leads by 1.20, flips above 55%" — the precise false statement DEF-042 is recorded as having closed. REQ-CON-04 fails, and the project should stop treating it as Zaid's problem: GOV-F4.5a names .xlsx first and forbids horizontal scrolling, DEC-008's "unsatisfiable" premise is refuted by transposing one sheet, and the project has already amended a badly-worded requirement once by change record.

Read the defects before the count. Three of the five checkers that exist to protect this baseline — C34, C41, C43 — are defeatable, C44 is defeatable, and I defeated all four in a sandbox inside an hour, including putting V8's exact wrong numbers back into the delivered study and getting 44 of 44 green. One of the four defect closures is asserted on code that was never written, and another on a negative test that is not in the file it cites. The pattern across V6, V7, V8 and now V9 is consistent and it is worth naming plainly: this project fixes the instance and writes a checker that tests the instance, and the checker is then cited as proof that the class is closed. C43 recomputing its own arithmetic while the wrong number sits on the page is that pattern in its purest form.

Left behind: nothing. I ran run_checks.py only inside /tmp/v9/* sandboxes, so 01_System/checker_run_log.txt still carries the builder's 08:16:47 run. python 01_System/tidy.py --report returns TIDY PASS — placement map satisfied: no loose root files, no debris, no secret stores, no links to live files, no unknown folders, no missing mandated folders, and find . -newermt "2026-09-07 08:20" returns nothing, so this file is the only thing I added to the tree. The tidy report's clean verdict is itself slightly optimistic — see D-V9-12 on the orphaned BUSINESS_PLAN_A3.html.probe.pdf, which is debris that the debris patterns do not describe.

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