What it was for
Auditability is an inherited control. In accounting it meant a second party could reconstruct how a number was reached. In software it became logs, diffs, traces and review trails. The purpose never changed: make the work checkable by someone who was not there when it happened.
It worked because of a ratio nobody had to think about. The things needing checking were produced by people at human speed, so the volume was roughly matched to the attention available to check it. Auditability was the scarce half. Attention was not.
The verdict
TRANSFORMS, and the change is which half is scarce.
Machine output is auditable almost by construction. It shows its work, it cites, it explains, it produces a trace on request. What it will not do is wait to be read. The volume outruns the attention by a margin that widens with every release, so the property everyone is optimising is the one that stopped being the constraint.
Auditable is a property of the artifact. Audited is a property of somebody's attention, and attention is the scarce thing.
What changes
"Explainable", "transparent" and "auditable" stop counting as safety properties on their own. Each names a capability that only exists once a person spends something to realise it, and nothing tracks the spend. A system can be fully auditable and entirely unaudited, and from the inside those two states look the same.
Three bugs in my own engine in one morning make the case better than the argument does. A copy button annotated eight lines out of ten when it had promised to annotate only the ones that needed it. A parse failure printed library internals at the reader. And "3 pm to 5 pm", asked how long the meeting was, answered with an error about time zones.
Every one was auditable. Every one computed. None was caught by a test. They were caught because I sat down to record a launch video and watched the thing work.
So the craft is not producing more auditability. It is capitalising attention — taking a judgment a person made once, by looking, and freezing it into something that re-checks itself from then on.
What that looks like when someone has done it
The clearest working example is the smart library in Design Docs Are All You Need (Kushnir et al., September 2026). Its implementation is regenerated from design docs by agents, which only works because "every number-bearing doc ends with a reconciliation anchor: a small preset whose expected outputs are stated exactly and enforced by generated tests," and every rebuild "must pass reconciliation against hand-built references before it replaces the previous build."
Read what that actually is. Somebody looked, once, and decided what the right answer was. That look was written down as an exact expected output, and a machine now re-spends it on every rebuild. The references are hand-audited, so a human's attention is still the origin of the standard. It has been made durable rather than spent again each time.
The strongest objection
That attention is a setup cost rather than a recurring one. TypeSafe AI's manifesto puts it plainly: "You let a component run unattended if it's reliable; you only build on top of it if it's trustworthy." Establish reliability once, then compose freely on top of it.
Conceded in principle, and a reconciliation anchor is that move done properly. The problem is what "reliable" gets measured by. All three bugs above ran clean — no bad input, no exception, confident output returned. Reliability read as absence of error cannot detect confident wrongness, and a component composed on that basis exports its error into everything built above it. An anchor works because it states what the answer should be, where "it ran without complaint" states nothing at all.
Worth noting where that manifesto comes from. TypeSafe AI is selling early access to the component it argues you should let run unattended.
Falsification: downgrade to ENDURES if a system turns out to sustain quality on auditability alone — output legible enough that defects get caught reliably without anyone having budgeted the attention to look.