Python basics, local files and running tests. General Intermediate lessons provide preparation.
A computer and Python 3.10+. The supplied standard-library lab needs no API key, network or purchase.
Download the runnable offline builder lab →Start with the idea
Specify the application’s job before choosing a model.
Define allowed inputs, outputs and actions. Try a simple lookup as the baseline. Use generated prose only when it helps, and verify it against the returned record.
Application contract: The required behavior, input rules and explicit success or failure states.
See the example and check your understanding
A made-up teaching example
A guest may read public workshop record P, which starts at 10:00. Restricted record R is not available to the guest. The task needs no sending, file edits or autonomous agent.
Ask yourself
Does an AI model need to decide whether the guest may read R?
Show the explanation
No. Application permissions control access. Return an explicit denial rather than an inferred replacement.
Start with these checks
- Use only permitted records.
- Keep missing and denied states explicit.
- Do not add unneeded side effects.
Use the different practice case below and check every requirement in its full instructions.
Full learning objectives
- Separate model behavior from deterministic rules.
- Specify success and failure states.
- Choose a baseline before adding AI.
Captions appear here during playback.
Specify an application before choosing a model
Specify the application’s job before choosing a model.
Video playback is unavailable. Read the descriptive transcript below, go directly to practice, or open the video file.
Source-based teaching example · Fictional data · Reviewed 2026-10-03. Microsoft Mark · locally synthesized. On a small screen, use fullscreen for diagram details or read the transcript.
Read the descriptive transcript
0:00 · What you will learn
Specify the application’s job before choosing a model.
What appears on screen
Specify the application’s job before choosing a model.
0:06 · The idea
Define allowed inputs, outputs and actions. Try a simple lookup as the baseline. Use generated prose only when it helps, and verify it against the returned record.
What appears on screen
Define allowed inputs, outputs and actions. Try a simple lookup as the baseline. Use generated prose only when it helps, and verify it against the returned record.
0:21 · One useful term
Application contract. The required behavior, input rules and explicit success or failure states.
What appears on screen
The required behavior, input rules and explicit success or failure states.
0:31 · A worked example
A guest may read public workshop record P, which starts at 10:00. Restricted record R is not available to the guest. The task needs no sending, file edits or autonomous agent.
What appears on screen
A guest may read public workshop record P, which starts at 10:00. Restricted record R is not available to the guest. The task needs no sending, file edits or autonomous agent.
0:47 · Your turn to think
Does an AI model need to decide whether the guest may read R? Pause and decide before continuing.
What appears on screen
Does an AI model need to decide whether the guest may read R? Pause the video if you need more time.
1:04 · Why this answer works
No. Application permissions control access. Return an explicit denial rather than an inferred replacement.
What appears on screen
No. Application permissions control access. Return an explicit denial rather than an inferred replacement.
1:15 · Check 1
Use only permitted records.
What appears on screen
Use only permitted records.
1:20 · Check 2
Keep missing and denied states explicit.
What appears on screen
Keep missing and denied states explicit.
1:25 · Check 3
Do not add unneeded side effects.
What appears on screen
Do not add unneeded side effects.
1:30 · Now try a different case
Open the lesson and try its different practice case. Use every check in the full task. Watching alone does not mark the lesson complete.
What appears on screen
Open the lesson Try the new case Check and revise The full task and its requirements are in the linked lesson.
Watching explains the example. Complete the lesson practice to check what you can do. Explore all visual lessons →
The method
Start with an observable task. Define inputs, permitted operations, output shape and failure states before selecting a model. Use deterministic code for known rules and arithmetic. An AI component is justified when interpretation adds value that can be evaluated. A rule-based baseline makes that value visible.
Draw the system boundary: application, model, files, tools and logs. “Local model” describes inference location, not necessarily every dependency. Record actual capability support rather than assuming every model handles schemas, images or tools. In this pathway, offline fixtures test control logic; they do not measure live model quality or provider latency.
Choose your model, harness and offline route
Text-only assistant
Use supplied text. Ask for a plan or draft; do not claim browsing, code execution or file access that was unavailable.
Tool-enabled application or harness
Record which tools actually run, allowed files and actions, approval boundaries and observable results. Tools are optional unless the task needs them.
Local or cloud deployment
Inspect inference, retrieval, connectors, logs and storage separately. Use only authorized environments for real data; training fixtures are fictional.
Higher-capability or frontier model
Evaluate the exact task and configuration. Capability does not supply missing evidence or grant permission. No provider ranking or guarantee is implied.
Offline alternative
Use the supplied inputs and inspect the worked example manually. Builder exercises use local deterministic Python. No paid account or live model call is required.
Record the exact product/model label when available, tools actually used, inputs, permitted actions, observed output and checks. Live accounts or APIs may have external costs; they are optional and are not used by this page.
Read the general workflow guide →Worked example
Supplied input
Fictional app: answer a guest’s question about a public workshop record. Public record P says starts 10:00; restricted record R says staff briefing 09:00. No network, sending or file edits are needed.
A checked result
Contract: guest lookup may read P only; answer includes record ID; denied, absent and malformed requests have explicit statuses. A deterministic lookup is the baseline. Generated prose is optional and checked against the returned record.
Why this works
The task can work without an agent or a large model. Authorization remains an application responsibility.
Try a different case
Independent task: a library-hours assistant may use public record H: opens 08:30; internal record I: setup 08:00. Write a contract, threat boundary and four acceptance cases. Use builder-lab’s README to identify the six lab stages.
Download this task and checklist →Interactive practice / Fictional fixture
Specify the guest lookup contract
Use the supplied independent case above. Check the bounded decisions, then review your written artifact against the full acceptance criteria.
Everything runs in this browser. No AI model is called and no work is uploaded. Bounded checks cover specific facts and rules. Your writing is not graded: you review it yourself. Practice never marks a lesson complete automatically.
Cover public, internal, absent and malformed requests.
Try the task, run the checks, then revise. Checks are teaching feedback, not an instructor grade.
Observed browser simulation
This trace comes from the bounded local checker. It is not a Python run, model result or production tool execution.
Self-review
Locked. Write every written part, then run the checks. A few words is not an attempt.
This is self-review, not grading. Read our answers, then tick what your own work does. Ticks are optional. They stay on this page and are not saved or sent anywhere. A different answer can be just as good if it meets the lesson criteria.
Your contract and four acceptance cases
A strong answer
Contract: a guest may look up public record H only. The answer gives the opening time and the record ID. The application code checks record scope before any read. A model, if used, only words the answer. Threat boundary: the guest’s text is untrusted and cannot change scope. Cases: 1) guest asks for H: status ok, 08:30, cites H. 2) guest asks for I: status denied, no time returned, I not read. 3) guest asks for an ID that does not exist: status missing. 4) request is malformed or has extra fields: status invalid, no lookup. Baseline: a plain lookup with no model.
A flawed answer
The assistant answers questions about library hours. The system prompt tells it never to reveal internal records. Cases: ask for opening time and get 08:30; ask for setup time and the model politely declines.
What is wrong with it: A prompt instruction is a request, not a control: the model could still be handed record I. There is no case for a missing ID or a malformed request, and no status for any outcome.
Keep or restore your work
Drafts are not saved automatically. Save only fictional practice data. A browser draft may be lost if storage is cleared; download a copy to keep it.
Your steps
- Define guest input, allowed data and output fields.
- Include public answer, internal denial, missing ID and malformed argument.
- Explain where deterministic code suffices and what AI would add.
Check your work
- Guest access to I is denied.
- No inferred opening time replaces H.
- Failures have explicit statuses and no hidden side effects.
After your attempt: review notes and a common mistake
A prompt telling the model “do not read internal records” is not an authorization implementation. The dispatcher must enforce it regardless of proposed text.
Different wording or a different justified decision can pass. Check your work against every requirement; these notes are not an automated grade.
The lab’s reference.py is a worked solution. Run python check.py --reference only to inspect feedback after your attempt; passing the reference does not complete your work.
Explain your approach
What feature would you remove if the baseline already solves the task?
Keep your artifact, one correction or decision, its evidence and one remaining limitation. Nothing on this page sends or uploads your work.
Check your understanding
Choose an answer to see feedback. This is a knowledge check, not instructor assessment.
Review your independent practice
Complete the supplied task before recording progress. Use the acceptance criteria and reveal the review notes after your attempt. Keep your artifact yourself; nothing is uploaded.
Not yet self-reviewed. Completion stays in this browser and does not issue a badge.
Optional deeper study
Explore the related general-course lesson → This opens the existing canonical lesson; it is optional depth, not another copy of this focused task.
Primary references
Revision 2026-10-03. Fictional examples, not observed provider results. Knowledge checks and completion records are self-study aids.