Agree what the discovery must establish
Scope an operational discovery by naming what needs to be understood, who will decide what happens next and what evidence would be sufficient for that decision. Define the unit and period. State exclusions and unresolved access constraints. A completed discovery can recommend further checking or stopping as well as a change.
GOV.UK's discovery guidance starts from understanding the problem and constraints before building a service. It also calls for clarity about what is outside the problem. The charter below adapts that approach for an operational investigation; it is not a government standard for commercial engagements.
Turn a requested solution into a question
“Automate invoice approvals” names a solution. A question that can inform that choice is: “Which elapsed intervals differ between the selected late and on-time invoices, and what records explain those differences?”
The invoice worksheet demonstrates this question using ten synthetic invoices. The example's largest difference is before the ready-for-approval checkpoint. Equal approval medians do not rule out individual approval problems. The result identifies a place to check; it does not prove a cause or an automation business case.
A synthetic investigation charter
| Field | Example |
|---|---|
| Question | Where do elapsed intervals differ in the selected invoices? |
| Decision | Which stage should receive the next evidence check? |
| Unit | One invoice, using consistently defined checkpoints |
| Included | The ten explicitly synthetic invoices supplied with the worksheet |
| Excluded | Claims about a real company's late rate, all suppliers or active labour time |
| Evidence | Received, ready, approved, paid and due dates; explanatory notes |
| Checks | Confirm what each date means. Find missing or reversed dates and recalculate the intervals |
| Owner | To be assigned for a real investigation |
| Finish condition | A bounded comparison and a named next check, or a recorded reason the data cannot support one |
Use this blank charter before requesting records
| Field | Complete before proceeding |
|---|---|
| Operational question | What needs explaining or deciding? |
| Decision and owner | What could change, and who can authorise it? |
| Coverage | What does one record represent, which period does it cover and what is included? |
| Exclusions | Which plausible conclusions would exceed this scope? |
| Known evidence | Versioned references and the people who hold them |
| Competing explanations | What could produce the observed issue? |
| Next checks | Evidence that could distinguish those explanations |
| Dependencies | What must be resolved before the checks can proceed? |
| Finish condition | Enough evidence for which decision, or what reason to stop? |
Do not fill an unavailable source with an assumption to make the charter look complete. Record the dependency and who can address it. Agree a review point suited to the question and availability of evidence; this template does not imply a standard duration.
Close the investigation with a decision record
At the review point, compare the findings with the original question. Record what the evidence supports, what remains uncertain and the decision taken. If the next step is a change, use a requirements matrix to define what acceptance will require. If the next step is more research, name the missing evidence and limit the new question.
The charter defines the investigation. It does not set contractual terms, fees or a commitment to build software. You can discuss the question and available context with AutoSpark before arranging any engagement.