Work Understanding: Work explorer
Objective. Use the Work explorer to browse the discovered work and open one process or case to its evidence, so a reader can show flow from real signal rather than describe it from memory.
The explorer answers 'what work did we actually observe, and can I see the evidence behind one piece of it?' It is where Sales grounds the 'this is observed, not a drawing' claim and where a CSM starts an investigation from a concrete case.
See it in the demo
What this screen answers
The customer question is: what work is actually happening, and can I trace one instance down to its evidence? A Sales person opens the explorer to make discovery tangible - pick one process, show its real flow. A CSM opens it to begin an investigation grounded in a specific case rather than an aggregate.
The task
Filter the explorer to the process, team and period in scope, then browse the discovered work and open one item to its underlying signal. The move is to go from the list to a single concrete example and back - showing that the aggregate screens are built from real observed activity, not an assumed template.
How to read it
What you see is discovered from captured signal, so it reflects what was observed, not necessarily everything that happened. The classic misread is assuming the explorer shows the complete population of work: coverage may be partial, and some work may sit outside what capture sees. Read it as a representative, evidence-backed sample to reason from, and check confidence before generalising from one case.
Honest limits
The explorer shows observed work with a confidence, not a guaranteed-complete ledger. It does not prove the sample is representative of all work, and it does not establish cause. Confirm capture coverage and detection confidence with product before stating that the explorer represents the full process.
Interpretation check
The explorer shows observed work with a confidence, not a complete population - do not generalise from a visible sample without checking coverage.
Practical task
In the explorer, filter to one process and open a single case to its evidence; write a two-line note describing what the observed flow shows and one thing you would confirm about coverage before generalising.
Self-check
A customer says 'so this is everything my team did last week?' What is the honest answer?
It is the work we observed with adequate confidence. Coverage can be partial, so treat it as evidence-backed observation, not a guaranteed-complete ledger, and confirm coverage with product.
Why open a single case in the explorer during a demo?
To ground the 'observed, not a whiteboard' claim - showing the aggregate is built from real signal you can trace to one concrete instance.
What should you check before generalising from one explorer case?
Detection confidence and coverage for that process - one vivid case is not proof the pattern holds across the population.
Verified vs demo. Screen is live in the demo at /#/explorer; exact controls, filters and figures are SME-validation-pending.