The LIA project: one system, five milestones
420-302-VA · LIA PROJECT · FALL 2026

Stage 5 of 5 · Being graded · and the last Thursday

Evaluation & demo day

Grading criteria, point values and formats come from the brief on Omnivox, which governs. What this page gives you is the through-line the criteria share, what evaluation is fundamentally looking for, and the protocol that makes the public demonstration a controlled experiment instead of a coin flip.

What is actually graded

Across all five deliverables, evaluation keeps asking three questions, and every rubric line in the brief is an instance of one of them:

Does it work?

The system

The sensing-deciding-acting-showing loop, running, against disturbances you cause. Demonstrated live, never narrated: "it worked at home" is Week 12's forbidden sentence for the rest of the course.

Is it true?

The evidence

The repo backs every claim: tagged states, the verification table with dated greens, contracts in docs/topics.md matching the running programs. Markers can say "show me" at any row; the grade assumes they will.

Do you own it?

The understanding

Each partner can explain any layer and answer the why behind each decision: why this topic grammar, why this rule, why this rung order. Pairs are graded as pairs; a system only one partner understands is half-owned.

Three bands, informally

BandThe systemThe evidenceThe understanding
StrongFull loop against its disturbances; survives a reboot; degrades gracefully when pokedTable green with dates; main walks; a stranger could rebuild from the repoEither partner fields any question; decisions have reasons
SolidLoop runs; some rungs open; needs its builders nearbySpine present, partially filled; some claims demonstrated on the spot rather than pre-verifiedEach partner strong on their layers, thinner on the other's
At riskPieces work, the whole does not; demo narrated instead of causedDocs trail the code; greens that cannot be re-shown; untagged historyAnswers defer to the absent partner or to "it just works"

The bands are this hub's informal reading, a self-diagnosis tool between milestones; the brief's rubric is what produces marks. The honest use: read your project's row every Monday, and let any "at risk" cell pick that week's rung.

Demo day, by protocol

Thursday, December 10, Monday schedule, public: classmates, invited guests, the program's staff passing through. Each pair's slot follows one protocol, the three-step demo shape from Week 12 grown to full size:

The demonstration slot as five blocks on a timeline. Setup, two minutes: system already running as services, dashboard on the projector, verification table open. Frame, one minute: the six slots stated, what we will fight. The live run, four minutes: cause the disturbance, show the system sense, decide, act, and the dashboard tell the story. Proof points, two minutes: two verification rows re-run on request. Questions, three minutes: either partner answers, any layer. A note under the bar: the system runs from the frozen d5 final tag, started from cold power that morning. SetupFrameThe live runProof pointsQuestions services up, pageon the projector six slots, andwhat we fight cause the disturbance; sense,decide, act; the page tells it two table rows,re-run on request either partner,any layer ~2 min~1 min~4 min~2 min~3 min The system runs from the frozen d5-final tag, as services, started from cold power that morning: nobody types during a demo. Slot lengths indicative; the brief's format governs. The shape is the point: frame, cause, show, prove, answer.
A demo is a controlled experiment, performed. The audience watches you cause the disturbance and the system answer it; the dashboard is the narrator. Everything before "Questions" is rehearsed, which is what the week between D4 and D5 is for.

Rehearse, then freeze

Two rules make December 10 calm, both announced since the project opened. The freeze: after the last planned rung lands (D4 week), no new features; the days before D5 are for the rehearsal protocol, re-running every verification row against the frozen tag, twice, including once from cold power. The rehearsal: perform the full slot, timed, at least twice, swapping who speaks when; the second run is where the missing cable, the sleeping laptop and the untested projector resolution get discovered, at zero cost. Demos die of Friday features and first performances; the freeze kills the first cause, rehearsal the second.

When something dies on the day

Hardware has a documented taste for demo mornings, so the protocol includes its own failure modes, and handling one well is itself graded understanding:

  • A sensor dies: the stub inherits its job, announced plainly: "the sensor failed this morning; these are hand-published values on the real topic, everything downstream is live." Five of six contracts still demonstrate, and the recovery shows exactly the method the course taught.
  • The network misbehaves: the fallback chain from Weeks 2 and 9: the Pi's own hotspot or the phone's, the dashboard on localhost on the projector, the firehose as the visible heartbeat while the page reloads.
  • The whole run wedges: reboot, out loud, with confidence, because the services page made cold boot a tested path: "everything starts itself; thirty seconds." A system that recovers in public earns more trust than one that never got to fail.

Check yourself

Why does the protocol forbid typing during a demo, and which two course pages made that rule achievable?
Typing during a demo means the system cannot run itself, so the audience is watching an operator, not a system, and every keystroke is a new chance to improvise a failure. The rule became achievable the week the bridge turned into a systemd service (Week 12: starts at boot, restarts on failure, no terminal) and the week the dashboard gained its controls (Week 11: the setpoint changes from the page, not from a shell). What remains for hands is exactly what should remain: causing the physical disturbance.
A pair argues rehearsal is wasted time better spent polishing the dashboard. Price both options against D5's evaluation focus.
D5 grades the demonstration and the understanding behind it, so each hour buys: polishing, a marginally nicer page inside a performance that has never been run end to end; rehearsing, the discovery and repair of performance faults (timing, handoffs, the projector, the cold-start path) plus a timed, confident delivery of everything already built. The failure modes rehearsal removes are exactly the ones that zero out a demo slot, while unpolished CSS costs a sliver of one question. The asymmetry is the freeze rule's whole justification; and the verification re-runs during rehearsal double as the evidence face of the grade.
During questions, a guest asks your partner, the dashboard owner, why the node averages 16 ADC samples. What does the protocol expect, and what preparation makes it routine?
The protocol expects the partner asked to answer: pairs own the system jointly, and cross-layer questions are how that is tested. The answer itself is Week 8's: the ESP32's ADC is noisy, averaging n samples cuts the noise's standard deviation by roughly the square root of n, and 16 buys a 4× reduction at negligible cost, which the D-term of any rule downstream is grateful for. The preparation that makes it routine is built into the method: PR reviews across layers, the stand-up, and a rehearsal pass where partners deliberately field questions about each other's side.