Counters stay
Aggregate counters are non-identifying by construction, so the usual data-minimization pressure to delete does not apply the way it would to identifying data. Deleting them would destroy your historical reporting for no privacy gain.
Data and retention
The complete inventory.
One table. If a record is not on it, it does not exist — and every row answers the only question that matters first: does this contain patron data?
| Record | Contents | Patron data? | Retention |
|---|---|---|---|
| verification_totals | Cumulative outcome counters per location | No | Indefinite — coarse and cumulative, so it is non-identifying by construction |
| verification_aggregates | The same counters with a day bucket | No | Indefinite, with rows below a group size of three suppressed at every tier |
| verification_ingestion_receipts | Hash of a random event ID, device/credential binding, keyed payload commitment, receipt time, expiry | No | At most 30 days, pruned during ingestion |
| operational_events | Typed system events with schema-bound metadata | No | Operational window, not indefinite |
| fleet_health_events | Connectivity and trust-freshness transitions | No | Operational window, not indefinite |
| device_credentials | Credential lifecycle state; retired credentials kept as a hash | No | Rotated on schedule, revoked immediately on decommission, hash retained for audit |
| organizations, locations | Your business and site records, including the venue's address | No — the address is the venue's | For the life of the account |
| users, memberships | Your staff accounts and roles | No — this is staff data, a separate ordinary privacy domain | For the life of the account |
| Business inquiries | Work email, organization, and the answers you type into the contact or pilot form | No | Retained as sales correspondence |
Two privacy domains, kept apart deliberately: patron data, of which there is none, and staff and account data, which follows ordinary rules.
01 · The other list
What has no row, no column, and no retention window.
Because it is never received. A retention question about any of these has no answer, and that is the correct outcome.
- Name
- Date of birth
- Address
- Portrait or photo
- Document number
- Wallet identifier
- Mobile-ID payload
- Session transcript
- Patron identifier
- Repeat-visitor identifier
02 · Why some things are kept forever
Retention is a judgement, and here is ours.
Receipts expire quickly
De-duplication receipts exist only to cover the delivery retry window, so they are capped at thirty days — matching the device outbox — and pruned during ingestion rather than by a job that might not run.
System events age out
Operational and fleet-health events describe our own system rather than your customers, but they still should not accumulate forever for no reason. They are retained on an operational window.
03 · Your data, on request
Export, and exit.
Export
Aggregate reporting exports as typed JSON, with suppression applied. Every field is typed and controlled, so there is no free-text cell and no spreadsheet formula-injection surface.
Exit
On termination, verifiers are revoked and their credentials retired. Organization and staff records are removed on request. There is no patron data to delete, which makes the hardest part of most exits trivial here.
Need this as part of a vendor assessment?
Tell us which questionnaire you are working through and we will answer it against this inventory.