Map the Workflow That Actually Exists

The most dangerous workflow diagram is the one everyone recognizes and nobody actually follows.

It begins with a clean request. It moves through approved systems in a straight line. Each box has one owner. Data arrives before it is needed. Exceptions appear in a footnote. The diagram is easy to present because it describes how the organization believes work should happen.

A deployment enters the workflow that does happen.

That workflow contains waits, rework, personal notes, duplicated entry, judgment under incomplete evidence, inconsistent identifiers, unofficial communication, manual reconciliation, approval delays, retries, partial completion, and exceptions handled by people who may not appear in the project plan. A system designed for the ideal path does not merely miss detail. It can move the bottleneck, remove a safety check, create invisible work, or optimize the wrong result.

The purpose of current-state mapping is therefore not documentation. It is decision control. The model must be detailed enough to change the outcome contract, scope, architecture, verification, rollout, or ownership decision, and no more detailed than that.

Official service guidance supports mapping the whole user problem and the broken handoffs across channels, rather than treating one interface as the service. Observation of real users can reveal the difference between reported procedure and actual work. These principles ground the chapter; the coordinated model used here is an original FDE synthesis. [CLM-015] [CLM-016] [CLM-020]

Start with the operational result

Chapter 2 established legitimate access and an evidence log. Now choose a workflow boundary by naming an operational result from the user’s perspective.

For Orchid, “use the AI copilot” is not the result. “Close a service ticket” may be the administrative endpoint, but it can still be a poor workflow boundary. A ticket can close after a temporary workaround while the equipment fails again, or after a difficult case is routed elsewhere.

A more useful provisional result is:

A technician resolves or appropriately escalates a service request with sufficient evidence, required approval, and an operable record of what was decided and why.

This boundary reaches before the proposed interface and after its output. It includes the request, equipment identification, triage, evidence gathering, decision, parts state, safety approval, work at the site, resolution or escalation, and record completion. It may later be narrowed to a selected equipment family, region, and cohort, but the whole path must be visible before the slice is chosen.

Define the start and end events. Then ask which earlier and later events can change the meaning of the result. A technician arriving without the right part may originate in inventory data hours earlier. A repeated failure may be caused by a closure process that hides unresolved uncertainty. A privacy or safety consequence may begin with evidence collection before the user sees a recommendation.

The boundary is not universal. It serves a decision. Record which upstream and downstream paths are excluded and why.

Use coordinated views, not one perfect diagram

No single representation handles sequence, state, decision, data, ownership, incentives, and exception equally well. Trying to place everything on one canvas creates a model that is comprehensive but unusable.

Use five linked views.

1. The service journey

The journey shows the user’s progress toward the operational result across channels and time. It includes visible action, waiting, handoff, failure, and recovery. It is useful for finding gaps between teams or systems that each appear healthy in isolation.

A journey row for Orchid might show:

1. request arrives through portal, phone, or email;
2. dispatch creates or amends a ticket;
3. equipment is identified or ambiguity is flagged;
4. technician receives assignment and gathers evidence;
5. site inspection changes the evidence state;
6. technician decides, seeks approval, or escalates;
7. inventory/part action occurs;
8. work is performed and verified;
9. ticket and equipment history are updated;
10. unresolved condition is handed to another owner.

The journey prevents the interface from becoming the workflow. Journey and experience maps are specifically useful for exposing cross-channel handoffs and gaps. [CLM-017]

2. The swimlane and state flow

The swimlane shows actors and systems over sequence. A linked state model shows what the request, equipment match, recommendation, approval, part, and resolution can become.

For example, a request may be received, triaged, assigned, in-field, awaiting-evidence, awaiting-approval, awaiting-part, resolved, escalated, cancelled, or reopened. “Ticket open” is too coarse if different waits have different owners and consequences.

The state model should name transition evidence. What makes a request awaiting-approval rather than merely paused? Who can move it? Can a transition be reversed? Which external system is authoritative? What happens when systems disagree?

3. The decision and evidence table

For every material decision, record:

• decision and consequence;
• actor and required qualification;
• evidence available at that moment;
• evidence trusted, distrusted, or missing;
• rule, judgment, policy, or incentive applied;
• system action and human action;
• next state and escalation path;
• observed variation or contradiction.

