grok14ENGINEERING FIELD SCHOOL
Curriculum/Module 15
Discover / Week 15

Domain prototyping

Build a small useful prototype, gather realistic feedback, and decide what must change before a pilot.

5 lesson sections16-hour study & practice planModule 14 or equivalent experience

See the system

Build a small useful prototype, gather realistic feedback, and decide what must change before a pilot.

Discover a measurable workflow, build the smallest useful system, evaluate it, ship a tested release, and feed operating evidence back into discovery.
The FDE delivery cycle. Discover a measurable workflow, build the smallest useful system, evaluate it, ship a tested release, and feed operating evidence back into discovery.
Module 15 / Lesson 01

Learn the domain’s decision structure

Domain expertise includes vocabulary, workflow, exceptions, authority, and consequences. A maintenance assistant, procurement helper, and support copilot may use similar retrieval code but require different evidence and review boundaries.

Ask which decisions are reversible, which require expertise, and which source is authoritative. Use synthetic data for learning and obtain qualified domain review before making operational claims in high-stakes settings.

Apply the ideaChoose a domain and list its workflow owner, authoritative source, and consequential actions.
Module 15 / Lesson 02

Time-box around an evidence goal

A prototype should answer a specific uncertainty: can we retrieve the needed evidence, can users verify the result, or can the integration support the workflow? Build the smallest slice that tests it.

State what is simulated and what is real. A polished interface backed by a fixed response can test presentation, but it cannot establish retrieval quality or production integration. Label the boundary so reviewers interpret the demo correctly.

Apply the ideaWrite a prototype question and define the minimal artifact needed to answer it.
Module 15 / Lesson 03

Observe actual user tasks

Give users a concrete task and watch how they work. Ask them to explain confusion, verify an answer, and recover from an error. Leading questions such as “Was that helpful?” produce weaker evidence than observing task completion.

Record task outcomes, review effort, and recurring misunderstandings. Keep sample limitations visible. A few enthusiastic comments are useful feedback, but not proof of organization-wide adoption.

Apply the ideaDesign a 20-minute session with three tasks and neutral follow-up questions.
Module 15 / Lesson 04

Compare against the current workflow

Measure the baseline and assisted workflow under comparable conditions. Counterbalance task order when learning effects matter. Record correctness and rework alongside time, because faster incorrect work is not an improvement.

Report small-study results cautiously and distinguish synthetic exercises from operational pilots. Explain what remains uncertain and which next experiment would reduce that uncertainty.

Apply the ideaCreate a comparison sheet with completion, time, errors, review effort, and notes.
Module 15 / Lesson 05

Make the pilot decision explicit

A pilot needs owners, real access arrangements, representative data, support, success criteria, and stop conditions. The prototype may need major changes before it can meet those requirements.

Use a decision record: proceed, revise, defer, or stop, with evidence and dependencies. Avoid moving into production simply because the demonstration was well received. Reusable assets should preserve tested patterns, not preserve known prototype shortcuts.

Apply the ideaWrite a pilot go/no-go memo with three evidence-backed reasons.

Worked scenario

A manufacturing maintenance prototype retrieves the right manual but users cannot tell which equipment revision it applies to. The next iteration should establish equipment-to-document version mapping and expert review. Adding a more autonomous agent would not address the observed failure.

Practical assignment

This is a practical design or implementation assignment. Use synthetic data. Where managed services are required, verify account access, costs, supported features, and cleanup before provisioning.
  1. Select a support, procurement, retail, or maintenance scenario.
  2. Define one uncertainty to test.
  3. Build a clearly labeled prototype slice.
  4. Run a structured task review with a peer.
  5. Compare results with a baseline.
  6. Submit a pilot decision and unresolved dependencies.

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 dimensionSubmission evidence
CorrectnessShow the expected behavior and a meaningful counterexample.
ReproducibilityState setup, inputs, versions, and what was actually executed.
Delivery judgmentExplain the client impact, alternative, and unresolved assumption.
Operational boundaryIdentify permissions, failure behavior, and any resource cleanup.
Open the lab workbenchGet delivery templates

Knowledge check

1. What should a prototype test?
2. What does a fixed-response mock demonstrate?
3. Which is stronger feedback?

Answer guide
  1. A specific uncertainty. A narrow evidence goal guides scope and interpretation.
  2. Only the behavior it actually simulates. Mocked behavior must be labeled so its evidence is not overstated.
  3. Observed task completion and recovery. Concrete tasks reveal friction and errors.

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.