!Presh

Inspiration

Exam week turns a calendar into a negotiation: another hour of studying, a looming deadline, or time to rest. A calendar can show an open slot, but that does not necessarily mean it is a good time to study. Wearables offer another piece of context, yet a chart alone still leaves students asking, "What should I change?"

We built !presh around that question. Our idea is to connect the work a student has left with recent wearable patterns, then turn that context into an understandable study-plan adjustment. The goal is a plan that can adapt while keeping deadlines, fixed commitments, and protected rest in view.

What it does

!presh is an adaptive exam-week planning prototype. Its dashboard brings together a weekly calendar, remaining study tasks, wearable-context cards, a signal timeline, and a coaching panel. Students can review a proposed schedule change, compare it with the current plan, apply it, and inspect the explanation afterward.

For example, the demo illustrates moving a late-night study block into available time the next day while preserving the amount of work and respecting an earlier exam. When work cannot fit, the proposal identifies the unscheduled minutes instead of silently dropping them.

The current dashboard demonstration uses synthetic scenarios for normal conditions, a replanning trigger, missing data, and an overloaded calendar. Separately, our ingestion pipeline has processed synthetic wearable events in Databricks. Connecting the downstream analytics and agent to the dashboard is the next integration step.

How we built it

Frontend: React, TypeScript, Vite, Tailwind CSS, and Recharts for the calendar, task controls, signal charts, and proposal comparison.
Backend and contracts: Python, FastAPI, Pydantic, and JSON Schema for typed API boundaries, with server-sent events for dashboard updates. The current API serves fixtures and checks versions before applying proposals.
Data ingestion: A Python replay controller normalizes timestamped heart-rate, electrodermal-activity, and accelerometer readings. Databricks Structured Streaming ingests the event batches into Bronze Delta tables, using stable event IDs and insert-only merges to prevent duplicate ingestion.
Planning: A Python validator checks overlaps, deadlines, allowed study hours, protected sleep, and study-minute accounting. The current demo serves prepared proposals; dynamic scheduling remains an integration milestone.
AI architecture: We defined a tool interface for an agent to retrieve evidence, request a constrained replan, and explain the result. Exact time placement belongs to the deterministic scheduler, while the API controls application of the proposal. The current local chat uses fixture explanations.

Challenges we ran into

The hardest problems were at the boundaries. Sensor timestamps, replay time, and calendar time have to agree. Replaying a batch twice must not duplicate events. A missing measurement must remain unknown rather than turn into a convincing-looking zero. A proposed plan must also be rejected if the underlying schedule has changed.

Data provenance mattered just as much as implementation. Our original plan referenced the BIG IDEAs wearable dataset, but the verified ingestion run uses generated data. We keep that distinction explicit: both the current wearable demo and the exam-week context are synthetic. Physiological-load and rest estimates are engineering heuristics, not diagnoses or validated measures of student performance.

Accomplishments that we're proud of

We brought the planning concept into a concrete dashboard with schedule comparisons, explanations, and explicit missing-data states. We also established shared contracts so the frontend, data pipeline, and planning components could be developed against the same definitions.

On the data side, the verified Databricks Bronze run contains 3,890,102 synthetic events. Repeating ingestion left that count unchanged, and the run verified a deliberately planted out-of-range heart-rate quality flag. Those checks gave us tangible evidence that the ingestion path handles retries and flags problematic input.

What we learned

An adaptive planner needs more than a persuasive explanation. It needs a traceable reason for each change and rules that protect the student's commitments. Separating explanation from scheduling makes those responsibilities easier to inspect and test.

We also learned that uncertainty belongs in the interface. Showing an unavailable estimate, a data-quality warning, or unfinished work makes the plan more useful than hiding those limitations behind a confident score.

What's next for !presh

Our next milestone is to connect the verified Bronze ingestion to minute-level Silver features and Gold wearable-state summaries, then feed those states into the backend. We will complete the deterministic scheduling loop and connect a tool-calling model so explanations reference the evidence behind each proposal.

After that, we want to evaluate the workflow with appropriately sourced wearable recordings and student feedback. Real wearable integration and external calendar connections are future extensions. Demonstrating that the system improves rest or academic outcomes would require separate validation beyond this prototype.