Example:

Decision	Actor	Evidence available	Rule or judgment	Failure consequence
Which equipment record matches?	dispatcher or technician	ticket ID, site, serial plate, prior history	compare identifiers; resolve ambiguity manually	wrong manual, part, or history
Is suggested action eligible?	qualified technician/domain owner	equipment state, evidence, policy	deterministic/safety rule plus judgment	unsafe or prohibited action
Is the job resolved?	technician and service process	work performed, test result, remaining condition	resolution criterion or escalation	premature closure, repeat visit

The table reveals where the proposed system would act and which evidence/authority it must not replace.

4. The system and data inventory

List each system, store, document, informal tool, and identifier used by the workflow. Record its purpose, owner, authoritative claim, update path, latency/freshness, access, interface, common mismatch, and failure behavior.

Do not omit spreadsheets, messaging, paper, personal notes, phone calls, or memory because they are unofficial. They may carry the evidence that makes the official process work. Their presence is not proof that they should be automated or retained. It is evidence that the current path depends on them.

5. The exception topology

Place the normal path in the center and surround it with exception families:

• identity and matching;
• missing, late, duplicate, invalid, or contradictory data;
• connectivity and environment;
• policy, approval, and authority;
• inventory and external dependency;
• user access, capability, and accessibility;
• safety and high-consequence conditions;
• system timeout, retry, and ambiguous completion;
• handoff, ownership, and support;
• cancellation, reopen, and changed intent.

The topology prevents exception handling from becoming “show an error.” It asks what work follows, who performs it, which state is authoritative, and how the main path resumes or ends.

Map what is observed and what is reported

Every element in the current-state model should retain evidence status.

• solid line: observed, measured, or reproduced within the recorded boundary;
• dashed line: reported or assumed, validation pending;
• conflict marker: evidence disagrees;
• gap marker: material behavior or owner unknown;
• proposed marker: future-state idea, excluded from current state.

Do not convert a dashed path to solid because several stakeholders repeat it. Repetition can reflect a shared official narrative. Do not mark a path false because an observation contradicts it once. The observation may be an exception or an effect of being observed.

Use evidence IDs on important nodes and transitions. A diagram should allow a reviewer to ask: “Why do we believe the equipment match happens here?” and reach the interview, observation, query, reproduction, limitation, and contradiction record.

The model is versioned. When new evidence changes it, record the change and affected decisions. Do not silently redraw history.

Separate process, state, and intent

Sequence alone can hide the most important technical ambiguity: whether an action completed and whether the same request still expresses the same intent.

Suppose Orchid Assist calls an ERP operation to reserve a part. The request times out. Three different states may exist:

1. the ERP never received the request;
2. the ERP committed the reservation but the response was lost;
3. the ERP accepted the request but later rejected downstream processing.

The technician sees one symptom: no confirmed result. A naive retry can create a duplicate reservation. Refusing to retry can leave the job blocked. The workflow needs a way to determine or reconcile operational state.

HTTP defines method semantics, including the idea of idempotent methods, but transport-level semantics do not by themselves settle the business meaning of a retry. First-party engineering guidance on idempotent APIs emphasizes caller intent and ambiguous completion. Technical retry behavior is therefore part of the workflow because it changes the next human and system decision. [CLM-019]

Map the intent explicitly:

• Which person/system initiated the action?
• What did they intend to happen once?
• How is that intent identified?
• Which system records acceptance and final effect?
• How can another attempt mean “same intent” versus “new intent”?
• How long is the intent identity valid?
• What does the user see while state is uncertain?
• Who reconciles disagreement?

Chapter 7 will design the contract. Current-state discovery must first establish how ambiguity is handled now, including manual calls, repeated clicks, spreadsheet checks, or silent duplicate work.

Put waiting and invisible work on the map

Value-stream diagrams often emphasize active work and duration. For FDE decisions, waiting needs ownership and reason.

Record:

• queue entered and exit condition;
• waiting owner versus action owner;
• evidence missing;
• service expectation or informal norm;
• user workaround while waiting;
• escalation threshold;
• consequence of delay;
• whether the wait is visible to the next actor.

