--- title: "Auditing a system that changes faster than its auditor" url: "https://demertis.com/blog/auditing-a-system-that-changes-faster-than-its-auditor" description: "An audit assumes a stable object. A self-improving system has changed by the time the report is written, so the audit has to move from behaviour to invariants." --- # Auditing a system that changes faster than its auditor October 22, 2026·4 min read·Editorial team Cyanotype print of a wax-sealed glass inspection window set into a steel cabinet door, with a brass tamper-evident seal on the hinge and a pressure gauge beside it Picture an auditor arriving at an operation where the software runs the scheduling, the purchasing and the pricing. She is given what auditors are given: a system description, a set of configuration exports, a sample of transactions from the quarter, and a walkthrough with the engineer who looks after it. Three weeks later a report lands on the owner’s desk, accurate in every line. It is also a description of a system that no longer exists. The pricing rules were revised by the system itself eleven times while she was writing. The configuration export she tested against was superseded the day after it was taken. Nothing she sampled was wrong, and nothing she sampled is still running. The cause is not the auditor’s method. Audit was designed for objects that hold still: a set of accounts for a closed year, a process as documented in a manual, a control that either operates or does not. A system that rewrites its own configuration as a normal part of operating is not that kind of object, and a method built for stable things cannot be made to fit it by working faster. ## Where audit loses its grip **The object moves during the engagement.** An annual review of a self-improving system is a photograph of one frame in a film. The finding “control X operated effectively” is true of a configuration that may have been replaced before the sentence was finished. The report is not false; it is simply about the past, in a way that annual accounts are not. **Behaviour is sampled, and behaviour is what changes.** Testing a sample of decisions tells you how the system behaved in those cases. In an adaptive system the mapping from situation to decision is exactly what the Evolve loop keeps altering. A clean sample says less and less the further it gets from the date it was drawn. **The documentation is written by the thing being audited.** When the system keeps its own description current, the auditor is reading the subject’s account of itself. That is not necessarily wrong, but it is not independent, and most audit standards assume independence of evidence somewhere in the chain. **Oversight obligations grow with the loop.** Rules on artificial intelligence in the EU move in one direction: more autonomy brings more documentation, traceability and human oversight, not less. An operation that cannot be audited in a meaningful way is not merely hard to review; it may not be permitted to run as it does. **The auditor is asked to certify the future.** A signature on a report about a system that will change tomorrow is read by everyone as a statement about tomorrow. The auditor knows it is not. The gap between what the signature says and what it is read to say is where this goes wrong. ## Audit the parts that do not move The way out is not to audit more often. It is to change what is audited. A self-improving system has a small set of properties that do not change, or change only through a human act, and those are the ones worth a signature. **The bounds.** What the loop may touch, how much it may spend, where it may not reach. These are set outside the loop and cannot be edited from inside it, as we argued for [the budget](https://demertis.com/blog/an-autonomous-firms-budget-money-the-loop-cannot-spend). An auditor can verify that the bounds exist, that they live where the loop has no write access, and that every change to them was made by a named person. That holds regardless of what the loop learned this week. **The ledger.** Every decision, with what was observed, what was concluded and what was done, written somewhere the loop cannot alter afterwards. The auditor does not need to understand every entry; she needs to establish that the record is complete, append-only and replayable. A [ledger that can be replayed](https://demertis.com/blog/a-log-nobody-can-replay-is-not-a-ledger) is what lets a later reader reconstruct any version of the system, including the ones that have been superseded. **The off switch.** An interrupt outside the loop, on separate infrastructure, exercised on a schedule. The auditor checks the test log, not the diagram. A stop that has not been run since the last report is a finding. **The objective.** The yardstick the system is measured against, and the fact that the system cannot edit it. The auditor confirms where it lives and who changed it last, not whether the system is currently meeting it. **Continuous attestation instead of the annual visit.** If the invariants are machine-checkable, and they should be, then checking them is a process the auditor configures once and reads continuously: bounds unchanged, ledger intact, interrupt tested on schedule, objective untouched. The annual report becomes a summary of a year of attestations rather than a photograph of one week. The auditor’s independence is preserved because the checks run on her infrastructure, against evidence the loop cannot shape. ## What an auditor should refuse to sign A short list, offered plainly. An auditor should decline to certify any statement about the behaviour of a self-improving system beyond the period actually observed. She should refuse to treat a system-generated description as independent evidence of that system. She should refuse to sign off an off switch that has a design document and no test record. And she should refuse to rely on bounds that are stored where the loop can reach them, however reasonable their current values look. What she can sign is narrower and more useful: that the invariants existed, were enforced outside the loop, and were checked continuously for the period covered. That is a statement that stays true after the system has changed, which is the only kind worth making. ## A test you can run today Take the most recent audit, review or assurance report written about any automated process in your operation. Mark every sentence that describes what the process does or how it behaves. Then mark every sentence that describes something the process cannot change about itself. Count the two sets. If the first is nearly everything and the second is nearly empty, the report expired on the day the process next updated, and nobody was told. The ledger and the human envelope are two of the six parts of [the Demertis programme](https://demertis.com/), and they are there because an autonomous operation that cannot be audited afterwards is not a research result. This post and its companion on [money the loop cannot spend](https://demertis.com/blog/an-autonomous-firms-budget-money-the-loop-cannot-spend) are two views of the same requirement: what a person outside the loop has to be able to check. - audit - attestation - invariants - traceability - accountability ## Keep reading - [How to build an agent factory, stage by stage](https://demertis.com/blog/how-to-build-an-agent-factory-stage-by-stage) - [Who owns what an agent factory learns](https://demertis.com/blog/who-owns-what-an-agent-factory-learns)