Home›How it works
How it works.
For the technically minded — the deterministic machine under AKRIBBA, and the proofs it leaves behind.
For the technically minded — the deterministic machine under AKRIBBA, and the proofs it leaves behind.
Same inputs, same policy, same result — provably, every time.
replay_digest == output_digest
AKRIBBA recomputes every payout batch as a deterministic function: exact integer math in a fixed order, sealed to a fingerprint that anyone can reproduce. No floating point, no hidden state, no "trust us."
A batch enters at the gateway and leaves as a sealed verdict. Each stage is one step on that path — here's what it does, and what it guarantees.
Receives the payout batch from your ERP and PSP. A single, typed entry point — nothing else can inject work into the run.
One way in. Every batch is accounted for from the first byte.Normalizes every record against a strict schema contract. Anything malformed or unexpected is rejected here, at the door, not deep inside the math.
Bad data fails loudly and early — never silently mid-computation.Sorts records into one canonical, deterministic sequence. The same inputs always process in the same order on every run.
Order is fixed, so results never depend on timing or chance.Computes every amount in exact integer cents. No floating point, no rounding drift — the totals are exact by construction.
No stray penny can ever appear.Evaluates each record against versioned, reason-coded policy: limits, attestations, freshness windows, and quorum requirements.
Every decision traces to a named rule and a policy version.Resolves remainders, splits, and allocations deterministically, so the same fractions land the same way every single run.
Splits and roundings are reproducible to the cent.Hashes the full result into a content-addressed digest — a compact fingerprint of exactly this batch.
The result now has a unique, tamper-evident identity.Independent recomputations must agree under a 2-of-3 quorum: replay_digest == output_digest, or the batch does not pass.
Release needs independent agreement — no self-approval.Emits the verdict — ALLOW to release, or a reason-coded HOLD — together with the sealed transcript bundle.
Every outcome is explicit and reason-coded, never a shrug.Anyone can replay the transcript later and reproduce the exact same digest, weeks or years on.
Proof on demand, forever — without re-running your stack.Every batch ends in one check. Recompute it independently; if the fingerprints match, the result is provably the result. If they don't, nothing moves.
The digest is a content address — a fingerprint of exactly these inputs, this policy version, and this math. Reproduce the digest and you have reproduced the truth.
Integer-cent arithmetic in a fixed canonical order. No floating point and no nondeterminism, so the same inputs always produce the same totals.
Each batch seals to a transcript bundle keyed by its digest. Re-run it next week or next year and you reach the identical result — evidence on demand.
Release requires a 2-of-3 quorum of independent recomputations that agree on the digest. One process can't quietly approve itself.
AKRIBBA sits beside your stack as a gate, not a replacement. The integration surface is deliberately tiny.
Call AKRIBBA with your batch before you disburse. It returns ALLOW or a reason-coded HOLD — your money movement stays exactly where it is.
Keep window_id and digest next to each batch. That's the whole footprint — proof you can replay later, with nothing else to maintain.
Run in shadow first to compare against your current totals, then switch the gate on. No rip-and-replace, no migration weekend.
A thousand line items in. One answer out.
Every strand of the batch converges to a single sealed digest — the same one, every run, for anyone who checks.
From the plain-English idea to the math under the hood — and the people behind it.