The Workflow Constraint and Root-Cause Audit: Simplify the Work Before Automating It

When manual work or a queue keeps growing, check what creates it. Demand may exceed capacity, but incomplete inputs, delayed decisions, repeated controls, unclear ownership and recurring exceptions can produce the same symptom. Find the cause before assuming automation is the answer.

This operating guide gives leadership a governed method for deciding what should be removed, clarified, standardised, redesigned, validated or transferred to a separately governed automation assessment. It does not select technology or authorise implementation.

1. The Market Connection Context

Every workflow converts a commitment into something a customer, employee, partner, citizen or leadership team can use. When that conversion breaks, the bottom-line effect rarely stays inside an operations metric. Delayed work can postpone revenue, increase avoidable handling, consume skilled capacity, weaken service reliability, create control exposure and make the organisation harder to deal with.

The audit follows one bounded commitment-to-value path:

Trigger → accepted work → correct information → controlled decision → completed handoff → usable outcome

The path is not a promise that every case should move quickly. Some work must slow down for safety, fairness, security, quality or qualified judgement. The leadership question is whether each activity, delay, decision and control earns its place in producing a reliable outcome.

The decision to make

For each material constraint, the authorised forum chooses one primary disposition:

• remove an activity that has no required value or control purpose;
• clarify an outcome, rule, ownership or input condition before redesign;
• standardise a stable variation where one controlled method is appropriate;
• redesign the workflow, handoff, decision or control;
• validate a root-cause claim or proposed change with bounded evidence;
• retain a necessary activity or control within its stated limits;
• escalate a legal, privacy, security, safety, accessibility, financial, employment or sector question to a qualified authority;
• handoff an accepted opportunity to The Automation Opportunity Portfolio: A Value, Feasibility, Risk and Learning Playbook or another named downstream standard; or
• stop or defer when authority, evidence, benefit, capacity or safeguards are insufficient.

These are diagnostic dispositions. None authorises automation procurement, system configuration, model use, production release or workforce change.

What the audit must separate

The audit distinguishes observed conditions from explanations. “Staff re-enter data” is an observation. “The team needs automation” is a proposed intervention. The cause may instead be an upstream definition, inaccessible source, duplicated control, mismatched identifier, incomplete intake, unowned exception or policy interpretation.

It also separates five forms of time: active work, waiting, correction, review and blocked time. A shorter touch time can coexist with a longer end-to-end experience. A faster local team can transfer work or risk to another team. The unit of analysis is therefore the whole bounded workflow and its affected people, not the most visible task.

Scope and exclusions

Use this guide when leadership can name a material workflow, affected population, current outcome concern and decision owner. The audit may cover trigger conditions, tasks, information, decisions, queues, handoffs, exceptions, controls, systems, roles, outcomes and current measures.

It excludes technology selection, detailed solution architecture, an automation portfolio ranking, formal business case, procurement, production implementation, employment determination, statutory assurance and any forecast unsupported by organisational evidence. The Automation and Technology Readiness Assessment: An Executive Standard for Choosing What Should Change determines use-case readiness; The Automation Opportunity Portfolio: A Value, Feasibility, Risk and Learning Playbook compares accepted opportunities; The Automation Architecture Decision: Rules, Platforms, Agents, Custom Software or No Build chooses an architecture route; The AI and Automation Governance Standard: Proportionate Control from Assistance to Autonomous Action governs proportionate control; The Proof-of-Value Pilot Standard: Designing Automation Tests That Can Earn Production governs a proof-of-value pilot.

Expected result

The output is a decision pack, not a process picture: an approved charter; current-state evidence register; accepted workflow and exception model; constraint and root-cause ledger; option and control record; baseline and measure contracts; executive disposition; owned handoff; and dated review conditions.

2. The Leadership vs. Delegation Boundary

Leadership owns the outcome, scope, risk appetite, evidence access, trade-offs, resource boundary and final disposition. A process analyst, service designer, operations lead, data analyst, internal audit contributor or independent specialist may facilitate observation and analysis. They cannot silently redefine the business outcome, approve their own proposal, remove a control or commit the organisation to automation.

Internal leadership can lead when

• the process owner has authority across all material handoffs;
• participants can describe actual work without retaliation or supplier pressure;
• representative cases and exceptions are accessible lawfully;
• baseline definitions can be reconciled;
• the team has credible facilitation and root-cause capability; and
• the final forum is independent of any preferred tool or implementation benefit.

