---
name: discovery
description: Investigate enterprise work, systems and expert judgment to discover what an AI solution should change. Use for operator research, technical discovery, workflow redesign, workshops or diagnosis of an inherited process.
license: MIT
---

# Discovery

Discover the mechanism of the work: how an outcome is produced, why it sometimes fails, and what prevents the organization from doing it better or more broadly. Enter through the available material and access. Interviews, observation, product exploration, operational records and technical investigation answer different parts of the question; combine them where they change the design.

Choose discovery around the decision at hand. A first opportunity discussion needs enough evidence to select a valuable problem; a contested integration needs a trace through the affected systems; an inherited pilot may need observation of failed cases. Use existing research before requesting another workshop. Stop broadening when the remaining unknowns would not change the next commitment, and turn unresolved consequential questions into a bounded investigation with a stated decision to inform.

## Follow an outcome through the enterprise

Choose a recognizable business outcome and trace a case from its trigger to accepted completion. Follow information and decisions across teams, documents, products and systems. Separate active work from waiting, rework and external dependencies. A task that takes a day may contain minutes of analysis and hours waiting for information; automating the analysis alone may barely change the outcome.

Compare cases that expose variation. A routine success shows the usual path; an expert intervention reveals judgment; a failed or abandoned case reveals where the process stops working. Also inspect work that never entered the process: rejected quotations, unserved customers, deferred reviews, ignored signals and exceptions handled outside the official workflow. Today's throughput can conceal the most valuable demand.

Look beyond the local task. Faster preparation can overload the approver, a new recommendation can create a queue nobody owns, and a missing upstream decision can cause downstream rework. Locate the constraint on the outcome and test whether the proposed intervention removes, moves or intensifies it.

## Learn how expertise changes the case

Ask the expert to reconstruct the moment a decision became clear. What did they notice? Which explanation initially looked plausible? What contradicted it? Which next observation was worth obtaining? What did they decide not to do? Inspect the documents, screens or case state they used when available.

Distinguish a rule from its application. A warranty policy may be explicit while identifying the applicable equipment configuration is difficult. A credit formula may be straightforward while deciding which reporting perimeter and amendment apply requires interpretation. A technician may recognize that a new symptom invalidates an earlier diagnosis. These distinctions identify what AI must reason about, what authoritative services can decide and what information the solution must preserve.

Use counterfactual questions to expose hidden knowledge. Change one material fact and ask whether the action changes: a different customer entitlement, a revised contract, a substituted component, an absent measurement or a new deadline. The boundary between two apparently similar cases often teaches more than another happy-path description.

When a reported bottleneck rests on partial records or an expert says they "just know," [the service-case reconstruction](references/service-case-reconstruction.md) shows how to recover an omitted handoff, expose a decision cue and turn it into a changed operation. It also shows where the same evidence is too weak to support a workload or savings claim.

## Inspect the systems people actually use

Follow the operator through the product surfaces and, with appropriate access, investigate the corresponding administrative and developer capabilities. Learn which business record each system owns, how records are identified, which updates arrive when, and how a decision becomes an action. Screens and exports can reveal relationships that a systems inventory misses.

Investigate a seam through a concrete case. Does the installed-asset record describe the machine as sold or as currently maintained? Is a customer number a legal entity, billing account or service location? Does inventory availability mean physically present, unreserved, or available to this customer? Can a long-running case resume after another team changes the underlying record? Resolve the meaning before proposing a connector or a shared data model.

Explore affordances as well as deficiencies. The current product may support a richer workbench, native orchestration, delegated actions or a relevant extension mechanism that users have never adopted. A developer surface may expose an operation missing from the user interface. These discoveries can materially improve the solution and reduce custom work.

## Develop and challenge a changed operation

Construct a target episode with the people doing the work. Show how information would arrive, how the system would investigate or prepare a decision, what the operator would see and do, and how the outcome would reach the authoritative business process. Use a sketch or prototype when interaction is hard to describe.

Ask what becomes unnecessary, what becomes possible, and what new work appears. Test the design against the difficult case, including changed information and competing responsibilities. Find out whether people would use the proposal inside their working day, not merely whether they like it in a workshop. Resistance may expose a loss of discretion, a misaligned incentive or a genuine product flaw.

Bring competing accounts together around the decision they affect. A sponsor's estimate and an operator's measurement may concern different populations. A policy owner and system owner may disagree about how authority is implemented. Resolve what can be resolved from the available record, then identify the particular observation or investigation that would change the design. Avoid turning unresolved details into an excuse to stop independent work.

Deliver the understanding the task needs: a persuasive diagnosis, a current-to-target workflow, a solution hypothesis, a discovery session, or a technical investigation. Preserve useful sources and commitments in the working material. The main result should explain what the enterprise could do differently and what you learned that changes the next decision.

When preparing a workshop, give the facilitator material they can use in the room: a case to reconstruct, questions whose answers change a choice, and an exercise or contrasting example where it helps people expose judgment. Tailor the session and information requests to what is already known. When a workspace is the requested output, let the team add later sessions, connect findings and develop new opportunities; a fixed set of example records is a demonstration, not continuing discovery support. Keep source details accessible without making record maintenance the main activity.