V6 — INDEPENDENT VERIFICATION, BASELINE v2.0.0

I built none of this and I have taken no statement in it on trust. I read the 32 requirements out of project_data.REQ and then went to the artefacts themselves. I opened the delivered study with python-docx and extracted all 553 blocks and all 42 tables to text; I opened the delivered workbook twice with openpyxl, once for formulas and once for cached values, and dumped all fourteen sheets cell by cell; I opened the delivered Decision Pack with python-pptx and read every run and every table on all twelve slides. I re-derived the aged care contribution, the NDIS contribution, the 2.3x ratio, the trade study weighted scores, the sensitivity flip and the whole business-plan CBA from first principles in a scratch interpreter without importing the project's own result functions, then compared my numbers against the model, against the workbook's cached values, and against the study. I rendered BUSINESS_PLAN_A3.html in headless Chromium and printed it to PDF three ways. I extracted every one of the 177 distinct dollar figures in the study and matched them mechanically against every numeric cell in the workbook. I read model_agedcare.py, model_params.py, trade_study.py, build_business_plan_json.py, business_plan.json, BUSINESS_PLAN_A3.html, SYSTEM_BREAKDOWN.md, SOURCE_MANIFEST.json, Dashboard.html, 09_Help_Hub/index.html, 02_Work/scratch/T3_trade_study_weights.md, 02_Work/scratch/V4_agedcare_margin_verification.md, the checker source for C10, C27, C29, C34 and C36, and the REQ, SRC, ASM, ACT, DEC, COMPONENTS and METRIC_LINEAGE registers. I ran 01_System/checkers/run_checks.py once. I did not run build_all.py.

The arithmetic in this project is, with two exceptions, correct — I could not break the aged care model, the trade study or the CBA. What I could break is the gap between what the checkers measure and what the requirements say. Six of the nine failures below are cases where a check passes over a narrower artefact set than its requirement covers, and nobody noticed because the check's own PASS line reads like a proof.

Verdict table

Defects found

1. The A3 business plan is a two-page document called a one-page document, and the check that says otherwise measures the wrong thing. What is wrong: BUSINESS_PLAN_A3.html prints to two A3 landscape sheets in Chromium under its own @page rule, at zero margins, and at browser-default margins. C34 measures document.querySelector('.sheet') height with style.height='auto' in a 1600×1200 screen viewport and reports "20 px to spare"; I reproduced that measurement exactly (held 1123, wanted 1103) and it is simply not a test of pagination — the DOM height is identical under emulate_media('print'), yet the printed output splits inside the three-column masonry. Why it matters: REQ-BUS-01 is the one requirement whose criterion explicitly says "as measured in a browser", precisely to stop this being asserted. The check was written to close a prior instance of this exact defect (its own docstring says the first build ran to 2,169px) and it closed the symptom, not the mechanism. What would fix it: make C34 call page.pdf(...) and fail on len(PdfReader(...).pages) > 1. Then fix the layout — the .sheet is 420mm×297mm inside an 8mm-margin @page, so it cannot fit even before the column fragmentation.

2. REQ-CON-04 is enforced over one of three delivered Office artefacts. What is wrong: C29 opens only the .docx. The delivered .pptx has 8 runs at 9.0pt; the delivered .xlsx has 145 cells at 9.0pt and three sheets wider than six columns (Scenarios 14, Costs 7, TradeStudy3 7). Why it matters: the requirement says "every delivered Office artefact". A green check over a subset is worse than no check, because the DoD in Appendix A cites C29's measured counts as the evidence for gate 13. What would fix it: extend C29 to iterate 05_Outputs/*.docx, *.pptx and *.xlsx, and then either raise the small type or record a waiver — there is currently no WVR row and the register is empty by design.

