Skip to content
Technical

How it works underneath, with the real names.

If you (or your engineer) have to sign off on putting your records here, this is how it works underneath, with the exact names so you can check it yourself. Eight short pages, each naming the functions, tables and tests involved. No pitch.

  1. 1Architecture at a glanceOne app in front of one database, and the database, not the app, decides who can do what. (A Next.js application over a single PostgreSQL database; the app is a client of it.)
  2. 2How the rules are enforcedEach step asks for a specific kind of proof. The database won't mark it done without that proof, and won't close a check while a required step is still open.
  3. 3Keeping each firm's data apartEvery table checks, row by row, whether you're allowed to see it, based on your organization and your projects. (Row-level security keyed by org_id and project_id, with the role checks as security-definer functions the policies call.)
  4. 4The audit trail and the hash chainEvery event is written once and never changed, and each one is sealed to the one before it, so any tampering shows. (One append-only events table per organization; each row carries a SHA-256 digest of the row before it, verifiable end to end by a single function.)
  5. 5The AI assistantsTen AI assistants that are on the record like people, can act only through permission-checked tools, and hand anything consequential to a named person.
  6. 6Working offline on site, and proving you were thereA tablet on site holds on to what it captures, sends it when it gets signal, and the same database rules apply when it lands.
  7. 7Your data: its shape, how it leaves, and the APIOrganizations own projects; projects own sites, assets, checks and documents; everything you own leaves as CSV and files whenever you ask.
  8. 8How changes ship, and how we test themDatabase changes that are safe to run twice, tests that run the real database with no network, and scheduled jobs that refuse to run if they aren't set up properly. (Checksummed, re-runnable migrations; crons that fail closed.)

Terms used here are defined in the glossary. The public readiness register is on the security page.