Design-Based Research Capstone

Classroom Presence System

Traditional classroom attendance systems typically rely on a single observation or event to determine whether a student is present, which can be inaccurate and inefficient in determining analytics of actual time in classroom. Our system is intended to provide continuous and accurate tracking of student presence.

Overview

The Problem	Roll call is a snapshot. It misses lost minutes, tardiness, restroom breaks, counseling visits, and early departures all flatten into one present/absent mark, and it costs teacher time every period.
Background	Time leaks in minutes, not just in whether a student showed up at all. Prior classroom-attendance studies (see Project Summary) mostly check recognition at the door; few measure minutes-in-room against a real ground truth.
Research Question	Can classroom presence be measured with zero teacher effort? Design-based research, pragmatic mixed methods. The technology, RFID tap, QR, or face, is a variable under test, not the product.
Current Phase	Cycle 0 of the research design below is done: an RFID tap reliably reaches OCS. See Phases for the build roadmap, the Research Proposal for the full hypotheses and cycle plan, and the Presence System Index for live task tracking across all three inputs.

Team & Workstreams

Three inputs are evaluated in parallel against the same presence engine, one owner each.

Input	Owner	Status
RFID tap	Vibha Mandayam	Working prototype, tracked in #6
QR scan	Ruta Sirdeshmukh	Not started, tracked in #7
Face scan	Kush Shah	Existing system, integration pending, tracked in #8

Research Question & Hypotheses

Hypothesis	Claim	Sanity check
H1	Presence accuracy at least as good as roll call	Low-risk claim, roll call's own bar is low.
H2	Minutes within 2 min of ground truth per period	Genuinely tight for a tap mechanism: accuracy depends on when a student remembers to tap, not continuous sensing. This may get rejected for contact-tap specifically, which would still be a real, useful finding.
H3	Zero teacher attendance actions	Needs a precise operational definition, does one-time tag registration count, or only ongoing per-period actions? As built today, periods are still admin-managed, so this would fail under a strict reading.
H4	A combination of inputs beats any single input	Supported by the sensor-fusion literature already cited, but a poorly correlated combination can introduce more failure points than either signal alone. Testing this, not assuming it.

Design-Based Research Cycles

Each cycle: question, build, test, analyze, reflect, repeat if it fails.

flowchart LR
		C0["Cycle 0, done
RFID reader to OCS
Tested: can a tap reach OCS?
Issue #3"] --> C1["Cycle 1, tests H2
Input-agnostic API, roster, minutes
Measure roll call baseline
minutes correct?"]
		C1 --> C2["Cycle 2, tests H3
Who's missing view and report
Short class trial, RFID only
teacher does nothing?"]
		C2 --> C3["Cycle 3, tests H4
Add QR or face to same API
Side by side with RFID
which input wins?"]
		C3 --> C4["Cycle 4, tests H1 + main
Classroom pilot
2 to 4 weeks, one class
H1 to H4 decided"]

Cycle 1 requires an input-agnostic API. What's built today (Technical Detail) is explicitly RFID-shaped, an /api/rfid/scan endpoint and an RfidTag model in OCS. That needs generalizing to a generic presence-event API before QR or face can plug into the same pipeline in Cycle 3. Flagged now so it's planned rather than discovered mid-cycle.

The Intervention Being Tested

flowchart LR
		RFID["RFID tap"] --> API[One Event API
student, room, time, direction]
		QR["QR scan"] --> API
		FACE["Face scan"] --> API
		API --> ENGINE[Presence Engine
+ bell schedule + roster]
		ENGINE --> MISSING["Who's missing now"]
		ENGINE --> MINUTES["Minutes report"]

RFID tap, QR scan, and face scan are the independent variable. Who's missing now and the minutes report are the dependent variables, measured against ground truth below.

Evaluating Against Ground Truth

Ground Truth	A student observer hand-logs every entry and exit; a second observer checks them, a standard dual-rater design.
Measures	Agreement rate, minutes error, teacher actions per period, missed and false events per input, teacher and student survey.
Findings	Each hypothesis is accepted or rejected, with limitations and design lessons carried back into OCS, not just a pass/fail on RFID.

The hand-logging ground truth is new data collection beyond what the existing privacy and governance decisions (Project Summary) currently cover, opt-in face scanning and team's-own-data-only testing. It needs its own consent treatment before the Cycle 4 classroom pilot runs, not an assumption that it's already covered.

RFID + Camera Target Architecture

This is the correlation design for the RFID and camera tracks specifically, the most-developed of the three inputs. QR follows the same event API once it's generalized in Cycle 1.

flowchart TD
		BS[Bell Schedule] --> CP[Class / Period]
		CP --> REG["Registration:
Student + Face + Computer + RFID Tag"]
		REG --> RFID["RFID System
Front door / Back door / Room"]
		REG --> CAM["Camera System
Spatial presence, face-scanning system"]
		RFID --> CORR[Correlation / Intelligence Engine]
		CAM --> CORR
		CP -. expected enrollment .-> CORR
		BS -. attendance window .-> CORR
		CORR --> PRES[Attendance / Presence State]

This is the target architecture the team is building toward across four phases; the current prototype implements the leftmost slice of it. Full detail, including the presence-state machine and data model, is on the Technical Detail page. Design rationale and a literature review of comparable systems, confirming this approach against prior work, is on the Project Summary page.