Investment Deck Check

Deck Check

QC that ends in a decision. Finding a discrepancy is the easy half; the work is saying what it proves, how confident we are, and whether the deck can go out. Every consequential finding carries a confidence label, and the pass ends in one readiness posture for the whole document.

Evidence labels, source tiers, staleness, the readiness posture and the intake limits: .agents/skills/research-conventions/SKILL.md, read before the first finding.

Step 1: Establish the artifact set and the evidence rules

Name the controlling artifact (the deck under review) and list every supporting artifact with its role: the model the numbers tie to, the filings behind the market claims, the prior version, the data pulls. A finding's confidence depends on which artifact it came from, so this classification happens before any checking.

The controlling model is the subject under test, and the deck is checked against it: a deck figure that does not match the model is a finding about the deck. Where the model and a source disagree, the sources resolve down the tiers in .agents/skills/research-conventions/references/evidence.md, the filing first, then the data tools, then company materials labelled as such, then third-party summaries. Two conflicting sources are never averaged and never silently resolved in favour of the flattering one.

Read the deck out with the pptx skill's extractor, which keeps the slide structure the checks depend on:

python .agents/skills/pptx/scripts/extract.py presentation.pptx > deck.json

The result is one JSON object with file, slide_size_in and slides. Each slide carries its index, title, layout, its text lines in shape order, a shapes inventory of names, positions and font sizes, tables as cells (a list of rows of strings), charts as series values against categories (or x_values, y_values and bubble_sizes for a scatter or bubble chart), and speaker notes. Keeping that structure is the point: a figure can then be reported as slide 4, Table 3 r2c2, and a table cell can be read through the row label and column header that say what it is, neither of which survives a prose export.

Render the slides to images with the pptx skill workflow. Every Critical or Important finding that rests on visible content is looked at on the rendered page before it is written, because the extractor sees text and cells while the reader sees a layout. Where a chart or table is an embedded image, the data is unextractable: say so in the report as a scope limit rather than passing over the page in silence.

Finding confidence

Every consequential finding takes exactly one label:

An external fact, an identifier or a third-party claim is never called wrong because the supplied files disagree with it or because the number looks implausible. Internal disagreement proves an internal disagreement. Anything beyond that needs the external source in hand, and without it the finding is needs review with the exact document that would settle it named.

Done when the controlling artifact is named, every supporting artifact carries its role, deck.json exists, the pages are rendered, and any image-only content is listed as a scope limit.

Step 2: Number consistency

python .agents/skills/check-deck/scripts/extract_numbers.py deck.json --check

The script also takes presentation.pptx directly when the extractor above is reachable, and falls back to a markdown or text export where a ## Slide 3 line starts a slide.

Every number is keyed by the metric word and the period or scenario token nearest to it (revenue|fy2024a, ebitda margin|fy2025e, revenue|h1fy2025, irr|basecase), and two numbers are compared only when the key, the unit class (percent, bps, multiple, currency, count) and the currency mark all match. So $1,200m and $1.2bn tie out, an FY25E forecast never reads as a contradiction of the FY24A actual, a CY24 figure never reads as a contradiction of the FY24 one (the two are the same window only for a December year end), an H1 figure never reads as a contradiction of the H2 one, and a percent is never weighed against a multiple. A scale suffix with no currency mark reads as money when the metric beside it is one, so Revenue FY25 100m still weighs against $120m, and as a tally otherwise, so 5m customers stays a count. A per-share figure written with its decimals is a price with or without the mark, so EPS FY25 5.00 weighs against $6.00, while the tallies a deck writes beside the same word (raised for 12 consecutive years) stay counts. A figure with no mark of its own takes the scale from the label beside it, singular or plural, so the bare 100 under a ($ in millions) header weighs against that $120m too. Two currencies are two amounts, so $100m and €100m never tie out and never contradict each other: the mixing is reported instead, and an unmarked figure weighs against whichever currency it is written beside. A gross figure and a net one are two claims about the same line rather than one claim made twice, so gross IRR, net IRR, gross MOIC, net MOIC, gross revenue and net revenue each key on their own: a deck stating 25% gross and 18% net is reconciling them, not contradicting itself. It reports:

Output is a JSON report: status, file, stats, every numbers entry with its slide, location, raw text, normalised value, unit class, currency mark and key, then findings. With --check the exit code is 1 when any fail exists, so it can gate a loop.

Reading the findings

Two figures are expected to match only when all seven agree: entity, metric definition, period, currency, scale, scenario, and source version. A finding that fails one of the seven is a definition difference, and the deck's fix is a clearer label rather than a changed number.

Worked non-mismatches, each of which looks like a value_conflict and is not one:

• An adjusted metric against a lender-defined or covenant-defined version of the same metric. Different definitions, both correct, both needing their basis named on the slide.
• Net leverage against first-lien net leverage. Different numerators.
• A figure in basis points against the same figure as a decimal percent (250bp and 2.50%). Different presentation, same value.
• A change stated in percentage points written as a percent move ("margin rose 12%" for a 120bp move). This is a convention error, logged as unit and period ambiguity rather than as an arithmetic error, per .agents/skills/research-conventions/references/market-data-rules.md.

Verify by hand what the script cannot

• Calculations are correct (totals, percentages, growth rates).
• Bridges and waterfalls add up to the totals they claim.
• Scale notation holds across pages ($M vs $MM, $B vs $Bn), rather than only within one.
• A basis-point move is written in basis points, and a margin delta in percentage points.
• Fiscal and calendar periods are not mixed inside one table, and each is labelled.
• Reported, adjusted, street and model versions of a metric are labelled where they appear, rather than used interchangeably.
• A denominator change or a sign-convention change is explained where it happens.
• Every data slide carries a source or as-of line.

Flag pattern:

ISSUE: EBITDA margin mismatch (key ebitda margin|fy2024a)
CONFIDENCE: confirmed internal mismatch
- 24.5% on Slide 2 (BodyBox) and Slide 3 (Table 3 r3c2)
- 24.9% on Slide 5 (BodyBox)
ACTION: Reconcile to a single figure

Done when every value_conflict is either a written finding or dismissed with the specific matching condition that fails, every hand-verification line above has been run, and every finding carries a confidence label.