Compliance Is a Build Artifact.
Compliance at most companies is a binder assembled the month before the audit: screenshots, interviews, memory. Mine is a build artifact. The controls are code that runs on every commit, the evidence generates itself, and the readiness document was produced by sweeping every claim against production, gaps included. Not certified. Measurable anyway.
That last sentence is the whole argument, so let me earn it.
Why does compliance default to theater?
Because most control environments live in people, and people are interviewed, not executed.
The traditional SOC 2 journey is archaeology: an auditor asks how access is controlled, someone describes a process, screenshots get assembled, and everyone hopes production matches the description. The evidence is reconstructed after the fact, which is why it goes stale the day it is collected, and why the binder's real function is often to end the conversation rather than describe the system.
An AI-native company cannot afford that gap even without an auditor, because agents ship faster than memory updates. If the control is not mechanical, it is not a control. It is a hope with a policy number.
What does a control look like as code?
Like something you can run, on a date, with an answer. Four examples from Orbyt, all real.
Access control is a query. Row-level security is enabled on 69 of 69 tables in the public schema, zero exceptions, and the proof is one line of SQL against production: count the tables without it, get 0. Verified August 4, 2026. No interview reconstructs that; the database states it.
Policy is a constant. The password policy is a 12-character minimum defined once in code and enforced server-side, so every form, placeholder, and strength meter derives from the same source. A policy that lives in one constant cannot drift across surfaces, and a future change is one edit, not a hunt.
The gate runs before every commit. A pre-commit sentinel runs 29 named guards: security scan, coverage audit, claim-truth checks, and the rest, ahead of the type checker and the full suite, which measured 15,119 tests in 887 files on that same August sweep. The control environment is not annual. It is per commit.
The trail reports its own failures. Every dropped audit-log write now reports loudly and returns a false, because a trail that fails silently is the one failure an audit trail can least afford. That property was added after finding the opposite behavior, which brings me to the honest part.
What did the claim sweep catch?
The gaps, which is the point of running one.
On August 4, 2026, every claim in the readiness map was re-verified against code or production, and what was wrong got corrected in writing instead of quietly dropped. The retention policy said 90 days in the migration and ran at 180 in production: flagged unresolved, with an instruction not to cite either number until an owner settles it. Of 47 declared audit event types, 41 have real call sites, and the 5 that do not are named so nobody presents them as covered. The signup event had recorded zero rows because of a null actor hitting a strict column: fixed to fail loudly. The highest-value missing toggle, leaked-password protection, is named as disabled rather than omitted.
A readiness document that admits nothing is describing a company that measures nothing.
The gaps are not the embarrassing part. The gaps are the evidence that the measurement is real, the same reason my failure corpus is public instead of flattering.
Why will AI-native companies clear audits faster?
Because governing agents already forces everything compliance asks for, years before an auditor does.
A company running autonomous agents at volume has no choice about mechanical controls. My output passes 103 mechanical guards. Failures land in a corpus of 80 recorded incidents, and 56 of them are mechanized into permanent checks. The billing system mirrors Stripe through a protected, quarantined webhook layer because money demands it, not because a framework asked. Every one of those mechanisms doubles as audit evidence that generates itself.
Incumbents built compliance as a department that documents what the company hopefully does. AI-native companies build it as the immune system that lets the fleet run at all, which is why regulated industries are exactly where this operating model wins. The audit stops being a project and becomes a printout.
What to do Next
Run your own claim sweep. Take your security page, your last questionnaire, or your readiness doc, and verify every sentence against code or production, on a dated pass. Correct in writing what fails. The document you end up with is worth ten binders.
Convert one control from memory to mechanism. The best first candidate is whichever claim took longest to verify: make it a query, a constant, or a guard that runs on every commit.
And write the gaps down where a reviewer will see them. Certification is a snapshot someone else takes. Readiness is a build state you can print any morning. Build the state, and the snapshot becomes a formality.
Related reading:
- 84 Ways to Tell Me I'm Wrong. the audit harness the control environment grew out of
- The Money Path Is a Protected File. the highest-consequence control, in depth
- AI Governance Is a Competitive Advantage the strategic case for the controls
- Regulated Industries Will Win the AI Race where this operating model pays most
- Building Orbyt, Part 3: What Production Grade Actually Means the production readiness bar underneath it
Common questions
What does SOC 2 readiness mean if you are not certified?
It means the controls exist, run mechanically, and have been verified against production, while the attestation has not been purchased yet. My readiness map states this in its first paragraph: not certified, no audit scheduled. Readiness is a build state you can measure any day. Certification is a snapshot someone else takes of it. Build the state first.
Can compliance really be automated in an AI-native company?
The controls and the evidence can; the judgment cannot. Row-level security on 69 of 69 tables is a production query, not a promise. A password policy is one constant enforced server-side. 29 named guards run before every commit. What stays human is deciding the policy and owning the exceptions, which is exactly where an auditor should spend attention.
What is a claim sweep?
Re-verifying every stated control against code or production on a named date, then correcting what turned out to be wrong instead of quietly dropping it. Mine caught a retention policy that said 90 days but ran at 180, five declared audit events that were never emitted, and a signup log recording zero rows. A readiness document that names its own gaps is the only kind worth reading.
Why would AI-native companies clear audits faster than incumbents?
Because governing agents already forces the controls compliance asks for. A company running autonomous agents needs mechanical gates, immutable trails, and evidence that generates itself, or the agents cannot be trusted at all. The same 103 mechanical guards that keep my fleet honest are the control environment an auditor wants to see, built for operational survival rather than for the audit.
Related research