At Orchid, a ticket may wait for equipment clarification, inventory confirmation, qualified approval, a site connection, or a regional data decision. Grouping every condition as “pending” prevents useful scope and telemetry decisions.

Invisible work includes copying identifiers, reformatting notes, reconciling systems, calling experienced colleagues, checking whether an API action took effect, and explaining system output to a user. Automation that reduces visible clicks but adds invisible verification work can worsen the workflow.

Observe who absorbs this work. Support, coordinators, junior staff, contractors, or affected users may compensate for system gaps without appearing in project measures.

Model incentives without pretending to read minds

The workflow is shaped by what people are measured, rewarded, blamed, or authorized to do. Record observable incentives and consequences, not psychological speculation.

Orchid service leaders may track ticket closure. Technicians may prioritize safe first-visit resolution. Inventory may minimize stock. Regional leaders may minimize data movement. Support may prioritize response targets. These aims can conflict without any actor behaving irrationally.

Ask:

• Which metric or policy affects this decision?
• What behavior could improve the metric while worsening the user outcome?
• Which difficult cases leave the measured population?
• Who bears rework or risk created by the local optimization?
• Which escalation is discouraged by time or performance pressure?

The answers will inform the metric tree in Chapter 4. At this stage, label them as reported, observed, or measured.

For Orchid, “time to ticket closure” can improve if difficult cases are transferred, prematurely closed, or excluded. “First-visit success” can improve if unsafe or unserviceable cases never enter the denominator. Mapping the transitions and populations is necessary before contracting either outcome.

Build an exception taxonomy that changes scope

An exception taxonomy is not a catalog of every edge case. It groups exceptions by the engineering and operating decision they require.

Use these fields:

• exception ID and family;
• trigger and evidence;
• affected actor, decision, and state;
• known frequency range or “unknown”;
• consequence and reversibility;
• current detection;
• current handling and owner;
• data/system dependencies;
• whether the first slice must handle, prevent, detect/escalate, simulate, defer, or reject it;
• validation evidence and remaining gap.

Example:

EX-ID-02: multiple equipment matches

• Trigger: ticket identifier maps to more than one active equipment record.
• Evidence: observed in supervised cases and reported by dispatch; population frequency not yet measured.
• Consequence: wrong history/manual/part; safety consequence depends on later action.
• Current handling: dispatcher/technician compares site, serial evidence, and prior history; escalates unresolved ambiguity.
• First-slice decision: detect and block recommendation until a qualified match is confirmed; include reconciliation path.

EX-ERP-04: timeout after reservation request

• Trigger: no response before client timeout.
• Evidence: API documentation reports timeout; commit semantics and occurrence unknown.
• Consequence: duplicate reservation or unresolved part state.
• Current handling: repeated request plus manual inventory check, according to one operator; reproduction pending.
• First-slice decision: interface cannot be designed until acceptance/reconciliation behavior is verified; dependency risk remains open.

The first example may belong in the slice even if rare because its consequence and central data boundary are material. The second may block automated writes while allowing a read-only recommendation path.

Apply the resolution test

How much detail is enough? Add detail when it can change at least one of these:

• the problem or outcome definition;
• the selected user, region, equipment, or exception boundary;
• a risk, guardrail, or authority decision;
• system/interface/data/identity architecture;
• an acceptance or evaluation case;
• a rollout cohort or stop trigger;
• an operating/support owner;
• a handoff or product-leverage decision.

If detail cannot change a decision, place it in a reference note or omit it. If a material decision depends on an unexplained transition, keep investigating.

The resolution test avoids two extremes. A shallow map hides constraints. An exhaustive map consumes time and becomes impossible to maintain. The goal is decision sufficiency, not a complete digital twin of the organization.

The five-view model and resolution test are an original synthesis. BPMN 2.0.2 is a standardized notation that may be useful for formal process representation, but neither the standard nor this book makes BPMN mandatory. A notation cannot compensate for weak evidence, missing users, or hidden exceptions. [CLM-018] [CLM-020]

Derive the state model from decisions

