Rajesh Mahapatra · Applied AI strategyProcess reinvention and automation

Zero-Based Workflow Design

A first-principles method for building AI-enabled work from required outcomes, obligations and recovery rather than automating the sequence an organisation inherited.

TLDR

  1. Design the obligation-bearing service episode that must work for an affected party, not the current task list with model icons attached.
  2. Quarantine inherited approvals, roles, systems, controls and workarounds until each proves the present obligation it serves.
  3. Every proposed step must create a verifiable state, carry a necessary service or control, and expose its authority, downstream burden and removal trigger.
  4. Generate at least three coherent workflows that allocate human, deterministic, model and agent capability differently, then test them against the same cases and obligations.
  5. Choose the smallest reversible commitment supported by end-to-end evidence, while treating transition, degraded service and recovery as designed work.

The current process, now with an assistant in every box

A team redraws customer onboarding. Beside identity review it adds a model. Beside risk assessment it adds another. A planning agent chases approvals; a drafting assistant writes the same reports; an orchestration layer pushes cases across the same departmental boundaries. The demonstration moves quickly, yet customers still provide the same evidence three times and wait for committees whose control purpose nobody can name.

The workflow has been accelerated without being redesigned. Its inherited sequence determined the architecture before outcomes, obligations and authority were reconsidered. Zero-based workflow design starts from a different unit: one service episode whose required outcome can be proved for the user, business, worker and affected population. Every step, old or new, must earn a place in that future system.

Research Essays

Zero-Based Workflow Design

Rajesh Ranjan Mahapatra

A first-principles method for designing AI-enabled workflows from outcomes, obligations and recovery rather than decorating inherited steps.

© 2026 Rajesh Ranjan Mahapatra. 21 min read

Zero-Based Workflow DesignAll Research Essays

01 · The clean design fieldJustify the future without forgetting the past

Zero-based design is not historical amnesia. It removes inheritance as an entitlement while preserving current work as evidence about obligations, risks and hard-won adaptation.

Begin with the problem, intended outcome, affected parties and proof of completion. Add the service, legal, policy, accessibility, explanation, appeal, remedy and continuity obligations that must hold. Define the case population, consequences and non-action cost. Only then allow current activities, organisation structures, vendors or models into view.

This order matters because present steps bundle several purposes. An approval may carry a control objective, scarce authority, political reassurance or no current value. A conversation may look slow while delivering consent, trust and professional judgement. A duplicated form may be pure artefact. Starting from boxes treats these functions alike and invites local automation. Starting from obligations permits the control to move, the relational service to remain and the duplicate request to disappear.

Inherited workflow folding into quarantine An inherited process with model icons folds into a quarantine area while outcome and obligation anchors remain on a clean design field. Decorated inheritance leaves; obligations stay INHERITED PROCESS + MODEL ICONS check + AI assistant approve + AI assistant report + AI assistant INHERITANCE QUARANTINE approval · team · form · system queue · workaround · control retain only after justification PROVABLE OUTCOME IRREDUCIBLE OBLIGATION
Figure 1. This article’s starting move. Inherited work becomes evidence in quarantine; outcome and obligation anchor the design field.

Thought experiment: delete every label

Take the current process map and remove activity names, department labels and system brands. Retain only the state entering each step, the state leaving it, the obligation served and the consequence of failure. Some boxes become essential: a consent decision, a segregation control, an explanation to the affected person. Others become empty rectangles that move information without changing it. The exercise reveals how much apparent necessity came from familiarity.

The negative control

Draft a no-AI future workflow with the same obligation contract and test population. Give it clean data, explicit authority, event-driven integration and adequate operational attention. If it meets the outcome, the comparison shows that AI was not necessary. If a bounded interpretation or coordination problem remains, a model or agent can be tested against a serious baseline rather than a neglected current process.

Zero-based rule. No current step is entitled to survive, and no new step is entitled to exist, until it names the service or control it provides, the state it changes and the evidence that will prove it earns its place.

02 · Zero-Based Workflow ArchitectureNine layers carry an obligation-bearing episode

The architecture moves from purpose to lifecycle. It prevents capability allocation from preceding the service definition.