3. Two artefacts state different values for the same named quantity: the modelled three-year net. What is wrong: trade_study.py line 79 scores option D on "The modelled three-year net forgone is $145,621", and ASM-029 (in project_data.py line 1574, projected into both 03_Registers/ASM.csv and 00_Handover/ASM.csv) uses the same $145,621. The business plan computes $144,421.10 and repeats it three times, and the A3 page and value_validation both carry $144,421.10. The difference is $1,199.90. Why it matters: $145,621 is not produced by any function in the project — I re-derived the CBA and got 144,421.10 exactly. It is a stale constant carried into a trade study score rationale, and the whole point of trade_study.py's design is that "every score cites the figure it rests on". Here the figure it rests on does not exist. C09 compares twelve figures across artefacts and this was not one of them. What would fix it: compute it from build_business_plan_json's net rather than typing it, in both places.

4. The "same basis" comparison is not on the same basis, and the trade study's capital rationale misdescribes its own numbers. What is wrong: (a) The aged care side of Table 15.3 carries a care-management revenue line and a bad-debt line the NDIS side does not, and compares a budget-capped 5.04 hr/week client against an assumed 15 hr/week NDIS client (ASM-025, Low confidence) — ASM-025 itself concedes "At 34 hours a week the two contributions are equal", so the headline 2.3x is a statement about the assumed hours as much as about the sectors. The study discloses this in prose; the criterion for REQ-AC-01 does not test it, which is why I passed the requirement and am recording it here instead. (b) trade_study.py scores option C's capital 5/5 on "$3,673 one-off and an $8,757 six-month runway — under a quarter of either operating business". It is not: $3,673 is 34% of the NDIS $10,791 and 33% of the aged care $11,158, and $8,757 is 55% and 51% of the two six-month runways. The score may still be right; the figure cited to justify it is wrong by a factor of two. What would fix it: state the comparison's asymmetry inside Table 15.3 rather than only in the surrounding prose, and correct the option-C rationale to the ratio the model actually produces.

5. The number that reconciles the aged care paradox is in no source register row. What is wrong: "$16.10 per client per day" carries the whole of REQ-AC-04 — it appears in study finding 5, Table 29, RSK-011, deck slide 9 and the business plan mitigation, each time cited as "[SRC-068 …]". SRC-068's Value field is "Aged Care Financial Performance Survey, March 2026, Support at Home results". It contains no figure. No SRC row anywhere carries $16.10, $63.85 or $47.75. Why it matters: C36 checks that every cited identifier exists; it does not check that the cited row contains the figure. The project's own C36 docstring warns that "a citation that resolves to nothing is worse than no citation" — this is the same failure one level down. The derivation is real (V4 quotes the primary text and does the subtraction honestly, and explicitly refuses to convert it to a $/hour figure it cannot evidence), but a scratch verification file is not the source register. What would fix it: add an SRC row carrying $63.85 and $47.75 pcd from SRC-068's PDF, and cite that.

6. The T3 weights record cannot evidence its own ordering, and the file system contradicts it. What is wrong: 02_Work/scratch/T3_trade_study_weights.md states "Timestamp: 2026-09-07T06:22:16Z" and "Nothing below this line existed when the timestamp above was taken" — then contains the scored results below that line, in the same file. Its mtime is 06:23:22. trade_study.py's mtime is 06:23:07. The weights record was last written fifteen seconds after the scores file. The manifest hash-gates it at 06:38:43, long after both. Why it matters: GOV-B6.3's whole content is the ordering, and under GOV-C3.2 the builder's statement about that ordering carries zero weight. A single file that contains both the weights and the scores, whose only ordering evidence is a line of prose inside itself, is exactly the "justification, not a trade study" the file's own text warns against. Note the contrast: DEC-004 and DEC-003 do it properly, recording weights at 09:40 and scores at 11:05 as separate register fields. What would fix it: split the record into a weights file and a results file, and let the results file's mtime be the later one. (Separately: alternative A3 in trade study 1, "Remain unregistered indefinitely", is by the study's own SRC-015 unlawful for a core-supports business from July 2027, so the three-alternative count leans on one option that cannot be adopted for the period the study models.)

