Verification Is Not Optional

After a named human authorizes an action, the loop is not closed until verification is recorded. Learning requires a verified outcome, not a hoped-for one.

Reliability work is full of actions that were approved and never checked. The interval was stretched. The assembly was replaced. The route was added. The meeting moved on. Months later the same failure returns, and the record shows a decision without a result. The organization remembers what it intended. It cannot show what happened.

Sync keeps that check on the signed-in Decision Case. A signed-in user completes the case in a fixed order: Question, Evidence, Recommendation, Human decision, Action, Verification, and Learning. Orville Davis states that order in Field Manual v0. The manuals index lives at /manuals. This essay is why verification cannot be skipped once a person has authorized the work. The manual is the public contents.

Authorization closes the argument. It does not close the case.

Recommend is not authorize. A recommendation is an argument. Authorization is an act by a person who can be named. That distinction is the subject of Recommend Is Not Authorize. It is necessary, and it is not the end of the loop.

The human decision records who accepted, rejected, escalated, or returned the proposal. Action records the work that decision authorized and keeps that statement on the case, beside the question and the evidence. Those two steps answer who permitted the work and what was approved to happen next.

They do not answer whether the action did what it was supposed to do.

A signed approval can be complete and still leave the outcome unknown. The case that stops at action has a named person and an intended change. It does not have a result. Treating the signature as closure is how a hoped-for outcome gets filed as if it had been observed.

Read those steps as separate chapters: Human decision and Action. Work that follows the decision moves through the customer’s systems of record and the people who already hold operating authority. Recording the action is not plant execute.

Verification is the recorded check

Verification records whether the authorized action did what it was supposed to do, and which evidence would show that. The check sits on the same record as the question, the recommendation, and the human decision. A later reader should be able to see the intended effect, the evidence that was supposed to show it, and what was actually observed.

A useful verification entry keeps three things distinct:

• What the authorized action was supposed to change
• Which evidence would show that change, and what is still missing
• What was observed after the action — including a result that did not match

The third item is the one organizations skip. A plan states the first. A procedure sometimes states the second. Only the recorded observation turns the case from an intention into an outcome. If the observation contradicts the intention, the case still closes honestly. A failed check is a result. An unchecked hope is not.

The Verification chapter states that gate. Stage-1 verification is the recorded check held on the case. A live pull of control-system tags is not the proof this edition describes. Telemetry and asset context shown in the workspace may be simulated or seeded. Treat that material as a practice record. It is not a plant historian, and it is not a customer result.

The same discipline applies to the evidence the recommendation was built on. Evidence Lineage Is Not Optional asks whether a later reviewer can reconstruct the proposal. Verification extends that trail past the proposal: which check was named, who recorded it, and what it showed. A recommendation you cannot reconstruct is not an industrial decision. An authorized action you never checked is not a closed one.

Learning waits on the check

Learning keeps the closed case — question, evidence, recommendation, human decision, action, and verification — so a later question can see what was believed, what was authorized, and what was checked. The signed-in loop ends on that record.

Learning requires a verified outcome, not a hoped-for one.

If verification is missing, a later question inherits a story. The story says the action was approved, so it must have worked. The next recommendation then cites that story as evidence. The gap compounds: an unchecked action becomes the basis for the next proposal, and the case looks more certain each time it is reused.

A verified outcome can be narrow. It can say the check was inconclusive, that the expected signal was not available, or that the action did not produce the intended effect. Those are learnable records. A blank verification field is not. The Learning chapter publishes that rule. It does not publish a result from a customer site.

Where the public statement lives

Field Manual v0 is the public contents of this loop. Start at the manuals index or open Sync Field Manual directly. Verification is step 06. It sits after the human decision and the action, and before learning. Later editions can deepen a chapter. The spine stays in this order.

What this article is not claiming

This is an essay about the Decision Case order, not a customer case study. It names no plant, states no savings figure, and claims no prevented failure.

Stage-1 readiness means a signed-in user can complete the Decision Case — question, evidence, recommendation, human decision, action, verification, and learning — and Field Manual v0 describes that journey. This edition does not describe plant execute, a live connector tag pull, SMTP invite delivery, or automatic revocation of access on expiry as live. Simulated or seeded telemetry and assets are practice records. They are not live plant results.

The next essay in this order is Learning Requires a Verified Outcome. Companion reading: Recommend Is Not Authorize on why a drafted proposal is not permission, and Evidence Lineage Is Not Optional on why the record behind a recommendation has to be reconstructable.