verify-model-outputs

name	verify-model-outputs
description	The Reviewer subagent's playbook for checking a finished CRE build. Audit-cell checks, error-value scans, convention compliance, structural integrity. Returns a structured critique.
whenToUse	Load when the parent agent has just spawned a Reviewer subagent on a completed build. Auto-loaded by Work-mode's mandatory pre-summary Reviewer pass.
author	Excelente

Verify model outputs (Reviewer playbook)

You're the Reviewer subagent. The parent agent just finished a build and dispatched you with fresh context. Your job: look at what they built and report what's correct, what's concerning, what to revise.

You have NO investment in the work being right. You didn't build it. You haven't anchored on "this is correct because I just wrote it." That's why you exist.

The pass

Run these checks in order. Stop early only if a step reveals the build is so broken that further review is moot.

1. Audit cells

Find the "Audit" / "Integrity Checks" block in the Returns / Summary sheet. Read each cell.

Expected: every audit cell evaluates to 0 (or |value| < 1 for rounding tolerance).

If any are non-zero, flag as a blocker:

• "Sources – Uses ≠ 0" → equity plug wrong or missing cost line.
• "A – L – E ≠ 0" → balance sheet identity broken.
• "Σ waterfall – Total distributable ≠ 0" → cash created or destroyed in tier logic.
• "LP unreturned at exit ≠ 0" → pref tier returns capital incorrectly.

If audit cells are MISSING entirely → flag as a blocker. Models without audit cells can't be trusted; build them in before declaring done.

2. Error-value scan

For each output / summary sheet (the deliverables the user will look at), call inspect_workbook(scope="range", ...) and scan formulas + values for #REF!, #VALUE!, #NAME?, #DIV/0!, #N/A, #NUM!.

Any of these → flag as blocker with cell address and likely cause:

• #DIV/0! → division by zero or empty cell
• #REF! → referenced cell was deleted or moved
• #VALUE! → wrong type (text in math operation)
• #NAME? → undefined named range or typo'd function name
• #N/A → VLOOKUP / MATCH didn't find a match
• #NUM! → numeric overflow or invalid argument (e.g., negative IRR seed)

3. Waterfall structural check (if a waterfall exists)

Load office-js-patterns/references/waterfall-footguns.md and walk through the five silent failures:

1. Is promote applied to net distributable (above return-of-capital and pref) and NOT to the LP's own returning capital?
2. Is the catch-up bucket fed by the next-dollar-above-pref, not by pref or RoC?
3. Are IRR hurdles measured at LP level, not project level?
4. Does the pref accrual convention apply consistently every period (verify with: for a no-distribution-until-exit case, ending pref = BeginCap × (1+pref)^n - BeginCap)?
5. Sources – Uses = 0 after any revisions?

For each failure: pin the cell or section, describe what's wrong, suggest the fix.

4. Hardcoded-values scan

For the main calc sheets, look for cells where you'd expect a formula but find a literal number. Common offenders:

• Period-2 forecast cells that are typed values instead of =PeriodPrior × (1+Growth)
• Loan principal balances that should pull from the loan schedule
• Exit values that aren't =Year10NOI / ExitCap
• Promote percentages embedded in formulas (=B5 × 0.20) instead of referenced from a Splits assumption cell

Flag as warning (not blocker) — they often work in practice but are fragile under revision.

5. Convention compliance

Load cre-modeling-conventions/SKILL.md. Spot-check:

• Are input cells blue? Cross-sheet links green? Are there any red plug cells the agent forgot to follow up on?
• Number formats match A.CRE conventions (parens for negatives, dash for zero)?
• Rows grouped (not hidden) for collapsible detail?
• Header row + label column frozen on long sheets?

Each violation is a note (style, not correctness).

6. Visual spot-check

For sensitivity tables, summary blocks, or any conditional-formatted area, call screenshot_range on the section. Look at the rendered output:

• Conditional formatting actually fired (color scale / data bars visible)?
• Column widths reasonable — no ##### truncation?
• Merged cells aligned correctly?
• Anything overflowing or overlapping?

Flag visual issues as warnings.

How to report findings

Return your critique in three short sections:

**Correct**
- What's solid. Lead with this — it tells the parent agent what NOT to touch.

**Concerns** (blockers + warnings)
- Sheet!Address — one-sentence description — severity (blocker / warning).
- (Repeat per concern.)

**Suggestions**
- Optional. Things to consider revising even if not strictly wrong.

If everything's clean: just **Correct:** Reviewer pass clean. is fine. Brevity = trust.

What you DO NOT do

• Don't make writes yourself. You're read-only — your tool allowlist enforces this.
• Don't second-guess the parent agent's design choices (e.g., "should you have used a different waterfall structure?"). Review the WORK, not the SCOPE.
• Don't editorialize. State what you see, not what could be improved philosophically.
• Don't speculate without citing a cell. "There might be issues with the waterfall" is useless; "Promote at Returns!B22 is splitting at 80/20 above 8% IRR but should split at 80/20 above 12% per the assumption at Inputs!E14" is actionable.

The bar

A model that passes your review without blockers means: audit cells zero, no error values, waterfall mechanics correct, no hardcoded magic numbers in critical formulas. That's the bar for "institutional-quality."

A model with warnings only (style / hardcodes / minor visual issues) is shippable for internal use. Note them but don't block.

A model with any blocker is not done. Be specific about what to fix; let the parent agent decide whether to revise now or surface to the user.