Not legal advice, not a fund administrator, and not a capital-call or distribution-processing system. Every input is SUPPLIED by the caller and treated as asserted: this pack performs no lookup against a fund administrator's ledger, a capital account statement, or the fund's own books and records, and cannot establish that a declared cashflow, its date, or its amount is real. A recompute assembled from a mistaken input matches or diverges exactly as well as a true one. Matching the GP-reported allocation means only what the cited node computed from the declared inputs, and a countersigned receipt of that recomputation means only that the signer independently reached the same execution hash, never that the LP has approved the distribution, paid a capital call in reliance on it, or waived a later dispute over the underlying waterfall's terms. Whether the declared waterfall parameterization is what the fund's limited partnership agreement actually authorizes remains a question for the LPA and counsel, never a claim this pack makes for itself. This pack is not endorsed by, and never claims compliance with, ILPA.

§4 Execution Hash · Workflow Definition Anchor

execution_hash:computing…

Workflow Stage · 1 Node · Linear

1 ROOT · WATERFALL RECOMPUTE node

PE Distribution Waterfall LP-Side Recompute art-567-pe-waterfall-lp-recompute

The waterfall recompute, run independently by the GP and the LP over the same declared batch of dated cashflows and the same declared waterfall parameterization, each diffed tier by tier against the GP's own reported allocation with no declared tolerance, exact fixed-point equality only. Every tier carries its own MATCHES, DIVERGES, or INDETERMINATE verdict, and the run carries one overall verdict of the same three values. Only the resulting execution hash, not any editorial reading of it, is what the two sides countersign.

MCP Call · recompute_pe_waterfall_lp

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "recompute_pe_waterfall_lp",
    "arguments": {
      "fund_id": "FUND-A",
      "waterfall": {
        "pref_rate": 0.08,
        "compounding_basis": "simple",
        "day_count_convention": "actual/365",
        "gp_catchup_pct": 1,
        "carry_pct": 0.2,
        "tier_structure": "european_whole_fund"
      },
      "cashflows": [
        {"date": "2025-01-01", "type": "contribution", "amount": 1000000},
        {"date": "2026-01-01", "type": "distribution", "amount": 1300000}
      ],
      "gp_reported_allocation": {
        "tiers": [
          {"tier": "return_of_capital", "lp_amount": 1000000, "gp_amount": 0},
          {"tier": "preferred_return", "lp_amount": 80000, "gp_amount": 0},
          {"tier": "gp_catchup", "lp_amount": 0, "gp_amount": 20000},
          {"tier": "carry_residual", "lp_amount": 160000, "gp_amount": 40000}
        ]
      }
    }
  },
  "id": 1
}

The Bilateral Countersigned Recompute Exchange · SPEC.md §27.12

This is the pattern the pack is built around, not a second node in the chain. The GP and the LP each hold the same declared cashflows and waterfall terms, run the same deterministic kernel over them, and each mints a signed receipt of its own run. Nothing above passes through AINumbers between the fund and its investor: the exchange is a flat file, sent however the two sides already exchange the distribution notice, and it is verifiable offline by either side or a third party who never talked to either party's systems.

The GP assembles the distribution's declared cashflows (date, type, amount) and the waterfall parameterization it used, runs recompute_pe_waterfall_lp against its own reported allocation, and seals the resulting artifact and its execution_hash.
The GP sends the LP the declared inputs and the sealed artifact, by whatever channel the two sides already use for the distribution notice. No relay and no shared registry sits between them.
The LP runs the identical kernel over the identical declared inputs on its own side. Because the kernel is deterministic and every tier comparison is exact fixed-point equality with no declared tolerance, an honest recomputation over the same inputs reaches the identical execution_hash the GP sealed.
The LP mints a counter_signed_receipt record (SPEC.md §27.12): subject_hash names the matched execution_hash, kernel_pin.kernel_digest names the exact art-567 kernel it verified against, role is checker, and replay_verified: true states plainly that it actually re-ran the computation rather than reviewing the allocation on paper.
Either side, or a third party holding both the sealed artifact and the receipt, can recompute the execution hash from the declared inputs and confirm it matches subject_hash, then verify the receipt's own signature, entirely offline.