Independent challenge is justified when

• the workflow crosses competing budgets, performance measures or executive accountabilities;
• local teams disagree about the current state or transfer blame across a handoff;
• a supplier, platform owner or programme sponsor has already framed the answer;
• workforce, customer, safety, privacy or financial-control consequences are material;
• evidence quality is weak and the investment consequence is high; or
• the organisation needs a neutral record of dissent, limitations and rejected alternatives.

The reader recognises that credible diagnosis requires observation, exception analysis, process evidence and control redesign across functions before any technology choice.

Human authority that cannot be delegated

Named organisational authorities approve participation, evidence access, control interpretation, employee or customer safeguards, exception ownership, removal of a required activity, baseline use, funding and the final disposition. “Human in the loop” is insufficient: the record must say which person can approve, override, contain, stop and accept residual exposure.

Use an internal team when it can observe work safely and challenge the process owner. Use an independent partner where incentives, workforce concerns or cross-functional conflict compromise observation. Use a narrower specialist for a bounded control, accessibility, privacy, safety, statistical or financial question. Ask a provider: how is observation independent; how are contrary cases retained; what burden is transferred; how are control interpretations qualified; what records remain with the organisation; and where does the provider stop before technology selection? Stop or escalate when access, participation, safety, evidence coverage or authority is insufficient.

Conditions that stop or narrow the audit

Stop, contain or narrow the work when evidence was obtained without authority; participants face material harm; a regulatory or employment conclusion is being made without qualified review; the current-state sample is materially unrepresentative; the decision owner cannot access cross-functional evidence; a preferred solution is treated as mandatory; or a serious control failure requires incident response rather than diagnostic workshops.

3. The Step-by-Step Execution Standard

Step 01: Charter the workflow decision

Purpose and decision served

Convert a complaint such as “too manual” or “too slow” into one bounded leadership decision about a named workflow and outcome.

Accountable owner

The economic or service owner accountable for the workflow outcome.

Delegated lead and contributors

Audit lead with the process owner, customer or service representative, finance or metric owner, information authority, risk or control owner and affected operational roles.

Preconditions, inputs and access

An observable workflow, an important decision, an initial affected population, permission to test the premise and no irreversible automation commitment.

Actions

1. Name the workflow from trigger to usable outcome in language affected people recognise.
2. State the current condition, consequence, decision deadline and why leadership must act.
3. Define in-scope populations, channels, locations, teams, systems and time periods.
4. Record exclusions, dependencies, assumptions and the no-change consequence.
5. Approve the diagnostic dispositions and what each does not authorise.

Evidence to retain

Signed charter, scope map, decision statement, conflict declarations and prior-commitment inventory.

Decision or scoring rule

Proceed only if the decision can be changed by evidence and the workflow boundary reaches a usable outcome rather than ending at a department or screen.

Output and template

Workflow Audit Charter and Observation Plan.

Acceptance gate

The sponsor, process owner and evidence authority accept the same decision, boundary and stop conditions.

Leadership checkpoint

Confirm that “implement automation” is not the chartered answer.

Human control point

A named sponsor approves scope and can stop access or analysis.

Failure modes and safeguards

Failure modes include mapping an entire enterprise, selecting only the happy path and hiding a mandated solution. Safeguard with a decision-bounded slice and visible commitments.

Change, stop or escalation condition

Re-charter if the material outcome, population, workflow boundary or authority changes.

Handoff to the next step

Transfer the approved charter and unresolved authority gaps to Step 02.

Step 02: Assign authority, participation and independent challenge

Purpose and decision served

Make evidence access, control interpretation and the final disposition accountable before observation begins.

Accountable owner

The executive sponsor.

Delegated lead and contributors

Governance coordinator with process, information, risk, people, customer, accessibility, finance and specialist authorities.

Preconditions, inputs and access

Approved charter, role inventory, known conflicts and the organisation's existing authority routes.

Actions

1. Assign one named decision owner and one accountable workflow owner.
2. Assign evidence, participation, information, control, metric and change authorities.
3. State who approves, challenges, overrides, contains and stops the work.
4. Record supplier, programme, performance-target and implementation conflicts.
5. Approve proportionate participation, confidentiality, retention and escalation routes.

Evidence to retain

Authority matrix, access approvals, participation route, conflict register and recusal decisions.

