From an ambiguous AI initiative to buildable work.

1. Start with the decision, not the demo

A prompt that produces an impressive answer is not yet a product requirement. Begin with the person who must act, the decision they are trying to make, and the consequence of getting that decision wrong. This keeps the initiative tied to an operating need instead of a technology showcase.

Write the intended change as an observable statement. For example: a coordinator receives a complete draft with cited source records and can approve, correct, or reject it before anything is sent. That statement is more useful than “use AI to automate follow-up” because it identifies the user, output, control point, and boundary.

• Who has the problem and who owns the final decision?
• What happens today, including manual work and exceptions?
• What must become faster, clearer, safer, or more consistent?
• What harm could a plausible but incorrect output create?

Decision prompt: If the team cannot describe the changed decision without naming a model, the problem is not yet defined well enough to build.

2. Map the current work and its evidence

Observe the real workflow before redesigning it. The official process may omit spreadsheets, inboxes, copy-and-paste work, informal approvals, or the person who resolves ambiguous records. Those details determine whether an AI-assisted step can be trusted in practice.

For one representative case, trace the trigger through the final business outcome. Record where information originates, which system owns each fact, who changes it, how duplicate or conflicting records are resolved, and what evidence shows the work was completed. Include at least one exception path rather than documenting only the happy path.

• Trigger: the event that starts the work.
• Source of truth: the system or person authoritative for each fact.
• Transformation: what is classified, summarized, generated, or routed.
• Handoff: who receives the result and what they need to continue.
• Exception: what happens when data is missing, contradictory, or late.
• Evidence: the record that lets someone verify the outcome later.

3. Set data and responsibility boundaries before choosing tools

List the data the workflow may use, the data it must never use, and the environments where processing is permitted. Personal, client-confidential, employment, financial, health, credential, or security-sensitive records require deliberate handling. Do not paste confidential or personal records into an external AI service unless the organization has approved that service, purpose, retention model, and access pattern.

Separate assistance from authority. The system may draft, compare, classify, or flag; a named person or deterministic control should own decisions with material business, legal, financial, safety, or employment impact. Define where human review is mandatory and what the reviewer must be able to inspect.

• Allowed inputs and prohibited inputs.
• Approved environments, retention rules, and access roles.
• Outputs that require human review before use.
• Actions the AI-assisted step is never allowed to perform.
• The owner who can pause the workflow when evidence is weak.

Boundary prompt: Could a team member explain where every sensitive field goes and who can see it? If not, stop tool selection and resolve the data path first.

4. Shape the smallest useful end-to-end slice

A small slice should still reach a real outcome. Avoid a disconnected prototype that demonstrates generation but leaves identity, permissions, review, delivery, and recovery for later. Choose one user group, one trigger, one output, and one controlled destination so the team can test the whole path.

Keep the first slice reversible. Use a limited data set, a clear feature switch, and a manual fallback. The aim is not to hide unfinished work; it is to learn from a bounded implementation without making the business dependent on behavior that has not been validated.

• One defined user and business context.
• One complete path from trigger to reviewed outcome.
• A representative set of normal, edge, and unacceptable cases.
• A manual fallback and an owner for intervention.
• A kill switch that does not remove access to the underlying work.

5. Write acceptance criteria around evidence

Requirements should describe what can be observed, not merely what the system intends to do. Include the input state, user action, expected output, permissions, source references, failure behavior, and evidence captured. A result that looks correct once is not enough to prove repeatable operation.

Evaluate content quality and system behavior separately. Content checks may cover completeness, unsupported claims, tone, and required citations. System checks may cover authentication, routing, duplicate handling, latency, audit records, retries, and the inability to take prohibited actions.

• Given a known input state, when the workflow runs, then the expected result and evidence are visible.
• When a required source is missing, the system stops safely and explains the next action.
• A reviewer can trace material output back to the approved source records.
• Rejected output does not silently continue to a downstream system.
• The team can distinguish model uncertainty from an integration or permissions failure.

6. Separate model behavior from system behavior

Model output can vary even when the surrounding workflow must remain controlled. Put deterministic rules around identity, permissions, required fields, destination selection, money movement, external communication, and destructive actions. Use the model only where variation is acceptable and reviewable.

Test the full system with the model unavailable, slow, or unhelpful. The user should receive a truthful state and a usable fallback, not a fabricated success message. Logs should identify the stage that failed without exposing sensitive prompt or record content.

• Model quality: Is the output useful, grounded, and within the requested scope?
• Workflow integrity: Did the correct record, owner, and destination remain intact?
• Control behavior: Did permissions, review, and prohibited-action rules hold?
• Failure behavior: Can the user recover without losing or duplicating work?

7. Make an explicit readiness decision

Close discovery with a decision, not a vague recommendation to experiment. The evidence may support a controlled pilot, another design pass, a non-AI workflow improvement, or stopping the initiative. Each is a valid outcome when it follows from the operating need and risk.

Record the unresolved assumptions, owner, next proof, and expiry date for the decision. This prevents a pilot from quietly becoming permanent production and makes it clear what must be true before scope expands.

Decision prompt: Are the problem, boundary, first slice, evidence, fallback, and accountable owner all explicit? If any answer is no, the initiative is not ready to build yet.