Financing Execution & Schedule Variance

Architecture

Key specifications

What it does for you

A capital-markets team publishes a monthly "Upcoming Financings" report: every active financing is a workstream, typed as debt marketing, equity syndication or an extension/refinancing, and each carries an Original | Prior | Current | Variance block of milestone dates plus a summary Gantt and a rollup of the active count, the overdue count and the total capital in flight. It is a snapshot of a pipeline that moves every month, and it drifts in ways nobody watches. Four failures hide inside that, and none of them look wrong in a spreadsheet. The variance stops reconciling: a hand-edited Current date leaves the Variance beside it behind, so the report says a milestone slipped by a number that no longer matches its own dates. The month-over-month chain breaks: this month's Prior column no longer equals last month's Current, or the Original baseline is quietly overwritten, and the report reads current while its history no longer ties. The playbook or the portfolio has a hole: a live workstream is missing one of its financing type's standard milestones, or a project on the master tracker has no workstream in the report at all. And the rollup drifts from the schedule: the active count, the overdue list or the financing total is stated on a figure nobody recomputed from the workstreams underneath it, while the Gantt places a bar in a month that is not the month the deal is set to close. None of these are judgment calls. They are equalities and comparisons -- a stated Variance against Current minus Prior with exact ==, a Prior date against last month's Current, a financing total against the sum of the active workstreams, an overdue flag against a date gate with a strict less-than -- which a deterministic control settles better than a spreadsheet inherited by whoever keeps the pipeline this month.

The seeded demo runs every control over every financing report⁷. The CLI generates twenty-three fictional financing reports -- one clean baseline and one carrying each of the twenty-two planted defects -- then runs all twenty-one controls over each. The clean report returns PASS with no flags; every defect report returns REVIEW or FAIL and names the control it tripped along with the reason that control exists.

The controls are independent and boundary-exact⁸. One defect file pulls a later-sequence milestone back to its predecessor's date while re-deriving the variance, so only ord_current_nondecreasing fires and var_recomputes still holds. Another moves the report date one day before period-end, tripping date_report_is_period_end while every overdue count stays untouched, because the gate is a strict less-than that no current date has yet crossed. Each break is confined to the control it was built for.

The variance is recomputed, not read back⁹. A defect file bumps one milestone's stated Variance by a single day without moving its dates, so the report claims a slippage its own Prior and Current no longer support. var_recomputes rebuilds the variance as Current minus Prior in whole days and fails, proving the number is recomputed from the milestone's dates rather than trusted as stated.

Functional block diagram

Instruction set

Benchmarks

Control characteristics

• Read-only: financing reports are parsed and never written back, so the engine cannot introduce the break it reports.
• Integer cents throughout, compared with exact ==; there is no tolerance band on a financing amount or a count, and a cent or a day off the re-derivation is reported as a break.
• A count or amount that should be an integer but is not produces an AMOUNT_INVALID finding contained to the one field it was read on, rather than being coerced into the number the engine is meant to audit.
• One schedule kernel: the controls and the generator share the kernel in financing_engine.schedule, so a re-derived variance, overdue flag or Gantt month cannot disagree with the data that produced it.
• The overdue gate is boundary-exact: a milestone whose current date lands exactly on the report date is due today, not yet overdue, and a closed workstream is never overdue.
• Every overdue and period-end test is measured to the report_date carried in the file, never the system clock, so the run is deterministic and byte-stable with no timestamps or absolute paths in any output.
• Absent evidence is never a passing control; a missing artifact fails completeness rather than letting the controls that read it pass unread.

Operating limits

• The engine never books an entry, releases a wire, accrues a note, settles cash, files a report, or writes to a source artifact. It reads the financing report and stops.¹⁴
• It reads the seven artifacts the monthly report emits. It does not connect to a loan system, a treasury workstation, a general ledger or the underlying deal documents.¹⁵
• It proves the report reconciles to itself and to the month before it -- variances re-derive, the roll-forward ties, the baseline is frozen, the playbook is complete -- not that any milestone date is the right target or that a financing will actually close. That judgment is the deal team's.¹⁶
• It re-derives each overdue flag and period-end date against the report_date the file carries; it does not decide whether that report date, or the target closing dates beneath it, are the correct ones for the pipeline.¹⁷
• It takes the milestone dates, statuses and amounts at face value: it confirms the register, schedule and rollup foot and reconcile, not that a milestone was actually met. All shipped data is fictional and the report period is set in a fictional future.¹⁸

See it run

Integration

Distribution: public repository, MIT license.