The four questions your board will ask about your last release

There is a conversation that happens in every enterprise eventually. Sometimes it is an auditor. Sometimes it is a regulator, a risk committee, or an incident review. Often it is simply a non-executive director who has read something about AI and wants to understand what the organisation actually did.

The questions are always roughly the same, and there are only four of them. They are not technical questions. Nobody asks which model you used or how the pipeline is configured. They ask about evidence — and the striking thing is how rarely a delivery organisation can produce any.

01. What did the business actually request?

Not the epic title. Not the summary in the steering pack. The document somebody in the business wrote, in their own words, before any of this became a delivery problem.

Why it is hard to answer. The signed-off document exists somewhere. By the time it reached the sprint it had been summarised three times — once by an analyst, once into a ticket, once into a prompt. Each summary was reasonable. Nobody kept the original alongside the work.

02. Who approved it?

A name, a date, and a record of what that person actually saw when they approved it. Not who was in the room. Who signed.

Why it is hard to answer. Verbal agreement in a stand-up is not an approval. A thumbs-up in a Teams thread is not an audit trail. In most organisations the approval genuinely happened — it simply was not recorded anywhere that survives the quarter.

03. Where is the test that proves it works?

Not that the code runs. Not that the build is green. That the thing does what the business asked it to do — written before the code, and attached to the story it belongs to.

Why it is hard to answer. Acceptance criteria written in the sprint before release are written by people who have already forgotten what was meant. A test retrofitted to passing code proves the code works. It does not prove the code is right.

04. What did the AI cost against what it delivered?

The licence spend is on an invoice somewhere. The question is what it produced, and how much of that reached production.

Why it is hard to answer. AI spend sits in a procurement line. AI output sits in a hundred individual sessions. Nobody has joined them, so the return on the single fastest-growing line in the technology budget is reported as a number with nothing on the other side of it.

“The AI decided” has never once satisfied an auditor.
Deon Thomas · CEO, eBlocks Software

Nobody made a mistake. The record was simply never created

Between the requirement and the code there are six handoffs. The business writes it. An analyst interprets it. It becomes a ticket. The ticket becomes a sprint item. A developer prompts an agent. The agent produces code. Every one of those steps is a reasonable act by a competent person.

And at the end there is no artefact anywhere in the building that proves the difference between what was asked for and what went live. That is not a speed problem, and it is not a governance failure by any individual. It is an evidence problem, and it is structural.

Four artefacts. None of them optional

A release that can answer all four questions arrives carrying its own evidence. Not assembled afterwards — created alongside the work.

1. The requirement. The document itself, not a summary of it.
2. The approval. A named person, a timestamp, and what they saw.
3. The test. Written before the code, attached to its story.
4. The cost. AI spend reported against work that actually shipped.

The test of one: could you hand your last release to an auditor without a fire drill? If the honest answer is no, the gap is not in your engineering. It is in what your engineering leaves behind.