Security enforced at the database. Not promised in a policy document.

Data isolation, enforced at the database

Row-level security is enforced at the PostgreSQL database level, not the application layer. A staff member from one organization cannot read, write, or query another organization's records — not because the interface prevents it, but because the database itself won't return the data.

Every artwork, condition report, movement log, and audit event is scoped to a single organization. A query that doesn't carry the correct scope doesn't get an error and doesn't get redacted data back — it gets zero rows

Authentication runs through clerk, layered on top of that database-level isolation: every session carries the user's organization ID, so a misconfigured request never even reaches another organization's data. Two independent layers, so a failure in one doesn't expose the other.

Records that can't be silently changed

Provenance records, verification events, NFC scan logs, and audit logs are append-only. A database-level trigger — not an application rule, not a permissions setting — blocks any attempt to update or delete these records outright.

That applies to Art Trackers' own administrators too. Correcting a record doesn't mean editing history — it means creating a new, separately timestamped entry while the original stays exactly as written. That's the difference between a system that promises not to change your records and one that's built so it can't.

Verification you can't fake

Each artwork's NFC tag carries a unique cryptographic verification token. The raw token is never stored anywhere in the database — only its SHA-256 hash. The verification link itself can't be guessed or reconstructed from the artwork's public page.

That means a counterfeit tag can't be issued against a real artwork record, and a genuine tag can't be quietly reassigned to a different piece