Article15 Jul 2026 · 15 min read28 / 34Members · Subscription

Automate only what you can verify

The boundary of useful automation is not where a system can act, but where its outcomes can still be checked reliably.

AutomationQualityVerificationGovernance
FFurkan SakızlıAI researcher & tutor · independent
A process whose outcomes become visible at a checkpoint
Not feasibility but verifiability sets the boundary.

Automation is often judged by feasibility: Can the system perform the process? That is not enough for responsible AI work. An agent can research, draft, modify files or prepare decisions while producing outcomes that look convincing. The decisive measure is whether we can determine, at reasonable cost, that an outcome is correct, complete and fit for purpose. Where that check no longer works, technical capability may continue—but responsible autonomy ends.

The real boundary appears after the output

In conventional automation, success and failure are often observable. A file was transferred or not, a field satisfies a rule or not. Generative systems create open-ended outcomes: a plan, evaluation, summary or recommendation. Such outputs may be formally polished and still be substantively incomplete.

Planning must therefore continue beyond the action. Every automated action needs a verification path describing how a good outcome is recognised, which foundation applies and what happens when the check cannot reach a clear decision. Without that path, automation is accelerated uncertainty.

Verifiability does not mean absolute truth. It means that a claimed outcome can be checked against observable criteria, sources or consequences. The less verifiable an output, the smaller its permitted effect should be.

Three classes of task require three boundaries

The first class is deterministically testable. Filenames follow a pattern, required fields exist, totals reconcile or a test passes. A system can act with considerable autonomy here when permissions are limited and errors are reversible.

The second class is assessable but not fully computable. A text should contain all approved claims, a draft should suit an audience or research should expose conflicting sources. This requires rubrics, reference examples, sampling and traceable approval. Automation may prepare much of the work, but it cannot close every quality question by itself.

The third class depends on situated judgement. It includes ethical, strategic, legal or interpersonal decisions whose quality relies on circumstances that cannot be fully formalised. AI can prepare options, consequences and open questions. The binding decision remains with an accountable person.

Verification fatigue is a hidden price of automation

A system can generate more outcomes in minutes than a person can inspect carefully. Production becomes cheaper while control becomes the bottleneck. If every output must be fully reworked, labour has not disappeared; it has shifted into a more exhausting form.

Fatigue changes decisions. After the tenth plausible result, attention falls. Reviewers skim, approve under time pressure or focus on visible defects while substantive gaps survive. A human approval step is therefore not automatically an effective safeguard.

Good automation limits verification load as well as error. It produces less, groups deviations, prioritises high-risk cases and demands human attention where it changes the outcome. The question is not whether a person can inspect everything, but whether the process leaves that person capable of judgement.

Acceptance criteria must exist before the run

When quality is defined only after the output appears, its presentation can set the standard. Elegant prose becomes its own evidence. A better approach starts with a short verification contract: desired outcome, authoritative sources, three to five acceptance criteria, prohibited deviations and behaviour under uncertainty.

Criteria must be observable. “The text is good” cannot be tested reliably. “Every number points to an approved source”, “missing information is marked open” and “no change occurs outside the working directory” can. Concrete criteria can be assigned to a test, a rule or a human decision.

Negative criteria matter too. They describe outcomes that remain unacceptable despite a polished surface: invented evidence, hidden uncertainty, irreversible changes or recommendations outside the brief. A system becomes safe through its behaviour at the boundary, not through the ideal case.

Verification needs several layers

No single method catches every error. Deterministic checks work for formats, completeness, value ranges and technical tests. An independent model review can look for contradictions, missing perspectives and unsupported leaps. Source checks reconnect claims to evidence. People finally evaluate context, consequences and acceptability.

These layers should receive different tasks. The generating system should not be the sole judge of its own success. Self-review can be useful, but it does not replace independent control. Important claims need a route back to a source or observable test.

Not every project needs every layer at equal depth. What matters is risk-based assignment. A reversible formatting change can be checked automatically. A public claim needs source verification. A consequential decision also needs accountable approval.

Human approval must be decidable

A weak checkpoint presents a hundred pages at the end and asks for agreement. A strong checkpoint shows what changed, which criteria passed, where uncertainty remains and which precise decision is now required. It reduces the object of review without hiding relevant risk.

The reviewer needs three things: a readable difference from the previous state, the authoritative basis and a limited set of actions. Approve, reject, request targeted revision or escalate are often enough. Open questions should appear as decision points rather than disappear inside long explanations.

Human control then becomes more than a symbolic click. It is the point where context and responsibility actually meet. The less verifiable an outcome is, the earlier that point should appear in the workflow.

Stopping is a productive outcome

Automation is often considered successful only when it reaches the end. In responsible systems, a justified stop can also be correct. Missing sources, conflicting instructions, an unmeasurable criterion or an effect outside the agreed frame are reasons to return the task.

Stops should be recorded and analysed. If they repeat, the process may lack an input field, domain rule, example or clear owner. A stopped run then improves the system instead of encouraging people to bypass its limits.

The mature question is not how to automate more. It is how to move work into a process whose outcomes remain recognisable, testable and correctable. The gain comes from reliable effect, not maximum autonomy.

The verification card

A short verification contract records, before the run, how an outcome is measured and when a human takes over:

verification-card.mdmarkdown
# VERIFICATION CARD

**Task and effect**
What should be produced, and what may change as a result?

**Task class**
Deterministically testable, assessable or judgement-dependent?

**Observable criteria**
How would two people recognise the same acceptable outcome?

**Verification layers**
Which rule, test, source and person will check it?

**Review load**
How many outcomes can be inspected attentively?

**Stop and escalation**
When does automation end, and who takes over?

**Approval**
Which precise decision remains human?

Automation is valuable when it not only performs work but also carries its own verifiability. A system that recognises limits, keeps evidence visible and stops under undecidable uncertainty is not less capable. It is closer to the kind of capability people can actually trust.

Worksheet: Define the automation boundary

Choose a recurring process you want to accelerate with AI. Break it down so that production, verification and responsibility become visibly distinct.

1. Describe the effect. Record not only the output but the change it may cause. Mark irreversible or external consequences.

2. Classify the tasks. Assign each step as deterministically testable, assessable or judgement-dependent. Explain borderline cases in one sentence.

3. Write criteria first. Formulate three to five observable acceptance criteria and at least two prohibited outcomes.

4. Plan layers and load. Assign rule tests, source checks, sampling or human approval. Estimate how many cases can be reviewed attentively.

5. Set stop and decision. Define two stop signals and the point at which an accountable person takes over.

Members only

Read the full article and download all files with a membership.

Unlock full article + downloads → Subscribe

0 comments

Loading comments…

Sign in to comment · become a member →