Your AI's Audit Trail Is a Git Log. That Won't Survive an Audit.

An audit trail is not one thing. In AI-generated software there are three distinct altitudes of evidence, and they get quietly treated as interchangeable.

• Altitude one — code-provenance. Commit history, the diff, who authored which line, which model generated it, what the review said. A record of how the instrument was built.
• Altitude two — data-access. Query logs, the record of who read or wrote which row, the button-click stream, the session replay. A record of what was touched and by whom.
• Altitude three — business-action. An immutable account of every business action the process took — this invoice approved, this refund issued, this entitlement granted, this ledger posted — the policy that permitted it, the authority it ran under, and the reason it was allowed at that moment.

Only the third reconstructs a decision. And it is precisely the one the tools do not produce — not because they logged too little, but because of where their output lands.

Both lower altitudes are genuinely valuable, and I want to be fair about that. Provenance is real engineering hygiene — attribution, reproducibility, the ability to roll back a bad change. Access logs and session replay are real security telemetry. If a vendor gives you always-on scanning and a clean record of who edited and shipped the code, that is better than opt-in policy nobody remembers to turn on. None of that is in dispute.

The dispute is what those records can be used to prove. The autonomous-coding-agent and repo-agent vendors tend to equate a commit history with auditability — but commit history tells you how a control was built, not that it held on a given Tuesday. Even perfect provenance describes the construction of the instrument, never the actions it took in production. The app-gen platforms whose audit "records every button clicked" or "who queried which record" sit one altitude up and still short of the target: a read event is not the decision that reading fed, nor proof the decision was authorized, nor an account of what the process then did with it.

A regulator testing a control is not asking who wrote this? or who looked at the record? They are asking: reconstruct this specific decision — show me it was permitted, by whom, under which rule, and that the rule was in force at that instant. "Here's the diff" and "here's who queried the row" are answers to different questions.

This is not a logging-feature gap that a better dashboard closes. It is structural, and the most sophisticated version of the category proves the point by accident.

The strongest players have stopped talking about logs and started talking about architecture: make governance structural, not procedural — build the system so the unsafe action simply isn't available, and split who may edit, who may approve, and who may publish into separate permissions enforced on the server rather than left to a policy document. That is genuinely smart, and it is real. A constraint that can't be violated beats a rule someone has to remember.

But be precise about what those constraints govern. They govern the build, edit, and publish lifecycle of the generated app — who is allowed to change the code and ship it. They are controls over authorship and release. The business actions the running app then takes against your systems of record — the payment it moves, the entitlement it grants, the record it amends — happen at runtime, inside an artifact that, however well its build was governed, now runs as a separate system. Governing who was allowed to write and deploy the code is not the same as governing what the code does once it is live. The audit that falls out of build-time governance is an audit of the build.

That through-line holds across the whole category, whatever the surface — prompt-to-app, design-to-app, autonomous SWE agent, legacy-modernization engine. The genuine achievement is real: idea to working software in hours instead of weeks, legacy rules carried into a clean cloud-native rewrite, scanning that never sleeps, and exported code with no proprietary lock-in. But every one of those is an achievement about producing an artifact. "Production-ready" is a claim about the code — it compiles, it passes scans, it deploys. It is not a claim that the actions the deployed process takes are permitted, attributed, and reconstructable. The artifact lands outside any governed runtime, and then someone has to integrate it, secure it at runtime, monitor it, and stand up its audit — one more silo. The commit log ships with the code. The business-action audit does not exist, because there was never a runtime recording at altitude three.

Entroid inverts the artifact. Its generation toolkits — the one that turns ideas, conversations, and documents into applications, and the one that turns legacy code into cloud-native systems with every business rule preserved — do not emit an app or a repo. They compose a process from five primitives on one runtime: deterministic workflows that carry governance inline, intelligence orchestration, atomic agents with human-in-the-loop as a first-class step, functions, and connectors — the only primitive that touches an external system — all resolved against a shared semantic ontology.

Because every step the process takes is one of those governed primitives executing on a single runtime, the runtime writes an immutable, per-action record as the action happens: which action, against which system, under which policy, with what authority, and — by design — why it was allowed. Explainability is not a feature bolted onto a log; it is a property of running every step as a governed primitive. This is an architectural claim about how the fabric is built, not a report on any particular deployment.

The distinction from the artifact model is not "better logging." There is no separate app whose runtime sits outside the governance to be reconstructed later from telemetry it happened to emit. The governed runtime is the output. The audit is the byproduct of execution, native and per-action, at exactly the altitude a regulator's question lives at.

None of this pretends ES escapes integration — that would be the same over-claim I'm criticizing. It runs over your existing estate through governed connectors; the systems of record stay yours. What changes is that the actions taken across them execute inside the governed process, so the account of those actions is native — not stitched together from four separate log stores after the fact.

Picture the test any regulated enterprise eventually faces — illustrative, not a delivered result. An auditor picks one action out of millions: a specific credit memo issued eight months ago. Reconstruct it.

At altitude one, you can show the code that issues credit memos and who committed it. At altitude two, you can show that some record was read and some button clicked in some session. Neither reconstructs the decision. At altitude three, the runtime hands back the single governed action: the memo, the workflow step that authorized it, the policy in force at that timestamp, the human who approved the exception if one was required, and the reason the action was permitted — as one immutable entry, not a correlation exercise across four systems that were never designed to agree.

That is the gap between evidence that the software was built carefully and evidence that a business decision was governed. For SOX, for regulated work, for anything an auditor will sample down to a single line — only the second one is an answer. The first is a very good story about how the code got written.