← Projects

IoT · Anomaly Detection · AWS · 0→1

Perch

Passive Behavioral Monitoring Platform for Elderly Care

IoTAnomaly DetectionAWS LambdaKinesisMongoDBStatistical Baselines
Overview

Perch is a passive elderly care monitoring platform that infers behavioral health signals from commodity motion and door sensors. It detects wake patterns, inactivity, and overnight wandering without cameras or wearables — preserving privacy while providing caregivers with actionable, interpretable signals.

Problem

Existing elder monitoring tools are often intrusive: cameras raise privacy concerns, wearables require active participation, and many systems generate alert fatigue without actionable context. The gap is a passive, ambient monitoring layer that gives caregivers signal — not noise.

Perch addresses this by treating sensor events as behavioral fingerprints. Motion sensors, door contacts, and environmental sensors become a low-resolution but privacy-preserving picture of daily routine.

Constraints
  • Sparse and noisy IoT event streams with variable sensor coverage
  • No cameras or wearables — commodity motion and door sensors only
  • Low household-level data volume, making per-user ML impractical at MVP
  • Safety-critical alerting — false negatives carry real cost
  • Multi-timezone correctness across household deployments
  • Need for interpretable anomaly detection caregivers can trust
Architecture
Sensor Events
Ingestion API
Kinesis
Aggregation Lambda
MongoDB Rollups
Baseline Builder
Periodic Evaluator
Alerts
Evidence Snapshots
Analytics
Key Engineering Decisions
  • Timezone enrichment at ingestion

    All events are tagged with local time at the point of entry, not processing time — critical for cross-midnight behavioral patterns.

  • Idempotent writes throughout

    Every write operation is idempotent by design. Retry storms and duplicate sensor events produce no side effects.

  • Local-day attribution

    Events spanning midnight (overnight wandering, late bathroom trips) are attributed to the correct behavioral day, not calendar day.

  • Rolling 14-day per-household baselines

    Each household builds its own normal. Baselines roll nightly, decaying stale signal while preserving recent patterns.

  • Evidence snapshots for every anomaly

    Every alert is accompanied by a snapshot of the sensor events that triggered it — making every flag auditable and explainable.

  • Continuous evaluator on 5-minute cadence

    The evaluator runs on a short cycle to minimize detection latency without overwhelming the database.

  • Pre-aggregated analytics collections

    Dashboard queries are served from pre-computed rollups, keeping analytics fast without burdening the hot path.

Why No ML Models

At MVP scale, per-household ML models would be chronically underfit. With weeks of data per household and high sensor sparsity, a model would have neither the volume nor variance to generalize reliably.

Statistical baselines were the right call because they are transparent, reliable, and directly aligned with the safety-critical nature of the product. Caregivers need to understand why an alert fired — a deviation from a rolling average is explainable; a neural network output is not.

ML becomes appropriate at scale when per-household data volume grows, cross-household patterns become learnable, and the product has the evaluation infrastructure to validate model behavior safely.

Evaluation & Observability
  • Anomaly evidence snapshots — every alert is traceable to specific sensor events
  • CloudWatch health checks on the ingestion and evaluator pipeline
  • Kinesis pipeline gap monitoring to detect sensor dropout
  • Baseline history logging for drift detection
  • Analytics-ready MongoDB summaries for dashboard performance
Scaling Considerations

The current architecture is designed for MVP-scale household deployments. At larger scale:

  • Evaluator and baseline workloads move to SQS fan-out per household for parallel processing
  • MongoDB scales with read replicas and cold storage tiering for historical data
  • Kinesis shards partition by household key to maintain ordered event streams
  • The ingestion API horizontally scales behind a load balancer with no shared state
Lessons Learned
  • Production AI systems are often more about data quality, reliability, and evaluation than models.
  • Interpretable baselines can outperform premature ML in low-data environments — and are far easier to debug.
  • Idempotency and timezone correctness need to be first-class design constraints, not retrofits.
  • Evidence capture is not optional in safety-sensitive AI systems. Every alert needs to be auditable.
  • The evaluator cadence is a product decision, not just an engineering one — it directly affects caregiver trust.