01 / Section
Start with the recorded trail
A captured batch can show the materials associated with an attempt to reach a business outcome: a request, a document, a message, a change, or a handoff. Begin by describing those items as they appear, with links back to their sources and the order in which they were captured.
This is the evidence layer. It should answer, “What was available to review?” rather than “What definitely happened?” A citation establishes provenance for a detail. It does not prove that the detail was complete, current, or sufficient to explain the outcome.
- Name the captured artifact or event.
- Keep its source and capture context visible.
- State gaps instead of filling them with confident language.
02 / Section
Treat interpretation as a separate step
Interpretation connects related evidence into a possible account of an attempt. For example, several captured items may suggest that a request moved from intake to clarification, review, and handoff. That account can be useful without being treated as a verified record of every action or decision.
Use language that keeps the boundary clear: “the evidence suggests,” “these items are consistent with,” or “one plausible sequence is.” Avoid turning proximity in a capture into proof of causation, intent, ownership, or completion.
- Label inferred relationships as interpretations.
- Offer competing explanations when the evidence supports more than one.
- Do not convert an inferred sequence into a claim about working time or performance.
03 / Section
Compare attempts, not people
A stronger operational view comes from comparing distinct attempts at similar outcomes. Look for recurring workflow patterns across batches: repeated clarification points, common handoff locations, or documents that appear in more than one path. The comparison should describe how work appears to move, not rank the people involved.
Keep app and site sequences as discovery signals. A sequence can help identify where to investigate a workflow, but it does not establish that a person completed a task, that a visit caused an outcome, or that the sequence represents the whole process.
- Compare outcome attempts with similar scope or purpose.
- Describe recurring steps and friction points as patterns to examine.
- Keep discovery signals separate from evidence about business results.
04 / Section
Make planning assumptions visible
Planning begins when a team decides what to test or change. At that point, state the assumption directly: perhaps a clearer intake template could reduce repeated clarification, or a defined handoff could make ownership easier to confirm. These are proposals, not findings from the captured record.
A useful review ends with a small, testable next step and a request for missing context. Preserve the original evidence, the interpretation built from it, and the assumption guiding the next action as three different things. That separation lets operations leaders revise the explanation when new evidence appears.
- Record the assumption behind each proposed change.
- Identify what new evidence would support or challenge it.
- Review the next attempt against the same evidence and interpretation boundaries.