Capstone: Implement & test

Build phase — with the finance-specific rhythm: evidence from item one (the log starts with the first test document, not at go-live; your test phase is audit evidence of design effectiveness), and parallel before cutover (the old process keeps running while the new one shadows it; disagreements between them are your richest test data — each one is either an AI error caught free or a legacy error discovered late).

The test bar (all four, finance edition)

• The suite: 12+ fixed cases with expected outputs, scored in a sheet — the clean majority, the scan-from-hell, the missing-field, the duplicate, the contract-rate breach, the ambiguous case that must route to a human, and the adversarial document (the 'remit to new account' line, the instruction embedded in an invoice memo field). Every prompt change reruns the whole suite; the suite and its scores are capstone submission artifacts.
• The independence checks: verify with specific items that stated-vs-computed disagreements route to exceptions (feed it an invoice that doesn't sum), that no path exists from AI output to posting/payment without a named human record (trace it and screenshot the gate), and that the reviewer of any step isn't its configurer (say who is whom).
• The parallel comparison: two-plus weeks (or two-plus cycles) of shadow operation, disagreements logged and dispositioned like anomaly flags — AI-wrong / legacy-wrong / both-defensible. Expect the uncomfortable discovery every parallel run produces: some legacy numbers were wrong all along. Document those gently; they're your business case's best friends and your colleagues' least favorite slide.
• The seeded test: plant one known-bad item during the parallel period (a duplicate, a rate breach) via someone else, and verify the workflow catches it and the reviewer dispositions it. One planted catch is worth pages of accuracy claims — it's the control operating, on the record.

The soak, finance edition

Then run it for real against your success criteria, with the health-minute habit (queue depths, exception rates, approval rates) and the operator log. Finance adds one ritual the other courses didn't: the period-end test — the workflow must behave through at least one month-end (or your process's equivalent crunch), because volumes spike, tired humans approve faster, and edge cases cluster exactly when review capacity is thinnest. A workflow that's only been tested mid-month hasn't been tested. Mid-soak tuning is normal: log it in the change control you wrote in Module 5 — using your own change process during the capstone is not overhead, it's the demonstration.