What the receipt says, exactly: a counter-signed receipt states one fact, that both parties independently recomputed and signed the same result. It does not say, and must never be read to say, that the LP approves the distribution, that the true-up is closed, or that a dispute over the underlying waterfall's terms, its pref rate, its catch-up percentage, or its carry split, is foreclosed. A matching recomputation is evidence about the arithmetic. What either side chooses to do with that evidence, release a capital call, dispute a tier, or escalate through the LPA's own governance provisions, stays outside this pack.

Illustrative counter_signed_receipt output_payload · SPEC.md §27.2 / §27.12 shape, not a live signer

{
  "record_type": "counter_signed_receipt",
  "role": "checker",
  "subject_hash": "sha256:<the execution_hash both sides independently reached>",
  "kernel_pin": { "kernel_digest": "sha256:df13afbe5e611661922ccea2123194de8f703a3efa283154ec7af8b7876881e9" },
  "replay_verified": true,
  "identity": { "id": "did:key:z6Mk<the LP's own key>" },
  "timestamp": "2026-08-08T00:00:00Z"
}

The record above is itself a first-class artifact under SPEC.md §27.2: it carries its own §4 execution_hash and MUST be bound by a §16 eddsa-jcs-2022 proof to the signer's identity before it counts as conformant evidence. A bare did:key (SPEC.md §9) is sufficient to mint and verify one with no external dependency; an unsigned receipt is not evidence of anything.

Reading the Receipt · Two Subjects, One Vocabulary

The recompute names two distinct subjects and gives each its own verdict from the same three-value vocabulary, so a run that matches overall never hides one tier that diverged, and one diverging tier never gets read as the whole distribution being wrong.

Per Tier · Once Per Tier

MATCHES The recomputed LP and GP amounts for this tier agree exactly with the GP-reported figures. No tolerance is declared or applied; the comparison is exact fixed-point equality.

DIVERGES The recomputed amount for this tier differs from the GP-reported figure by any nonzero delta. The receipt records the per-tier LP and GP delta; what caused it, a wrong pref rate, a wrong catch-up percentage, or a genuine dispute over the waterfall's terms, is a question for the two sides.

INDETERMINATE A required parameter, most often the GP-reported allocation itself, was not declared, so no per-tier comparison could be made. Never read as a pass.

Overall Run · Once Per Recompute

DIVERGES At least one tier in the run diverges. The overall verdict is never softened by tiers that matched.

INDETERMINATE No tier diverges, but a required parameter, the waterfall terms, the cashflows, or the GP-reported allocation, was absent, so the run cannot be called a clean match.

MATCHES Every tier the waterfall produces carries a declared GP-reported figure and every one agrees exactly.

no verdict of its own The counter-signed receipt carries no MATCHES, DIVERGES, or INDETERMINATE of its own. It attests only that the signer's recomputation reached the same execution_hash as the artifact it counter-signs, whatever that artifact's verdict was.

Standing Context · Dated Observations

ILPA's own reporting-template guidance, as read on 2026-08-08, states its templates were "not designed for verifying any of the GP's calculations." This pack is cited here only as the dated gap that leaves open, never as an ILPA endorsement, and this pack makes no claim of being ILPA-compliant. Confirm current ILPA guidance text at ilpa.org before relying on a computed figure for a live distribution.

SPEC.md §27.12, as landed 2026-08-08, defines the counter-signed receipt's shape: the counter_signed_receipt record type, the checker role, and the optional kernel_pin and replay_verified sibling fields. The section states its own vocabulary ban normatively: neither the record nor any copy describing it may use language implying legal or economic closure to describe what it proves.

The pack declares no regulatory basis of its own. It produces a recomputation receipt and, where both sides choose to exchange one, a countersigned record of that recomputation; it does not compute, distribute, or negotiate the underlying waterfall allocation on either side's behalf, and it makes no finding on whether the declared parameterization is what the governing limited partnership agreement authorizes.

The exchange itself, the flat file carrying the sealed artifact and the countersigned receipt between the GP and the LP, follows no AINumbers-operated relay or registry. Either side can verify the bundle offline, and so can a third party holding it, without contacting either party's own systems.

Export Workflow Artifact

Download a §4-compliant workflow artifact with execution hash and step definition. Hash is deterministic over canonical {policy_parameters, output_payload} per RFC 8785/JCS.

PE Waterfall True-Up Pack