Purpose and affected party define the problem and intended value. Irreducible obligations capture what must remain true. The case population introduces triggers, variants, novelty, volume and consequence. Decisions and authority identify criteria, discretion, accountability and action rights. Evidence and state specify authoritative sources, provenance, freshness and verifiable transitions.

Only the sixth layer allocates work across people, deterministic logic, conventional software, models and agents. Flow and capacity place sequence, parallelism, queues and exceptions. Outcome and learning test service, safety, burden, cost and distribution. Transition and lifecycle handle coexistence, fallback, training, monitoring, retirement and reauthorisation without treating rollout mechanics as permanent workflow design.

Nine-layer Zero-Based Workflow Architecture A service episode travels through nine differently shaped stations from purpose and obligation to case, decision, evidence, allocation, flow, outcome and lifecycle. An obligation-bearing service episode crosses nine design layers 1 · purpose + party 2 · IRREDUCIBLE obligations 3 · case population 4 · decision + authority 5 · evidence + state 6 · work allocation 7 · flow + capacity 8 · OUTCOME + learning 9 · lifecycle + transition operating evidence loops back into purpose, obligations and cases
Figure 2. This article’s architecture. Work allocation is downstream of obligation, authority and evidence, not the opening design choice.

The Zero-Based Workflow Charter

The charter names the service episode, sponsor, affected populations, evidence that inheritance should be challenged, authorised constraints, case tiers and design horizon. It lists available capabilities without preferring one. It sets criteria for outcome, control, resilience, workload, cost and distribution; requires at least three coherent workflow concepts; defines representative trials and thresholds; includes worker and affected-party participation; and records transition boundaries, reversibility, expiry and reauthorisation. It expressly prohibits beginning from a vendor, model, organisation chart or current sequence.

Design the population before designing the route

A single future workflow rarely suits every case. Separate ordinary, consequential, exceptional and novel episodes before drawing flow. Include volume, peak arrival, seasonality, accessibility, language, evidence quality and the cost of delayed resolution. A case can move between tiers when new evidence changes consequence. That movement needs a visible rule, an accountable actor and a route back. Without population design, a simple ordinary path becomes the architecture for cases it was never built to carry.

Termination also deserves design. Administrative completion is not enough when another team must accept the state, a customer must understand the decision or a payment must reconcile. Define the closure receipt for each material population. This exposes steps that produce documents without completing service and prevents a fast front end from exporting unfinished work to operations, customers or appeals.

03 · Irreducible Outcome and Obligation ContractPreserve the service, not its historical carrier

An obligation can survive while the meeting, form, approval or system that currently carries it disappears.

The contract begins with the outcome and proof of completion. It then covers seven obligation families: service; consequential decision; evidence; control; people; continuity; and value. Each item is labelled mandated, necessary for the claimed outcome, deliberately optional or an inherited assumption to test. This classification prevents two opposite errors: discarding essential work in the name of speed and retaining empty ceremony in the name of safety.

Irreducible Outcome and Obligation Contract Seven obligation arcs for service, decision, evidence, control, people, continuity and value surround an affected party and a provable outcome. The affected party sits inside every obligation test AFFECTED PARTY PROVABLE OUTCOME completion · consequence SERVICE DECISION EVIDENCE CONTROL PEOPLE CONTINUITY VALUE
Figure 3. This article’s contract. Accessibility, remedy, dignity and recovery belong to the design core rather than an exception appendix.
Obligation Affected party Current carrier Future treatment Required evidence Authority Failure consequence
Outcome completion Applicant Administrative closure code Prove accepted service or explained refusal Downstream receipt and reason Service owner False completion
Accessibility People needing supported channels Specialist manual route Retain service while redesigning entry Journey and outcome by channel Accessibility owner Exclusion or excess burden
Decision Customer and business Three sequential approvals One authorised decision at evidence point Criteria, delegation and cases Accountable officer Unowned consequence
Evidence Reviewer and affected person Repeated document packs Request once, preserve provenance Freshness and lawful reuse Data owner Unsupported action
Control Business and public End-of-process checklist Prevent at the state transition Control objective and independent signal Risk owner Undetected prohibited state
Professional relationship Patient or vulnerable customer Human consultation Preserve judgement and consent service User, clinical and workforce evidence Professional owner Loss of trust or unsafe decision
Continuity All active cases Experienced workers’ workaround Formal degraded route and recovery Exercised fallback and reconciliation Operations owner Service abandonment
Value Sponsor, worker and user Local time-saving target End-to-end benefit and burden ledger Capacity capture, cost and distribution Investment owner Transferred cost