State names are often inherited from a ticketing system. That can be useful, but the system’s fields may exist for reporting or queue management rather than for the decision the deployment must support.

Derive workflow states by asking what becomes newly true, which action is now permitted, which evidence is required, and who is responsible next.

Take the generic state pending. It may conceal:

• awaiting-equipment-match: evidence is insufficient to bind the request to one equipment record; recommendations must remain blocked;
• awaiting-site-evidence: a technician must inspect or capture a condition before a decision can proceed;
• awaiting-qualified-approval: the proposed action exists but cannot be performed until an authorized person accepts it;
• awaiting-inventory-confirmation: a part candidate exists, but availability/freshness is unresolved;
• awaiting-customer-access: the site or system cannot be reached;
• ambiguous-external-write: a request timed out and the effect must be reconciled;
• escalated-unowned: the normal owner cannot resolve the case and a new accountable owner is not yet confirmed.

These states look similar on a dashboard if all are “pending,” but they require different data, timers, owners, alerts, user messages, and stop conditions.

For each candidate state, complete a state contract:

Field	Question
Meaning	What is true while the workflow is in this state?
Entry evidence	Which event and evidence permit entry?
Owner	Who must act or monitor now?
Allowed actions	Which operations are permitted or prohibited?
Exit transitions	Which evidence moves the workflow to each next state?
Time behavior	When does waiting become degradation or escalation?
System of record	Where is the authoritative state, and what can disagree?
User visibility	What does the affected person need to know or do?
Failure/recovery	How is an invalid, stuck, or split state detected and reconciled?

Do not assume every state belongs in the future application. Some exist only to understand current work. Some can be simplified after an architecture or policy decision. Others are vital because hiding them would create unsafe automation.

State disagreement is itself a state

When ticketing says “resolved,” inventory says “reserved,” and the equipment history has no completed work record, the deployment should not choose whichever system is easiest to query. Model the disagreement and its owner.

Ask which system is authoritative for each claim, not for the workflow as a whole. Ticketing may own assignment state. ERP may own inventory commitment. A qualified service record may own completed inspection. An audit event may prove who approved an action. “Single source of truth” is often an unhelpful simplification when different systems legitimately own different propositions.

This distinction will later shape the interface catalog and reconciliation plan. At discovery time, it explains why users cross-check systems.

Quantify only what the decision needs

Workflow maps can become anecdotal if they contain no magnitude. They can become falsely authoritative if weak observations are converted into exact numbers. Use a measured-evidence plan tied to decisions.

Suppose scope depends on whether identifier mismatch is material. Define:

• population: selected-family service requests created in Region West during the stated 30-day window;
• unit: distinct request at initial triage;
• mismatch: no unique active equipment record can be selected using the canonical ticket identifier under rule version 2;
• exclusions: test tickets, cancelled before triage, and requests without equipment by design;
• data owner and query version;
• missingness and known correction behavior;
• segmentation: channel, site connectivity class, technician cohort, and equipment subfamily where permitted;
• decision: include reconciliation in the first slice if consequence and measured/unknown magnitude justify it; otherwise detect/escalate with a validation plan.

The threshold is not invented by the engineer. The outcome and risk owners decide how evidence affects scope. The FDE ensures the measurement definition is inspectable and the unknown is not replaced with a convenient estimate.

Some decisions do not need prevalence. A rare exception with catastrophic or irreversible consequence may require prevention, approval, containment, or explicit exclusion. A common low-cost workaround may be deferred. Frequency, consequence, detectability, reversibility, and owner capacity must be considered together.

Use ranges and categories when the evidence supports only ranges and categories. “Observed in 2 of 7 supervised cases, convenience sample, prevalence unknown” is stronger than “29 percent” because it does not pretend sampling validity.

Show how the map changes the deployment

A workflow model earns acceptance by changing downstream work. For Orchid, each finding should have a trace:

Finding: equipment identifier is not always a trusted key

