Every generated number should carry its own receipt.

The email arrives mid-audit: "Please walk us through the Q3 management fee charged to folio MC-0142."

One number. One investor. And in most funds, that question starts an excavation: the workbook with the fee logic, the person who built it (who left in March), the tab named Q3_FINAL_v14(2), and the quiet hope that nobody re-sorted a range since.

The number is probably right. But probably right is not what audits, LP advisory committees, or your own sign-off are made of. What they need is a number that can show its work.

That is the design goal of CapHive's allocation engine: a quarter-end that explains itself.

Your fund's economics, written down once

Every fund's economics live somewhere. Management fee schedules, admin cost splits, income allocations, master–feeder pass-throughs, portfolio expense allocations. Usually they live in spreadsheets — which means they live in people.

CapHive stores them as formula rules: named, ordered, versioned rules attached to the fund. Twenty-one rule types cover the spectrum — generate an entry per LP, allocate a fund-level cost across commitments, pull master-fund entries down into a feeder, compute ownership percentages, roll amounts up into cumulative totals.

Run a period — month, quarter, or year — and the engine executes the rules in sequence, computes every entry for every LP commitment at 8-decimal-place precision, rolls per-LP entries up into fund-level totals, and hands back the statements, ratios, and reports built on top. For a real fund structure that is hundreds of thousands of generated numbers — in minutes, each one traceable to the rule and run that produced it.

Every number carries its own receipt

Here is the part we think matters most.

When the engine computes an entry, it doesn't just store the amount. It stores, on the entry itself, at the moment of computation:

• the exact formula that produced it,
• a plain description of what the rule does, and
• a variable-by-variable breakdown — every input the formula used, with the actual value it had: committed capital, fee rate, day count, FX rate.

Not reconstructed after the fact. Not "we can probably rebuild it." Stored at creation, on the number, where an auditor's question lands.

And because the breakdown is data, an AI layer can turn it into a sentence on demand: "2% per annum on $5.0M of committed capital, accrued for 92 days of Q3." The AI explains the receipt — it never computes the number.

Re-running is safe. Locking is final.

Numbers change late. A restated invoice, a corrected commitment, a fee rebate agreed after the quarter ended. The question is what a correction costs you.

In the engine, re-running a period replaces that period's entries rather than duplicating them. The run deletes what its formulas generated last time, then regenerates from the current data. Correction becomes: fix the input, run again, compare.

Before touching a full fund, you can run in sample mode — three LP commitments, end to end — and read the results like a proof.

And every run is a record: who ran it, for what period, with which formulas, how long each formula took (to the millisecond), and whether it succeeded. The Previous Runs page is a run ledger; every entry links back to its run and its formula.

Then there's the other direction: a period you never want to change again. Lock the run, and the engine refuses to execute anything overlapping those dates. Not a policy. A refusal.

⚙️ Under the hood: the close runs in a sealed room

The engineering here is what makes the guarantees above real:

• A private compute copy. Each run snapshots the fund's data — 15 tables — into an isolated scratch database. The heavy quarter-end computation happens there, never contending with the live platform your team is using. Two funds can close simultaneously without touching each other.
• Fail-closed isolation. The scratch models are physically unable to reach the primary database — the connection layer raises a safety violation rather than fall through. Not "instructed not to." Unable.
• Verified migration back. Finished entries return to the primary database in 5,000-row transactional batches, each batch flagged as migrated only after it lands, with a final sweep that catches anything a failure left behind.
• Numeric guardrails. A formula that divides by zero or produces a non-finite value fails loudly with the formula text and the LP named — it cannot silently write garbage.
• Attribution everywhere. Every generated row is attributed to the user who triggered the run, and the formulas themselves carry full change history — who edited what, when, from what to what.

	The workbook close	The engine close
Where the logic lives	One person's spreadsheet	Named, ordered, versioned rules
Re-running a period	New tab, duplicate risk	Replaces its own entries
"Walk me through this number"	Archaeology	Receipt stored on the entry
Who changed the fee logic	Unknown	Full change history, attributed
A closed quarter	A promise	Locked — the engine refuses

One run, every period

Month, quarter, and year are not three reporting projects. A formula can be flagged to emit its Quarterly, YTD, and Since-Inception variants automatically — same run, three period views, for every LP. Fiscal years are respected (an April-start year works out of the box).

And formulas consolidate: one multi-fee rule type generates entries for a whole list of fee types at once. The documented example: a reporting setup that needed 15 formulas became 3 — same entries, same totals, a third of the surface area to maintain.

When someone asks "what happened this quarter?", the period report answers on the fly: totals, entry counts, composition by fee type, a trailing-quarters trend, and drill-down from fund level to any single LP's folio — the same report an investor can be given for their own folio. AI commentary is on demand and anomaly-aware: "Management Fee is 42% above its trailing 4-quarter average" is a sentence you want before the LP asks.

And the numbers don't stop at reports you read on screen. Every generated entry feeds the statement and report builders: the same run can produce bespoke investor statements from your own templates — one per LP, built from that LP's entries — and custom reports that pull any generated number, for any period, into exactly the layout your team and your LPs expect. No re-keying, no export-and-paste. The number on the statement is the number in the ledger — receipt and all.

The five properties of a close you can defend

1. Repeatable — re-running a period replaces its entries; correction is cheap.
2. Explainable — every number stores its formula and inputs at creation.
3. Isolated — computation runs on a sealed copy, never the live system.
4. Attributed — every row, every formula edit, traced to a person.
5. Locked — closed periods are refused by the engine, not by policy.

Six questions for your next quarter-end

Can your team answer yes to all six?

1. Could you re-run last quarter today and get the same entries?
2. Can any fee number on an LP statement show the formula that produced it?
3. …and the actual values that went into it?
4. Do you know who last changed the fee logic, and what it said before?
5. Is it impossible — not just forbidden — to overwrite a closed quarter?
6. Could you answer an auditor's "walk me through this" in one click?

What to take from this

One question before you go: if an auditor picked one number off your last quarterly statement, how long would the full walk-through take — and how many people would it involve?

— Fund Ops, Unstacked #2: one CapHive feature, properly explained, each time.