The clinical consultation that earns its place

A clinical pathway can use AI to assemble evidence, identify missing results and prepare competing questions. The human consultation remains because consent, relationship, contextual interpretation and professional judgement are irreducible services. Retention is not nostalgia. The step names its obligation, authority and outcome, while the redesigned surrounding work gives the clinician better evidence and protects time for the service only the consultation can provide.

04 · Inheritance QuarantineMake every artefact apply for readmission

Quarantine current activities, approvals, roles, reports, systems, controls, handoffs, batches, workarounds and tacit skills. None crosses into the future merely because it exists.

For each artefact, identify the obligation or outcome it currently serves, evidence that it works, and the cost or harm it creates. Then decide whether the function can be removed, reassigned, combined, redesigned or retained. “Unresolved” is preferable to a false assumption, provided it has an owner and expiry.

Inheritance Quarantine sorter Approvals, reports, systems, controls, handoffs and shadow tools enter a sorter and travel to retain, redesign, combine, remove or unresolved treatments. Inherited artefacts are evidence, not default architecture approvals reports systems controls handoffs shadow tools OBLIGATION? EVIDENCE? COST OR HARM? owner · expiry RETAIN REDESIGN COMBINE REMOVE UNRESOLVED
Figure 4. This article’s quarantine. The treatment follows the function and evidence, not the age or visibility of the artefact.
Artefact Claimed purpose Evidence Cost or harm Treatment Owner
Second invoice approval Reduce improper payment No distinct risk detection in sampled cases Queue and duplicate review Remove after risk acceptance Finance control owner
Segregation check Prevent self-approval Control incidents and audit objective Occurs late Redesign at state transition Risk owner
Customer evidence form Collect facts Most fields already authoritative Repeated effort and error Combine into authorised state reuse Service and data owners
Clinical conversation Consent and professional judgement Patient, safety and professional evidence Capacity pressure Retain; remove surrounding administration Clinical owner
Departmental handoff Move work to expertise Expertise is necessary, boundary is not Context reconstruction Redesign specialist participation End-to-end owner
Shadow spreadsheet Track missing workflow state Operators rely on it during recovery Duplicate truth and weak control Unresolved until state service is proven Product owner

The three invoice approvals

Two approvals trace back to managers who no longer hold distinct risk authority. They add no unique evidence and disappear. The third protects segregation of duties. Its objective survives, but the step moves into a permission check at the payment state transition, with an independent record and exception route. The new flow has fewer approvals because obsolete work was removed and a necessary control was placed closer to the risk.

05 · Step Justification TestMake each activity prove its state change

A proposed step must serve an irreducible obligation, consume a known input state, create a verifiable output state and have a named decision consumer.

Classify it as work, wait, handoff, decision, control, explanation, relationship or recovery. Ask whether removing the cause would eliminate the step. Test combination, reordering, parallel execution and movement to the point where evidence first exists. Allocate human, deterministic, model or agent capability only after purpose and state are clear. Record authority, consequence, exception, appeal, downstream burden and a removal trigger.