Decision or scoring rule

No person may approve a diagnostic conclusion or follow-on engagement from which they materially benefit without independent review.

Output and template

Authority and participation rows in the Workflow Audit Charter and Observation Plan.

Acceptance gate

All decision-critical roles are named; missing authority is accepted as a constraint or resolved.

Leadership checkpoint

Confirm the audit can cross the handoffs implicated by the charter.

Human control point

Information and people authorities approve how cases and participants may be observed.

Failure modes and safeguards

Failure modes are symbolic sponsorship, coercive participation and implementer self-approval. Safeguard with named people, recusal and direct escalation.

Change, stop or escalation condition

Pause when access exceeds approval, participation becomes unsafe or an authority withdraws.

Handoff to the next step

Transfer the authority and access record to Step 03.

Step 03: Define the workflow outcome and evidence grammar

Purpose and decision served

Establish a shared language for cases, outcomes, time, defects, exceptions and controls so unlike facts are not combined.

Accountable owner

The workflow owner.

Delegated lead and contributors

Process analyst with affected roles, customer or service representative, data owner, finance and control owners.

Preconditions, inputs and access

Charter, authority record, current definitions, reports, policies and sample case identifiers.

Actions

1. Define the trigger, accepted case, completion, usable outcome and excluded outcomes.
2. Define active, waiting, correction, review and blocked time separately.
3. Define defect, rework, transfer, exception, abandonment and demand units.
4. Record source, population, period, exclusions, owner and limitation for each definition.
5. Reconcile conflicts or mark them REQUIRES VALIDATION.

Evidence to retain

Definition register, metric contracts, unresolved conflicts and forum decisions.

Decision or scoring rule

A definition is fit only for the stated decision, population and period; a dashboard label alone is not a definition.

Output and template

Definition and baseline section in the Current-State Workflow and Case Evidence Register.

Acceptance gate

The process, metric and decision owners approve all decision-critical definitions or name the validation gate.

Leadership checkpoint

Review whether existing targets encourage local optimisation or hidden transfer.

Human control point

The metric owner accepts calculation and use limits.

Failure modes and safeguards

Failure modes are mixing touch and elapsed time, treating transfers as completion and changing definitions after results. Safeguard with versioned contracts.

Change, stop or escalation condition

Return to the charter if the usable outcome cannot be defined or material populations require separate decisions.

Handoff to the next step

Transfer the evidence grammar and sampling gaps to Step 04.

Step 04: Design representative observation and case sampling

Purpose and decision served

Observe actual work, including variation and failure demand, rather than relying on the documented process or a workshop average.

Accountable owner

The evidence authority.

Delegated lead and contributors

Research or process-observation lead with frontline roles, data analyst, customer representative and privacy or people authority.

Preconditions, inputs and access

Approved participation route, evidence grammar, source inventory and known case strata.

Actions

1. Define relevant case strata by outcome, channel, complexity, exception, affected group and period.
2. Select observation, interviews, case traces, logs, documents and aggregate data for their native claims.
3. Include successful, delayed, corrected, abandoned and escalated cases where lawful and relevant.
4. Record sampling, missingness, survivorship and observer limitations.
5. Pilot the capture method and correct fields that invite interpretation instead of observation.

Evidence to retain

Sampling rationale, approvals, case list, observation protocol, exclusion log and limitation statement.

Decision or scoring rule

Do not generalise beyond the observed or defensibly represented population; absence from a system is not proof that a case did not exist.

Output and template

Observation-plan rows in the Workflow Audit Charter and Observation Plan.

Acceptance gate

The evidence owner accepts that the planned sample can expose the material paths and limitations relevant to the decision.

Leadership checkpoint

Approve any deliberate exclusion of high-consequence or underserved cases.

Human control point

Participation and information authorities can narrow or stop collection.

Failure modes and safeguards

Failure modes include observing only high performers, extracting excessive personal data and treating anecdotes as prevalence. Safeguard with strata, minimisation and proof status.

Change, stop or escalation condition

Change the plan when observed variation materially differs from the assumed workflow.

Handoff to the next step

Transfer approved sample and protocol to Step 05.

Step 05: Trace the current state from trigger to usable outcome

Purpose and decision served

Create an evidence-linked account of what actually happens across roles, systems and handoffs.

Accountable owner

The workflow owner.

Delegated lead and contributors