7. The Help Hub and the Dashboard are Part-I surfaces that were not updated for Part II, and two Help Hub entries state facts that are false. What is wrong: HLP-10 tells a user diagnosing "two documents give different numbers" to "Check the as-at date on both. Every artefact in this project carries 20 August 2026" — every artefact carries 7 September 2026 and v2.0.0. It tells a user chasing a dead source URL that "Every row says 20 August 2026" in SRC.csv — twenty of the seventy-three rows say 2026-09-07. HLP-03's register table describes DEF as "Three raised, three closed" beside a count of 24. HLP-05's fifteen-minute reading route sends the reader to sections 1, 9, 5.2, 7 and 13 — entirely Part I — and never mentions the aged care business, section 16 or the recommendation that actually stands; it also says section 1 has "Six findings" where the delivered study has seven. The Dashboard's "Capital at risk before first revenue" tile reads $15,875 (the NDIS entity alone) while the study's headline for the same concept is $44,483–$52,848, and no aged care metric appears on the dashboard at all, though METRIC_LINEAGE carries four. Why it matters: C10 matches the nine failure modes by regex against wording, so wording that is present but false passes. The status surface a stranger opens first tells them the capital at risk is a third of what the study says it is. What would fix it: drive those sentences from CURRENCY_DATE and the register counts instead of typing them, and add the combined capital and the per-client contribution to the dashboard.

8. The delivered workbook's own README makes three false statements about the workbook. What is wrong: it is titled "NDIS Business Enabling Study — Financial Model v1.0" on a file delivered as v2.0; it says "CURRENCY | Every external figure was verified on 2026-09-07" when 53 of 73 sources were verified 2026-08-20 (and then says "re-verify before 2027-08-20", which is twelve months from the other date); and it says "Nothing in this workbook is a typed-in result", which is untrue of the Combined sheet (B5:C9 are all typed constants copied from the models, only D5:D11 are formulas) and the Structure sheet (B5, C5, B6, C6 typed). Why it matters: the second statement is the exact falsification that CR-007 amended REQ-CON-03 to prevent — "the project could only stay green by pretending the older sources had been re-read". The amendment fixed the register and left the claim standing inside the delivered artefact. What would fix it: generate the README's currency sentence from CURRENCY_DATE and the SRC accessed-date distribution, and either wire Combined and Structure to the other sheets or drop the "nothing is typed in" claim.

9. The study contradicts its own computed sensitivity table on what happens at a $20,000 budget, and the $90,000 opportunity-cost figure is wrong. What is wrong: (a) Study finding on page 1 and ACT-010 say "At $20,000 the contribution per client falls by a third" (the model says 36%, consistent). Study Table 37, business_plan.json.value_validation.what_would_change_this and the A3 page all say "An average assessed classification budget below $20,000 a year, which halves the aged care contribution per client". Halving happens at roughly $16,200, not $20,000 — the study's own Table 15.2 shows $20,000 → $638.83 against $1,002.06. The same document says "a third" and "a half" about the same threshold. (b) ASM-028 and the study's ACT-013 box both say "At $90,000 a year of foregone income the three-year return falls from 53 per cent to roughly 10 per cent". Substituting $90,000 into the plan's own CBA gives total cost $365,726.60, net $54,421.10, ROI 14.9% — and the base is 52.4%, not 53. ACT-013 describes this as "the one input that changes the verdict", so the number carrying it should be computed, not estimated. What would fix it: compute both sensitivities from build_business_plan_json and emit them, rather than writing them in prose.