• Problem effect: evidence retrieval can begin from the wrong equipment.
• Outcome effect: “faster recommendation” is unsafe without match confidence/confirmation.
• Scope effect: the first slice must detect ambiguity and include human confirmation/reconciliation.
• Architecture effect: ticket ID and equipment ID remain distinct; lineage/provenance is required.
• Verification effect: duplicate, stale, absent, and conflicting identifiers become required cases.
• Rollout effect: cohort selection should include representative mismatch conditions or explicitly exclude them with monitoring.

Finding: technicians rely on provenance to trust advice

• Problem effect: generated or ranked output without sources increases verification work.
• Outcome effect: time saved must account for evidence checking and bypass behavior.
• Scope effect: visible evidence and uncertainty are included before cosmetic breadth.
• Architecture effect: retrieval/provenance path is a first-class component.
• Verification effect: UAT must test whether users can inspect and challenge supporting evidence.
• Adoption effect: low use is diagnosed against evidence visibility, not labeled resistance.

Finding: safety-relevant decisions require qualified approval

• Role effect: the FDE cannot define or accept the safety rule.
• Scope effect: autonomous action is excluded; approval and escalation are included.
• Architecture effect: deterministic eligibility, identity/authorization, audit, and fail-closed behavior are required.
• Verification effect: prohibited/uncertain cases and authority failures are tested.
• Rollout effect: qualified approvers and escalation coverage must exist for every exposed cohort.

Finding: ERP completion can be ambiguous after timeout

• Scope effect: automatic writes may be deferred until semantics and reconciliation are verified.
• Interface effect: intent identity, status lookup, conflict behavior, and operator reconciliation become contract requirements.
• Operability effect: uncertain state requires a signal, queue, owner, and runbook.
• Recovery effect: retry/rollback cannot be designed as a transport-only choice.

If a major workflow finding has no downstream consequence, ask whether it belongs in the model. If a downstream decision has no workflow finding or explicit assumption behind it, the deployment is designing from preference.

Keep the current state ethically legible

Current-state mapping can expose workarounds, policy deviations, individual mistakes, performance concerns, or sensitive operational weaknesses. Treat this evidence according to the approved purpose and customer process.

The artifact should make systemic conditions visible without turning it into a personnel dossier. Use role labels and de-identified cases where individual identity is not required. Restrict sensitive variants. Do not publish an unofficial workaround merely because it is operationally important. Escalate immediate safety or security concerns through the customer’s established path rather than waiting for a chapter artifact to be reviewed.

“Blameless” mapping does not mean pretending choices have no owners. It means asking which conditions, incentives, information, tools, authority, and safeguards made the observed choice reasonable or likely, then locating the appropriate corrective decision.

The FDE’s proximity creates a special obligation here. Users who reveal the real workflow are not consenting to have every detail copied into product analytics, training data, or cross-customer stories. The evidence and access rules from Chapter 2 continue to govern the map.

Validate the model with users and owners

Validation is not asking a sponsor whether the diagram “looks right.” Use role-diverse walkthroughs and concrete cases.

Normal-case walkthrough

Choose a recent representative case. Ask each actor to locate when they entered, what they knew, which state they trusted, what they produced, and what happened next. Compare the model with artifacts or records inside the approved evidence boundary.

Exception walkthrough

Choose a high-consequence or common exception. Ask what signal reveals it, who responds, what authority is required, how state is reconciled, and how the path ends. If participants disagree, retain the contradiction.

Counterfactual walkthrough

Change one condition: no connectivity, duplicate ID, unavailable expert, stale inventory, policy conflict, downstream timeout, or user unable to access the interface. Observe which assumed path collapses.

Ownership walkthrough

For each wait, control, data correction, support action, and escalation, ask the named owner to confirm responsibility and access. A label placed by the project team is not owner acceptance.

Evidence walkthrough

Ask reviewers which parts are observed, measured, reproduced, reported, or unknown. Confirm that the legend matches the evidence log.

Validation can produce three outcomes: accepted within a boundary, disputed with next evidence, or unknown with consequence/owner. “Validated” does not mean every participant agrees or every gap is solved.

Orchid Assist: current-state findings

The fictional case now has enough stated evidence to create OA-02 Verified Current-State Workflow. These are constructed pedagogical findings, not claims about a real company.

Observed or stipulated case facts

