Capstone: The Close-to-Board Simulation

Here is the part that is easy to underrate. Each component can be correct on its own and the package can still fail, because the board does not read the pieces in isolation; it reads them together. If the summary says revenue rose on one story and the variance section shows a different one, or if a figure reads $410,000 in one place and $450,000 in another, the reader stops trusting the whole package, even though most of it is right. Getting each piece right is necessary. Getting the pieces to agree with one another, and getting the summary to tie back to them, is a separate discipline layered on top.

Think of it as a reconciliation problem rather than four writing problems. The one-page summary is a claim about the components underneath it, so every headline figure in the summary should trace down to the component it came from, and any figure that appears in two components should read the same in both. That through-line, from the summary down to each supporting piece and back, is what makes a package defensible in front of a board and an audit committee.

Before chaining them, recall what each component is for and what standard it is held to, since the capstone carries those standards forward unchanged.

• Close and flux (Module 1). Close-ready commentary that ties every figure to the trial balance, screens by materiality as a first pass, and names only drivers the data supports. The material movements this month were a price-led revenue gain, a freight-rate cost spike, an engineering run-rate step, and a one-time legal item.
• Variance and driver tree (Module 2). The revenue beat decomposed into price and volume by line, with at least one alternative hypothesis so the story is not a single confident guess.
• Exception review (Module 6). A small set of rules run against the general-ledger extract, surfacing the entries that warrant a look, each with the rule it tripped and a proportionate disposition, on a reperformable audit trail.
• Technical memo (Module 7). One issue worked to a supported position, with the alternative treatment addressed and ruled out, and the open point flagged rather than hidden.

Each of those modules left you a worked example of its finished output. Those four examples are your destinations again here; the capstone asks you to reach all four in one month and then bind them together.

Now the reason this belongs in an AI course rather than being left as four separate exercises. The method you have practiced generalizes cleanly to a chain: the deterministic math still lives in each component's template or query, the folder is still scoped to what the task needs, the human checkpoint still sits before the deliverable, and the whole thing is still a reusable pattern rather than a one-off. A model is genuinely useful at running four practiced workflows over one dataset and drafting a first-pass summary that pulls their headlines together, which is the slow, assembly-heavy part of a board package.

What the chain does not hand to the model is the judgment that the pieces agree. Reconciling the components to each other, and confirming the summary ties to them, is the cross-check that stays with you. As in every module, the model is a fast preparer here, not an approver. The rest of this module builds the workflow around that split: let the model draft and synthesize, and keep the reconciliation and the sign-off human.