Step Justification Test A proposed activity passes through obligation, state change, allocation, authority, downstream effect and removal gates, with failed steps dropping out. A step earns a place by passing six gates obligation served? state changed? actor justified? authority bounded? downstream effect? removal trigger? REMOVE, REFRAME OR RETURN TO THE DESIGN FIELD a failed gate is evidence, not a request for decoration
Figure 5. This article’s test. Capability enters after the state and obligation, while a removal condition prevents permanent accumulation.
Proposed step Input state Output state Obligation Actor Authority Downstream effect Removal trigger
Reuse verified identity Current verified state with provenance Identity accepted for ordinary action Low-burden secure access Deterministic policy service No consequential action Removes repeated checks Freshness or risk condition changes
Step-up identity check Consequential request Strong authentication evidence Prevent unauthorised action Person plus secure service Bound to action tier Adds necessary friction Equivalent control proven
Assemble clinical evidence Authorised records Cited review packet Complete information Retrieval and bounded model No diagnosis Preserves consultation time Records become directly usable
Professional consultation Evidence and patient context Consented accountable decision Judgement and relationship Clinician Professional accountability Creates care plan Obligation genuinely changes
Onboarding chase loop Pending approvals Messages and escalations Coordination Proposed agent Unclear More noise across teams Event-driven ownership removes cause
Payment action Approved payable state Recorded external transaction Execute obligation Deterministic software Explicit permission and limit Irreversible side effect Action route changes

Control from objective, not from inherited activity

State the risk and control objective without naming today’s checklist or meeting. Ask whether the future workflow removes, changes or preserves the risk. Place prevention near the relevant decision or state transition, make detection independent where needed, and define correction, appeal, remedy and recovery. Compare residual risk and evidence quality, not control step counts. Material change still requires authorised risk acceptance.

06 · Workflow Design SpaceGenerate competing systems, not isolated options

A clean sheet should produce at least three coherent workflows with different causal bets, work allocation and recovery, not one favourite surrounded by cosmetic variants.

Explore trigger, orientation, authority, information, flow, allocation, action timing, exception separation, ownership and reversibility as linked dimensions. A design can be event-driven, object-oriented, distributed, information-once, parallel and deterministic-first. Another can be request-driven, case-oriented, human-led and model-assisted. A bounded agent design can coordinate uncertain multi-step work while consequential decisions remain separately authorised.

Workflow Design Space with three coherent futures Three distinct future workflows show a deterministic event-driven flow, a human-led evidence flow and a bounded agent coordination loop. Three designs make three different causal claims A · EVENT-DRIVEN, DETERMINISTIC-FIRST reuse state apply rule execute B · HUMAN-LED, EVIDENCE-ASSEMBLED assemble consult decide C · BOUNDED AGENT COORDINATION observe · plan · tool · checkpoint AUTHORISED HUMAN consequential decision
Figure 6. This article’s design space. Each concept is an operating hypothesis with its own authority and failure boundary.

Onboarding without a planning loop

A team expects an agent to chase equipment, access and approvals. Zero-based design reveals that most coordination exists because triggers are late and ownership is implicit. One event-driven integration starts eligible actions, explicit owners receive exceptions and a simple state service exposes progress. A bounded assistant may answer new-starter questions, but an agentic planning loop does not earn a role. Removing coordination demand outperforms automating the chase.

Coordination is a cost with several causes

Coordination work can arise from genuine interdependence, but it can also be manufactured by missing state, fragmented authority, departmental targets or incompatible schedules. Treating all of it as a planning problem encourages an agent to absorb ambiguity that the organisation should resolve. For each message, chase and status meeting, identify the dependency being managed. Remove the contact when a trusted event can carry state; retain human negotiation when interests or professional judgements genuinely conflict.

Capacity must be tested at the receiving boundary. Parallelising evidence checks may shorten the apparent middle of a case while sending a burst into a scarce specialist queue. Likewise, a model that drafts decisions quickly can increase verification and appeal load. Candidate designs should expose arrival variability, active time, waiting, work in progress and downstream absorption under the same demand trace. The end-to-end episode, not the busiest component, decides whether flow improved.

07 · Joint Work Allocation ContractDesign the social and technical system together

Allocate acquisition, analysis, generation, judgement, action, coordination and recovery separately, with the evidence and authority each actor needs.

For each primitive and case population, name the person, rule, software, model or agent assigned. Record available context, output, permitted use, receiving actor, decision right, execution authority, review, challenge, abstention, escalation, latency, reliability, cost and recovery. Include skill, workload, dignity and learning effects. Human oversight is not a residual box. It is a specific service with capacity and evidence.