Process lead with people who perform, receive, approve, support and experience the work.

Preconditions, inputs and access

Representative cases, approved observation, source access and reconciled event definitions.

Actions

1. Trace each case's trigger, intake, task, decision, queue, handoff, exception, control and outcome.
2. Capture role, system, input, output and evidence reference at each node.
3. Separate documented, reported and observed variants.
4. Record what affected people must do outside the formal workflow.
5. Mark unknown sequence or ownership as a gap, not an inferred connection.

Evidence to retain

Case traces, observations, workflow-node register, source references, variant list and participant corrections.

Decision or scoring rule

A node exists in the accepted current state only when its occurrence or required purpose has evidence and an owner.

Output and template

Current-State Workflow and Case Evidence Register. Use the Workflow Audit Link and Identity Register to propagate AUD-001, parent IDs and linked record IDs across the case, cause and executive files.

Acceptance gate

Performers and receivers confirm the map represents material paths, while disagreements remain visible.

Leadership checkpoint

Review where the organisational view and affected-person view materially diverge.

Human control point

The workflow owner approves the current state without approving a future design.

Failure modes and safeguards

Failure modes are a polished ideal map, missing backstage work and forced consensus. Safeguard with case-level links, variants and dissent.

Change, stop or escalation condition

Return to sampling if a material path, population or control was omitted.

Handoff to the next step

Transfer accepted nodes, paths and evidence gaps to Step 06.

Step 06: Quantify flow, demand, delay and rework within limits

Purpose and decision served

Locate material constraint symptoms without confusing measurement with cause.

Accountable owner

The metric owner.

Delegated lead and contributors

Data analyst with process, finance, service and source-system owners.

Preconditions, inputs and access

Accepted workflow definitions, case evidence, reconciled timestamps and known source limitations.

Actions

1. Establish demand, completion, queue, work-in-progress and outcome counts by relevant stratum.
2. Separate active, waiting, correction, review and blocked time.
3. Measure first-pass completion, return, repeat contact, transfer and exception where meaningful.
4. Reconcile totals across sources and retain unexplained differences.
5. Mark every baseline VERIFIED, INFERRED, PROPOSED or REQUIRES VALIDATION.

Evidence to retain

Metric calculations, source extracts or references, reconciliations, exclusions, confidence limits and owner approval.

Decision or scoring rule

A material symptom must affect the chartered outcome or risk and survive definition and source review; volume alone does not establish priority.

Output and template

Baseline rows in the Current-State Workflow and Case Evidence Register.

Acceptance gate

Decision-critical baselines are accepted within limits or a named evidence gate prevents unsupported quantification.

Leadership checkpoint

Confirm the forum can see end-to-end performance and transferred burden, not only local productivity.

Human control point

Metric and finance owners approve any economic use of a baseline.

Failure modes and safeguards

Failure modes include false timestamp precision, averages hiding tails and counting work shifted elsewhere as saving. Safeguard with strata and reconciliation.

Change, stop or escalation condition

Stop quantified claims when source lineage or definitions cannot support the decision.

Handoff to the next step

Transfer material symptoms and baseline gaps to Step 07.

Step 07: Model exceptions, controls and failure demand

Purpose and decision served

Reveal work created by earlier failure, legitimate variation and required safeguards before proposing simplification.

Accountable owner

The workflow owner with the relevant control authority.

Delegated lead and contributors

Process analyst, frontline roles, quality, risk, customer support, information and specialist control owners.

Preconditions, inputs and access

Current-state register, case sample, exception definitions, incident records and applicable policies.

Actions

1. Classify exceptions by trigger, frequency evidence, consequence, routing and owner.
2. Distinguish legitimate complexity from preventable failure demand.
3. Trace each control to its obligation, risk, evidence and decision authority.
4. Identify duplicated, retrospective, bypassed or unactionable controls.
5. Record cases that the current process excludes, burdens or handles unsafely.

Evidence to retain

Exception catalogue, control-purpose record, repeat-demand evidence, incident references and specialist decisions.

Decision or scoring rule

No control is removed because it is slow; retain, redesign or escalate it according to verified purpose, consequence and qualified authority.

Output and template

Exception and control rows in the Constraint, Root-Cause and Redesign Decision Ledger.

Acceptance gate

Material exceptions and controls have owners, evidence, purpose and a permitted review route.

Leadership checkpoint

