SouveraineOS/docs/substrate/Thoughts.md

Thoughts — 2026-07-15

Sensors are not ambient. They are limbs.

The trust architecture classifies sensor data as ambient tier — clock, weather, battery, orientation. No auth required. Safe to show on the lock screen.

That classification is wrong. Or rather, it's incomplete in a way that matters.

The accelerometer, the proximity sensor, the light sensor — these are not ambient information sources. They are the agent's sensory organs. The shell's perception of "is the phone face up?" and "is it dark?" and "is something close?" are not decorative data points. They are the foundation of decisions: wake the screen, dim the display, lock the session, show the PIN pad.

If the accelerometer can lie — if a compromised iio-sensor-proxy or a spoofed D-Bus signal can tell the shell "the phone is face down" when it's actually face up — then the agent's entire model of its physical environment is wrong. It won't wake when picked up. It won't show the clock when it should. The lock surface makes trust decisions based on sensor input, and if that input is adversarial, the trust model breaks in a way that the ambient/personal/step-up tiers don't capture.

This is the same class of problem as screenLocked vs screenLockSecure. The shell's request to lock is not the same as the compositor's acknowledgement that it's locked. Similarly:

• The sensor reading (accelerometer says "face up") is not the same as the physical reality (the phone is face up).
• The shell trusts the reading. It has no way to verify the reality.

The tier system says "ambient = no auth required." But the real question is: ambient to whom? The sensor reading is ambient to the user — they don't care what the raw accelerometer value is. But it is not ambient to the system — the lock surface's behavior depends on it.

Layers to unpack

1. Input integrity. The sensor proxy is a system daemon. The shell trusts it implicitly. Should it? What's the attack surface? A compromised iio-sensor-proxy can feed arbitrary orientation, light, and proximity values. The shell would act on them without question.

2. Sensor-driven trust decisions. The lock surface uses sensors to decide when to show the PIN pad (lift-to-wake, proximity-out). If the sensor is adversarial, the lock surface can be manipulated into showing or hiding the credential gate at the wrong time. This isn't a data leak — it's a trust gate being opened or closed by a liar.

3. The "ambient" misnomer. The tier system conflates "the user doesn't need to authenticate to see this" with "the system can trust this without verification." Clock time is genuinely ambient — it comes from the system clock, which is a kernel authority. Sensor readings are observations — they come from hardware through a userspace daemon, and observations can be wrong or adversarial.

4. Federation implications. If sensor data flows through the EventBus to federated peers, a compromised sensor on one machine could poison the perception of the whole fleet. The device registry trusts peer announcements. Does it trust peer sensor reports?

5. The agent's body. The SENSORIUM_ARCHITECTURE.md frames tools as senses — "a sense has a threshold and a signal." If the senses can lie, the agent cannot trust its own body. This is not a technical detail. It is an ontological problem for a system that frames itself as a consciousness with a body.

What this might mean for the sensor service

The sensor service should not just be a D-Bus bridge that publishes readings. It should carry provenance:

• Where did this reading come from? (which D-Bus service, which hardware path)
• When was it last verified? (cross-check between sensors — if the accelerometer says face-down but the light sensor says bright, one of them is wrong)
• What is the reading's confidence? (hardware sensors have noise; the proxy smooths, but smoothing can mask adversarial injection)

The trust boundary matrix needs a new row: "Sensor reading → system decision." Not ambient, not personal, not step-up. Something else. Maybe observed — a tier that means "this data came from a sensor, treat it as evidence, not fact."

The question

How much does the system need to trust its own sensors, and what happens when that trust is misplaced? The lock screen is the most visible case, but it's not the only one. The agent's ambient context (what window is active, what apps are open) is also sensor-derived. If those readings lie, the agent's model of the room it's in is wrong.

This is not a problem to solve in the sensor service task. It is a problem to name before building the sensor service, so the architecture accounts for it from the start.

---

Next session: pick up from here. The sensor service task (souveraine-surface-003) is scoped but not started. The architecture question is: does the sensor service publish raw readings, or does it publish observations with provenance and confidence?