Kore 11 · Privacy

Privacy and safety

Nothing to hide, because nothing is hidden.

A system that watches a home must answer hard privacy questions before it ships. These are our answers, written while the system is still a plan: every safeguard is labeled PLANNED or IMPLEMENTED, and nothing is implemented.

Pre-prototype. Every visual is concept imagery.

Sensor data collection · Planned, not implemented

What the concept would collect.

This page describes the design intent for a system that does not exist yet. Nothing is implemented, so no data is being collected by Kore today. Every safeguard below is marked PLANNED or IMPLEMENTED.

Status key:PlannedImplemented: nothing
Data

Environmental readings Planned

Temperature, humidity, pressure, and VOC/air quality readings from the room, sampled on a fixed cadence. Used for thresholds, baselines, and the documented record.

Implemented: nothing. No device exists to take these readings.

Data

Motion and presence events Planned

Motion events from PIR sensing and presence patterns over time, so the system can learn the room's rhythm and notice meaningful absences.

Implemented: nothing. Presence sensing is a planned capability.

Data

Camera footage Planned

Stills or short clips captured on event triggers for visual documentation. The flagship configuration includes cameras; a camera-free configuration is planned for schools, churches, senior living, and similar sensitive settings.

Implemented: nothing. No camera is recording.

Data

System health logs Planned

Device status, sensor errors, and alert history, so failures are visible instead of silent.

Implemented: nothing. No logs exist.

Cameras and audio · Planned functionality

Cameras are the flagship. Consent is the rule.

Kore is being designed as a full ultra-surveillance system, cameras included, for unmatched safety and documentation. Both camera and audio functionality below are planned; neither is implemented.

Sensing

Camera functionality Planned

Planned: cameras capture visual documentation on event triggers, stored locally first, viewable by the owner on the phone dashboard. Planned: recording indicators and clear on-device controls for when cameras are active.

Implemented: nothing. No camera exists, no footage exists, no indicators exist.

Sensing

Audio functionality Planned

Planned: audio event sensing for safety-relevant events (for example, glass-break-like sounds), processed locally, with the same owner-only access as footage. Continuous audio recording is not part of the plan.

Implemented: nothing. No microphone is listening.

Sensing

Camera-free option Planned

Planned: for schools, churches, senior living, and similar sensitive settings, the system can be configured without cameras, using environmental and presence sensing only. Privacy posture follows the setting.

Implemented: nothing. The option is a design commitment, not a shipped mode.

Sensing

Personal Intelligence sharing Planned

Planned: sensed rhythms and conditions belong to the person they describe. Sharing with doctors, insurers, agencies, or non-profits happens only with explicit opt-in per sharing point. Nothing moves without consent.

Implemented: nothing. There is no Personal Intelligence file yet.

Local vs cloud processing · Planned local-first

Your room's data stays in your room, by design.

The design intent is local-first: sensing, comparison, and alerting happen on the device in the room. This is a plan, not a property of anything built.

Processing

Planned: local-first Planned

Event detection, baseline comparison, and the documented record are planned to run on the local hub. Core monitoring is planned to keep working even if the network drops.

Processing

Implemented: nothing Not implemented

No hub exists, no local processing exists, and no cloud service exists. Any statement about where data lives today is simple: there is no data, because there is no device.

The honest boundary

  • Local-first is a design intent, not a tested property. Until a prototype is built and audited, no claim is made about data never leaving the device.
  • Any future cloud sync would be opt-in and disclosed, with the local-first default kept for core sensing.

Storage, retention, deletion, user control · All planned

You own the record.

The documented record is the point of Kore, and the owner of the home owns it. Every control below is planned; none is implemented.

Control

Data storage Planned

Planned: readings, events, and footage stored on the local device first. Implemented: nothing. No storage exists.

Control

Retention Planned

Planned: owner-set retention windows, so footage and readings age out automatically on a schedule the owner chooses. Implemented: nothing. No retention policy is enforced anywhere.

Control

Deletion Planned

Planned: delete any event, clip, or the entire record at any time from the dashboard, with confirmation that deletion completed. Implemented: nothing. There is nothing to delete.

Control

User control Planned

Planned: pause sensing, disable the camera, export your own data, and review exactly what the system recorded and why an event fired. Implemented: nothing. No controls exist.

Encryption and access controls · Planned, not implemented

Security is a plan being written in the open.

A safety system that watches a home must protect what it records. The controls below are planned and will be tested on the prototype; they do not exist today, and this page does not claim otherwise.

Security

Encryption Planned

Planned: encrypted storage on the device and encrypted transport for dashboard access. This page does not claim encryption exists. It does not. It is planned work for the prototype phase and will be listed as implemented only after it is built and checked.

Security

Access controls Planned

Planned: owner-only access by default, per-person permissions for household members, and per-sharing-point opt-in before any data reaches doctors, insurers, agencies, or non-profits. No access model is implemented.

False alarms and missed detections

  • A developing system will miss things. Missed detections are expected during development; thresholds and baselines reduce them but do not eliminate them.
  • A developing system will cry wolf. False alarms are expected during development. Every false alarm is planned to be logged with its cause, so the record improves.
  • Nothing here is validated. Detection rates, false-alarm rates, and reliability figures do not exist. Any such figure would be invented, so none is given.
  • Do not rely on Kore for safety-critical detection until a prototype is built, tested, and validated. Keep certified alarms installed (below).

Human control · Design intent

A person decides what happens next.

Kore senses and documents; people act. Consequential actions stay under human control by design.

Control

No automatic emergency dispatch Planned

Planned: Kore alerts the owner and documents the event. It does not call emergency services on its own. The person decides whether to call, and the record shows what they decided.

Control

Opt-in sharing, per sharing point Planned

Planned: sharing sensed data with a doctor, insurer, agency, or non-profit requires explicit opt-in for that specific sharing point. One yes does not open every door. Nothing moves without consent.

What Kore is not

  • Kore is in development. There is no shipping product.
  • Kore does not replace certified smoke alarms, carbon-monoxide alarms, emergency services, or validated medical monitoring.
  • Keep certified alarms installed, keep their batteries fresh, and call emergency services directly in an emergency.
  • When a Kore prototype exists and is validated, this page will say exactly what it is validated to do, with evidence. Until then, this page is a plan, not a promise.

Contact and enquiry data · Implemented

What happens when you write to us.

This section is about this website today, not the future product. It is implemented, not planned.

  • What is stored:whatever you type into a form on this site (name, email, and your message), plus the page it came from.
  • Where it goes:to the founder's email inbox via the form service, so he can reply to you personally.
  • Who reads it:Kristian Brown, the founder. Nobody else has access.
  • What it is used for:replying to your enquiry and, if you joined the build list, occasional prototype updates. Nothing else.
  • Deletion:reply to any email and ask to be removed, and your details are deleted.
  • No tracking:this site runs no analytics, no advertising pixels, and no third-party trackers.

Questions

Privacy questions welcome.

Ask anything about the plan: data, cameras, sharing, or what happens next. Hard questions make the system better.

Prototype updates and pilot news. No spam, unsubscribe anytime.

Interactive 3D · Concept

The credit, in your hands.

Drag to spin, pinch or scroll to zoom. Every product, explorable.