Review where failure demand originates outside the team carrying its cost.

Human control point

Only the named control authority may accept removal, substitution or residual exposure.

Failure modes and safeguards

Failure modes are automating the happy path, labelling people as exceptions and deleting controls by workshop vote. Safeguard with case evidence and specialist authority.

Change, stop or escalation condition

Escalate material safety, rights, privacy, security, financial or regulatory failures immediately.

Handoff to the next step

Transfer the exception and control model to Step 08.

Step 08: Test root-cause hypotheses

Purpose and decision served

Distinguish causes the organisation can act on from symptoms, correlations and preferred explanations.

Accountable owner

The audit decision owner.

Delegated lead and contributors

Independent facilitator with workflow, data, system, policy, customer, finance and control owners.

Preconditions, inputs and access

Accepted current state, material symptoms, exceptions, controls, baseline limits and contrary cases.

Actions

1. Write each hypothesis as condition, mechanism, affected cases and predicted observable evidence.
2. Test upstream input, rule, ownership, handoff, capacity, capability, system, incentive and control explanations.
3. Seek contrary and disconfirming cases deliberately.
4. Separate direct evidence, interpretation, proposed mechanism and missing evidence.
5. Classify each hypothesis as accepted within limits, validate, retain as context or reject.

Evidence to retain

Hypothesis cards, tests, contrary evidence, causal reasoning, proof status and challenge record.

Decision or scoring rule

A root-cause claim is accepted only when evidence supports the condition and credible mechanism, alternatives were tested and its limits are explicit.

Output and template

Root-cause rows in the Constraint, Root-Cause and Redesign Decision Ledger.

Acceptance gate

Every material constraint has at least one bounded accepted or validation-required cause; unsupported certainty is rejected.

Leadership checkpoint

Challenge causes that conveniently preserve local targets or the preferred technology.

Human control point

The decision owner records dissent and approves the classification, not the facilitator.

Failure modes and safeguards

Failure modes include workshop voting, “lack of automation” as cause and stopping at individual error. Safeguard with mechanisms, contrary cases and system conditions.

Change, stop or escalation condition

Return to observation when the evidence cannot distinguish competing material causes.

Handoff to the next step

Transfer accepted causes and validation gaps to Step 09.

Step 09: Design non-technology and technology-neutral options

Purpose and decision served

Create proportionate alternatives that address accepted causes before any architecture choice.

Accountable owner

The workflow owner.

Delegated lead and contributors

Service or process designer with affected roles, customers or representatives, control, data, finance and technology contributors.

Preconditions, inputs and access

Accepted root-cause ledger, control purposes, workflow outcome and change constraints.

Actions

1. Consider removal, input clarification, policy or rule change, ownership change, standard work, handoff redesign, capacity, training and no-change options.
2. Describe each option's mechanism, affected cases, dependencies and displaced burden.
3. Preserve necessary exceptions, human judgement and control authority.
4. State where technology might later assist without choosing a product or architecture.
5. Define the smallest evidence needed to compare material options.

Evidence to retain

Option cards, mechanism links, affected-person review, control review, dependency map and rejected alternatives.

Decision or scoring rule

An option is eligible only if it addresses an accepted cause, protects the required outcome and exposes new burden and risk.

Output and template

Option rows in the Constraint, Root-Cause and Redesign Decision Ledger.

Acceptance gate

The portfolio includes a credible non-technology route, current-state route and validation route where applicable.

Leadership checkpoint

Confirm local efficiency does not transfer cost, risk or work to customers or another function.

Human control point

Affected workflow and control owners accept an option for comparison, not implementation.

Failure modes and safeguards

Failure modes are solution theatre, removing human judgement by default and comparing a detailed tool with vague alternatives. Safeguard with common option fields.

Change, stop or escalation condition

Reject options that require prohibited access, remove unreviewed controls or cannot name an accountable operator.

Handoff to the next step

Transfer eligible options and open validation needs to Step 10.

Step 10: Compare options and define the next evidence gate

Purpose and decision served

Make trade-offs visible across value, service, workflow, control, feasibility, capability and learning without an automatic winner.

Accountable owner

The economic or service owner.

Delegated lead and contributors

Audit lead with finance, operations, customer, risk, people, data and technology authorities.

Preconditions, inputs and access

Eligible option set, accepted causes, baselines, dependencies, constraints and specialist conditions.

