Guest actions need distinct records from family members'

What it is

Household activity records — who unlocked the door, who changed the thermostat, who viewed the camera and when — must keep guest behaviour attributed separately from family members'. When the two merge, two things break at once: accountability ("who touched the thermostat while we were away" becomes unanswerable, or answers wrongly point at a member) and privacy (a guest's traces in someone's home settle permanently into the hosts' records, saved and exported along with the household retention policy).

Separation presupposes independent credentials: a record's attribution power is decided entirely by the credential structure of the grant. When every action logs under the owner's account, "guest" is not a category the records contain.

Why it happens

The mechanism of attribution failure is blunt: the log's attribution key is the credential. A guest acting through the master account logs as "the owner"; entering through a shared PIN logs as "someone". Two systematic errors follow —

Grafting: guest actions land under a member's name. In later investigations (something missing, a device altered), the timeline points at an innocent family member; the log itself plants the seed of a domestic dispute.

Degradation: the action is recorded but subject-less ("door opened by unknown code" under a shared PIN). The record exists yet cannot answer "who", returning the investigation to the no-record state while charging the cost of digging through logs.

The privacy mechanism runs the same way: with a personal credential, a guest's behaviour is separable — it can carry a shorter retention window aligned to the grant and be cleared at expiry. A visit's traces need not persist at household depth and duration. Under shared credentials this separation is structurally absent: guest data and family data fuse at the entry point.

Where it stops holding

• The traditional-key baseline is a meaningful floor. Physical keys were never attributable and society ran for centuries — demanding "every entry accountable to a person" exceeds a guest's reasonable privacy expectations (biometric entry for the cleaner is cost wildly disproportionate to threat). The sane target is category-level attribution (family / which guest), not identity-proofing everyone.
• Retention policy is policy, not technology. After an incident the owner wants longer records; day to day the guest wants shorter traces — both legitimate, the boundary varying by jurisdiction (data minimization versus evidentiary need). What the system can do is make both sides configurable and declared; deciding for either is overreach.
• The record's own visibility must converge. If any admin can browse the "who entered when" list at will, what is recorded is not just guest behaviour but the entire relationship history between guest and household — the first act of separation is often restricting who may see the separation.

Applying it

• Issue credentials per person (keypad code / temporary account / NFC), building the attribution key into the granting moment — without independent credentials, everything downstream is empty talk.
• Give guest activity a separate section and filter in the activity log: a one-tap "guests only" view; the family timeline excludes guest events by default, preventing grafting-style misreadings.
• Guest records get shorter retention than family records, aligned to the grant's expiry; when cleared, leave the owner's log a detail-free summary ("authorization ended and cleared").
• Provide an incident-reconstruction view: the after-the-fact question "who was here that afternoon" answers on one page (visit window, entries, devices touched) without the owner writing queries.
• How to check: drill a standard post-incident question — "who changed the thermostat on the Tuesday afternoon we were out" — and time whether the owner gets the correct answer from the log UI within one minute. Wrong answers (grafting), absent answers (degradation), or timeouts (unusable) all count as failures.

Related

• Same group: Z4.08.1 Guest access should default to least privilege with an explicit expiry · Z4.08.2 After expiry, access must revoke automatically · Z4.08.4 Over-complicated granting makes owners share the master account
• Nearby: Z2.04 Presence and identity · Z6.06 Passive collection and informedness
• Search terms: audit trail attribution · guest activity logs · accountability · smart home