What a six-week AI discovery engagement should deliver
Discovery must reduce a funded decision
AI discovery should resolve a decision that leaders are prepared to fund, defer, narrow, or reject. Without that decision, discovery becomes a broad research exercise whose outputs are difficult to accept. Begin with a decision brief that names the opportunity, problem owner, affected users, workflow boundary, value mechanism, constraints, and choices under consideration. State what leaders need to know by the end. A useful engagement changes the quality of a commitment rather than producing a larger collection of possibilities.
Limit the scope to one coherent workflow or capability boundary. The team needs enough depth to examine real data, systems, user behavior, controls, and operating responsibilities. A portfolio-wide ambition may be important, but it cannot be tested with the same rigor in a short engagement. If several use cases are competing, prioritize them first and select one for discovery. Preserve the others as context and dependencies instead of pretending each will receive equal evidence.
Define the decision rights. The business owner accepts the problem and value evidence. Data and system owners approve access and interfaces. Security and governance owners set the control boundary. Product and engineering leads recommend the delivery design. An executive sponsor makes the funding or priority decision. These roles may vary by organization, but the engagement should not depend on a vague steering group. Named decisions and dates keep learning connected to action.
Agree on stop conditions as well as success. Discovery should recommend no-go when the outcome is not meaningful, required evidence cannot be accessed responsibly, the workflow cannot support the change, controls make the use case unsuitable, or no operating owner exists. It may recommend a narrower path when value remains plausible inside a safer boundary. Making these outcomes legitimate protects the team from designing evidence only to justify a predetermined build.
Week-by-week outputs that matter
Week one produces the decision brief and names the engagement owners. The team interviews the problem owner and representative users, observes the current decision where possible, inventories existing artifacts, and records the intended change, value mechanism, constraints, decision rights, and open questions. The problem owner accepts the brief, while the executive sponsor accepts the funded decision and stop conditions. This brief remains active through week six so later evidence can correct its assumptions.
Week two produces the workflow map and opens the data evidence record. The map shows triggers, roles, systems, information, decisions, exceptions, controls, and outcomes. The data record identifies source ownership, meaning, access, quality conditions, and available outcome evidence. The workflow owner accepts the map, and the data owner accepts the source inventory and access plan. Data evidence spans weeks two through five because prototype work will expose additional conditions.
Week three produces architecture and control options for the agreed boundary. The team compares integration patterns, model or component choices, identity and permission needs, evaluation design, human oversight, observability, fallback, and rollback. Each option states consequences and unknowns rather than presenting an unsupported target architecture. The architecture owner accepts technical feasibility, while the security or governance owner accepts the control questions and any prohibited paths. Unresolved items become explicit prototype tests.
Week four begins the bounded prototype and locks its evaluation plan. The team selects the assumption most capable of changing the decision, prepares representative inputs, defines acceptance cases and failure categories, and implements only what the test requires. Prototype evidence therefore spans weeks four and five. The product and engineering owners accept the test boundary, while the evaluation owner accepts the cases and review method before results are examined.
Week five completes the prototype evidence and starts the delivery plan. The team records successful and failed cases, workflow observations, integration findings, control implications, and changes to the data evidence record. A polished demonstration is optional because the gate concerns what the proof establishes and what remains unknown. The problem owner accepts the relevance of the evidence, and the evaluation and control owners accept its limitations. Those decisions determine whether planning continues, narrows, or stops.
Week six completes the delivery plan, confirms ongoing owners, and issues the go or no-go recommendation. The plan sequences data, integration, evaluation, security, adoption, and operations into testable increments with dependencies, team shape, decision cadence, and stop conditions. Each future owner accepts their responsibility and first gate. The executive sponsor then accepts the recommendation to proceed, narrow, defer, or stop, using the cumulative brief, maps, records, options, and prototype evidence.
Acceptance tests for the engagement
Test the decision brief by asking whether an uninvolved leader can state the funded choice, the use case boundary, the value mechanism, and who decides. Test the workflow map by walking through a normal case, an exception, a system failure, and a user correction. Test data evidence by confirming ownership and access rather than relying on sample files detached from their origin. These acceptance checks reveal whether discovery has created shared understanding or simply collected specialist views.
Test architecture and control options against real constraints. Each option should identify dependencies, sensitive data boundaries, integration points, evaluation needs, human authority, observability, support, and rollback. The team should explain why it recommends one path and what evidence could change that recommendation. If the architecture cannot be connected to the workflow map and risk boundary, it is not ready to guide delivery.
Test prototype evidence for relevance and repeatability. Confirm that cases represent the intended scope, acceptance criteria were defined before the result, failures are categorized, and another reviewer can inspect the record. A prototype should answer the selected uncertainty without being presented as a production estimate. Where evidence is weak, the report should say so and propose a bounded next test. Honest uncertainty is a valid discovery result.
Test the delivery plan by assigning each increment an owner, acceptance artifact, dependency, and decision. Include client roles needed for domain, data, systems, controls, operations, and adoption. Check that early increments retire high-impact uncertainty rather than building low-risk surfaces first. The plan should be useful to the people who will execute it, not only to sponsors. Ask those owners to accept or challenge their responsibilities before the engagement closes.
Test the recommendation for traceability. Every major conclusion should point to a workflow observation, data finding, control decision, technical test, or owner commitment. Mark conclusions that still rely on assumption and explain how delivery will test them. Traceability lets sponsors challenge the recommendation constructively and prevents confident language from outrunning the evidence.
Use an acceptance table with rows for the decision brief, workflow map, data evidence, architecture and control options, prototype evidence, delivery plan, owners, and go or no-go recommendation. Columns should capture acceptance question, artifact, accountable reviewer, status, and unresolved condition. This table prevents a charismatic final presentation from hiding missing deliverables and creates a clean handoff into funding or production planning.
What should be ready for production delivery
A positive recommendation should leave a production-oriented first increment ready to start. The team should know the user and workflow boundary, required data access, integration interfaces, evaluation cases, control design, human review, monitoring needs, adoption work, and operating owners. Not every detail must be complete, but the unknowns should be visible and sequenced. The first increment should produce evidence that supports the next release decision rather than attempting the entire target state.
The handoff needs a shared workspace of artifacts and decisions. Include the accepted briefs and maps, source inventory, evaluation materials, prototype code where applicable, architecture records, risk decisions, delivery backlog, and owner list. Confirm access and explain how artifacts are maintained. A handover meeting without usable repositories and decision history transfers awareness, not capability. Client practitioners should have participated throughout so the final transition is a gate, not an introduction.
Hold a production entry review with the people who will fund, build, govern, operate, and adopt the next increment. Walk from the original decision through evidence and open conditions, then ask each owner to accept their commitment. Capture disagreements and resolve them before declaring discovery complete. This review verifies that the recommendation can enter delivery as coordinated work rather than becoming another document awaiting interpretation.
Ngenux structures discovery around workflow evidence, embedded engineering, and an explicit production decision. The aim is to reduce uncertainty while strengthening client ownership, even when the recommendation is to narrow or stop. Request an AI opportunity assessment. To choose the right opportunity before discovery, read Enterprise AI opportunity assessment: How to choose the first use case. To place the resulting work into a broader sequence, read A ninety-day enterprise AI roadmap.
A six-week frame creates focus, but duration alone does not create quality. The engagement succeeds when its outputs connect: the decision brief guides workflow research, the workflow exposes data and control needs, those needs shape architecture and prototype tests, and the evidence supports an owned delivery decision. Leaders should finish with fewer unsupported assumptions, a clearer boundary, and a next action they can explain and govern.
If the recommendation is no-go, preserve the evidence and state what would have to change before reconsideration. If it is narrow, define the exact reduced boundary and the question it tests. If it is go, fund the owners and acceptance gates as well as engineering. Discovery has done its job when the organization can make one of these choices without confusing activity, enthusiasm, or a polished demo with production confidence.