A dangerous allocation removes ordinary cases from experts and leaves them only rare, difficult exceptions. Their workload becomes cognitively extreme while experience needed for recovery decays. A viable design preserves representative practice, simulation and exercised fallback. Models can assemble evidence and challenge assumptions; rules can enforce exact limits; people can hold relational and consequential judgement; agents can coordinate only within permissions and checkpoints that the recovery system can support.

Credit assessment as joint work

A bank separates evidence acquisition, ratio calculation, policy comparison, judgement and approval. Deterministic services calculate ratios and test explicit covenants. Controlled retrieval provides current policy. A model assembles cited evidence and drafts competing rationales. A trained analyst exercises judgement and an authorised officer approves consequential cases. Every component receives only the context and authority its primitive requires. This is not a single intelligent flow. It is a jointly designed decision system.

08 · Competing Workflow TrialMake every design answer the same obligation contract

Compare ordinary, peak, rare, accessibility, adversarial, incident and recovery cases under common outcomes and adequate support.

A trial is unfair when the preferred prototype receives clean data, expert attention and fresh interfaces while the baseline remains neglected. Fund each candidate enough to test its governing hypothesis. Separate temporary implementation friction from persistent design load. Measure service, quality, safety, error, delay, rework, user burden, worker load, cost, value, distribution, downstream absorption and recovery.

Competing Workflow Trial Three workflow designs run across ordinary, peak, rare, accessibility, adversarial and recovery cases under a shared obligation beam. Common obligations make unlike workflows comparable SAME OUTCOME · CONTROL · ACCESSIBILITY · REMEDY · CONTINUITY ordinary peak rare accessibility adversarial recovery A B C PRE-COMMITTED: PROCEED · REPAIR · NARROW · REVERSE · STOP choose the smallest reversible commitment supported by end-to-end evidence
Figure 7. This article’s trial protocol. Clean cases cannot prove peak, accessibility, adversarial or recovery behaviour.
Design Governing assumption Human-model allocation Controls Peak and recovery Outcome Burden and cost Reversibility
A · Deterministic-first Most cases follow explicit stable rules Software handles ordinary; specialists own exceptions Exact tests, permission gates, independent audit Queue grows predictably; manual route exercised Strong on stable cases Low review, moderate rule maintenance High through modular services
B · Human-led augmentation Judgement and relationship remain central Model assembles evidence; person decides Citations, challenge, delegated authority Human capacity limits peak; evidence aid survives degradation Strong on consequential variation Review remains material High if record and decision stay portable
C · Bounded agent Adaptive multi-step coordination adds value Agent plans and uses tools; people approve consequence Least privilege, checkpoints, budgets, rollback Orchestration tested under tool failure Strong only if recovery holds Higher monitoring and integration cost Medium, dependent on state portability
D · No-change baseline Transition may cost more than redesign benefits Current allocation with funded repairs Existing objectives verified Known fallback and capacity Credible counterfactual Includes current rework and harm Not applicable, but dependencies recorded

The strongest rival: blank sheets can erase reality

Radical redesign can be hubristic. Current processes contain regulatory interpretation, local coordination and resilience that designers cannot see. A clean-sheet target can disrupt service, deskill workers and become brittle. Incremental improvement may deliver value faster, and generating alternatives consumes scarce operational attention.

The answer is zero-based justification, not historical amnesia. Quarantine steps while preserving evidence about the obligations they carry. Include operators, affected parties, control owners and downstream teams. Retain a proven activity when it passes the test. Reach the justified target through reversible trials and incremental transition. Zero-based describes the logic of the future system, not the recklessness of its rollout.

Explicit failure boundary. Stop when the service episode, outcome, affected population or authoritative obligations are unstable; when consequential decisions lack an accountable owner; when no candidate preserves accessibility, appeal, continuity or recovery; when alternatives cannot be tested on common cases; or when transition can create an uncontrolled period of service or control failure.

09 · Ten named casesDifferent obligations produce different futures

The cases test retention, removal, deterministic redesign, bounded augmentation, agentic orchestration and refusal.

1 · Credit assessment rebuilt

Evidence, calculation, policy comparison, judgement and approval receive separate actors and permissions.

Decision: build from first-principles obligations with deterministic calculations and bounded drafting.

