Operations Checklist Build

Your group writes a checklist. Perfect formatting, every box lined up, and you're confident: "this is obvious." Now hand it to someone who didn't write it. That's today's actual test.

The goal

Build a Competition-Ready Operations Checklist for a fictional Robotnix Arena Lab: eight player stations, one caster station, one broadcast station, two network switches, one shared router/uplink, spare mice, and spare headsets. The lab needs to be ready for a scheduled esports event.

You aren't troubleshooting everything

Week 16 already covered that. This week asks a narrower question: what routine helps you discover problems before the event actually starts?

Checklist architecture

Use at least six sections: lab/power, player stations, network, software plus account, audio/communication, and final readiness test. Add broadcast and shutdown/post-event sections if your scope calls for them.

Lab readiness. Power available, work area clear, required equipment present, spares available. Don't waste time on anything that isn't actually part of the operating need.

Station readiness. For each player station: power, display, keyboard, mouse/controller, headset, operating system — written as observable steps, not vague ones.

Network readiness. Physical connection, expected network connection, required online service, a multi-station spot check. Reuse Week 16's model here rather than re-teaching it from scratch.

Software. Required game installed, expected version, required launcher/service, communication software, and whether updates need to complete before the event window opens — timing matters, since a mid-event update is a very different problem than a pre-event one.

Accounts. Never put passwords on a checklist. Instead, write something like "verify required account can access service," and use only fictional or classroom-safe accounts in any simulation.

Audio. Test output, input, and the voice application itself — not just "cable plugged in."

Final readiness test. After checking individual pieces, test the whole function: join a test lobby, confirm input, confirm audio, confirm network, confirm the expected application. The exact test depends on your environment.

Why test the whole system

Mouse works, network works, game opens, account works — individually — but some combination of them can still fail in actual use. Whole-system verification is what closes that gap, and it's the step most checklists skip.

Add ownership and priority

Each section needs an owner — station tech, network lead, team lead, broadcast lead, kept simple. Add priority levels only if they're actually useful (critical/supporting), and don't turn this into seventeen shades of urgency.

Add failure response

At least five steps need a real failure path, for example: "verify mouse input; fail — use approved spare mouse; retest — confirm input; still fails — move station out of ready status and notify instructor/tech lead."

The blind test

This is the most important part. Exchange checklists with another group. The designers stay silent — no clarifying, no hinting. The testing group gets the fictional lab information and follows the checklist exactly as written, nothing more.

Testers record: unclear steps, missing steps, wrong order, unverifiable steps, missing failure paths, and unnecessary steps.

Hidden failures

Hidden Failure 1. Station 03's headset microphone fails. Did the checklist catch it? If not, it probably only checked "headset connected" instead of actually verifying input — a connection isn't the same as a working function.

Hidden Failure 2. Station 05's game version is outdated. Did the checklist check version, and if so, when — early enough that an update was actually possible before the event?

Hidden Failure 3. Station 07 has working internet but can't access the required game account. Does the final function test catch this, or only the earlier, narrower checks?

Hidden Failure 4. Switch-A affects four stations. Would your checklist detect that pattern, or would it just report four separate, unrelated-looking failures? A multi-station network test is what surfaces the shared cause.

Hidden Failure 5. Everything passes individually, but the final test reveals voice chat input isn't actually available inside the required application. This is exactly why component checks and whole-system verification aren't interchangeable.

Revision

After the blind test, sort the feedback into critical fix, clarity fix, efficiency fix, and optional. Then build Version 2.

Include a short change log — for example: added microphone verification because a tester missed the hidden mic failure and connection alone hadn't confirmed input; moved the network test earlier because software tests kept failing without it, which is a dependency-order problem; removed a duplicate mouse check that verified the same function twice. A change log tied to actual evidence is much stronger proof of real iteration than "we made it better."

Final artifact requirements

Your Competition-Ready Operations Checklist needs: a title; version and date; purpose; simple ownership; ordered sections; hardware, network, and software checks; account/access verification; audio/communication verification; a final whole-system test; at least five failure-response paths; observable completion criteria for every step; one completed blind test; Version 2 revisions; and a short change log.

Format

A Google Doc, a spreadsheet, a slide-based operations board, or an MDX/Fumadocs demo all work — whatever communicates the process most clearly. For an actual operations document, a table or checklist format will usually beat a fourteen-slide presentation. Use the tool that fits the job, not the one that looks most impressive.

The checklist rule

Every item should answer: can another student tell whether this is done? If the answer isn't obviously yes, rewrite it.

Instructor challenge

Your instructor selects one step from your checklist. Answer: why is this included, why is it in this position, what dependency does it protect, how do you know it passed, and what happens if it fails? That's your defense.

One final test

Remove the checklist's authors from the room entirely. Could another group still prepare the lab using only what's written? If yes, you've built shared operational knowledge — which is the whole point of this week.

Before you leave

Complete:

1. The blind test exposed __________ because we assumed __________.
2. Version 2 is more reliable because __________.

Answer with evidence, not "it looks better."

Source note

This project synthesizes Middle Township Unit 5 expectations involving technology operation, reliability, maintenance, repair, usability, integrated systems, and network dependencies.

The fictional Robotnix Arena Lab, the blind-test process, the hidden failures, the Version 1/Version 2 cycle, the change log, and the Competition-Ready Operations Checklist are original Robotnix Academy components.