pitch.forecasts.finance
Forecasts as typed calls.
Rolling forecasts and cash projections derived from the same records the close certifies — under assumption sets you name, with lineage on every record and a receipt on every served call. The platform computes; it never opines.
↓ scroll · arrow keys
The close produces certified records. The forecast is built somewhere else — a spreadsheet, or a planning tool that is a spreadsheet with a login — by re-keying those records into a model that starts diverging from the books the day it is born. Assumptions live in cell formulas and in the modeler's head; the monthly "actuals refresh" is manual archaeology; and when the board asks where a number came from, the honest answer is a person and a tab, not a record.
The newer tools make the deeper problem worse, not better. Planning platforms now ship "AI insights" — views the vendor's model authored about your business, presented in your numbers' clothing. An FP&A lead who could not fully explain the spreadsheet now cannot fully explain the vendor either. And the caller is increasingly a machine: agent-run planning loops that want to refresh a projection the moment a period closes cannot sit through a seat-licence procurement, and a forecast they cannot re-derive is a forecast they should not act on.
The family's contract grammar carries over — discover the catalog, describe one function, estimate a call before making it, inspect the receipts — and this door adds four verbs of its own. derive: a rolling operating forecast from certified close records under a named assumption set. project: the cash view, at 13-week grain, from the same records. scenario: the same records under a different named assumption set — a scenario is an assumption set, never a platform opinion. reconcile: forecast-to-actual once the next period closes, with drivers named against the entity's own account names.
// SPECIMEN — illustrative product mechanics; nothing at this domain is live
POST /derive
{
"function": "derive.rolling_forecast@v3",
"program": "fpa-2026",
"inputs": {
"periods": ["close_2026-05@final", "close_2026-06@final", "close_2026-07@final"],
"assumptions": "entity:assumptions/base-case@v12",
"horizon": "P12M"
}
}
// every served record carries its lineage, and a receipt:
{
"record": {
"object": "forecast.record",
"specimen": true,
"derived_from": ["close_2026-05@final", "close_2026-06@final", "close_2026-07@final"],
"assumptions": "entity:assumptions/base-case@v12",
"function": "derive.rolling_forecast@v3",
"authored_view": null
},
"receipt": { "rate": "cited from the family card", "outcome": "served" }
}
Three properties are the whole design. Lineage is mandatory: every
forecast record names the certified close records it derived from and the
assumption set it derived under — authored_view is null by construction,
because there is no field for a platform opinion to live in. Assumptions
are the entity's: named, versioned, and authored by a named party at the
entity; the platform never supplies a default worldview. Derivation is
reproducible: the same records under the same assumption set return the
same forecast for any reviewer at any later date, and versions never change
silently under a planning cycle.
Two rules bound this door, and both are the product rather than the fine print. First: a forecast is never presented as anything the platform authored a view on. What is sold is derivation — arithmetic over the entity's certified records under the entity's named assumptions — so the entity's view is the only view in the record, and the person defending the number to a board is defending their own assumptions, not a vendor's.
Second: the one adjacent act the law reserves. Recommending where the
projected cash is placed is investment advice, reserved to a registered
investment adviser. A call that reaches it is designed to return a typed
BLOCKED that names the act and the party who may lawfully perform it —
and routes nowhere, permanently. The suite's doctrine holds
family-wide: the refusal runs at the moment a recommendation would be
uttered, not at the moment money would move, and no amount of licensing,
contracting, or sponsorship clears it on this platform.
| name | unit | covers |
|---|---|---|
| Rolling forecast | per served record | operating forecast derived from certified close records under a named assumption set |
| Cash projection | per served record | the 13-week-grain cash view, derived from the same records |
| Scenario | per served record | the same records under a different named assumption set |
| Forecast-to-actual | per served record | reconciliation against the next certified close, drivers named |
The meter's predicate is the estate's fourth, named in the family's canon (unratified): no record, no charge. A served forecast record meters; a null meters nothing; a retried failure never meters. No fee varies with the direction of any number — a forecast-up incentive is a forecast-wrong incentive, and the same rule that keeps the close honest keeps the projection honest. Rates are flat, fixed at post, on the family's one machine-readable card: no seats, no annual minimum, no percentage of anything projected.
Per-served-record rates by function class. The structure is fixed — flat, posted, predicate-named per SKU; the figures publish when the card carries them, and no figure is asserted before then.
The fourth ProofPredicate was written for data products and is new, unratified canon — and the live family card posts "no decision, no charge"; the fourth appears on no served surface yet (curl-verified 2026-07-30). Whether a forecast — a close-suite work product — is a served record is the same open owner question the sibling reconciliations door gates on. Until it is ruled, the meter promise here is design intent, and no SKU ships against it.
The finance back-office suite is one substrate with named faces:
monthend.finance is the close as a product — accruals, reconciliations,
variances, the books closed on a named clock — with controllers.finance
as its persona door. This door is the suite's forward face, and the
dependency runs one way: a forecast here derives from the records the
close certifies, so forecast quality is a property of record quality. That
is the argument for the suite, stated as product: the close is not
paperwork that precedes planning — it is the substrate planning should
have been standing on all along.
One ICP × one motion, chosen explicitly: the controller owns the certified past and walks through the close's own doors; the FP&A lead owns the derived future and walks through this one. Same family key, same posted card, different work-product, different owner.
Filed candidly: fin canon (owner-ratified 2026-07-26) rules the close-suite .finance work-product names 301 aliases into the monthend.finance flagship "until a SKU is real," and the live apex serves the RESERVED holding leaf that ruling prescribes. This record graduates the name to the suite's FP&A door; the graduation is queued for ratification, and the alias ruling stands until it lands.
Primary motion is B2A2B: the door serves the entity through its own
systems and agents — the planning loop calling derive the moment a
period closes, on the entity's behalf, under the entity's credential.
Secondary is A2A: external agents transacting with the rail directly,
machine to machine. The channel matches the caller — machine-readable
discovery at the apex and position in the agent-discovery namespace —
because a rail whose caller is a system is found the way systems look.
The FP&A lead is the named human this door is written for: the reader of
this contract, the author of the assumption sets, and the owner of the
number the calls produce.
A2A is the least proven motion in the estate and is claimed when the first external settlement clears on this door, not before.
The forecasting work-product migrates Human → Agentic → Generative → Code — and derivation is the rare case where the destination is available on day one: re-keying actuals dies at the lineage edge, schedule math is deterministic by construction, and drafting the variance narrative is generative work over named drivers. What never migrates is the part the entity keeps: authoring the assumptions. The door is built so that is all the human owns — which is why it can run at software economics with no licensed supply on its books.
Calling-system count, served-record volume, and revenue. Not presentable until the reporting basis resolves; no figure appears in this deck before then.
Stated as intent, not as standing — this door is pre-launch and says so below.
an entity whose board packs cite derived forecast records with lineage does not re-fork the ledger back into a spreadsheet — the record trail is the switching cost
a forecast derived from close-certified records is only offerable by the suite that certifies them; a standalone planning tool starts from re-keyed data by construction
posted per-record rates with no seats let the door serve any entity size at the same card — the family doctrine, inherited whole
computes-never-opines is a position an insights vendor cannot copy without deleting their own product
Stated plainly: this deck precedes everything except the coordinate and the family it is filed in. No forecast function, no catalog entry, no card row exists yet; the apex serves the estate's own RESERVED holding leaf, filed on purpose. Every amber above and below is deliberate — the record is built before the product, and says so.
The apex serves today (curl-verified 2026-07-30): the estate's RESERVED register leaf — "forecasts.finance · RESERVED · apis.finance family register," "Reserved for forecasts as typed calls … Rolling forecasts and cash projections derived from the same records the close certifies. Nothing at this domain is live." Serving is a liveness fact, not a product surface — and the leaf's own words are this record's offer.
The family hub serves today (curl-verified 2026-07-30): live front door, one-key onboarding, llms.txt / MCP / x402 rate-card framing, and the posted "no decision, no charge" promise. One key is designed to open every live door in the family — this one included, when it opens.
The close flagship this door derives from serves its own RESERVED leaf (curl-verified 2026-07-30): "Reserved for the close, as a product … Nothing at this domain is live." The dependency is stated with its true state: the substrate this door forecasts from is itself pre-launch.
What the apex serves is a placeholder, not a front door. The first product claim this brand can post is a real surface at its own address — which the suite's own copy law requires: a name becomes a door "at its own address before it says so" anywhere else.
The claim that matters: a real entity's planning loop, calling under its own program-scoped credential, deriving forecasts from its own certified close records — re-derivable by its own reviewers. It posts when it has happened, with the lineage discipline as the evidence.
The family's front door is apis.finance — it serves today, and this
record is this door's whole surface until the suite ships.
If this was forwarded to you: forecasts.finance is the FP&A door of the finance back-office suite — rolling forecasts and cash projections derived, as typed calls, from the same records the month-end close certifies, under assumption sets your entity names, with lineage on every record — priced flat per served record on the family's posted card once forecast SKUs post, and no figure is asserted before then. The platform computes; it never opines, and it never recommends where money is placed. Every claim above carries its own state and evidence — including the many not yet earned: this brand is candidly pre-launch, and its apex says so in the estate's own words. If you own a forecast: read the contract. If you know who does: forward this.