Stage 2 of 5 · Choosing and scoping · the brief's logic
The brief, decoded
The brief on Omnivox states what each deliverable must contain; this page explains the shape every qualifying idea shares, and the method for getting your theme into that shape without betting the semester on it. Freedom of theme is real, which is exactly why the tests below matter: they are how you tell an idea that will carry five milestones from one that will fold at D2.
What the system must be
A complete project does four things, continuously, at once: it senses a physical quantity with real hardware, it decides something about what it senses, against a target or a rule that can change, it acts on the world in a way an observer can verify, and it shows its state and history to any browser on the network. The parts talk the way the course's parts talk: the node over MQTT to the Pi, the Pi's programs through the broker to each other, the dashboard over HTTP to the browser. A system missing one of the four is a different, smaller thing: sense-and-show is a gauge, decide-and-act without showing is a black box, and the brief asks for neither.
The six-slot test
The fastest honest test of an idea, from Week 10's vocabulary and Week 11's launch: fill all six slots in one line each. An idea that cannot fill a slot is telling you now, for free, what it would otherwise tell you in Week 14.
Six blanks, one line each, on paper, before any code. The architecture in the middle is already built; the project is what you write in the dashed boxes. Slot 5 is the one beginners skip and markers do not: a demo is a fight against a disturbance you cause on purpose.
From idea to requirements
Filled slots become requirements, and Week 5's five qualities grade them at real stakes now: each line testable, unambiguous, atomic, necessary, feasible. The working translation: every requirement gets a number or an observable event ("the fan starts within 5 s of the reading crossing the threshold", not "the system reacts quickly"), one behaviour per line, nothing you cannot demonstrate on the bench by Week 14. Each requirement also gets a row in the verification table, the A2 habit at project scale: how it will be demonstrated, with what disturbance, and at which milestone. The table lives in docs/ and fills with green as rungs land; the workflow page shows the format, and the brief says which deliverables must include it.
Four idea shapes
Shapes, not assignments, the same four Week 11 opened with; your theme and the brief's constraints decide. Each is the full architecture with a different relationship between rule and world:
Pick the shape, then the theme fills the slots. Each shape passes the six-slot test by construction; the themes under each are the common ones, not the only ones. A pair split between two themes should run the six slots on both and keep the one with the sharper slot 5.
Three scope rules
Skeleton first. By D2, the thinnest end-to-end slice through every component, because faults live at the interfaces and the skeleton flushes all of them in the cheapest week. Week 12's theory page carries the full argument.
Rungs, ranked. Every feature is a rung, ordered by value, and a rung leaves the system demonstrable; anything that breaks end to end for a week is a cliff, not a rung. Climb in order, re-verify old rungs after each new one.
Week 13 is half-width; freeze before D5. The final exam shares D3's Monday, so D3's rung is planned tiny but real, in advance. And the last days before the public demonstration are for rehearsal and the verification run, never for new rungs: demos die of Friday features.
Checklist
Check yourself
Run the six-slot test on "a dashboard that shows the room's noise level with nice graphs". What fails, and what is the smallest repair?
Slots 1, 2 and 6 fill (PV: sound level; topics; dashboard), but slot 3 is empty (nothing decides), slot 4 is empty (nothing acts) and slot 5 follows them down (no fight to demonstrate). It is sense-and-show, a gauge. Smallest repair: add a settable threshold and one verifiable action, a quiet-please LED or a logged alert event, and the disturbance writes itself: make noise, on purpose, in the demo. The graphs survive intact; they were never the problem.
Why does slot 5 ask what you will fight rather than what might go wrong?
Because a demonstration is an experiment, and an experiment needs an intervention you control. "Might go wrong" is a risk list; slot 5 asks for the disturbance you will cause, live, so the audience watches the system detect and answer it: shade the sensor, open the door, block the feeder. A project whose disturbance cannot be caused on demand cannot be demonstrated on demand either, and that discovery is worth making at the idea stage, not on December 10.
A pair wants a theme needing a sensor the kit does not have. What questions decide it, and in what order?
In order: does the brief's constraint section allow added hardware at all (the brief governs); can the sensor be on the bench and verified by D2, since the skeleton cannot wait for shipping; does it speak something the node already speaks (an analog voltage into the Week 8 ADC pattern, or a simple digital line), because an exotic protocol is a seventh contract with no course page behind it; and is there a fallback slot-1 that keeps the same rule and dashboard if it fails. Yes to all four: reasonable. Any no: the kit's sensors have five weeks of troubleshoot tables behind them, and the theme usually survives translation onto one of them.