Nikhil Jathar: AvanSaber Co-founder, IEEE-USA advocate bridging AI innovation with responsible governance.gettyMost discussions of "AI auditability" in enterprise software start with the wrong assumption: that audit is a downstream activity, performed on logs after the fact, by people who arrive after the system has already produced its output.In my own work on ERPClaw, I had to abandon that framing. An ERP system runs financial workflows. The audit cannot wait until after the AI generates code that touches a general ledger. By that point, the integrity violation has already happened. So I tried something different. I gave the AI a constitution and a second AI whose only job is to enforce it.The Downstream Audit Assumption And Where It BreaksThe current AI audit conversation in federal proposals, internal compliance frameworks and third-party tooling mostly assumes auditability is log-based or post hoc. In most enterprise contexts that pattern is fine. The application keeps running on a fixed code path and the AI is bolted onto the side as a recommender, summarizer or chatbot. If the AI hallucinates, the application is unaffected; the audit catches the bad recommendation.For a small but growing class of enterprise systems, the assumption breaks. Any system with nonnegotiable integrity rules, balanced books in finance, immutable journals in accounting, role-based access boundaries and regulatory-mandated audit trail completeness cannot run a "wait and review" pattern around an AI that is allowed to modify the system itself. The integrity rules have to hold during the AI's operation, not be reconstructed afterward. ERP is the obvious case. Healthcare records, legal contracts and supply chain provenance face the same constraint.​Encoding The ConstitutionThe first design choice was what counts as an integrity rule. For ERPClaw, the rules are concrete: Every journal entry must sum to zero across accounts; posted entries cannot be deleted, only reversed by a counter-entry; access to financial data follows role-based boundaries that the system enforces at the database layer rather than in application code; the audit trail captures every state change without gaps; and domain-specific rules apply per ERPClaw industry vertical, such as HIPAA constraints in the HealthClaw module.Each rule is encoded as a machine-evaluable invariant that runs at code-modification time, not at runtime. The implementation uses an AST-based static analyzer that examines proposed code for any violation of the invariants before the code is allowed into the running system. A developer or AI agent proposing a change that would let a journal entry be soft-deleted gets blocked at the check-in layer. The check is automated and binary.I chose the term "constitution" deliberately. The invariants are intentionally short, named and hard to amend. Changes to the constitution itself require a separate review process, distinct from regular code changes, and they carry priority over any other rule in the system. The full set of invariants is documented in USPTO Application Number 19/650,218, where the patent language calls them "domain integrity guarantees."The Adversarial Audit AgentThe second design choice was who enforces the constitution. In a traditional system, a deterministic static analyzer or a CI/CD gate would do it alone. In a system where an AI agent can write or modify code at runtime, the enforcement layer has to wrap those deterministic checks with agentic reasoning.We modeled the audit as a separate AI agent with one job: Detect violations of the constitution. It uses the AST analyzer to read proposed code, reasons about whether the change violates an invariant and rejects it before deployment. It runs alongside the generation agent and operates on every proposed change.A key design choice that surprised me: The audit agent does not need to be smarter than the generation agent. It needs to be specialized. The audit agent only knows the integrity rules. It does not know the business logic or the user request. Specialization beats raw capability for this role.The audit agent is not a peer reviewer that can be talked into approving a marginal change. It is structurally adversarial: Its incentive is to find violations. Generation that survives the audit is the only generation that ships. In production, this means an AI can write or modify code inside a live ERP system without breaking integrity, because integrity is enforced inside the architecture, not as a downstream review.What This Scales To And Where It BreaksThe pattern scales to enterprise software domains with a small number of nonnegotiable integrity invariants. ERP qualifies. So do healthcare records management, financial reporting systems, legal document automation and supply chain provenance.The pattern does not scale to domains where "integrity" is contested or evolving. Generative content, marketing automation and customer support are not good fits. The rules are too soft, and the audit agent has nothing crisp to enforce against.The most honest limitation is that the constitution itself is the bottleneck. If the integrity rules are wrong, incomplete or contradictory, the audit agent enforces the wrong thing precisely. Constitution maintenance is its own engineering practice, with higher review than regular feature changes.The pattern also adds latency and infrastructure cost. The audit agent runs on every proposed change. For high-throughput AI workflows, the audit cost has to be tiered, with cheap deterministic checks running always and expensive non-deterministic checks running selectively. That is the architectural pattern that TailTest, a separate product we built, formalizes.Why This Matters NowAI policy in 2026 is being drafted with a downstream audit assumption baked in. That assumption will set the regulatory baseline for how AI is deployed in enterprise systems for years.For domains with hard integrity constraints, the regulatory baseline that maps to the architecture has to be on the record before policy locks in. The constitution-governed pattern is documented in our pending patent, deployed in ERPClaw and described publicly in pieces like this one. Architectural patterns that exist in the public record are easier for regulators and engineers to reach than patterns that live only in proprietary systems.ERPClaw is open source under the MIT license. Other engineers can build on it, critique it or improve it. Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?