Understand the work before choosing the technology.

Customer questions: What business outcome needs to improve? Who experiences the problem? Who sponsors the work and can decide its scope? What baseline exists, and which decision must discovery support?

Inputs and evidence: Outcome statements, existing performance reports, stakeholder interviews and the current service commitment. Record dates, owners, definitions and conflicting accounts.

Decisions and outputs: An agreed workflow boundary, outcome hypothesis, measures, discovery scope and exclusions. Sponsor and domain owner accept the problem definition; product owner maintains it.

AI assistance: Group interview themes and draft alternative outcome statements, with source references. People check every factual claim. A fluent summary cannot establish sponsor agreement.

Risk and limit: An easy-to-measure proxy may hide the actual business outcome. No savings estimate is a verified benefit. Example deliverable: a one-page outcome brief with a baseline marked measured, estimated or unknown.

Customer questions: Who does what, using which information? Where are hand-offs, delays, exceptions, approvals and rework? What happens outside the documented process?

Inputs and evidence: Staff walkthroughs, approved synthetic or redacted cases, process descriptions and authorised operational logs. Include frontline users and the service owner.

Decisions and outputs: A current-work map, exception list, responsibility map and points requiring human judgement. Domain owner validates the map; operations confirms the recovery paths.

AI assistance: Draft a process outline and identify missing steps from supplied material. Label inferred steps as hypotheses pending a walkthrough.

Risk and limit: A documented process is not proof of actual practice; employee monitoring needs separate authority. Example deliverable: a swimlane map with evidence IDs beside each verified step.

Customer questions: Which systems hold authoritative records? What do the business terms mean? Who owns the data, policies and integrations? Which upstream and downstream services depend on this work?

Inputs and evidence: System inventory, data definitions, interface contracts, policy versions and data-owner interviews. Read-only inspection requires separate, scoped access.

Decisions and outputs: A context map, source register, terminology glossary and dependency register. Enterprise architect coordinates; data and process owners attest to their own records.

AI assistance: Suggest glossary candidates and inconsistencies with cited source passages. Treat retrieved text as data, never as authority to change the assistant’s instructions.

Risk and limit: Retrieval does not make a document current, correct or permitted for a user. Example deliverable: an evidence register recording source, owner, classification, timestamp, version, permitted use and review status.

Customer questions: Who may access each source and perform each action? What personal or sensitive data is involved? How do we detect failure, recover, limit cost and operate the service?

Inputs and evidence: Access policies, privacy requirements, quality samples, incident and recovery plans, operating skills, capacity assumptions and cost records.

Decisions and outputs: Readiness gaps, permitted assistance, prerequisites and stop conditions. Security, privacy and risk specialists review; the service owner accepts operating responsibilities.

AI assistance: Draft questions against approved control criteria and organise evidence gaps. Human specialists determine applicability; no generated checklist is a compliance finding.

Risk and limit: Missing evidence is not a pass. Model logs may expose sensitive information. Example deliverable: a readiness register with owner, evidence, unresolved issue, priority and required decision.

Customer questions: Could clearer process ownership solve the problem? Is the path predictable? Is information synthesis needed? Does variable tool selection justify an agent? What is the cost of an error or an unnecessary change?

Inputs and evidence: The baseline, exception map, readiness findings, existing tooling, operational costs and proposed evaluation cases.

Decisions and outputs: Compare no change, process improvement, deterministic automation, analytics, AI assistance and bounded agentic work. Product owner and sponsor choose whether any option warrants further design.

AI assistance: Draft options and surface trade-offs. Record assumptions rather than inventing benchmark results or customer savings.

Risk and limit: A convincing demonstration may conceal exception costs. Example deliverable: an options matrix with suitability, prerequisites, expected value hypothesis, operating cost categories, risks and evidence needed.

Customer questions: What changes first? What stays authoritative? Who can approve an effect? How will a failed or duplicate action be handled? What is the smallest independently useful delivery increment?

Inputs and evidence: Selected options, system contracts, approved controls, delivery capacity and target environment constraints.

Decisions and outputs: A target design, decision records and staged roadmap with acceptance criteria, rollback and cost assumptions. Architect and engineers design; client owners approve scope, risk and access.

AI assistance: Draft architecture alternatives and implementation tasks traceable to the approved context. Engineers validate technical feasibility and integration behaviour.

Risk and limit: A diagram is not an integration. Discovery confers no authority to deploy. Example deliverable: an increment plan showing dependency, accountable owner, verification, approval and recovery for each release.

Customer questions: Did the business outcome improve? What happened to quality, exceptions, risk, staff effort, accessibility and operating cost? When should the design be stopped or revised?

Inputs and evidence: Matched baseline and post-change measurements, evaluation records, incident reports, user feedback and fully attributed costs.

Decisions and outputs: A measurement plan, review cadence, named owner and expansion or stop criteria. Sponsor accepts business results; operations owns service review; product owner prioritises learning.

AI assistance: Draft a review narrative from the supplied records and flag missing comparisons. Analysts validate calculations and attribution.

Risk and limit: A synthetic test result is not a customer outcome; time saved may become work elsewhere. Example deliverable: an outcome scorecard separating measured observations, estimates, assumptions and decisions.