Capstone: Build and Teach Your Own OT Module

Every earlier lesson in OT-101 handed you a finished module: someone else had already picked the topic, written the objectives, built the simulation, and drafted the quiz. This lesson flips that. You are the instructional designer now. You will take one OT/ICS concept from anywhere in this workshop — or one from your own program — and carry it through the same design process this course's lessons were built with: write objectives before you write content, design the assessment before you design the activity, and build the hands-on piece as a simulation, never as a live-equipment exercise. Then you teach a short segment of what you built to your colleagues and take their critique, and give critique back.

This capstone has four required artifacts and one required performance:

• Learning objectives for your module — 4 to 6 of them, each written with an observable, measurable verb.
• One hands-on simulation or lab activity that directly practices one of those objectives, built or specified as simulation-only.
• An assessment with a rubric — not just a quiz key, but criteria and performance levels a student or a peer reviewer could apply consistently.
• A written safeguards statement — the same kind of commitment this course has modeled in every lesson: no live or energized equipment, no offensive tooling, no real vendor or student data.
• A micro-teach — you deliver a short segment of your module to a small group of peers and receive structured feedback against a shared rubric.

Learning objectives

By the end of this 4-hour capstone session, you will be able to:

1. Write 4 to 6 measurable learning objectives for an OT/ICS topic of your choosing, each using an observable Bloom's-taxonomy verb.
2. Design a hands-on, simulation-based lab activity that gives direct practice toward one of those objectives without requiring live or energized equipment.
3. Construct an analytic rubric with clearly differentiated performance levels for assessing a teachable module.
4. Draft a safeguards statement addressing equipment safety, offensive-tooling boundaries, and data handling for a module intended for community college students.
5. Deliver a short micro-teach segment of an original module and give specific, actionable peer feedback in return.
6. Evaluate a peer's module packet against a shared rubric and justify a rating using rubric language rather than general impression.

Learning Objectives are statements describing what a learner will be able to do — using an observable, measurable verb — by the end of a lesson or module. They are the anchor of backward design: the practice of writing the objective first, then the assessment that would prove a learner met it, and only then the activity that gets them there. Every lesson in this course, including this one, was built in that order. A module built the other way around — activity first, objective written afterward to match whatever the activity happened to produce — tends to produce a fun hour with no defensible answer to "what exactly did they learn."

The single most common failure at this stage is an objective built on a verb that can't be observed. "Understand," "know," "appreciate," and "be familiar with" describe an internal mental state — you cannot watch a student understand something, and you cannot grade understanding directly. You can only grade what they do that you take as evidence of it: explain it in their own words, identify it in a diagram, configure it correctly, evaluate a scenario using it. Bloom's taxonomy exists to give you a working vocabulary of verbs at different cognitive levels, from recalling a fact up through creating something new, so that the verb you choose actually matches the depth you intend to teach and assess.

Quick check — four key terms from this capstone

Press each card to reveal how the term functions in this lesson before you read further.

Worked example — turning a vague goal into measurable objectives

A participant wants to build a module on detecting an unauthorized setpoint change at Ironwood Precision Manufacturing's (fictional) mixing line — the same scenario family this course's own thermal-attack material draws on. Their first draft objective reads: "Students will understand how setpoint attacks work." That sentence cannot be observed or graded as written. Rewritten with Bloom's verbs and scoped to a 90-minute module:

• Explain why a setpoint change at a thermal-processing PLC can be a safety-relevant event even when no alarm has yet fired. (Understand level, made observable with "explain.")
• Identify, from a historian trend, the point at which an outlet temperature deviates from its commanded setpoint. (Apply level.)
• Configure a simulated alarm threshold that would have caught the deviation earlier without producing nuisance alarms during normal operation. (Apply/Analyze level.)
• Evaluate whether a proposed containment action (pausing the batch vs. alerting the operator only) is appropriate given the process state described in a short scenario. (Evaluate level.)

Every one of those four can be watched, timed, and scored. None of them require the grader to guess at an internal mental state.

The backward design loop

Lab Design is the process of building a hands-on or simulated activity that gives a learner direct practice with one specific objective, scoped so it is safe, repeatable, and requires nothing beyond a browser. Every simulation embedded in this course — the triage simulators, the mapping labs, the compliance checkers — was designed by picking one objective first and then asking: what is the smallest interaction a learner could perform, entirely client-side, that would produce direct evidence toward that objective? A lab that's engaging but doesn't map back to a specific objective is entertainment, not assessment evidence.

Three design constraints apply to every lab you build for this course, and they aren't negotiable:

• No live or energized equipment, ever. If your module concept genuinely requires touching a real PLC or panel, the lab must be redesigned as a simulation or restricted to isolated bench hardware under direct instructor supervision — never assumed to run unsupervised on production equipment.
• No offensive tooling. A lab may show the effect of an attack (a setpoint drifting, an alarm firing) as a pre-scripted or simulated scenario. It may never hand a learner a working exploit, a real malware sample, or step-by-step instructions for compromising a real system.
• Runs entirely client-side. No live network calls, no real equipment interaction, no dependency the learner has to install. This is what makes a lab shareable as a single self-contained file, and it's what makes the safety guarantee actually true rather than just stated.