Actions

1. State the decision lenses and evidence threshold before comparison.
2. Assess each option separately against outcome, effort, delay, risk, control, operability, reversibility and learning.
3. Record evidence and uncertainty for every material judgement.
4. Design a bounded validation gate for decision-critical uncertainty.
5. Record rejected alternatives, dissent and the cost or exposure of no action.

Evidence to retain

Comparable option record, source references, assumptions, validation design, dissent and forum notes.

Decision or scoring rule

Scores may structure discussion but cannot offset a prohibited condition, qualified-control objection or missing decision-critical evidence.

Output and template

Comparison and gate rows in the Constraint, Root-Cause and Redesign Decision Ledger.

Acceptance gate

The forum can explain why an option is eligible, what remains uncertain and what evidence would change the decision.

Leadership checkpoint

Choose whether the next move is direct redesign, bounded validation, portfolio handoff, deferral or stop.

Human control point

Named authorities accept thresholds and stop conditions before validation begins.

Failure modes and safeguards

Failure modes are weighted-score automation, moving thresholds after results and discounting low-frequency severe harm. Safeguard with veto conditions and decision notes.

Change, stop or escalation condition

Reopen comparison when a material option, dependency, constraint or consequence was omitted.

Handoff to the next step

Transfer the recommended disposition and evidence boundary to Step 11.

Step 11: Make the executive diagnostic disposition

Purpose and decision served

Issue a bounded, accountable decision that authorises only the correct next work.

Accountable owner

The authorised executive forum.

Delegated lead and contributors

Decision owner with workflow, finance, evidence, control and receiving owners; audit lead presents but does not self-approve.

Preconditions, inputs and access

Accepted decision pack, material dissent, proof limits, option comparison and owned next gate.

Actions

1. Review the chartered decision and confirm the scope has not drifted.
2. Review accepted causes, limitations, options, rejected alternatives and no-action exposure.
3. Choose remove, clarify, standardise, redesign, validate, retain, escalate, handoff, defer or stop.
4. State what the decision authorises and explicitly excludes.
5. Assign resources, owner, safeguards, acceptance evidence and review date.

Evidence to retain

Decision minutes, disposition, rationale, dissent, authority, conditions, exclusions and signed handover.

Decision or scoring rule

One primary disposition applies to each bounded constraint; mixed constraints are split rather than hidden in one recommendation.

Output and template

Executive Workflow Decision and Review Register.

Acceptance gate

The decision has a named owner, evidence basis, resource boundary, stop condition and receiving-owner acceptance.

Leadership checkpoint

Confirm an automation handoff authorises assessment or portfolio comparison only, not implementation.

Human control point

Only the named forum accepts residual exposure and commits organisational resources.

Failure modes and safeguards

Failure modes are “approve the report,” bundle decisions and implied procurement. Safeguard with a controlled disposition enum and explicit exclusions.

Change, stop or escalation condition

Do not issue a proceed or handoff disposition without accepted decision-critical evidence and owner capacity.

Handoff to the next step

Transfer the controlled decision record and accepted artefacts to Step 12.

Step 12: Operate review, change, retirement and learning

Purpose and decision served

Keep the diagnosis valid as workflow, demand, controls and evidence change, and close obsolete work.

Accountable owner

The receiving workflow or change owner.

Delegated lead and contributors

Review owner with metric, evidence, control, operations and affected-person representatives.

Preconditions, inputs and access

Approved disposition, measure contracts, review triggers, access-closure requirements and accepted handover.

Actions

1. Monitor the named outcome, operating measures, learning evidence and guardrails.
2. Reconcile new evidence against the original population, period, cause and threshold.
3. Review changes to demand, policy, controls, roles, systems, suppliers and affected groups.
4. Renew, change, validate, escalate, retire or stop the disposition.
5. Close temporary access, archive decisions and record reusable learning with limitations.

Evidence to retain

Review log, metric evidence, change assessments, incidents, renewed decisions, retirement record and access closure.

Decision or scoring rule

A disposition remains active only while its evidence, owner, controls and review conditions remain valid.

Output and template

Review and lifecycle rows in the Executive Workflow Decision and Review Register.

Acceptance gate

The review owner confirms current validity or issues a changed, retired or stopped disposition.

Leadership checkpoint

Review whether the change improved the end-to-end outcome or merely shifted burden.

Human control point

