How the meal ledger actually works.

The meal ledger is deliberately simple, both because it's easier to reason about and because complexity is where trust erodes. Here's how it works, top to bottom.

One framing note up front. Our future hunger-relief partner is our **target** partner: their corporate-partnership framework requires a $50,000/year commitment, and until the pooled meal fund reaches that threshold, the money is held in a dedicated LADLE ledger and reported monthly. When we cross the threshold, the same ledger becomes the source-of-truth for real partner receipts on the partner's platform. See [the-fifty-thousand-threshold](/blog/the-fifty-thousand-threshold) for the full context. The mechanics below are what runs today.

We run two accounting ledgers separately. The operating ledger tracks the $12 per subscription that funds Anthropic API costs plus our overhead. The meal-committed ledger tracks the $8 earmarked for the meal fund. These are literally separate database tables with separate transactional boundaries. Money can flow into either from a Stripe charge; money can't flow between them.

When Stripe processes a successful $20 charge, our webhook handler writes two rows: $12 to operating, $8 to meal-committed. Both are timestamped with the exact moment of the charge. If the charge fails, no rows are written. If the charge is refunded (rare, but happens), both rows are reversed atomically in the same transaction.

On the last calendar day of each month, a scheduled job sums the meal-committed ledger for the month and posts the aggregate to the pooled meal fund. Today that post is a LADLE-internal transfer — money in reserve, held for the partnership with the hunger-relief charity we select. Once the $50,000/year threshold clears, this same job initiates a real donation to the partner we select via their API and receives a partner reference number in return, which we attach to the month's ledger rows.

The monthly fund report is published as soon as the aggregate post is confirmed. It appears in three places atomically (same database transaction): the public Impact page ledger, the current month's fund report, and every subscriber's personal My Table screen where the plates for that month "confirm" from pending to reserved status. Post-threshold, "reserved" becomes "funded" and the partner reference number lights up alongside.

Reconciliation checks run continuously. Every 15 minutes, a job verifies that: - The sum of the meal-committed ledger equals the sum of all successful $20 charges times $8 (adjusted for refunds). - The sum of published fund-report totals equals the sum of meal-committed rows posted to the pooled fund. - The pooled fund balance on our side equals the cumulative of every month's posted total, minus any partnership-triggered outflows (zero until the threshold clears).

Any drift triggers a page. In four months of operation, we've had zero true drift; two false positives from clock-skew between our systems and Stripe (resolved within minutes, published on the status page).

The intentional simplifications: we do not compound meal counts across time. If a subscriber's charge fails and they re-subscribe later, their historical meals stay counted at their original values — we don't retroactively adjust anything about past batches. And we do not partial-post. Every month's aggregate is a single all-in post; if for any reason we couldn't execute it (our own bug, an ops issue), the whole batch waits until the next successful attempt, with the status page reflecting the delay.

Everything on this page is verifiable independently today via the fund-report math. Post-threshold, the reference numbers on the ledger will be the specific bookkeeping identifiers the partner uses; you'll be able to email their donor support and they'll confirm the amounts and dates.