What is observed
While powered and operating, the prototype camera captures encoded video and examines detector-facing frames locally. A bounded encoded buffer can hold recent context around a possible event.
Privacy
What the prototype sees, sends, and keeps.
A camera inside a home deserves literal language. This page describes the current prototype posture, including the places where product-grade controls do not exist yet.
Observation and upload
The camera has to look before it can decide.
What normally leaves
When local detection and policy confirm an event, selected encoded event media and event metadata are uploaded. Uneventful time is not intended to become a continuous cloud feed.
What can go wrong
Detection, storage, networking, and upload can fail. The runtime is designed to suppress ungated upload when detection is unhealthy and to leave diagnostic evidence, but this remains prototype behavior.
Visible camera behavior
Do not treat today’s light as a hardware privacy guarantee.
The handoff enclosure design calls for one visible RGB status light, including blue during camera capture or live view, amber for booting or offline states, green for healthy connection, and red for a fault.
That vocabulary is the intended external interface, not proof that every current board implements it. The prototype has not yet demonstrated a production-grade indicator enforced below ordinary application control.
Until a specific handoff unit proves its indicator and physical controls, testers must receive unit-specific disclosure. A light going dark must not be interpreted as authoritative evidence that capture is impossible.
Current retention posture
Cleanup rules for a development service, not a product promise.
Seven-day prototype media cleanup
The current Render prototype service is configured to clean up uploaded media bodies and their primary event records after seven days. A narrow expired-session summary may remain for up to 30 additional days so an app can explain that media expired.
Compatibility logs are not yet compacted by the same cleanup path. The seven-day setting is an engineering cleanup rule and is not a customer retention guarantee. The project has not yet defined a production retention policy.
Reset and user control
Reset is scoped, and current controls vary.
The tester-facing reset design removes Wi-Fi, published settings and state, local logs, and local media. It preserves the device’s provisioned identity, installed runtime, and update capability so the same camera can reconnect.
On the current Raspberry Pi prototype, user reset is initiated locally rather than through the intended recessed enclosure button. Reset does not claim to erase event media already uploaded to the prototype service. Operator decommission is a separate process.
Exact power, placement, indicator, reset, offline, support, and return instructions live in the stable public setup and support guide. Follow any additional instructions supplied with a specific test unit.
Prototype limitations
No certification, no hidden certainty.
PanOptiCozy does not currently claim a privacy certification, guaranteed deletion deadline, production-grade capture indicator, public-scale account system, or complete self-service data controls.
Understand the tester program