What happens when your AI writes down a decision nobody made?

On 2026-08-10, on a client machine, we watched an automated job invent a decision. It took a four minute voice memo, recorded two days earlier, and wrote a file into the record marked as a settled decision. The substance of the title was: replace one system with another. Nobody had said that. Nobody had agreed to it. There had been no conversation, no ruling and no commitment of any kind.

By the time we found it, three more files referred to that decision as settled, and a sync log had started telling other scheduled jobs that the system was being rebuilt. A file nobody wrote was steering a system nobody was watching.

What the job did, step by step

The setup was ordinary and it is the setup half of our client base has some version of. A pocket voice recorder syncs on a schedule. The job pulls whatever is new, transcribes it, works out what each recording is about, and files it in the right place.

On 2026-08-10 it picked up a recording dated 2026-08-08, four minutes long. The content was somebody thinking about whether one system should be replaced by another. That is what a four minute voice memo is for. It is the sound of a person working something out while walking to the car.

The job auto-generated a file and recorded it as a decision. That single choice is the whole incident. Everything after it followed logically from a record that looked, to every downstream reader, like a settled position.

How it spread

Three more files inherited it inside the same automated pass. Once the decision file existed, other material generated afterward treated it as settled and referred to it as settled. That is correct behavior for a downstream job. It has no reason to doubt a record sitting in the place where decisions live.

Then the sync log began telling other scheduled tasks that the system was being rebuilt. This is where a small error becomes an operating condition. Jobs that read the log for context started working from a premise nobody had ever approved. Nothing in the chain was broken. Every link did its job correctly on bad input.

The person's own record ended up holding the fabricated decision and a later message contradicting it, sitting side by side, unreconciled. A reader arriving cold had no way to tell which one came from a person and which came from a machine. Both were files. Both were dated. Both read as authoritative.

The same week, in a different system

An overnight pass wrote two entries marked as decisions, recording something about ownership that was not true. The entries carried quotations attributed to a named person, and those quotations could not be found in any source we could reach.

Both were caught by a human being reading the record. Nothing automatic flagged either one. There was no consistency check, no confidence score, no review queue. The only mechanism that worked was somebody noticing that a sentence did not sound like the person it was attributed to.

The fixes, in the order we apply them

1. 01A machine may record anything. Only a person promotes anything to a decision. Recording is unrestricted and should be. The gate sits on status, and only a human hand opens it. A file with no status is treated as thinking out loud, however certain the writing sounds.
2. 02Use length as a signal, because the machine will not. Four minutes of speech is a thought. A decision has a date, a name, and somebody who can be asked about it. If a record cannot answer the question who decided this and when, it is not a decision yet, whatever it is filed as.
3. 03Fix the generating job to write the lower status. The job was working correctly and had been told the wrong thing to write. Change what it writes before you clean anything up, or you will clean the same mess twice.
4. 04Mark the affected files superseded and never delete them. A deleted file removes the error and also removes the evidence that the system produced it. A superseded file, with a dated line explaining what replaced it and why, shows the correction happening, which is the only way a reader six months out can trust the rest of the record.
5. 05Never build an automation that says it checked something. An automation reporting a check it did not run is worse than no automation at all, because the owner reads the line and stops looking. If the check is real, it names what it looked at. If it cannot name what it looked at, it should say nothing.

What this looks like in your business

The three below are illustrations rather than client cases. Each one is the same failure with different vocabulary.

• A meeting summary that turns "we might list in spring" into a listing date. The summary tool wanted a date field filled. There was a month in the conversation. Now there is a date in a record, and the next person to read it will build a marketing timeline on it.
• A transcript that turns a homeowner saying "maybe we do the upstairs too" into a change order. Four words of daydreaming out of a two hour walkthrough, promoted into scope. The crew lead reads scope and orders materials.
• A note that turns a borrower saying "I think my bonus is around forty" into an income figure in a file. The word think was in the sentence and is not in the file. What is in the file is a number, in a field, in a document that other people rely on.

Every one of these is the same failure: a machine promoting a maybe into a fact, and three other places quoting it by Friday.

The speed of the spread is the part people underestimate. In the incident above it took a single automated pass. In a business it takes about a week, because the fabricated fact is convenient. It fills a gap somebody needed filled, and nobody has an incentive to interrogate a record that answers their question.

Why this is worse than an ordinary mistake

A wrong number in a spreadsheet is bounded. Somebody finds it, corrects it, and the correction is the end of the story. A fabricated decision is different in two ways that both make it more expensive.

First, it reproduces. Records get quoted. A decision file is exactly the kind of file other material points at, and each pointer makes the original harder to retract, because retracting it now means correcting four things instead of one.

Second, it is indistinguishable from the real thing at a glance. That is the property that let the sync log start briefing other jobs on a rebuild. There was no signal to catch. The file looked precisely like every legitimate decision file next to it, which is what a good filing system is supposed to produce.

What the status rule does not fix

The rule is short enough to keep in your head. A machine may record anything it hears. Only a person promotes anything to a decision, with their name on it and a date beside it. Everything above is that sentence with an incident report attached.