CLIENT PROFILE
==============

NAME:         Barry
AGE:          86
SEX:          Male
DWELLING:     Apartment, Kingston ON
LIVES ALONE:  Yes
VEHICLE:      Parks in apartment parking lot outside the building

NORMAL DAILY PATTERN:
Active throughout the day. Sleep roughly 10pm to 7am - indoor sensors
quiet during this window is expected and normal. Car use varies -
could be daily or several days between trips. Overnight bathroom/bedroom
sensor blips through the night are normal and expected - this is not
something to flag or comment on unless a night looks meaningfully more
fragmented or restless than the rest of the week.

PELOTON WORKOUT PATTERN:
When LIVRM-KTCHN1 shows high-count peaks of 1,300-1,800+ motion
detections in a 10-minute interval, this is Barry on the Peloton bike.
Identify these clearly in any analysis. Note frequency, timing
(morning vs evening), duration (consecutive high-count windows),
and any change in consistency over the period reviewed.
During winter months this is attempted daily.

SENSOR ROLES (interpret by role, not by fixed name):
Treat sensors by what they do - "the car sensor," "the main daytime activity
sensor," "the sleep-area sensor," "the door sensor" - rather than assuming a
specific name will always be present. Barry occasionally reconfigures, renames,
or swaps sensor hardware (e.g. a portable sensor taken to another location for
a period), and the roles above should still apply correctly to whatever is
currently reporting, without needing an update every time a name changes.

CONCERN FLAG IS NOT A CONCLUSION:
The chip's own "concern level" status (shown in exports as "Last known status")
is a simple, dumb timer - it only means "no sensor has posted in over N hours."
It is not itself an interpretation and should never be treated as one. Your own
reasoning over the actual data and notes is the real analysis - the chip's flag
is just a basic liveness check, nothing more.

DAY OF WEEK:
Always state the day of week for every date referenced in your analysis.
Never use relative terms like "yesterday" or "two days ago" - always use
full date and day of week. Use the report's generation timestamp to
calculate the correct day of the week. Never assume or hardcode it.

REPORT ORDER:
For any multi-day report, always present days in chronological order,
oldest day first, ending with the most recent day. Never present days
newest-first or in any other order.

BEFORE FINALIZING YOUR REPORT - MANDATORY CHECKLIST:
For every day covered in the report, explicitly check the data against each
of these patterns before writing that day's narrative - don't rely on
noticing them naturally while summarizing, actively check for them:
1. Peloton range (1,300-1,800+ in a single 10-minute LIVRM-KTCHN1 reading) -
   if present, name it as Peloton use explicitly, even on an otherwise busy
   or ordinary-looking day.
2. Gap-first outing check (see sys_context.txt, "Gap-First Outing
   Detection") - for every day, scan for 40+ minute stretches where
   neither indoor sensor reported, and classify each one using that
   method (door on both sides = outing, name the likely mode of travel;
   no door on either side = flag as unexplained). Run this for every gap
   found, not just ones near a door event you already noticed.
Run this check for every single day in the window, not just days that look
unusual at a glance - a busy day can still contain a missed Peloton session
or a short outing worth naming. If neither pattern applies to a given day
after checking, no need to say so explicitly - just don't skip the check.

=== PERMANENT NOTES ===
Stable facts about this person. Consider when analysing sensor data.
07-Mar-2026 18:34 - The car noise floor should be set to 600. Below this is
ambient level for apt parking lot - rain is the specific known cause of these
false low-level triggers, not actual car use. Readings at or below 600 during
rain should not be read as driving activity.