A named authority decides continuation after a guardrail breach or material change.

Failure modes and safeguards

Failure modes are permanent pilots, stale baselines, orphaned controls and unrecorded workaround growth. Safeguard with expiry and change triggers.

Change, stop or escalation condition

Contain and escalate harm or control failure; re-charter a materially different workflow question.

Handoff to the next step

Close the audit or transfer a newly chartered decision to the relevant A2 operating guide.

4. The Evidence & Measurement Checklist

Use these tests as acceptance controls. A checked item must point to the retained artefact, not to a verbal assurance.

Preflight and authority

• One bounded workflow decision links a trigger to a usable outcome and remains open to contrary evidence. Evidence: approved charter and scope map. Owner: executive sponsor.
• The charter names affected populations, channels, functions, systems, periods and material exclusions. Evidence: charter boundary rows. Owner: workflow owner.
• Decision, workflow, evidence, information, control, metric and change authorities are assigned to named people. Evidence: authority matrix. Owner: executive sponsor.
• Supplier, programme, performance-target and implementation interests are declared and controlled. Evidence: conflict and recusal register. Owner: governance owner.
• Remove, clarify, standardise, redesign, validate, retain, escalate, handoff, defer and stop dispositions are defined as diagnostic decisions. Evidence: approved disposition glossary. Owner: decision owner.

Evidence access and quality

• Observation, participation, case access, retention and disposal routes are approved before collection. Evidence: participation and information approvals. Owner: information authority.
• Successful, delayed, corrected, abandoned, escalated and material exception cases are represented where relevant and lawful. Evidence: sampling rationale and case strata. Owner: evidence authority.
• Documented, reported, observed and system-recorded workflow evidence remain distinguishable. Evidence: evidence-class field and source references. Owner: audit lead.
• Every decision-critical definition states population, period, unit, source, exclusions, owner and limitation. Evidence: definition register. Owner: metric owner.
• Missingness, survivorship, timestamp, observer, participation and generalisation limits are visible. Evidence: limitation log. Owner: evidence authority.

Method execution

• The current state includes trigger, intake, task, decision, queue, handoff, exception, control and usable outcome where applicable. Evidence: accepted workflow register. Owner: workflow owner.
• Active, waiting, correction, review and blocked time are separately defined and not collapsed into one average. Evidence: baseline contracts. Owner: metric owner.
• Failure demand and preventable rework are distinguished from legitimate variation and required control work. Evidence: exception classification. Owner: process owner.
• Each material root-cause hypothesis states condition, mechanism, affected cases, predicted evidence and credible alternatives. Evidence: hypothesis rows. Owner: audit lead.
• Root-cause classifications preserve contrary evidence and use VERIFIED, INFERRED, PROPOSED or REQUIRES VALIDATION status. Evidence: root-cause ledger. Owner: decision owner.

Governance, privacy, security and risk

• Controls are linked to obligation, risk, evidence and qualified authority before retain, redesign or removal discussion. Evidence: control-purpose record. Owner: control authority.
• Research and case evidence use the minimum authorised personal or confidential information. Evidence: minimisation and access record. Owner: information authority.
• Accessibility and inclusion conditions cover affected disabled people and assisted or offline routes where relevant. Evidence: accessibility review. Owner: accessibility authority.
• Material safety, legal, privacy, security, employment, financial and sector questions are routed to qualified organisational authorities. Evidence: specialist-review disposition. Owner: executive sponsor.
• A platform owner, supplier or implementer cannot self-approve a conclusion or next phase from which it benefits. Evidence: independence and decision record. Owner: governance owner.

Deliverables and acceptance

• The charter, authority, access, conflict and sampling records are complete, versioned and accepted. Evidence: Workflow Audit Charter and Observation Plan. Owner: executive sponsor.
• Current-state nodes and case variants link to evidence and expose disagreement or unknowns. Evidence: Current-State Workflow and Case Evidence Register. Owner: workflow owner.
• Material symptoms, exceptions, controls, causes and options remain traceable to the chartered outcome. Evidence: Constraint, Root-Cause and Redesign Decision Ledger. Owner: audit lead.
• Every option states mechanism, affected cases, dependencies, displaced burden, control conditions and evidence gap. Evidence: comparable option rows. Owner: workflow owner.
• The executive record states the disposition, rationale, exclusions, dissent, safeguards, owner, resources and review gate. Evidence: Executive Workflow Decision and Review Register. Owner: decision owner.

