Lesson 22: Data and Decisions, Instructor Session Plan

Lesson 21 wired the network. This lesson decides what crosses it. The one outcome every student must leave with: response time between systems is a physical design constraint, not a software setting, and it travels back through belt speed, gap, and scan-to-divert distance. If a student can recite the three-part handshake but "fixes" a doubled latency by editing only the software, the lesson hasn't landed. Don't lecture the handshake off a slide. Build the failure table on the board, then run the Ray recalculation live and make the room find every number that moves.

Run of Show (60-minute baseline)

Segment	Min	What happens
The email that changes the design	7	Read Ray's correction email aloud. The confirmed number is 1 second, not the half-second placeholder. Land the jolt: because response time is physical, a lot of the design that hung off the half-second just moved. This is the Ray payoff. Don't resolve it yet, just open it.
Three data questions and two flows	11	Put the three data questions on the board: what information, where from, who decides. Then separate information flow from product flow. The carton moves down the belt; the query and answer move across the network. The trick is getting the data to finish before the product arrives at the divert.
The handshake and the failure taxonomy	14	Build the three-part handshake as a table on the board: request, response, confirmation. Then fill the failure column with the class, all six modes. Push every student to explain the handshake in plain language. Key teaching moment, below.
Latency, contracts, and governance	14	Response time as scan-to-divert distance over belt speed. The interface contract: payload, timeout, retry, failure behavior. Data governance: event IDs, idempotency, reconciliation, hung on the confirmation step. Run the Ray recalculation live here. Key teaching moment, below.
Riverside worksheet and interface map	12	Students produce both artifacts live at their own belt speed: the latency budget worksheet and the interface map. Make them defend the lever they'd pull if the distance doesn't fit. Riverside facilitation, below.
Forest and close	2	Response time is physical. The interface map and latency budget are two pages of the controls package. Close on the driving question.
Total	60	Baseline session. Expand with the stretch option below if you have 90 minutes.

Stretch option (for a 90-minute block):

A second sort point (add 30 min): hand the room a different sort point with a different belt speed and a different scan-to-divert distance, and have each student produce a second latency budget worksheet. Running the method twice, on numbers that behave differently, is what turns the worksheet into a tool instead of a one-off. Have them compare which lever each situation forces.

KEY TEACHING MOMENT | TWO MOVES

Move one: plain language. Have every student explain the three-part handshake with no jargon and no acronyms. Request, response, confirmation, in words a warehouse manager would follow. A student who can't explain it without acronyms can't have the conversation with a customer's IT team, and that conversation is the job. Do not accept a recitation of the layer names. Make them narrate what actually moves.

Move two: run the recalculation live. Hand out the "design just changed" beat. The WMS response time goes from 0.5 to 1.0 second. Have the room find every number that moves. The student who catches the scan-to-divert distance, the belt speed, and the gap all at once has understood that latency is physical. The student who changes one number and moves on has not. Steer with the fact that a response time touches distance, speed, and gap together, and let the ones who only found one number look again.

WATCH-FORS

The failure this lesson is built to prevent is a student who treats data exchange as a software layer someone else owns. Watch for it and drive them back to the physical-constraint principle. Signs:

They treat response time as a software setting to be tuned later. Send them to the belt. The carton's already moving; no line of code speeds up a carton that's past the divert.
They can recite the handshake but not its failure modes. A handshake without its failure column is half a design. Make them name where each part breaks.
They "fix" the doubled latency by only editing the software. Ask what happens to the scan-to-divert distance and the belt speed. That's the whole point of the lesson.
They skip the confirmation step as an afterthought. That step is where inventory accuracy and data governance live. No confirmation, no honest count.

RIVERSIDE FACILITATION | THE LATENCY WORKSHEET IS THE SPINE

The worksheet is the session's spine, not a takeaway. Make students produce the interface map and the latency budget as real artifacts, at their own specified belt speed, and defend the levers they'd pull if the distance doesn't fit. Give them the confirmed facts: 1-second response, scan trigger at the leading edge, transmit point 24 inches downstream, 0.25-second divert actuation. Then get out of the way and let them run the method.

Expect two honest outcomes. A student who picked a slower belt finds the distance covers the budget with room to spare. A student who picked a faster belt finds it doesn't, and now has to name a lever: more distance, a slower belt, or a bigger gap. Both are correct work. The wrong answer is a student who forces the fit by fudging a number instead of naming the trade. The illustrative 120 FPM figure on the worksheet shows the method; hold students to their own speed, not the example.

CHECKPOINT ANSWER KEY | NOT IN THE STUDENT FILE

Maximum response time and the levers. The method: the response window is the scan-to-divert distance divided by the belt speed, in consistent units. Convert the belt speed to feet per second, then divide the 15 feet by it. The source's own worked figure: at 150 FPM, which is 2.5 feet per second, 15 feet divided by 2.5 is 6 seconds, so the upper system has to answer inside 6 seconds. Look for the method and the unit conversion, not a memorized number. If the upper system can't answer that fast, the design options are all physical: lengthen the scan-to-divert distance, lower the belt speed, or open the gap. A strong answer notes both teams own that number and that the fix is cheap during design and expensive at commissioning. Don't accept "make the software faster" as the only answer.
The handshake, part by part. A complete answer names one failure and one cost for each of the three parts. Request: a no-read (barcode unreadable) or a timeout (no answer in the window) sends the carton to the hospital lane, which costs exception-handling labor and, if that lane's undersized, a sorter backup. Response: a wrong destination is a misdirect (a carton to the wrong carrier, a misship and a chargeback); a delayed response means the carton's past the divert and the sort's missed. Confirmation: no confirmation means the upper system doesn't know the carton landed and inventory accuracy slips; a false confirmation records a jammed carton as a success and puts phantom inventory in the system. Look for the cost tied to each failure, not just the failure named. A student who resolves the exception routing here has jumped ahead; that design is the next lesson, and naming it as deferred is the correct move.

INSTRUCTOR ONLY | DO NOT SHARE WITH STUDENTS

This beat is the payoff of the Ray thread that was seeded back in Lesson 18, when the WMS response time was logged as an open item that would come back. It came back today. Students who kept a running Riverside note have the half-second placeholder written down and can see exactly what the confirmed number changes. Don't preview the thread's origin to a student who hasn't connected it. Let them find it. The recalculation lands hardest on the ones who realize they'd been carrying an unconfirmed number for four lessons.

The two artifacts they build today, the interface map and the latency budget worksheet, are the required deliverables of this lesson and central pages of the capstone controls package. Frame them as normal project work, not as a graded exercise. The students who treat them as real deliverables now are the ones who'll have a controls architecture summary ready when the capstone asks for one.