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.