What was — vetted.
The official, signed, audit-grade record of everything your organisation has produced.
Not raw archive: vetted by named identities, walkable as a chain of evidence, defensible under questioning.
Every organisation has two kinds of data: raw (everything that happened) and vetted (the bit you'd stake your reputation on if asked to defend it). Most stacks blur the two. The board paper cites the dashboard, which cites the warehouse, which cites a cron job from three years ago that nobody can read. When the auditor asks "who said this number was right?" the answer is silence.
wot.was is the vetted layer. Each record carries the identity of the named reviewer who signed off on it, the source data it was derived from, the version of the procedure that produced it, and the timestamp the vetting happened. The because-line from claim to evidence is the audit trail — not a log file, not a paper memo, an actual structural chain.
Vetting is a workflow, not a magic property. Submit a record for vetting. The named reviewer (clinician, solicitor, finance director, scientist, archivist — whichever role your governance demands) signs it as vetted, with their identity. The record is now part of the wot.was register: walkable, queryable, citable, defensible.
Raw data still exists in your other systems. wot.was is the layer above — the parts you've explicitly committed to as the official truth, with the named human or process who committed.
If you're a regulated business that periodically gets audited on what you said, when you said it, and who signed off — this is built for you. Legal teams responding to discovery requests; compliance teams answering ICO subject access requests across years of history; finance teams citing month-end positions that the auditor wants traced to source; clinical teams maintaining a defensible record of decisions made; public-sector teams holding board minutes and policy decisions to a documentary standard. The receipt chain is the deliverable.
GDPR Article 15 across nine years of customer data.
A subject access request lands. The customer has been with you nine years. You owe them, in 30 days, a complete account of every piece of data you hold about them — across CRM systems you migrated three times, support ticket platforms that changed twice, finance systems with two regime changes, and the marketing automation that used to email them weekly until 2022.
The naive approach: get someone to spend two weeks crawling backups. Hope nothing's missed. Pay the ICO fine if it is.
The wot.was approach: historical records were vetted into the register at each migration boundary. The CRM-1 → CRM-2 cutover was signed off by the data lead with a vetted snapshot. The support-ticket import was signed by the platform owner. The finance regime change was signed by the FD. Each vetting is a signed thought with the reviewer's identity and a because-line back to the source.
The SAR is one query against the vetted register, scoped to the customer's identity. The result: every piece of data, every system it lived in, every named human who signed off the record — returned as a complete signed export. The customer gets their answer. The ICO never gets the call.
Vetted at the moment. Walkable forever. Defensible by construction.