Worked example — from objective to lab, at an unnamed water utility

Take the objective "Configure a simulated alarm threshold that would catch a tank-level deviation earlier without producing nuisance alarms." Working backward from that single objective to a lab spec:

1. What evidence proves the objective was met? The learner sets a threshold value; the simulation replays a known deviation event; the chosen threshold either catches it with acceptable lead time or it doesn't, and the simulation says which.
2. What is the smallest interaction that produces that evidence? One numeric input (the threshold), one "run scenario" button, and a result panel showing where the alarm would have fired against a pre-recorded tank-level trend.
3. What has to be pre-scripted rather than "real"? The tank-level trend itself — a fixed, fictional data series for a water utility's clearwell level, not a live SCADA feed — so every learner sees the identical scenario and results are comparable.
4. What's the safety flag? A visible line stating the trend is simulated historical data, not a connection to any real utility's system.

A Rubric is a scoring tool that names criteria and describes performance levels for each one, decided in advance, so that any rater — an instructor, a peer, or the student self-assessing — applies the same standard to the same evidence. Without a rubric, two reviewers scoring the same module packet can arrive at wildly different judgments, not because they disagree about quality, but because they never agreed on what "good" meant in the first place. An analytic rubric (separate criteria, each scored independently) is preferred over a holistic rubric (one overall impression score) whenever you need to tell a learner specifically which part of their work to improve — which is exactly the case for a module packet with four distinct artifacts.

Worked example — the capstone module rubric

This is the actual rubric your module packet will be scored against in Section 9. Read it now, before you build anything in Part B — a rubric is only useful to the person who sees it in advance.

Peer Review is a structured process in which learners critique one another's work against a shared rubric or protocol, rather than offering unstructured opinion. It only works when three conditions hold: reviewers apply the same criteria (the rubric from Section 3), feedback is specific enough that the author knows exactly what to change, and the process has a defined structure — who speaks when, for how long — so it doesn't collapse into whoever talks first or loudest.

Feedback quality sits on a spectrum. "This was good" and "I liked it" are reinforcing but not actionable — the author learns nothing about what specifically to keep doing. "Your rubric's Meets-level language for the simulation criterion is vague — 'works well' isn't something a second rater could apply the same way twice" is specific, tied to a named rubric criterion, and gives the author an exact next step. The second kind is what a peer-review protocol is designed to produce on purpose, rather than hoping reviewers happen to give it.

Worked example — the same lab, two kinds of feedback

A peer reviews a colleague's module built around Cascade Summit Electric's (fictional) substation monitoring scenario:

Your safeguards statement — the fourth required artifact — is peer-reviewable the same way. A reviewer checking it against the rubric in Table 1 should be able to point at your module's specific activities and confirm each one's safeguard is named, not just find a single sentence claiming "this is all simulated" at the top of the document with no detail underneath.

Choose one OT/ICS concept — from an earlier lesson in this course, or from your own program — narrow enough to teach in 60–90 minutes. Draft all four artifacts below as plain text; polish and formatting are not scored (Table 1). Work individually for this section; you'll trade drafts with a partner in Section 7.

Calibration is the practice of multiple raters scoring the same sample against the same rubric and comparing results before rating independently — it's how peer reviewers and instructors converge on what "Meets Expectations" actually looks like in practice, not just on paper. Below are three fictional excerpts of a Safeguards Statement, the fourth rubric criterion from Table 1. Rate each one, then compare your rating to the instructor-calibrated rating and rationale.

Before you give feedback on a partner's draft from Section 5, classify each sample comment below into the category it actually belongs to. One category is not like the others: a comment that flags a genuine safeguards violation needs to go to the instructor, not just sit in a peer's feedback notes.

In groups of four, each participant delivers an 8-minute micro-teach of one segment of their module — typically the analogy, the objectives framing, or a short walkthrough of the simulation concept from Section 5. This is not the full module; it's enough for your group to give you real, rubric-anchored feedback before you finalize your packet.

Your capstone submission is a single module packet containing the four artifacts from Section 5's workshop, revised using the feedback you received in Section 8: your learning objectives, your hands-on simulation specification, your rubric, and your safeguards statement. It is graded against Table 1 in Section 3 — the same rubric you practiced calibrating against in Section 6 and applied to a peer in Section 8.

• Each of the four criteria in Table 1 is scored independently — Approaching, Meets, or Exceeds — the same way you scored the fictional excerpts in Section 6.
• Your instructor's score and rationale will use rubric language directly, the same pattern modeled in Table 2's actionable-feedback column.
• The micro-teach itself is not separately graded on delivery polish; it exists to surface feedback you can act on before final submission.
• Revision based on peer or instructor feedback is expected and rewarded — a packet that visibly incorporated Section 8's critique is evidence of Objective 6 in action.