How it works
Observe, authorise, execute, verify.
The same sequence is intended to govern every consequential step of a workflow. This page describes the designed behaviour at the level a reviewer needs to evaluate it.
§ 01
The governed loop.
Each stage has a defined input and a defined output. An execution step that is not accompanied by a valid authorisation is refused by construction rather than by convention.
Where a workflow is long, it is designed to be delivered as a sequence of shorter segments, each with its own checkpoint and resume point, so that a failure costs one segment rather than an entire run.
-
01 Observe
Read the current state of the application through the most reliable channel available, using an interface or a model only where each is appropriate. Which channel is used is set by policy, not chosen by a model.
-
02 Propose
Produce a single, explicitly described action. Every path produces the same kind of proposal, so one set of rules can govern all of them.
-
04 Execute
Re-check that conditions still hold, then carry out one approved action — designed so that a retry after an interruption establishes what already happened before acting again.
-
05 Verify
Confirm the business result from the application's own records rather than from the screen the action was performed on. Success is reported only when that independent check passes.
-
06 Record
Keep a structured record of what was decided, authorised, executed and confirmed, so a completed run can be reviewed later.
-
07 Stop when the evidence is insufficient
Where confidence is too low, evidence conflicts, or the situation is outside the approved workflow, the intended behaviour is to stop and hand control to a person with the reason attached.
§ 02
The approval step is a control, so it is designed like one.
If a reviewer has to open other systems to check the work, the value of the automation is gone. If the screen is designed to make approving effortless, the control is decorative.
Presented together
- A summary of the case and what was found.
- The values before the action, and the action proposed.
- The rule the proposal is based on.
- The supporting evidence, openable in place.
- The risk class and the expected effect.
- What the system was uncertain about.
Designed against rubber-stamping
- Uncertainty is shown first, not buried in the detail.
- No oversized recommended-action button — the case and evidence lead.
- Approvals are scoped and time-limited rather than standing.
- The authority of the approver is part of what makes an approval valid.
- A stop control is available throughout.
The indicator that matters
An approval rate approaching one hundred per cent means the reviewer is confirming rather than reviewing. Approval behaviour is treated as a safety signal, not a productivity statistic.
§ 03
Designing against the failure that matters.
A visibly broken automation is an inconvenience. An automation that reports a success it cannot substantiate is a liability.
A confirmation screen is not evidence
Interfaces show success messages for writes that failed further down. Verification is therefore designed to read the resulting business state through a different route from the one used to act.
A retry checks what already happened
An interrupted response after a successful write is a common way for automation to create duplicates. Recovery is designed to establish the prior effect before considering another attempt.
Ambiguity is a stop condition
Where the evidence does not separate two plausible candidates, the intended behaviour is to stop. Being right most of the time is not an acceptable property for something writing to a system of record.
Page content is data, not instruction
Content encountered in an interface is treated as untrusted input. Instructions found there are not designed to be able to grant permission, widen scope or extend an approval.
The governing principle
An explicit stop is better than a confident guess. A halted run costs a person a few minutes. An unverifiable success costs the organisation its ability to trust the system.
§ 04
Evidence: enough to review a run, and no more.
Recording everything an automation sees would be simpler to build and considerably worse to own. The intended approach is to keep only what establishes the inputs, the decision, the authority, the action and the confirmed result — and to remove sensitive values before the record is written rather than afterwards.
Access to run a workflow is designed to be separate from access to read its records, and both are separate again from the ability to export or delete them.
Why it matters commercially
A reviewable record is what allows a disputed result to be examined rather than argued about, and what makes an internal audit of an automated process possible at all. It is a requirement, not a feature.