Practical intelligence for accountable AI programs.
A practical guide to mapping real workflow behaviour, testing approvals, defining handoffs and resolving exceptions before automation begins.
ModelFold Editorial Team9 min read
Redesign the workflow before configuring rules, software, bots or AI. A request that is re-entered, signed without a real decision, left in several queues and returned when evidence is missing will not become sound merely because it moves faster. First map how a recurring case actually travels from an observable trigger to an accepted outcome. Then make its deviations, decisions, transfers and evidence explicit, and give every element one disposition: remove, standardise, clarify or retain for human review. Consequential judgement, delegated authority and required independence stay with an authorised person unless the organisation has a supported basis for changing that control.
Key takeaways
The map must show how one bounded case type moves from a visible trigger to an outcome that a named downstream user can accept. Begin with one recurring case, one start condition and one end condition rather than combining materially different work. Keep the map independent of any proposed platform. 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. This makes actors, decisions and task detail visible before a solution is selected.
Test the drawn path against representative completed cases, recent walkthroughs, procedures, forms, support records, audit findings and event data where available. Procedures describe intended work; records reveal parts of the performed sequence, so neither should automatically overrule the other. Keep touch time separate from elapsed or queue time. A usable event log commonly maps a case identifier, activity and timestamp, but those fields alone do not establish complete coverage, reliable data or the reason a delay occurred.
A deviation is a standard variant when it is legitimate, recurring and sufficiently stable to have defined entry criteria, steps, ownership, evidence and an outcome. Everything else should remain visible as an exception until its cause and safe response are understood. Use five working families: incomplete or invalid input; known business variation; policy or authority exception; capacity, dependency or timing failure; and technical execution failure. BPMN can depict alternate and failure paths, but notation does not decide their operational treatment.
Build an exception register from actual cases rather than a generic escalation box. Record the observable trigger, representative examples, frequency over a stated period when known, consequence, safe response, recovery owner, delegated boundary, evidence required, outcome and durable resolution record. Volume is a diagnostic signal, not a verdict. High counts can reflect unstable inputs, narrow normal paths or genuine variability; low counts can conceal miscoding, email workarounds or other side channels. Investigate the cases before choosing a remedy.
An approval is worth retaining when it makes a distinct, supported decision tied to a real resource, risk, policy or control purpose. Name the decision and its available outcomes: approve, reject, return, condition or escalate. If the person cannot alter the next state, the step may be an acknowledgement, consultation, notification or evidence-production task rather than an approval. Delay alone does not show that a control is unnecessary, just as a familiar signature does not prove that it remains useful.
Record the approver's delegated authority, required competence or independence, evidence available at decision time, criteria or bounded discretion, rationale or conditions, and downstream effect. Compare gates that inspect the same evidence for the same decision and risk, while preserving any separation of duties the organisation requires. Manual, partially automated and automated controls can coexist; the mode alone does not establish effectiveness. If AI is involved, document its role, limits, oversight, risk tolerance and how people are expected to use its outputs.
A handoff is complete when a named receiving owner accepts a sufficiently complete case and can begin the expected next action. Sending an email, forwarding a packet or placing work in a queue proves only that something was sent. For each retained transfer, specify the case identity and state, sending role, receiving owner, required information and attachments, evidence that the previous step is complete, acceptance criteria, next action and a locally appropriate service expectation.
Define what happens when work is incomplete, disputed, timed out or misrouted, then record the accepted transfer in a durable location. Measure elapsed time from ready-for-transfer to accepted ownership separately from touch time. Also watch returns for missing information, ownership changes, the age of unaccepted work, local service breaches, evidenced downstream rework and completion through side channels. A durable record supports examination and recovery, but it does not prove that the underlying decision was correct or that a control was effective.
Give every mapped step or branch exactly one 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 control design and human oversight; no cited authority prescribes them as one method. Apply the tests to the evidence gathered from cases, not to assumptions about what automation should do. Standardisation creates an improvable baseline, not a rule that every case must follow the same path.
Consider an internal request for a new third-party business service. Operations re-enters emailed fields, a manager signs only to acknowledge the request, finance checks the budget, specialists review cases, and a setup team receives the same packet without an acceptance rule. The redesign might remove the status-only signature if it makes no distinct decision, standardise intake and normal routing, clarify exception and transfer ownership, and retain authorised budget, specialist, independent or policy-exception decisions where organisational requirements call for them. Exact controls and delegations remain organisation-specific.
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 value, supplies no required information and mitigates no assessed risk not handled elsewhere. | Remove duplicate entry, a relay that forwards unchanged information or a status-only sign-off. | Confirm purpose, authority, dependencies and control obligations; delay alone is not a reason to remove it. |
| Standardise | Inputs can be complete, rules and permitted outcomes are stable, ambiguity is low and ownership is consistent. | Standardise required intake, duplicate checks, routine validation, classification and normal routing. | Keep the baseline open to review, and do not force materially different cases onto it. |
| Clarify | The element is necessary, but ownership, authority, criteria, evidence, completion, escalation or recovery is ambiguous. | Name the owner of incomplete submissions and define acceptance and timeout behaviour. | Resolve the smallest missing contract or authority instead of using a generic escalation. |
| Retain for human review | A consequential decision needs delegated authority, contextual judgement, expertise, independence or resolution of an unbounded case. | Retain authorised budget, specialist, independent-control or policy-exception decisions when required. | Provide evidence, criteria, possible outcomes and a durable rationale; human presence alone is not an effective control. |
The workflow is ready only when representative cases can pass through the proposed design with clear ownership, evidence, decisions, acceptance conditions and recovery behaviour. Walk routine, incomplete, rejected, boundary, timeout, override, reworked and technical-failure cases against records where available. A current-state diagram is not an implementation-ready specification: implementation also needs permissions, manual-review triggers, safe retry behaviour, duplicate prevention, reconciliation, monitoring and change ownership proportionate to the workflow's assessed risk.
Make a conditional go, revise or stop decision. Document why any control is removed and obtain the organisation's appropriate internal-control review. Assign measures and a review owner so returns, recurring exceptions, overrides, queue growth, defects and side channels trigger investigation after launch rather than one predetermined remedy. Consult qualified and authorised legal, regulatory, financial, security, privacy, safety, procurement, human-resources, internal-control and other professional roles before changing controls or interpreting obligations in their domains. Stop implementation while material policy, delegation, independence, risk-acceptance, evidence or professional-judgement questions remain unresolved.
Bound one recurring case from an observable trigger to an accepted outcome, then map the work using representative cases and operational records. Examine normal paths, variants, exceptions, approvals, handoffs and delays. Assign every mapped element one disposition: remove, standardise, clarify or retain for human review.
Include the observable trigger, representative cases, period-specific frequency when known, consequence and safe response. Name the recovery owner, delegated boundary, evidence required, outcome and durable resolution record. Also note whether recurrence points to an input, rule, capacity, policy, normal-path or system issue.
Identify its distinct decision, control purpose, authority, required competence or independence, evidence, outcomes and downstream effect. Compare it with retained controls addressing the same decision and risk. Remove it only after confirming that doing so will not discard necessary value, information or an assessed control.
Specify the case identity and state, sender, receiving owner, required information, attachments and completion evidence. Add acceptance criteria, the expected next action, a locally chosen service expectation and routes for incomplete or unaccepted work. Record the accepted transfer durably.
It is ready when representative normal and abnormal cases have clear owners, bounded exceptions, purposeful approvals, accepted handoffs, proportionate controls, recovery design and monitoring. The implementation detail must also cover permissions, retries, duplicate prevention, reconciliation and change ownership. Stop if material accountability, evidence or professional-judgement questions 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 method for observing real workflows, testing reported bottlenecks and framing evidence-backed AI opportunities without mistaking complaints for proof.
A practical, technology-neutral guide to designing a traceable IDP pipeline from secure intake and validation through review, delivery and retention.
A practical Australian guide to mapping tasks, testing AI assistance, tracking hidden effort and redesigning roles only after a measured pilot.
