Evidence Over Attestation, Part Three: The Standard in Five Rules

1. Count before you conclude. The obvious narrative is a hypothesis, never a finding.
2. Define “done” before the first instruction. In the customer’s terms, and before the work begins.
3. Close only on outside-in proof. Internal tests inform; the artifact from the customer’s vantage point closes the case.
4. Make courteous failures loud. A silent fallback converts your problem into your customer’s discovery.
5. No artifact, no closure. Attestation is a claim; evidence is an artifact.

What it protects the customer from. The bigger server bought to fix a traffic spike that was one open microphone. The restart applied to a service that was busy serving a customer. The remediation that treats the symptom the dashboard named and leaves the cause the customer is living with.

What it asks of your people. The discipline to pause at the moment of most pressure, when the story is plausible and the fix is one click away, and ask for the number. On the recorded day that pause took a minute and saved an evening, three times.

Boardroom mandate. Before approving any agentic deployment, the CEO or audit committee instructs the team to show the counts behind every claim in the proposal: the customers affected, the requests measured, the failures observed and their timestamps. A proposal that arrives with a narrative and no numbers goes back.

How you know it is in force. Your incident reviews begin with the counts, not the narrative. Nobody in the room is embarrassed to ask “how many,” and the person who asks is thanked rather than tolerated.

What it protects the customer from. The feature that “works” in every test and fails the first stranger who lets go of a button to read a dialog. The report that “saves” but cannot reproduce itself. The gate that was written after the work, to fit the work.

What it asks of your people. To write the proof first, when it is cheap and uncomfortable, and to describe it from the customer’s side: what she will see, what she will be able to do, what will be true from outside the building. Drucker’s question applies here as everywhere: what does the customer consider value?

Boardroom mandate. No agentic initiative is funded without a written definition of done, in the customer’s terms, that a non-technical director could read, and that definition is dated before the first line of work. The committee keeps the definition and audits the close-out against it, not against the team’s summary.

How you know it is in force. Every piece of work your teams start has a written definition of done that a non-technical executive could read and a customer would recognize, and the definition predates the first line of work.

What it protects the customer from. Nine hundred green tests that never met a stranger. A proof run against yesterday’s version. A health check that passes in the harness and times out in production because the harness never asked a slow question while the check was running.

What it asks of your people. To time the health check while the slowest request is in flight. To fetch the deployed page from outside and compare it to what was committed. To diff the saved report against the live one. To measure while the failure is happening, not after the system has cleaned up.

Boardroom mandate. Every production approval requires evidence gathered from outside the system: the customer-facing check, the timing taken during the slowest real request, the comparison of what is serving against what was approved. Internal test results and agent status reports are received as context, never as proof.

How you know it is in force. “Done” in your organization comes with an external artifact, not a status message: the fetch, the timing, the diff. Your leaders can produce it on request, and they are uneasy when a close-out arrives without one.

What it protects the customer from. The channel that posted the same message three times while the dashboard smiled. The daily job that quarantined its own output and sent an email that read like a normal day. The rescue that worked so well nobody noticed what it was rescuing.

What it asks of your people. To distrust their own safety nets. A rescue path is a courtesy to the customer only if someone is told it fired. Every fallback exits loudly, every retry is counted, and the third identical retry is treated as a finding rather than a feature.

Boardroom mandate. The team inventories every fallback, retry and quarantine path in the agentic system and shows, for each, the alert that fires and the person who is paged. A path that fails quietly is treated as an open defect, and the committee asks when the last one fired and whether the customer was told.

How you know it is in force. You can list the fallbacks in your systems, each one has an alert attached, and the last time one fired, a person was paged and a customer was told before they noticed.

What it protects the customer from. Everything above, compounded. An organization that closes work on a claim will, at machine speed, accumulate a portfolio of claims, and the customer is the one who eventually audits it.

What it asks of your people. A definition of “done” that does not bend to fatigue, deadline or an agent’s confidence. The identifier of the thing that is serving. The record of the check that was made against it. The willingness to say “not done” to a colleague, a partner, or a machine that has already said “done” three times.

Boardroom mandate. Nothing is reported to the board as complete without the artifact: the identifier of the version that is serving, the external check made against it, and the record of who verified it. A status of “done” without those three is recorded as “claimed,” and the distinction appears in the minutes.

How you know it is in force. Nothing in your company is marked complete without the artifact attached, and your leaders would rather delay a launch than close on a promise. The people you want feel physically uncomfortable typing “done” without it.