2 · Reusable customer identity

Ordinary actions reuse fresh authorised state; consequential actions retain a step-up check.

Decision: remove repeated checks while preserving the control-bearing step.

3 · Three invoice approvals

Two approvals have no current risk objective; segregation still matters.

Decision: remove two steps and relocate one control to the state transition.

4 · Clinical consultation

Relationship, consent and professional judgement remain irreducible while AI prepares evidence.

Decision: preserve the proven human step and redesign its administrative surround.

5 · Event-driven onboarding

Clear triggers, integrations and ownership remove most coordination demand.

Decision: choose deterministic redesign, not a planning agent.

6 · Fraud design trial

Human-led, deterministic-first and bounded-agent concepts face ordinary, peak, adversarial and recovery cases.

Decision: prototype competing workflows before binding architecture.

7 · Multilingual benefit service

Every design must carry language access, explanation, contestability and remedy.

Decision: reject any digital flow that adds these obligations after selection.

8 · Expert recovery skill

Removing easy work leaves specialists with rare cases and little practice.

Decision: preserve representative cases, simulation and exercised fallback.

9 · Mined common path

The current log highlights departmental handoffs but barely captures a vital exception service.

Decision: quarantine the common sequence, retain the proven exception obligation and generate new flows.

10 · Small-business workshop

A one-page obligation contract and three paper prototypes precede a reversible trial.

Decision: use proportionate first-principles design without a transformation programme.

10 · Zero-Based Workflow DesignerDecide what earns a place in the future service

Set the governing conditions or load a scenario. The result is a design route, not an automation score.

Zero-Based Workflow Designer Outcome, obligations, inheritance, work allocation and alternatives enter a clean design field that routes to build, preserve, remove, prototype or stop. Five routes hold old and new work to the same standard outcome proof irreducible obligation inheritance evidence work allocation CLEAN DESIGN FIELD alternatives · trial owners · recovery BUILD FROM OBLIGATIONS PRESERVE PROVEN STEP REMOVE INHERITED WORK PROTOTYPE ALTERNATIVES STOP
Figure 8. This article’s live instrument. Every route preserves the outcome contract while changing what is authorised next.

Build a new workflow from first-principles obligations

Outcome contractProve completion for the affected party.
ObligationsCarry service, decision, evidence, control, people, continuity and value.
Quarantined assumptionsCurrent sequence and roles receive no default status.
Case populationInclude ordinary, peak, rare, accessibility, incident and recovery cases.
Justified stepsRequire obligation, state change, authority and removal trigger.
Work allocationSeparate person, rule, software, model and agent roles.
Authority and controlsPlace permissions and control evidence at the relevant transition.
Design dimensionsChoose trigger, orientation, flow, ownership and reversibility coherently.
AlternativesRetain at least three designs and a no-change baseline.
ExperimentUse common obligations, cases and pre-committed thresholds.
Affected-party routePreserve accessibility, explanation, contestability and remedy.
Responsible ownersName service, decision, data, risk, workforce and assurance owners.
TransitionSeparate target design from coexistence and rollout work.
ReversalKeep state, skills and fallback sufficient to return safely.
ReauthorisationReopen for changed outcome, obligation, authority, model or recovery.

What the instrument can and cannot authorise

The result authorises a design activity: build, preserve, remove, prototype or stop. It does not select a vendor, predict benefit or declare the current process retired. Use it after completing the charter and obligation contract. Exercise the negative cases, record the governing assumption and move only to the smallest reversible commitment. An output becomes stale when the case population, authority, capability, law, workforce or recovery condition changes.

11 · Zero-Based Workflow DocketChoose a future, then design the path to it

The docket makes the target workflow, evidence and transition separate decisions so that a clean design does not justify a reckless cutover.

Record the charter, outcome contract, quarantine decisions, case population, authority, evidence states, competing concepts, step tests, joint allocation, trial results, rivals, workforce evidence, unit economics and residual risk. Name the selected design’s limits. Then specify coexistence, fallback, training, capacity, retirement preconditions, monitoring, expiry and reauthorisation. Transition work may be temporary; recovery work remains part of the service.

