DRIFT — Personal Digital Twin for Student Drift Detection

Industrial systems don't fail suddenly — they drift out of calibration first. DRIFT applies that same monitoring logic to a student's academics, career, wellbeing, and finances.

Comment

Inspiration

I'm a first-year Mechanical Engineering student, and the qualifier feedback on my first submission was blunt: too surface-level. So I asked myself what I actually know that most undergrad teams building "AI productivity tools" don't. The answer was reliability engineering — the discipline behind predictive maintenance, FMEA, and digital twins, which I'd already used to build a smart-factory monitoring platform (FactoryOS) earlier this year.

Industrial systems rarely fail without warning. They drift — slowly, measurably, out of calibration — long before something breaks. Nobody applies that exact discipline to a person. So I built DRIFT: a personal digital twin that monitors a student the way an engineer monitors a machine, watching academics, career readiness, wellbeing, and finances as four interdependent subsystems instead of four disconnected checklists.

What it does

DRIFT runs a full reliability-engineering pipeline on self-reported data:

  1. Calibration — a 5-section sensor form (15 inputs across the four subsystems) plus a personal target profile.
  2. Drift scoring — each subsystem gets a weighted health score, with cross-subsystem penalty coefficients (e.g. sleep below 6 hours measurably penalizes career readiness, not just wellbeing — drift cascades the way it does in a real coupled system).
  3. Root-cause trees — every score breaks down into the exact inputs driving it and their percentage contribution, the same way a fault-tree analysis isolates a failure mode.
  4. Archetype matching — your four-dimension score vector is compared against 12 synthetic student archetypes (e.g. "Isolated Academic," "Pre-Burnout Overachiever") via nearest-neighbour distance, surfaced with a radar chart and a confidence percentage.
  5. Forecasting — three projected trajectories (Stable / Overloaded / Recalibrated) with a 90% confidence corridor that widens over time, disclosed as a modelled estimate, not a prediction.
  6. Monte Carlo simulation — 500 simulated trajectories to a deadline you choose, returning a real probability distribution per subsystem rather than a single guess.
  7. Counterfactual interventions — toggle real actions (apply to internships, sleep more, drop a commitment) and watch quantified, disclosed-coefficient impacts ripple through the forecast live.
  8. Work orders — auto-generated, prioritised, completable actions, closing the loop from diagnosis to outcome.
  9. Twin Letter — a plain-English decision-support letter a student could actually bring to an advisor.

A System Integrity Index — an urgency-weighted composite, not a flat average — gives the whole twin one number that updates as drift accelerates or recovers.

How I built it

Single self-contained HTML file: vanilla JavaScript, Chart.js for the forecast bands, hand-written SVG for the twin diagram, the dependency map, and the archetype radar chart. No backend, no API calls, no external AI service — every score is a disclosed formula a judge can read in the source. Visually, I deliberately avoided the dark-glassmorphism look every AI tool defaults to; DRIFT is styled as a printed technical field report — warm paper tones, serif/mono typography, an engineering-instrument cursor — because the metaphor only works if it looks like something an engineer would actually read.

Challenges I ran into

Getting the cross-subsystem penalty coefficients to feel like a real coupled system instead of four independent quizzes took several iterations — sleep debt needed to visibly drag down career readiness, not just wellbeing, or the "digital twin" framing would be cosmetic. I also stress-tested every panel against edge cases: a twin with every score maxed at 100 needed to correctly say "all subsystems healthy" instead of inventing a fake concern, and a twin with every score minimised needed to stay numerically stable with no NaNs or runaway values. Several real bugs only surfaced under that kind of adversarial testing — including one where Reset silently corrupted state because of a stale element reference.

What I learned

That "AI" doesn't have to mean a language model. Weighted scoring, rule-based diagnosis, nearest-neighbour matching, and Monte Carlo simulation are a complete, explainable reasoning pipeline — and being forced to disclose every coefficient made the Responsible AI requirement something the product does, not something I wrote about afterward.

What's next for DRIFT

Letting students log actual daily check-ins instead of one calibration snapshot, so drift velocity is measured from real behaviour over time rather than self-report at a point in time; and extending the archetype library using anonymised, opt-in cohort data so the population-level "common pattern" alerts become genuinely statistical rather than illustrative.

Built With

Share this project:

Updates