01
Origin condition
Why it exists
Rooms and devices become opaque when state is scattered across vendor clouds, undocumented firmware, and hidden automations. RoomLight Data Spine exists as a local, inspectable path connecting sensors, controls, receipts, and starter firmware without surrendering custody.
Can a small local data spine make physical environments more useful while keeping control and failure visible?
02
Working system
What it does
- ⌂Connects room devices locally
Provides a simple spine for sensing, state, commands, and human-readable device identity.
- ▤Emits custody receipts
Records firmware, configuration, authority, observations, and command history.
- ⛨Fails toward safety
Uses explicit bounds, local override, safe defaults, and freeze behavior when state is uncertain.
03
System anatomy
Architecture
RLDS combines starter firmware, device identities, a local message spine, operator controls, safety envelopes, and ALO-compatible receipts.
Device edge
Sensors, actuators, firmware identity, and local safe state.
Room spine
Local transport, topics, schemas, timestamps, and health signals.
Operator authority
Manual override, permitted commands, freeze, and recovery.
Receipt bridge
Configuration, firmware, command, observation, and fault records.
04
Present tense
Current state
RoomLight Data Spine is recorded as Prototype at the Growing stage. The inventory currently marks 5 artifact lanes Ready, 3 Partial, and 0 Missing.
B3 Tier 1 room draft · Core canon · Operational evidence · public candidate
05
Honest edges
Known limitations
- The represented starter firmware is a prototype and not certified for safety-critical control.
- Device integrations inherit electrical, mechanical, radio, and vendor-specific risks.
- Local-first operation still requires secure updates, key custody, backups, and physical override.
- A successful bench test does not establish reliability in occupied or hazardous environments.
06
Claim boundary · v1.1.0
What we are—and are not—saying
RLDS v0.2.2 includes a documented safety patch and starter-firmware receipts, establishing more than a conceptual architecture while remaining a prototype.
RLDS is not certified building automation, life-safety control, industrial control, or evidence that connected hardware is safe for unattended deployment.
07
Development memory
Ledger
B3-RLDS-001-01Starter firmware and receipt path established for the RoomLight Data Spine.
✓ PrototypeB3-RLDS-001-02RLDS v0.2.2 safety patch accepted into the prototype baseline.
✓ AcceptedB3-RLDS-001-03Tier 1 technical room drafted with certification and deployment boundaries.
✓ DraftCurated project receipts · source-file binding and human review remain pending
08
Directional, revisable
Roadmap
Package the bench demonstration
Show device identity, observation, authorized command, override, fault, and receipt.
Threat-model the local spine
Review authentication, update, replay, physical access, and recovery paths.
Pilot one non-critical room
Test reliability and usability under supervision before expanding scope.
10
B10 evidence trail
Featured evidence
Registry-grounded trail
No primary source package is bound yet. The public trail is limited to the verified field card and public Genome snapshot.
RoomLight Data Spine — Project Field Card
B4-generated visual identity card built directly from the reviewed constellation registry.
Open bound artifactRoomLight Data Spine — Public Genome Snapshot
Public-safe JSON snapshot of the current project registry or expanded Project Genome.
Open bound artifact11
Publication intake
Artifacts & sources
RLDS v0.2.2 safety-patched baseline
Accepted prototype baseline and safety changes.
View archive recordarchive:intake/rlds-v022Starter firmware receipts
Evidence of firmware identity and prototype custody.
View archive recordarchive:intake/rlds-starter-receiptsSupervised bench demonstration
Needs a packaged, repeatable portal-safe demonstration.
View archive recordarchive:intake/rlds-bench-demoSource basis
archive:intake/roomlight-data-spine/source-basisinternal-prototypeportal:project/roomlight-data-spine@v0.4-b3planning-inventoryReview: Canon, claims, privacy, accessibility, and publication review · pending
12
Move with evidence
Next actions
The system should be evaluated through its failure behavior, not only its successful commands.
reviewReview the artifact registerSee which source packages, visuals, demonstrations, and public links are actually ready.
secondaryTrace related projectsFollow documented dependencies and neighboring systems without inventing connections.