10. Smaller things I would still record. build_business_plan_json.py line 186 emits "baseline": "NDIS $%s" % f"{ac_contrib_client_paid and NR and 0 or 0}" — which always evaluates to 0 — and is silently repaired 250 lines later by a patch at the end of build(). The delivered JSON is correct only because of that patch; any refactor that drops it ships "NDIS $0" onto the A3 page. The quantitative_benefits figure uses the rounded $6.70 rather than $6.69692875, overstating three-year benefits by $34.12 (immaterial, but it is why the number is 420,147.70 rather than 420,113.58). The CBA excludes the support coordination line entirely while revenue_model projects $246,660 of it over three years and the recommendation tells the owner to run it — the two blocks are on different bases, and the support coordination year_projection is net of fixed cost while the other two rows are gross revenue. Study Table 5.1 cites "$8,757 … [Financial Model, SupportCoordination sheet]" for a six-month runway figure that sheet does not contain. The SIL/SDA band "$8,600 to $16,900" is not reproducible from the components it names. Deck slide 12 uses Windows backslash separators in its file paths, and slides 7, 8 and 9 are all numbered "07". BUSINESS_PLAN_A3.html names two different OWNER generators — portable/templates/business_plan/build_business_plan.py in the head comment and build_business_plan_json.py in the footer. The workbook's AC_Inputs row for the Schedule F Level 3 rate says it is "used for care management and administration time" when the model deliberately uses the SACS rate instead (ASM-031, stated three rows below on the same sheet).

11. The 26 "Verified" statuses rest on a verification of a different artefact set. What is wrong: IV_VERDICT marks 26 requirements PASS, sourced to V3_closing_verdict.md, "independent verification pass 4, 2026-08-20". Every delivered artefact was rebuilt on 2026-09-07 with Part II, sections 14-20, tables 24-38 and the aged care registers added. C31 checks that the register agrees with IV_VERDICT; it does not check that IV_VERDICT was taken against the current baseline. Why it matters: nine of the failures in my table above are in artefacts that carry a v2.0.0 baseline stamp and a 20 August verdict. The mechanism that removed self-certification is sound; it simply has no staleness test. What would fix it: record the baseline each verdict was taken against, and have C31 fail when a requirement's verdict predates the baseline it is claimed for. This report supplies the v2.0.0 verdicts.

What I could not verify, and why

• Whether any external fact is actually true. I verified internal consistency, derivation and citation, not the world. Every price, wage, fee and legal position in this study rests on a single fetch, most of them Medium confidence with the reason stated. I did not open a single one of the 73 source URLs, and this report is not evidence that $103.11, $73.58, $45.28, $43.03 or the July 2027 date are correct.

• The trade study scores themselves. I re-derived the weighted arithmetic and the sensitivity flip and both are exact. Whether option A's capital deserves a 3 and option C's a 5 is a judgement, not a computation, and no verification pass can settle it. The project is right to escalate it.

• Print pagination on any engine other than Chromium. I measured with headless Chromium via Playwright, which is what C34 uses. A different print engine might paginate differently; two pages in the one engine the project's own checker drives is enough to fail the claim, but I have not tested Word, Safari or a physical printer.

• Whether the Decision Pack renders as designed. I read its text, runs and tables through python-pptx. I did not render the slides, so I cannot speak to overflow, overlap or contrast on any of the twelve.

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

• Whether "1.0 client" is the right break-even to publish. It is arithmetically correct against the aged care entity's own $993.17 fixed cost, but the study's own operating rule is that the aged care line must cover the combined $1,840.50, which is 1.84 clients. Both figures are stated; which one belongs on slide 2 is an editorial call I am not making.

Disclosure of my own footprint. Running 01_System/checkers/run_checks.py, as I was invited to, rewrote 01_System/checker_run_log.txt. My first command imported project_data without sys.dont_write_bytecode, which created 01_System/__pycache__/project_data.cpython-311.pyc — that directory is the entire content of the C35 FAIL in the run above, and it is mine, not the build's. python 01_System/tidy.py clears it. I modified no other file and did not run build_all.py.

Closing verdict

23 of 32 requirements PASS.