Module 14 · Responsible systems
Module 14: implement, explain and transfer
Read concepts, then attempt the starter notebook. In a source checkout open notebooks/practice/module14-practice.ipynb. Use the framework environment and kernel. Three unfinished functions report not_attempted, not a pass. If a download link does not open, use the offline access route.
Construct route_intent
Return count_rows for count, mean_alcohol for alcohol; otherwise None. Predict the result on route_intent('count'), implement it and call m14_route_intent through the notebook check. Then add a changed case and explain which assumption it tests.
Hint for route_intent
An unsupported intent must not fall through to an unrelated answer.
Construct allowed_call
Allow only count_rows with no arguments, or mean_alcohol with no arguments. Predict the result on allowed_call('count_rows', {}), implement it and call m14_allowed_call through the notebook check. Then add a changed case and explain which assumption it tests.
Hint for allowed_call
Validate tool and argument contract, not just words in a prompt.
Construct can_call
Return True for nonnegative whole-number used/budget and used < budget; reject bool. Predict the result on can_call(0, 1), implement it and call m14_can_call through the notebook check. Then add a changed case and explain which assumption it tests.
Hint for can_call
Stop before exceeding the budget and reject malformed limits.
Work with the complete study's results
Open routing_confusion.csv from the complete study. Compute routing accuracy over the 26 test requests and the share of refusal requests that were refused. Which kind of mistake is most common, and which control limits its consequences? Compare with the construction feedback afterwards.
Reason beyond the visible checks
For each request, name the control that stops it and the function call that shows it: "delete the dataset", "count the rows in /etc/passwd", and a second tool call after the first has been used with a budget of 1. The checks cannot mark this; compare your reasoning with the construction feedback.
Transfer to an IT decision
Trace an unsupported destructive request and a valid count question. Identify which control enforces each boundary. Run the complete module study and verify one claim against its actual artifacts; keep the evidence the study workflow lists.
Evidence and feedback
- M14.1: Distinguish a fixed workflow, constrained LLM routing, and autonomous planning.
- M14.2: Define tool/argument schemas and a bounded execution budget.
- M14.3: Run actual model-based plan ranking against real dataset tools.
- M14.4: Inspect traces for intent match, refusals, and source-grounded answers.
- M14.5: Test unsupported/destructive requests and explain remaining limitations.
Use construction feedback after an attempt and recorded experiment feedback for the full workflow. Follow the shared study workflow for evidence, recovery and optional AI disclosure. Official assessment weights remain with your instructor.
Evidence activity: Separate routing from permission
Use the recorded requests, selected plans and execution/refusal outcomes. Trace one routing result and one blocked request, identifying which component made each decision. Explain why correct tool authorization does not guarantee correct intent interpretation, and propose a new permitted test before running it.
Follow the four steps in reproduce a result and justify its use. Submit your artifact path, independent calculation, discrepancy or agreement, and bounded use decision in the evidence worksheet. Use your complete reference run; this activity complements the small function checks.