Measurement

• Demand, completion, queue, work-in-progress and outcome counts use reconciled definitions and source periods. Evidence: baseline workpaper. Owner: metric owner.
• First-pass completion, repeat demand, rework, transfer and exception measures are used only where definitions support them. Evidence: measurement contracts. Owner: process analyst.
• Local efficiency is accompanied by end-to-end outcome and transferred-burden evidence. Evidence: outcome and burden measures. Owner: economic owner.
• Thresholds for continue, change, validate, contain, stop or retire are approved before results. Evidence: dated measurement contract. Owner: decision owner.
• Baseline absence is recorded as baseline required and never converted into a saving or outcome claim. Evidence: baseline-gap decision. Owner: finance owner.

Decision and handover

• Every bounded constraint receives one primary diagnostic disposition. Evidence: executive decision row. Owner: authorised forum chair.
• Rejected alternatives, contrary evidence, dissent, accepted exposure and no-action consequence remain visible. Evidence: decision rationale and minutes. Owner: decision owner.
• A handoff to automation explicitly authorises readiness, portfolio or architecture assessment only. Evidence: authority-exclusion statement. Owner: executive sponsor.
• Every next gate names one owner, resource boundary, acceptance evidence, safeguards and stop condition. Evidence: signed handover. Owner: receiving owner.
• Definitions, sources, limitations, control decisions, open issues and review triggers transfer with recipient acceptance. Evidence: handover inventory. Owner: audit lead.

Review, change and stop controls

• Every active disposition has an expiry or material-change trigger and a dated review event. Evidence: lifecycle row. Owner: review owner.
• Demand, policy, control, role, system, supplier and affected-population changes trigger impact review. Evidence: change assessment. Owner: workflow owner.
• New evidence is reconciled against the original claim, population, period, cause and threshold. Evidence: review workpaper. Owner: evidence owner.
• Harm, control failure or unauthorised data use triggers containment and a named human decision. Evidence: incident and stop record. Owner: relevant authority.
• Retired maps, extracts, access, measures and dispositions have recorded closure or retention actions. Evidence: closure register. Owner: review owner.

Topic-specific measurement contract

Measure A: Decision-critical current-state evidence coverage

Measure B: Material root-cause hypothesis resolution

Measure C: End-to-end elapsed outcome performance

Measure D: First-pass usable outcome completion

Measure E: Transferred burden

Measure F: Material workflow guardrail breaches

Evidence classifications used in this guide

• VERIFIED: supported by accepted, traceable evidence for the stated population, period and decision use.
• INFERRED: a reasoned interpretation whose evidence and alternative explanations remain visible.
• PROPOSED: a method, option, threshold or mechanism awaiting organisational acceptance.
• REQUIRES VALIDATION: decision-critical evidence is missing, conflicting, stale or outside its permitted use.

Primary and supporting sources

• ISO: The process approach in ISO 9001: VERIFIED official guidance at the 25 August 2026 source cut-off. It frames activities as interrelated processes and connects objectives, inputs, outputs, sequence, interaction, ownership, risk, monitoring and improvement. This guide uses that logic without claiming ISO certification or conformance.
• ISO 9001 Auditing Practices Group: Guidance on processes: VERIFIED supporting official guidance at source cut-off. It supports examining process effectiveness, interaction, measures and improvement. It is not a substitute for the standard or a formal audit opinion.
• GOV.UK Service Manual: Map and understand a user's whole problem: VERIFIED public-service design guidance at source cut-off. It supports whole-journey mapping across organisational boundaries, including online, offline and back-office work. Organisation-specific application remains PROPOSED until accepted.
• GOV.UK Service Manual: Creating an experience map: VERIFIED public-service research guidance at source cut-off. It supports using several users' evidence and exposing stages, steps, needs, interdependencies and breakdowns. It does not establish commercial prevalence.
• Object Management Group: BPMN 2.0 specification: VERIFIED standards reference at source cut-off. It is a notation source where formal process representation is proportionate; this guide does not require BPMN or treat notation as evidence of actual work.
• Abrasim: AI transformation starts with workflow design: PROPOSED Abrasim framing upgraded by this guide. The article argues that the workflow, not the model, is the useful unit of analysis. Any organisation-specific cause, baseline or opportunity remains REQUIRES VALIDATION.