01 / Section
Start with the documented process as a reference
Write down the intended process before reviewing the evidence. Include the stated trigger, required decisions, expected handoffs, systems involved, and intended outcome. Keep this description specific enough to compare, but do not treat it as proof that the process was followed.
The documented process is a reference point, not a standard for judging individual behavior. A difference may indicate an undocumented exception, an unclear instruction, a missing system capability, or a legitimate alternative route.
02 / Section
Reconstruct separate attempts from captured evidence
Review captured batches and group related evidence into distinct attempts at the same business outcome. For each attempt, describe the actions supported by the record, the outcome or stopping point shown, and the evidence linked to each statement.
Keep the wording proportional to what the record supports. Say that an attempt included a recorded submission, review, or handoff when those events are evidenced. Do not turn a sequence of records into a claim about all work performed, verified working time, or the person’s complete activity.
A citation establishes where an observation came from. It does not make the observation complete or certain. Missing records, delayed updates, parallel work, and activity outside the captured sources may all affect the reconstruction.
- Recorded evidence: what the captured material directly shows.
- Interpretation: the workflow meaning assigned to those observations.
- Planning assumption: what must be checked or agreed before changing the process.
03 / Section
Compare paths, not isolated deviations
Place the documented path beside two or more reconstructed attempts. Look for recurring differences in order, handoffs, rework, decisions, and system changes. A single variation may be an exception; a pattern across distinct attempts is a stronger reason to examine the process design.
Describe the comparison in operational terms. For example, several attempts may reach the same review step through different intake routes, or repeatedly pause while a required detail is gathered. This identifies a workflow pattern without claiming that the pattern explains every case.
Keep app and site sequences separate from the business-process reconstruction. They can be useful discovery signals for finding candidate transitions or places to investigate, but they do not by themselves prove intent, completion, or the full sequence of work.
- Where does the observed path match the documented path?
- Where do multiple attempts take different routes to the same outcome?
- Which differences recur across attempts, and which appear only once?
- What evidence would confirm or challenge the proposed explanation?
04 / Section
Turn the comparison into a bounded improvement plan
Use recurring patterns to form a small number of testable questions. Ask whether the documented process needs an explicit branch, whether a handoff needs clearer ownership, or whether a missing input is creating repeated detours. Avoid presenting these as confirmed causes until they are checked with the people and records involved.
Separate the proposed change from the evidence that motivated it. State what is known, what is inferred, and what the team assumes for planning. Then define the next review point: which cases will be examined, what outcome will indicate improvement, and what new evidence is needed.
The goal is not to declare one path correct or to measure individual performance. It is to make the gap between the intended process and the recorded paths visible enough for responsible process decisions.