• Requests arrive through multiple channels and are normalized into tickets with inconsistent completeness.
• The ticket equipment identifier is not always a trusted key; matching can require site, serial, history, and human judgment.
• Technicians gather evidence across manuals, old tickets, inventory, equipment records, telemetry, and informal knowledge.
• Qualified approval is required for safety-relevant recommendations.
• Some sites have intermittent connectivity.
• Responsibility is split across service operations, IT, data, security, inventory, and regions.
• Technicians distrust recommendations that hide supporting evidence.

Remaining evidence gaps

• frequency and segment distribution of identifier mismatches;
• exact ERP timeout and write-completion semantics;
• inventory freshness by workflow decision;
• support demand attributable to evidence fragmentation;
• low-connectivity latency and abandonment patterns;
• authoritative safety rule and approval transition;
• baseline relationship among closure, resolution, repeat visit, and escalation.

Revised problem statement

The problem is not that technicians lack generated text. The bounded problem is that the evidence required to resolve or appropriately escalate selected service requests is fragmented, inconsistently identified, variably available, and difficult to evaluate at the point of decision. Any deployed path must improve evidence assembly and decision support while preserving qualified safety approval, visible provenance, exception handling, regional/access constraints, and operable state reconciliation.

This statement may still be rejected by later evidence. It is stronger than the initial request because it names the workflow decision, evidence conditions, and guardrails without committing to AI as the universal mechanism.

Workflow-mapping failure modes

The happy-path mural

The map describes the normal official sequence and places exceptions in a list.

Repair: build the exception topology and validate at least one material exception end to end.

The future state in current-state colors

The team draws how a new system will connect and calls it discovery.

Repair: mark proposed nodes and flows separately; require evidence IDs for current-state claims.

The unreadable master diagram

Every data field, team, system, state, and exception appears in one image.

Repair: use linked views with stable IDs and the resolution test.

The title-as-owner map

The project assigns responsibility based on job title without owner confirmation.

Repair: perform ownership walkthroughs; distinguish access, execution, responsibility, and decision authority.

False frequency

Words such as “usually,” “rarely,” or “always” become percentages, or a small observation sample becomes prevalence.

Repair: keep reported frequency as reported; measure with a defined population/method or record unknown.

Tool worship

The team debates BPMN, diagram software, or process-mining tools while evidence and semantics remain weak.

Repair: choose the smallest representation the audience can validate; keep editable sources and provenance.

Exception as error message

The technical design plans to display an error without mapping the work required afterward.

Repair: model detection, decision, owner, next state, reconciliation, return path, and terminal outcome.

Conduct the workflow-mapping exercise

Observe or use a constructed service request from arrival through closure. Produce the journey, swimlane/state flow, decision/evidence table, system/data inventory, and exception topology. Mark every statement observed, reported, inferred, or unknown.

Inject ambiguous equipment, stale manual, missing inventory response after acceptance, qualified-approval need, and offline technician work. Show waiting, rework, manual coordination, and ownership rather than hiding them in error boxes. Write the revised problem statement and identify which finding changes scope or architecture.

Validate the normal, exception, counterfactual, ownership, and evidence walkthroughs with representative fictional roles. Pass when another reader can predict state, decision, evidence, consequence, and owner for both the common and consequential exceptional paths.

The OA-02 gate

Before Chapter 4 contracts an outcome, OA-02 should contain:

• operational result and explicit workflow boundary;
• whole journey and channel/handoff view;
• current-state swimlane and state model;
• decision/evidence/authority table;
• system/data/informal-tool inventory;
• exception taxonomy and topology;
• waits, invisible work, incentives, and metric-population risks;
• evidence IDs and observed/reported/measured/reproduced/unknown legend;
• user/owner validation records and unresolved contradictions;
• revised problem statement;
• explicit remaining gaps and their next tests.

The gate passes when the model is sufficient to change a decision and its uncertainty remains visible. It does not pass because the diagram is polished.

Chapter 4, Contract for an Outcome, will turn this current-state evidence into a metric tree, guardrails, adoption measures, baselines, decision rights, non-goals, and exit criteria. That contract must be able to reject a convincing prototype that improves interface activity while leaving the real workflow unchanged or worse.