Practical intelligence for accountable AI programmes.
A practical method for mapping real workflows, testing controls, defining handoffs and resolving ambiguity before automation begins.
ModelFold Editorial Team9 min read
Before automating a recurring workflow, bound one case type and map how it actually reaches an accepted outcome. Inspect routine and abnormal cases, then record each step's purpose, owner, input, decision, output, evidence, delay and next acceptance condition. Classify deviations, test whether approvals make real decisions, and turn every retained handoff into an explicit transfer. Finally, give each mapped element one disposition: remove, standardise, clarify or retain for human review. This prevents software from merely accelerating re-entry, vague queues, ornamental signatures and missing evidence.
What to settle before implementation
The map must show how one recurring case moves from an observable trigger to an accepted outcome, without assuming a particular platform or automation approach. Name the downstream user and keep the initial boundary narrow. For every step, capture its purpose, performing role, input and source, rule or action, output, system or channel, completion evidence, next owner and acceptance condition. Solution-agnostic documentation makes actors, decisions and task detail visible before a solution is chosen; current-state evidence should come before future-state design.
Treat each source as a different lens. A procedure describes intended work; a completed case shows what was recorded; observation and walkthroughs expose the choices and side channels that records may omit. Value-stream mapping distinguishes lead time from cycle time, a useful distinction when adapting flow analysis to services. Timestamps can establish sequence and elapsed time, but they cannot by themselves explain why work waited. Record the suspected cause separately and test it against case evidence rather than presenting it as fact.
A standard variant is a legitimate recurring route with stable entry criteria, steps, ownership, evidence and outcome; a genuine exception cannot yet be handled safely by such a bounded branch. Frequency alone does not make that distinction. Use five working families to replace the catch-all exception queue: incomplete or invalid input; known business variation; policy or authority exception; capacity, dependency or timing failure; and technical execution failure. BPMN can make alternate and failure paths visible, but notation does not decide their business treatment.
Move a known variation onto a standard branch only after its contract is stable, then treat that branch as an improvable baseline rather than a permanent rule. Keep authority or policy exceptions with an authorised decision-maker. For technical failures, define duplicate prevention, safe retry, reconciliation, recovery authority and a stop condition before implementation. High or low exception counts are diagnostic signals, not verdicts: unstable inputs, hidden workarounds, miscoding, narrow normal paths and genuinely variable work can produce misleadingly similar figures.
An approval is worth retaining when it makes a distinct, supported decision within delegated authority and changes what the workflow may do next. Name the available outcomes: approve, reject, return, condition or escalate. If the person cannot alter the next state, the activity may instead be acknowledgement, consultation, notification or evidence production. Record the risk, policy, resource or control purpose, because delay or a duplicate-looking box is not sufficient evidence that a control is unnecessary.
Control activities should reflect objectives, assessed risks, operating conditions, complexity and data sensitivity rather than a blanket preference for people or software. Manual, partially automated and automated controls can coexist, including human authorisation prompted by a system flag; automation alone does not demonstrate effectiveness. Where AI is proposed, document its task context, limits, risk tolerance, oversight responsibilities and how people will use its outputs. Retain human review only where authority, expertise, independence, contextual judgement or material uncertainty gives it a real purpose.
A handoff is complete when a named receiving owner accepts an identifiable case with enough information and evidence to begin the expected next action. Sending an email, forwarding a packet or placing work in a queue proves only dispatch. For each retained transfer, specify the case and current state, sending role, receiving owner, required information and attachments, evidence of prior completion, acceptance criteria, next action and a locally appropriate service expectation. BPMN can distinguish participants and message flows, but acceptance requires an operating contract.
A durable transfer record makes responsibility and significant events available for examination, yet it does not prove that the underlying decision was correct or the control effective. Use the record to reconstruct what happened and identify where evidence or ownership failed. Avoid attributing downstream rework to a handoff unless linked case evidence supports that conclusion. The useful design question is whether the receiver could recognise a complete case, accept responsibility and act without searching inboxes or asking the sender to reconstruct missing context.
Every mapped element should receive exactly one evidence-based disposition: remove, standardise, clarify or retain for human review. These four labels are an editorial synthesis of whole-flow improvement, standardised work, explicit governance, risk-based controls and human oversight; no cited authority prescribes the combined method. Apply the tests to steps, branches, approvals and handoffs alike. A disposition is a design decision with a recorded reason, not shorthand for whether the element will eventually be performed by a person or a system.
Do not automate an inherited diagram; redesign the decisions, evidence, exceptions and ownership that make the workflow real.
| Disposition | Use when | Illustrative application | Required caution |
|---|---|---|---|
| Remove | The element makes no distinct decision, creates no necessary operational value, supplies no required information and mitigates no assessed risk not addressed elsewhere. | Eliminate duplicate entry, a relay that forwards unchanged information or a status-only signature. | Delay alone does not justify removal; confirm purpose, dependencies and control requirements. |
| Standardise | Inputs can be complete, rules and permitted outcomes are stable, ambiguity is low and a consistent owner or system can apply them. | Define required intake, duplicate checks, classifications, evidence checks and routine routing. | A baseline supports consistency and improvement; it does not prove every case belongs on the standard path. |
| Clarify | The element is necessary but ownership, authority, criteria, evidence, completion, escalation or recovery remains ambiguous. | Name an exception owner, define accepted transfer or specify what follows a timeout or rejection. | Resolve the smallest missing contract instead of encoding a generic escalation. |
| Retain for human review | A consequential decision requires delegated authority, contextual judgement, qualified expertise, required independence or resolution of an unbounded case. | Preserve authorised budget, specialist, independent-control or policy-exception decisions when organisational requirements call for them. | Require adequate evidence, criteria, available outcomes and a recorded rationale; human presence alone is not an effective control. |
Consider an internal request for a new third-party business service. Standardise the intake, case identity, duplicate check, sponsor, service category, required evidence and normal routing. Remove a manager's status-only signature if it makes no resource, authority or risk decision and no obligation requires it. Clarify ownership of incomplete submissions, known exceptions, rejection, timeouts, technical recovery and acceptance by the setup team. Retain budget authority and any specialist, independent or policy-exception review triggered by the organisation's requirements. Exact controls and delegations remain organisation-specific.
The workflow is ready only when representative cases can pass through a sufficiently detailed design with named ownership, explicit evidence, purposeful controls, accepted handoffs and safe recovery behaviour. A documentation-oriented process diagram may remain non-executable; implementation needs additional formal detail. Walk routine, incomplete, rejected, boundary, timeout, override, reworked and technical-failure cases against records where available. Choose go, revise or stop from the results rather than declaring readiness because the normal route appears tidy.
Control design, authorisation, documentation, segregation and the preventive-detective balance must respond to the organisation's objectives and assessed risks. If AI is included, context, responsibilities, system limits, oversight and risk tolerance must inform the deployment decision. Consult qualified and authorised legal, regulatory, financial, security, privacy, safety, procurement, human-resources, internal-control and other professional roles before changing a control or interpreting an obligation in their domain. Stop implementation when material questions about policy, delegation, independence, risk acceptance, evidence or professional judgement remain unresolved.
Bound one recurring case type from an observable trigger to an accepted outcome, then compare the documented procedure with representative records and walkthroughs. Map normal and abnormal routes, including owners, evidence, decisions, waiting and acceptance. Assign every element one disposition: remove, standardise, clarify or retain for human review.
Record the observable trigger, representative examples, period-specific frequency when known, consequence and safe response. Add the recovery or decision owner, delegated boundary, evidence needed, recorded resolution and likely source of recurrence. Keep known stable variants separate from genuinely unresolved exceptions.
Test the approval's distinct decision, control purpose, authority, competence or independence, evidence, possible outcomes and downstream effect. Compare it with retained controls addressing the same evidence, decision and risk. Do not remove it merely because it delays work or looks repetitive on a diagram.
Include the case identity and state, sender, receiving owner, required information, attachments and evidence of prior completion. Define acceptance criteria, the next action, a locally chosen service expectation and routes for incomplete, disputed, timed-out or misrouted work. Record accepted ownership durably.
It is ready when representative normal and abnormal cases can pass through a detailed design with named owners, bounded exceptions, purposeful approvals, accepted handoffs, preserved controls, recovery routes and monitoring. Revise the design when tests expose gaps. Stop when material questions about policy, delegation, evidence, independence, risk acceptance or professional judgement remain unresolved.
This article was researched using the following sources:
We report on how AI actually lands inside a business. Our work starts from named sources, separates what we found from what we think, and uses AI assistance for research and drafting under documented editorial controls. We are not a substitute for individual expert review.
A practical field-research method for testing workflow complaints against real cases before choosing an AI experiment or a simpler operational change.
A practical, technology-neutral framework for controlling document intake, extraction, review, delivery and retention through explicit stage contracts.
A practical method for mapping tasks, testing AI assistance, tracing redistributed effort and redesigning roles only when ownership and workload are clear.
