No cameras or microphones
Kin Sense uses privacy-preserving ambient sensing for presence, movement, and configured events. It is not an image or conversation archive.
Kin privacy and security center
Privacy is the architecture.
Kin is designed to support care without turning a private home into a place people feel watched. This center explains the data journey, the access model, and the questions that must be answered before a serious deployment.
Security assurance underway. Kin is preparing for SOC 2 and related control reviews. Certification status, scope, and target dates will be published here as they are confirmed.
Privacy should feel like part of the room.Learning close to home
Raw sensor signals, personal sensor data, and inference are intended to stay in the home. Only minimized aggregates and configured events should leave it.
Insights, not observations
The care portal should share a useful summary, a meaningful change, or an alert with context, not a live feed of someone's private life.
01 / Data flow
Every handoff should be explainable.
The intended path is local: raw sensor signals, the personal baseline, and inference stay in the home. Only minimized aggregates and configured events cross the boundary to support alerts and care workflows.
Placeholder architecture diagram
HomeKin Sense sensors
Local inferenceRaw signals and personal baseline stay home
Aggregate gatewayEvents and aggregates only
Care portalInsight and response
02 / Access boundaries
The right people see the right level of context.
Access should follow the care relationship, not the org chart. Permissions, consent, and audit history need to be visible to the people affected.
Placeholder permissions diagram
Person at homeConsent and control
Family carerSees only the agreed insights and alerts needed to support the person.
Care teamUses resident-specific context within an agreed response workflow.
Kin supportMaintains the service without becoming a viewer of private observations.
03 / Data residency
Know where the data travels.
For a private home or a care provider, geography is part of trust. The intended model is that personal sensor data and inference do not travel. Kin should still make the regions for aggregate/event storage, backups, and support access explicit before a customer commits.
Your data should have an address.
The final customer agreement should state that raw sensor signals and personal inference remain local, then name the countries or regions where minimized aggregates and events are stored, backed up, or accessed.
Ask about your region →Placeholder residency route
HomeRaw signals and personal baselineStays local
InferenceEvent interpretationStays local
Aggregate storageConfigured events and summariesRegion: to be confirmed
AccessAgreed carers and supportCross-border access: disclose
Intended residency model: raw personal sensor data and inference stay local. Replace this placeholder with approved aggregate/event hosting regions, subprocessors, transfer mechanisms, and support-access locations.
Local processingRaw sensor signals, personal data, and inference stay in the home.
Transmitted payloadOnly minimized aggregates and configured events leave the home.
Aggregate storagePublish where event and summary data is held and backed up.
Support accessDisclose who can access transmitted data, from which countries, and why.
04 / Data lifecycle
Collected, used, retained, deleted.
Privacy becomes credible when the full lifecycle is concrete. These are the decisions a customer should not have to infer.
Placeholder data lifecycle diagram
01SenseRaw radio reflections stay local
→02InterpretInference and baseline stay local
→03ShareAggregate or configured event only
→04Retain or deleteCustomer-defined policy
Before launch
Questions we should answer plainly.
This page is a customer-facing structure, not a substitute for a completed security review or legal policy.
What is processed on-device?
Document the exact boundary for raw sensing, personal data, feature extraction, model updates, and inference.
What leaves the home?
State the aggregate and event fields explicitly, and confirm that raw personal sensor data and inference do not leave.
How long is it retained?
Publish retention by data class, deletion behavior, backups, and customer export options.
Who can change access?
Show role ownership, approval steps, audit logs, and what happens when consent changes.
What happens when it fails?
Explain outages, stale data, sensor loss, connectivity problems, and escalation responsibilities.
Is transmitted data used to train models?
State the policy directly for aggregates, events, and support data. Customers should never have to guess whether their home becomes training data.
Trust should survive inspection.
Ask us about the home, the data, the people who need to respond, and the controls that keep all three connected.