Capital Spending Request Gate

Architecture

Key specifications

What it does for you

A developer commits capital to a project only through an ordered sequence of Investment Committee phase gates, and every Spending Request that opens a gate must conform to a written set of underwriting standards: dollar triggers that demand an approval before the first dollar is spent, contingency floors, a standard growth assumption, prescribed fee formulas, a phase-indexed estimate basis and deliverable matrix, and a comparison basis that switches once feasibility is waived. Whether the investment itself is worth making is genuine business judgment, and no control here opines on it. Three failures hide inside a bound package, and none of them look wrong. Pursuit costs accumulate past their trigger, or a deposit goes non-refundable, before the Initial Commitment Request was ever approved -- and by the time the package is assembled the approval that is in it post-dates the spend it was supposed to authorize. A contingency sits a cent under the floor, a fee is stated a little off its formula, the growth assumption departs from the standard with no market support documented, the comparison still points at the template after feasibility was waived -- each figure plausible, none re-derived. And the gate summary calls every phase cleared on a determination nobody rebuilt from the approvals and the deliverable checklist underneath it. None of these are judgment calls. They are date gates on a running total, equalities to the cent, floors cross-multiplied in integers, membership tests and re-derivations -- which a deterministic control settles better than a bound package inherited by whoever assembles the request this cycle.

The seeded demo runs every control over every request package⁷. The CLI generates thirty-one fictional request packages -- one clean baseline and thirty carrying a single planted defect each -- then runs all twenty-nine controls over each. The clean file returns PASS with no flags; every defect file returns REVIEW or FAIL and names the control it tripped along with the reason that control exists.

The trigger and the floor are boundary-exact⁸. The dollar trigger is a date gate on a running total and the contingency floor is a cross-multiplied equality. One defect file adds a pursuit invoice that pre-dates the Initial Commitment approval, carrying the cumulative total past the trigger on its own and tripping trg_ic_before_pursuit_spend; another drops the site contingency one cent under its construction-start floor and trips cty_hard_floor, while a contingency met to the cent passes -- proving each gate is settled at its boundary, not within a tolerance band.

The gate summary is recomputed, not read back⁹. A defect file flips a stated gate-cleared flag in the summary without changing the approvals or the checklist beneath it. seq_gate_summary_recomputes rebuilds every phase's determination from the approval log and the deliverable checklist through the shared standards kernel and fails on the one that disagrees, proving the summary is recomputed from the evidence rather than trusted as stated.

Functional block diagram

Instruction set

Benchmarks

Control characteristics

• Read-only: request packages are parsed and never written back, so the engine cannot introduce the break it reports.
• Integer cents throughout, compared with exact == and floors tested cross-multiplied in integers; there is no tolerance band, and a cent under a floor is reported as a break.
• A figure that should be integer cents or basis points but is not produces an AMOUNT_INVALID finding contained to the one row it was read on, rather than being coerced into the number the engine is meant to audit.
• One standards kernel: the controls and the generator share spending_engine.standards, so a determination cannot disagree with the data that produced it.
• The dollar triggers and the contingency floors are boundary-exact: an approval dated on the breach date satisfies the trigger and a contingency met to the cent meets the floor, each one day or one cent short a failure.
• Deterministic and byte-stable: same inputs produce the same findings in the same order, 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 approves a Spending Request, commits capital, files an interim request, or writes to a source artifact. It reads the request package and stops.¹⁴
• It reads the nine artifacts the request record emits. It does not connect to a general ledger, an accounts-payable system, a bid platform or the Investment Committee's minutes.¹⁵
• It proves the package conforms to the written underwriting standards -- triggers, floors, sequence, membership and re-derivations -- not that the investment is worth making or that a bid is genuinely competitive. That judgment is the Investment Committee's.¹⁶
• It re-derives every figure at the fictional policy constants the standards carry -- the trigger thresholds, the contingency floors, the fee rates and the growth default; it does not decide whether those standards are the correct ones for the developer or the market.¹⁷
• It takes the approval, spend and deliverable records at face value: it confirms the package foots, sequences and re-derives, not that a spend actually occurred or that a deliverable's content is adequate. All shipped data is fictional and the underwriting period is set in a fictional future.¹⁸

See it run

Integration

Distribution: public repository, MIT license.