Enough detail to understand what sits behind the exhibition desks.

Exhibity is designed for Cloudflare's serverless application platform, with its operational records held in Cloudflare D1. D1 provides SQL database behaviour and point-in-time recovery through Time Travel. Account sign-in is provided separately from the exhibition database.

This is a managed-cloud design: the organisation does not need to install a server at the exhibition venue.

No. A society continues to take payment through its chosen point of sale, card terminal or other payment method. Exhibity records the exhibition sale; it does not receive, hold or transfer the buyer's money and it must never store complete card details.

That separation limits banking risk, but the sales record still matters because it is used to calculate what the organisation and each artist are due.

The money would remain with the organisation or its payment provider, but the evidence needed for settlement could be damaged. Exhibity therefore treats unsettled sales as its most time-sensitive records.

A recoverable sale needs enough evidence to re-establish the time, artist, artwork or item, gross price, quantity where relevant, and the commission rule that applied. External point-of-sale receipts provide an independent record that money was taken; Exhibity provides the artist and item attribution needed for payout.

If evidence remained incomplete, Exhibity would not invent an allocation. The organisation would review the available records with the affected artists and document any equitable settlement it agreed.

Important changes are checked again when they reach the server. A stale screen should be rejected rather than silently overwriting a newer decision, and retried requests must not create a second sale or second financial consequence.

All or nothing.
A sale and its related financial and custody consequences are recorded as one atomic operation. If any part cannot complete, none of it is applied.

People sign in to their own account and receive access through their organisation and assigned roles. A person who is both an artist and a volunteer uses the same identity but enters the appropriate space for the work they are doing.

There is no special device to set up or share. A volunteer can sign in on any device with a browser and pick up the same exhibition record from their own account.

Operational permissions and active-role choice are checked at the application boundary, while the underlying services enforce the rules that protect sales, custody and payout records. Important changes retain an audit trail.

A temporary outage is not the same as losing the database. Two connectivity safeguards are already built and live. At the Sales Desk, if a volunteer's browser loses its connection after a sale has actually gone through and they try to submit it again, Exhibity recognises the matching sale and refuses to record it a second time, rather than silently creating a duplicate. And if a submission at the Sales Desk or the Receiving Desk is taking noticeably longer than expected — the kind of delay a real connectivity drop causes — the page shows an on-screen warning telling the volunteer to check their connection rather than resubmitting blindly.

A fuller offline-continuity design — recording entries during a genuine outage and reconciling them once the connection returns — remains a considered future direction, not yet built. It will not be described publicly as available until it has been implemented and verified working.

If an interruption means returning to paper for a while, keep that record as usual. Once Exhibity is reachable again, the sales can be added to its record, with an honest note where useful — for example, to explain the time the sale actually happened.

D1 Time Travel provides a short-term route back from accidental deletion, corruption or a faulty migration. Exhibity's release requirement goes further: automated encrypted exports held outside the Cloudflare account, verified retention, failure alerts and regular isolated restoration tests.

These independent recovery measures will not be described publicly as operational until they have been implemented and successfully restore-tested. An organisation-level download remains a separate portability and safekeeping feature, not a substitute for service recovery.

An organisation can already download an export of its artists, exhibitions, works, sales, payments and collections as spreadsheet files that can be read without Exhibity. The comprehensive export we are working towards will also cover corrections, refunds, rota, payout, billing and supporting audit records, and is not yet complete.

Export and future re-import are separate capabilities: a complete export is required for portability, while any restoration into a new live organisation would need controlled validation.

Roughly 167,000 lines of code: approximately 94,000 in the main application, 56,000 in its automated test suite, and 17,000 in the separately-deployed label-rendering service. 1,973 automated tests run against it.

Money and custody writes — sales, voids, payouts, refunds — commit as single atomic operations via D1's native batch API, with explicit guards against two requests racing the same record, proven with real concurrent-request tests rather than simulations. Every write is logged to an append-only audit trail enforced at the database level. The codebase has been through multiple independent hardening audits covering tenant data isolation and injection risks, not a single pre-launch check.