Apply the Workflow Reauthorisation Rule when the outcome, obligation, population, consequence, evidence, authority, control, model, workflow, volume, staffing, skill, vendor, cost, law, affected population or recovery condition changes materially. Reopen after shadow work, transferred queues, appeal failure, control weakness, worker burden, affected-party harm or divergence between local performance and end-to-end outcome.

Transition is a second workflow

Moving towards the chosen design creates temporary states that the target diagram does not show. Old and new evidence may coexist, workers may serve two routes and customers may cross versions during one episode. Give transition its own case identity, reconciliation rules, capacity plan and decision rights. State which route governs when records conflict and which external actions cannot be repeated. A clean target does not excuse an ambiguous journey towards it.

Close the transition only when the new workflow can carry its full population, obligations and degraded modes, and when stranded work has an owner. Retirement is a later operational decision, not an aesthetic consequence of selecting the new design. If trial evidence weakens, narrow the population or reverse while state and skills are still recoverable. Reversibility is most valuable before confidence hardens into dependency.

Transition evidence should distinguish learning cost from enduring work. Early cases may require dual entry, close supervision and manual reconciliation while interfaces and roles settle. Those temporary demands should not condemn a sound target. Equally, teams should not dismiss recurring verification, exception reconstruction or customer repair as teething trouble when the design itself creates them. Tag each burden with an expected expiry, owner and observation that would show it has become structural.

The same discipline applies to benefits. Released minutes have no value until capacity is removed, redeployed or converted into a better outcome. Faster decisions do not help when the next team cannot absorb arrivals. Record where benefit appears, who can capture it and which population might bear a shifted cost. This turns transition from optimistic scheduling into an evidence-bearing bridge between two operating systems.

A second thought experiment: the shortest workflow loses

Three candidates handle the same benefit request. The shortest automates evidence interpretation and closes in one pass, but offers weak explanation and no credible recovery when records conflict. The longest asks twice for the same document. The middle design reuses authoritative evidence, keeps a bounded human decision for consequential cases and provides an appeal route. Step count alone chooses the first. The obligation contract chooses the middle because service completion includes explanation, remedy and resilience.

Let every step earn its service

Zero-based workflow design changes the question from “Where can AI accelerate this map?” to “What system can prove the required outcome under ordinary, difficult and degraded conditions?” The current process supplies evidence, not entitlement. Technology supplies options, not purpose. Human work is retained where it carries judgement, relationship or authority, not as a ceremonial loop.

The final rule is demanding and practical: justify the obligation before the step, the state before the actor, the authority before the action and the recovery before commitment. That order creates workflows capable of using AI without becoming organised around it.

Evidence baseSources and foundations

These sources ground the synthesis in current governance, service design, process redesign, sociotechnical systems, automation allocation and implementation research.

  1. NIST AI Risk Management Framework 1.0 Core.
  2. UK Government, Artificial Intelligence Playbook for the UK Government.
  3. UK Government Service Manual, Solve a Whole Problem for Users.
  4. UK Government Service Manual, Map and Understand a User’s Whole Problem.
  5. US Government Accountability Office, Artificial Intelligence Accountability Framework.
  6. European Union, Regulation (EU) 2024/1689.
  7. Dumas, La Rosa, Mendling and Reijers, Fundamentals of Business Process Management.
  8. Hammer, Reengineering Work: Don’t Automate, Obliterate.
  9. Davenport and Short, The New Industrial Engineering.
  10. Limam Mansar and Reijers, Best Practices in Business Process Redesign.
  11. Gross and colleagues, The Business Process Design Space.
  12. van der Aalst, Process Mining: Data Science in Action.
  13. Goodhue and Thompson, Task-Technology Fit and Individual Performance.
  14. Parasuraman, Sheridan and Wickens, A Model for Types and Levels of Human Interaction with Automation.
  15. Trist and Bamforth, Some Social and Psychological Consequences of the Longwall Method of Coal-Getting.
  16. Goh, Gao and Agarwal, Evolving Work Routines.
  17. Edmondson, Bohmer and Pisano, Disrupted Routines.
  18. May and Finch, Implementing, Embedding, and Integrating Practices.