Model-in-the-Loop Engineering · Capstone brief
ENG-04 · The safety case for handing off
Your academy lab has a single actuator decision a model might trigger — open a damper, divert a part, enable a motor stage, release a brake, or raise a warn-only alarm. Can you write the safety case for letting the model request that action — including the exact conditions under which a human must remain in the loop, the acceptance tests that must pass first, and what you refused to automate?
The question
Your academy lab has a single actuator decision a model might trigger — open a damper, divert a part, enable a motor stage, release a brake, or raise a warn-only alarm. Can you write the safety case for letting the model request that action — including the exact conditions under which a human must remain in the loop, the acceptance tests that must pass first, and what you refused to automate?
System / materials
Pick one teacher-approved plant the teacher names in writing before Checkpoint 1, for example:
- A small conveyor or sorter with one discrete output (gate up/down, push solenoid, or lamp only — not both motion and grasp),
- A greenhouse or HVAC trainer with one bounded actuator step (fan stage, damper position band, or heater enable within a capped range),
- A robotics practice cell where the model may only request a motion that still requires operator confirmation on a physical enable switch,
- Or an approved simulation (Webots, Gazebo, or vendor educational twin) only if the teacher exports the same I/O contract the physical cell would use.
Do not wire unsupervised model output to shop equipment, vehicle systems, or anything that can injure someone without a hardware interlock the teacher controls.
Reference vocabulary (concepts — not a compliance claim):
- ISO 13849 / machinery functional safety — performance level as plain language (https://www.iso.org/standard/69883.html)
- NIST AI Risk Management Framework — map your case to one risk category (https://www.nist.gov/itl/ai-risk-management-framework)
- One page from the teacher’s PLTW / academy capstone rubric that names design review or safety expectations.
Optional model (pick one, keep it small):
- A threshold classifier on one sensor (current spike, distance bin, temperature band),
- A short horizon forecast that only suggests maintenance,
- Or a rule baseline the student must beat with evidence before the model earns a voice.
Expected failure modes
Demo without a hazard list. “Human in the loop” as a slide footer with no testable rule. Two actuators controlled by one model output. Testing on equipment the shop teacher did not approve. Latency ignored — the loop is faster than the model can answer. Treating simulation success as shop sign-off.
Done looks like
A safety-case packet with five pieces:
- Scope sheet — one actuator, allowed states, forbidden states, approved hardware/sim, mentor sign-off line.
- Hazard & effect table — at least four rows: cause, effect, severity, mitigation (hardware interlock, guard, e-stop path, or human confirm).
- Acceptance tests — numbered tests a mentor can run in one period: normal operation, single-fault injection (sensor stuck, model wrong class, comms delay), and human-override path.
- Handoff rule — plain-language “model may request when … human must always …” with timing or quality limits in physical units.
- Refusal log — what the student will not automate (second axis, higher speed, production run, unsupervised nights, etc.).
No requirement to include proprietary PLC code in the portfolio. Logic diagrams or pseudocode are enough.
Five C's
CT: separating “model confident” from “safe to act.” CR: designing the smallest autonomy worth measuring. CO: a peer runs two acceptance tests blind from the student’s script. CM: a one-page safety summary a principal could read. CZ: naming who is in the hazard zone and what happens on wrong actuation.
Mentor role
A controls, mechanical, or manufacturing engineer — or a certified shop / PLTW lead — reviews the hazard table at Checkpoint 1 (before energizing anything new) and the acceptance-test log at Checkpoint 2. Standing instruction: reject any plan without a hardware stop path. School-supervised, both times.
Rubric calibration
R1: one actuator, written approval, bounded states. R2: another student could run the tests from the script. R3: human-only or rule-only baseline named. R4: at least one injected fault and one latency/override case. R5: safety summary fits one page. R6: refusal log has real items, not “I refused to hurt people.”
Two ways this goes wrong
(a) The student wires model output directly to a motor with no interlock and calls it “engineering.” (b) The student writes a beautiful hazard analysis for a simulation they never connected to the acceptance tests — paper safety, not lab safety.
Checkpoint suggestions
- Week 1–2: Scope sheet signed; hazard table draft; baseline rule documented.
- Week 4–5: Acceptance tests on approved hardware/sim; fault injection log.
- Week 7–8: Handoff rule + refusal log; showcase version strips shop-only wiring details if needed.
Credit lane fit
Lane A immediately (engineering academy senior design / PLTW Capstone). Lane B only with a division Internship wrapper and a real host — the brief alone is not HQWBL. No verified credit claim.