A volleyball tournament app
and the platform under it.

One team's phone
should not decide a match.

If a platform pays out a prize, it is accepting a score it has no way to check. Forward whatever one team typed in and you have let one team decide a match that moves money. So in Sideout a score only becomes a result when two independent parties say the same thing, and the server is what decides whether they did, never the phone.

Both teams submit from their own side. The submission is canonicalised and hashed, and agreement is equality of hashes, never a comparison of who said what. A disagreement is not an error, it is just a state the match sits in, and only an organizer can move it out.

awaiting_first
  └─ one team submits ─────────────────► awaiting_second
        ├─ the other submits the same hash ──► agreed
        └─ the other submits a different hash ► disputed
disputed ──── organizer resolves ──────────► agreed
agreed ────── Purse accepts the scores ────► pushed_to_purse
pushed_to_purse ── Purse's replay confirms ► confirmed

Only agreed may push, and only under the idempotency key minted on entering it. The last step is my favourite part: confirmed is literally a replay. The proof that Purse is really holding the score is that sending it a second time changes nothing.

LIVE PLAY · TWO EVENTS ON THE SAND, ONE RESULT CONTESTED

BRACKET · WINNERS ADVANCED IN THE SAME TRANSACTION AS THE AGREEMENT

IMPACT · CHARITY DOLLARS, A LEDGER THAT NEVER MEETS THE CONTEST

Append-only is not a convention here.
The database role cannot do anything else.

Every entry has at least two lines, in one asset, and debits equal credits. Balances are derived by summing lines, so the balance at any past instant is one WHERE posted_at <= $1 away. Nothing is ever updated or deleted, and that is not just a rule I follow. The API runs as a role that holds SELECT and INSERT on the journal and nothing else. A test fires an UPDATE and expects Postgres to refuse it, and the API will not boot on a role that could. Corrections are reversing entries.

Seven invariants are checked every fifteen minutes, in CI against the seeded database, and from the console. A failing invariant makes the health endpoint answer 503, so any uptime check on the status code alone pages, and a deploy will not switch onto a ledger that does not reconcile.

The test I would read first is the randomised one: ten thousand seeded random operations covering issue, escrow, refund, settle, void, replay, reversal, attempted overdraft and every contest operation, a lot of them fired concurrently, all checked against an independent replay of every accepted line, after which reconcile has to come back clean. CI refuses to run fewer than that.

Settlement itself is a pure function: no database, no clock, no randomness, and the same input gives the same output byte for byte whatever order the entrants arrive in. Shares are floored in bigint and the remainder handed out one unit at a time to the best placement first, so 100 points split three ways is 34 / 33 / 33, never 33 / 33 / 33 with a point quietly missing. Conservation, non-negativity, placement monotonicity and determinism under permutation are property tests over thousands of generated contests, not examples.