See the system
Turn an ambiguous AI request into a scoped project with a workflow owner, a baseline, and evidence of value.
Start with the workflow
A request such as “build a support agent” describes a possible solution before explaining the problem. Reconstruct one recent task: what triggered it, which person handled it, which systems they opened, what decisions they made, and where they waited. A delay caused by missing approval will not necessarily improve with a better language model.
An FDE works through discovery, data inspection, prototyping, evaluation, integration, and operation. The deliverable includes code, but also decisions, tests, and a handoff that another team can use. The prototype should make the next decision easier: continue, narrow the scope, change the approach, or stop.
Interview the people doing the work
Speak with operators, the business owner, a domain reviewer, the technical lead, and the person responsible for access. Each sees a different part of the system. Ask for a recent example rather than a prediction about whether people would like AI.
Keep four categories in your notes: observed facts, stakeholder claims, hypotheses, and decisions. “The API permits updates” remains a claim until verified. If stakeholders disagree about the current policy source, record the conflict and assign an owner to resolve it. Hidden disagreement turns into inconsistent product behavior.
Choose a useful first use case
Compare business value, technical feasibility, data readiness, and consequences of failure. A scoring sheet structures discussion, but a positive average cannot remove a blocking access restriction. Include a conventional software or process alternative.
For support operations, cited policy search may be a better first pilot than automatic ticket closure. It lets staff validate evidence while the team learns about document quality. Ticket routing may be adequately solved by explicit rules. Choose the smallest scope that can produce useful evidence under the available constraints.
Define a baseline and acceptance contract
Separate technical quality from workflow and business outcomes. Citation correctness, task success, review time, and adoption answer different questions. An excellent model score does not establish that the user finishes work faster.
Specify the workload, measurement method, reviewer, denominator, and evaluation conditions. Preserve a held-out set that is not used to tune prompts. Stakeholder estimates can inform planning, but label them as estimates until measured. Agree on acceptable errors and operational boundaries before choosing thresholds.
Write the delivery brief
A brief connects the business problem to an implementable scope. Include users, the accountable owner, authoritative data, integrations, access rules, acceptance criteria, dependencies, risks, milestones, and handoff responsibilities. Explicitly distinguish pilot features from future ideas.
Milestones should produce evidence. “Working retrieval with passing department-access tests” is more useful than “AI complete.” When the client requests a change, record its reason and impact on acceptance criteria, effort, dependencies, and schedule. A decision log keeps distributed teams aligned.
Worked scenario
Harbor Service Operations is a fictional team of 12 analysts handling approximately 600 internal tickets per week. Its manager estimates that 30% concern policy questions and search takes 8–15 minutes; neither estimate has been validated. Analysts find conflicting policy copies. Start with authorized policy search and staff-reviewed drafts, verify the authoritative corpus, and collect step-level baseline data before claiming savings.
Practical assignment
- Map the current task and its exceptions.
- List stakeholder claims and assign validation owners.
- Compare three possible interventions, including a non-AI option.
- Choose a pilot with explicit access and action boundaries.
- Define technical, workflow, and adoption measurements.
- Submit a brief, assumption register, and five-minute demo narrative.
What to submit
Submit the artifacts named above, a short explanation of your decisions, and evidence of the checks you performed. Distinguish measured results from estimates and designs from executed integrations.
| Review dimension | Submission evidence |
|---|---|
| Correctness | Show the expected behavior and a meaningful counterexample. |
| Reproducibility | State setup, inputs, versions, and what was actually executed. |
| Delivery judgment | Explain the client impact, alternative, and unresolved assumption. |
| Operational boundary | Identify permissions, failure behavior, and any resource cleanup. |
Knowledge check
Answer guide
- A measurement collected using a defined method. A reproducible measurement establishes what was observed and how; an estimate remains useful but provisional.
- Resolve authorization before using the data. Authorization is a prerequisite. Use synthetic fixtures while the dependency is resolved.
- Performance under the stated evaluation conditions. Workflow effects and business outcomes need separate evidence.
References & next step
Platform examples are environment-dependent. Start with the official documentation in the reference library and verify the exact cloud, region, privileges, and versions you use.
Open the official reference library
Editorial edition: 5 October 2026. The local reference lab is executed locally; this course does not claim a live Databricks deployment.