V7 — INDEPENDENT RE-VERIFICATION, BASELINE v2.0.0

I built none of this and I took no docstring, comment or checker PASS line on trust. I read the 32 requirements out of project_data.REQ and then opened the artefacts. I extracted all 178 top-level paragraphs and all 45 tables of the delivered study with python-docx, cell by cell; I opened the delivered workbook twice with openpyxl, once for formulas and once for cached values, and dumped all fourteen sheets; I opened the Decision Pack with python-pptx and read every run, every table and every picture shape on all twelve slides. I re-derived the whole cost-benefit case from model_params and model_agedcare in my own arithmetic without calling the builder's build(), and got $420,113.58 of benefit, $275,726.60 of cost, a net of $144,386.98, an ROI of 52.366% and break-even at month 17 / month 10 — then compared that against business_plan.json, against the A3 page, against trade_study.py, against ASM-028 and ASM-029, and against the study. I diffed the delivered business_plan.json field by field against a fresh in-memory rebuild. I printed BUSINESS_PLAN_A3.html in headless Chromium five ways, rasterised two of the resulting PDFs at 100 dpi and looked at them. I ran my own sub-10pt scan across every Office file in 05_Outputs, including inherited paragraph-style sizes and raw sz= attributes that the project's own check cannot see. I ran my own jurisdiction scan, my own secrets and PII scan over 102 files, and my own attribution measurement at two different strictnesses. I viewed D11_budget_constraint.png and D12_two_entities.png as images. I read SYSTEM_BREAKDOWN.md, SOURCE_MANIFEST.json, Dashboard.html, README.md, 09_Help_Hub/index.html, 00_Handover/, all of 03_Registers/*.csv, both T3 records, and the source of C05, C10, C12, C22, C27, C29, C31, C33, C34, C40 and C41. I built a throwaway copy of the whole tree in scratch and attacked the new C41 baseline mechanism in it. I did not run build_all.py. I did not run run_checks.py inside the project — I read the log the builder's own run left at 07:07:57 and ran the suite only inside my sandbox copy — so checker_run_log.txt is untouched and I left no __pycache__ behind.

Two things dominate this pass. First, most of the eleven fixes are real, and two of them (DEF-027 and DEF-030) are better than the defect required. Second, the source of truth is now ahead of every artefact that projects from it. 01_System/project_data.py was last written at 07:07:36; every register CSV was written at 07:05, every deliverable, the dashboard, the README, the Help Hub and the A3 page at 07:06. So DEF-025 to DEF-034 exist in the source and in none of the 24-row defect registers; the study's Appendix B2 still publishes "24 defects, all closed"; and the dashboard's headline assurance tile still reads 26 / 32 requirements INDEPENDENTLY verified, sourced to a 20 August pass, while the source of truth now derives all 32 as Open. That is the exact condition DEF-035 was raised to make impossible, still visible on the surface a stranger opens first. C40 catches it and fails; nothing else does.

Did the V6 fixes hold?

Verdict table

New defects found

D-V7-1. Every delivered artefact and every register is a projection of a source of truth that has since moved, and the status surface asserts a verification that no longer exists. 01_System/project_data.py was last written at 07:07:36. Every register CSV was written at 07:05:55, every deliverable and every web surface at 07:06. Consequences I confirmed by opening the files: DEF-025 to DEF-034 exist in project_data.DEF (34 rows) and in neither 03_Registers/DEF.csv nor 00_Handover/ (24 rows); the study's Appendix B2 publishes a 24-row defect history and states "24 defects, all closed"; the Help Hub says "DEF | Defects. 24 raised, 24 closed"; the README says "Defects | 24 raised, 24 closed". Worse, 03_Registers/REQ.csv and 00_Handover/REQ.csv both carry 26 Verified / 6 Open, and Dashboard.html publishes "26 / 32 Requirements INDEPENDENTLY verified — the verifier built none of them" and "Requirements: 26 of 32 verified (81%)", while project_data.IV_VERDICT now derives all 32 as Open and 26 as STALE. The delivered study's Definition of Done gate 1 still reads "FAIL — 26 of 32 … Verdict source: V3_closing_verdict.md (independent verification pass 4, 2026-08-20)". That 20-August-verdict-on-a-7-September-artefact is exactly the condition DEF-035 was raised to eliminate; the mechanism was built and the artefacts were never rebuilt through it. C40 is the only check that notices, and it names a byte count rather than the consequence.

D-V7-2. The three-year net and the $90,000 sensitivity are wrong in the artefacts a reader actually opens. (a) ASM-029, in project_data.py and in both delivered ASM projections, states "a computed net of $144,421.10" while the computation now yields $144,386.98; trade_study.py's docstring says the same stale figure two lines above the function that computes the right one. (b) ASM-028 states the $90k case as "$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. (c) Far more seriously, the delivered study (section 1, the ACT-013 box) and the delivered dashboard (ACT-013 row) both still say "At $90,000 the three-year return falls from 53 per cent to roughly 10". The correct figures, which I computed twice, are 52.4% to 14.9% — and ASM-028 already carries them. V6 raised this; the register was corrected and the two documents a human reads were not. The project describes ACT-013 as "the one input that changes the verdict", so this is the wrong number attached to the most decision-relevant sensitivity in the plan.

D-V7-3. Three citations resolve to rows that do not contain the figure, and one figure has no source at all. (a) $16.10 / $63.85 / $47.75 are cited to SRC-068 everywhere they are used (study finding 5, study Table 15.1a, RSK-011, deck slide 9); SRC-068's Value field is a document title with no figure in it. SRC-074 exists and carries all three and is cited nowhere. (b) business_plan.json and the A3 page state the NDIS market as "Approximately 717,000 active participants nationally", cited to SRC-001, which is the price schedule identity ("v1.2, effective 1 July 2026"). No register anywhere contains 717,000 — the register figure is SRC-043's 774,456. (c) The second market row, "Around 300,000 home-care recipients nationally", is cited to SRC-064, the classification-budget schedule, which contains budgets and no population. Check C-BP3 passes all three 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. This is DEF-031's defect class, unfixed and now present in three more places.

D-V7-4. The DEF-032 fix left a false sentence behind it, and eight more false statements survive on the Help Hub, the dashboard and the README. build_business_plan_json.py line 347 formats R['budget_sensitivity'][0][3] into a hard-coded sentence: "the model brackets contribution from $302.14 a client a month at a $12,000 budget". budget_sensitivity[0] is now (10731, 1.80, 894.25, 302.14). $302.14 is the contribution at $10,731, not at $12,000. The value moved when DEF-032 was fixed; the literal in the sentence did not. That false statement is in business_plan.json, on the A3 page and in the delivered PDF render. Alongside it, on surfaces DEF-029 was supposed to clean: the Help Hub says the decision pack has "ten slides" three times and the README twice — it has twelve; the deliverables map says the workbook has "398 formulas, zero hard-coded results" — I counted 455 formulas, and the workbook's own README now explicitly says two sheets are typed-in results, so the Help Hub directly contradicts the DEF-030 fix; the deliverables map and the "chart is empty" troubleshooting entry both say "D1 to D10" — there are twelve; the reading order says "study sections 1 and 9 → the four ACT items" when the study's own box names six; and the Help Hub calls the study "32 pages" in one entry and "the 47-page study" two entries later.

D-V7-5. The published open-item count is short by two, and one of the two is the go/no-go decision itself. project_data.parked_decisions() matches the literal string "Parked-Zaid". DEC-003 uses that string. DEC-007 (the aged care/NDIS ordering — the decision the whole study escalates) and DEC-008 (the six-column interpretation) are both recorded as "Parked with Zaid", a different string, and are therefore invisible to open_item_count(). The dashboard prints "OPEN ITEMS … DEC parked with Zaid 1" beside a decisions table that visibly lists three parked decisions. The published figure of 47 should be 49. This silently undoes DEF-015, whose fix note reads "A decision parked with Zaid is an open item … so it is now counted". C11 cannot catch it because the published count and the "count the registers actually produce" are the same function. Note that the DEF-028 fix is what created DEC-008, so a fix introduced an uncounted open item.

D-V7-6. C22 does not do what its own description says, and the pack it certifies is stale. C22's description is "Every file in the transfer pack re-derives from its source: nothing missing, extra or altered", and REQ-SYS-17's statement is "The transfer pack shall re-derive from its sources". I read the function: it hashes each pack file and compares against the SHA-256 recorded in MANIFEST.txt, which was written at the same moment by the same generator. It proves the pack has not been tampered with since it was written. It re-derives nothing. That is why 00_Handover/REQ.csv can say 26 Verified against a source of truth that says 0, and 00_Handover/ASM.csv can carry the stale $144,421.10, while C22 reports zero discrepancies. This is the DEF-011 defect class ("checkers that assert more than they test") in a check that certifies a requirement.

D-V7-7. Smaller things I would still record. The T3 weights record — the GOV-B6.3 artefact — names criterion 5 "Dependence on the owner's own hours" while the scoring, the workbook and the study all use "Independence from"; the polarity of a fixed criterion is inverted in the only document that fixes it. Study Table 5.1 still cites "[Financial Model, SupportCoordination sheet]" for the $8,757 six-month runway; I searched every cell of that sheet and the figure is not in it. Workbook AC_Inputs!F9 still says the Schedule F Level 3 rate is "used for care management and administration time" while F23/ASM-031, fourteen rows below, says the SACS rate is used instead — V6 raised this and it is unchanged. C12 still reads if len(names) < 10: return False, "expected 10 diagrams" and passes on len(media) >= 10, so two of the twelve diagrams could be deleted without failing it. The A3 footer still says "verified by PENDING — independent verification pass V5 has not yet run against this plan"; V5 was the negative-test pass and the relevant pass is V7. The aged care critical path (Table 10.2) is the only critical path in the study with no diagram, while the NDIS one has D1 — and the aged care entity is the one the study recommends starting first. The CBA uses the rounded $1,002.06 for the aged care contribution while DEF-033 was specifically about not using the rounded $6.70 on the NDIS side; the effect is $0.18 over three years, but the principle is the one DEF-033 established. The README's section 1 still describes the project as being about "starting an NDIS provider business in Victoria" with no mention of aged care, and its reading order still points at Standard v3.7 while the governance line says v3.9 plus v4.0.

What I could not verify, and why

• Whether any external fact is true. I verified internal consistency, derivation and citation, not the world. I did not open one of the 74 source URLs. Nothing in this report is evidence that $103.11, $73.58, $45.28, $43.03, $10,731, $78,106 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, not a verified one.

• The trade study scores themselves. I re-derived every weighted total, the margin of 0.15 and all four flip points 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. I also cannot verify the ordering claim behind trade study 3 — and neither can the project, which now says so in its own weights record.

• Print behaviour on any engine but Chromium. I measured with headless Chromium via Playwright, which is what C34 drives. I did not test Word, Safari, Firefox or a physical printer, and I did not open Chrome's interactive print preview. My REQ-BUS-01 failure rests on the browser the project's own check uses, printing under the rule the file itself declares.

• Whether the Decision Pack renders as designed. I read every run, table and picture shape through python-pptx and measured every font size, but I did not render the twelve slides, so I cannot speak to overflow, overlap or contrast on any of them.

• The PDF rendition of the study. NDIS_and_Aged_Care_Business_Enabling_Study_v2.0.pdf sits in 05_Outputs, no requirement or checker addresses it, and I did not open it. I do not know whether it matches the .docx I verified.

• Whether my own verdicts will survive transcription. I proved in a sandbox that C31 and C41 pass regardless of what this file says. Nothing in the project mechanically connects the verdict map to this document, so the transcription step below is, today, an unverified builder statement — which is the thing GOV-C3.2 exists to forbid.

Disclosure of my own footprint. I ran the checker suite only inside a disposable copy of the tree in my scratch directory; 01_System/checker_run_log.txt still carries the builder's 07:07:57 run untouched. Every Python process I started set sys.dont_write_bytecode = True; the 01_System/__pycache__ directory that C35 reports predates this pass (mtime 07:07:36, written alongside project_data.py by the builder's own run) and I did not add to it. python 01_System/tidy.py clears it. I created and modified exactly one file inside the project: this report.

Closing verdict

30 of 32 requirements PASS.

The two failures are narrow and both are closable. REQ-CON-04 needs one decision from Zaid on DEC-008, or a restructured workbook. REQ-BUS-01 needs a layout that fits without overflow:hidden and a C34 with a negative test that proves it can fail. But read the new-defects section before reading the count as good news: nine of the eleven surfaces I opened are projections of a source of truth that moved after they were built, the delivered dashboard tells a stranger that 26 of 32 requirements are independently verified when none are, and the mechanism built to prevent exactly that can be defeated by writing a file with the right name.

MACHINE-READABLE VERDICTS

REQ-SYS-01=PASS
REQ-SYS-02=PASS
REQ-SYS-03=PASS
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=FAIL
REQ-WEB-01=PASS