The ledger is the transaction boundary
Hosted requests read an isolated ledger snapshot and publish the complete validated state through compare-and-set. A competing write receives a conflict. A request with an uncertain acknowledgement can be retried with the same identity without duplicating the financial operation.
That model addresses a practical event problem: a browser may not know whether a button press succeeded. Correctness depends on the transaction identity and stored state, not on whether the user saw a success message.
Give each role the right surface
Operating staff can work a selected till, sell tickets and scrip, and complete will-call workflows. Administrators additionally manage imports, transfers, audits, exports, and close-day archives. The application checks business permissions supplied by the trusted proxy; a generic platform role is insufficient.
Initial import is create-only and refuses to replace an existing ledger. A deployed process can be healthy while reporting that business data has not yet been imported.
Immutable close-day archives are referenced only by a successful ledger commit. An interrupted request may leave an unreferenced object but cannot silently change the visible ledger.
Keep test records separate from event history
The regression suite exercises transactions, concurrent writes, restart behavior, and role controls with synthetic records. Those fixtures allow uncertain acknowledgements and stale writes to be reproduced without changing an event's ledger. The application treats a committed transaction, an immutable archive, and a visible acknowledgement as related but distinct pieces of evidence.