| name | deliverable-verification |
| description | Every number you assert in a deliverable must first be confirmed by the vr-verify spine — a number the spine did not re-derive is NOT done, it is a draft. Load this whenever you produce a numeric deliverable: journal entries, a trial balance or tie-out, a depreciation/amortization schedule, a loan amortization or payment, a retained-earnings roll-forward, a footing/cross-foot, or any worksheet whose totals you are about to state to the partner or a client. Defines the side-artifact 'verification spec' you emit alongside the deliverable (the entries, the tie-out table of {name,expected,actual}, and the recompute params) and mandates the exact vr-verify call sequence (check_balanced, check_ties, foot, recompute_depreciation, recompute_loan_payment, reroll_retained_earnings) that must pass before you write the number down. Pairs with workpaper-standard (where the number lives) and self-review-qc (the human-eyes pass on top). |
| version | 1.0.0 |
| author | RealDeal CPA |
| license | MIT |
| platforms | ["linux","macos","windows"] |
| metadata | {"hermes":{"tags":["Verification","Tie-Out","Footing","Recompute","Deliverable","Quality","Numbers","Spine"],"related_skills":["workpaper-standard","self-review-qc","authority-and-escalation"]}} |
Deliverable Verification
A number you typed is a claim. A number the vr-verify spine re-derived is a fact. You only
ship facts. Before you assert any figure in a deliverable, you run it back through the spine; if the
spine did not confirm it, it is not done — it is a draft you are not allowed to send yet.
This is not optional self-discipline you can skip when you're confident. Confidence is exactly when
errors ship. The rule is mechanical: every asserted number gets a verify call, or it doesn't go out.
The verification spec (the side-artifact)
For any numeric deliverable, emit a small spec alongside the deliverable. It is the machine-checkable
shadow of what you're claiming. Three sections, only the ones that apply:
- entries — the journal entries you're posting, line by line with debits/credits, for
check_balanced.
- ties — a tie-out table: a list of
{name, expected, actual} rows, where expected is the
independent source (prior workpaper, bank statement, fixed-asset register, GL balance) and actual
is the number in your deliverable. Fed to check_ties. Also list any column/row that must foot.
- recompute — the parameters for anything you derived from a formula rather than read off a
document: depreciation (cost, salvage, life, method, period), a loan payment (principal, rate, term),
or a retained-earnings roll (beginning RE, net income, dividends/distributions, expected ending).
The spec is data, not prose. You hand each section to the matching tool and read back PASS/FAIL.
The vr-verify tools (the only ones you call here)
Use exactly these six — never invent a verify tool that isn't on this list:
check_balanced — debits == credits for an entry or batch. Run on every journal entry.check_ties — for each {name, expected, actual}, confirms expected == actual (within zero
tolerance unless you state one). Run on every tie-out.foot — re-adds a column/list and cross-foots; confirms the stated total. Run on every total you print.recompute_depreciation — re-derives the period (and accumulated) depreciation from the asset params.recompute_loan_payment — re-derives the payment / interest / principal split from the loan params.reroll_retained_earnings — re-rolls beginning RE + net income − distributions to your ending RE.
If a number isn't covered by one of these, that's a signal to decompose it until it is (a P&L line is a
foot of its accounts; a schedule total is a foot of its rows; a computed value is a recompute).
The discipline
- Build the deliverable.
- Build the verification spec from it.
- Run the spine over the spec — one call per tool that applies.
- Any FAIL → stop. Fix the deliverable (not the spec) and re-run from step 2. Never edit the
expected to match a wrong actual — that's gaming the check, and it's the no-deception line.
- All PASS → record the verify results in the workpaper per workpaper-standard, then hand off to
self-review-qc for the human-eyes pass (reasonableness, classification, presentation) that the
spine cannot do. Spine-green is necessary, never sufficient — both gates clear before it ships.
A number that never made it into the spec is the dangerous one: it looks asserted but was never checked.
When you review your own spec, ask "is every figure in the deliverable represented in a section here?"
If a figure has no row, it has no verification, and it is not done.
Worked example — a fixed-asset purchase + tie-out
Deliverable: post a $24,000 machine bought 2025-01-01 (5-yr straight-line, $0 salvage), and tie the
FY2025 depreciation and ending accumulated depreciation to the fixed-asset register.
Verification spec:
entries:
- JE-2025-014:
DR Machinery & Equipment 24000.00
CR Cash 24000.00
recompute:
- depreciation: {cost: 24000.00, salvage: 0.00, life_years: 5,
method: straight_line, period: FY2025} # expect 4800.00
ties:
- {name: "FY2025 depr exp", expected: 4800.00, actual: 4800.00}
- {name: "Accum depr 12/31/25", expected: 4800.00, actual: 4800.00}
foot:
- {name: "FA register dep column", rows: [4800.00], total: 4800.00}
Verify call sequence:
check_balanced(JE-2025-014) -> PASS (24000 == 24000)
recompute_depreciation(cost=24000, salvage=0, life_years=5,
method=straight_line, period=FY2025) -> 4800.00
check_ties([{FY2025 depr exp,4800,4800},
{Accum depr 12/31/25,4800,4800}]) -> PASS
foot(rows=[4800.00], total=4800.00) -> PASS
Four greens → the $4,800 is now a fact. Had recompute_depreciation returned 4800.00 but the
register's expected said 4000.00, check_ties FAILs — you investigate the register/source, you do
not quietly overwrite expected. Only after all-PASS do you write "FY2025 depreciation $4,800" in the
deliverable and log the verify results to the workpaper.
When the spine and a source disagree
A FAIL is information, not an obstacle. The recompute is arithmetic-correct by construction, so a tie
break usually means the source is stale, the params are wrong, or your actual was mistyped. Run it
down; if it's a real discrepancy in the client's records, that's an exception — escalate per
authority-and-escalation, don't paper over it to get to green.
