Safety — replacing the two-button hold¶

Status: concepts, not a decision. Nothing here is normative. Normative home: docs/marketing/launch-plan.md §11.2 (the requirement) and §11.3 (primitive bounds). This file exists to work out what should replace §11.2's mechanism; when something is settled, it moves there and this file loses that section. Raised: 2026-08-08, from Todos.md — the two-button hold was judged both unbuildable on Board V1 and wrong in principle.

The problem in one paragraph¶

§11.2 asks for a stop that is "never delayed, never rationed, never removable" and specifies it as both buttons held 10 seconds → all enforcement stops for 24 hours. Two things went wrong with that. Board V1 has one user-accessible button (P0.05, on the back) plus a reset switch, so it is not implementable as written. And on the hardware that does exist, the only real override is a screwdriver — which is a stop that a determined adult defeats in a minute, and that a distressed teenager cannot use at all. It fails both halves of what §11.2 is for, in opposite directions.

Why physical friction is the wrong lever¶

§11.2 wants two things from one control:

Available. Zero friction for someone who needs out — a medical emergency, a fire, a panic attack, a wear sensor stuck alarming at 3am in a hotel room.
Not tempting. Enough friction that 6am-you doesn't reach for it to buy twenty more minutes in bed.

Physical difficulty looks like it serves the second. It doesn't. It is a tax paid entirely by the honest user in distress, while the user who genuinely wants to cheat is exactly the user willing to find a screwdriver, or a charger, or a pair of scissors. Any friction you can build into a wrist-worn plastic object is friction the motivated defeat and the desperate cannot.

So the mechanism has to get its "not tempting" from somewhere other than difficulty. That somewhere is cost, not effort — and §11.2's own closing line already says it: the friction is that stopping is total and visible, not that it's impossible. The rest of this document is about taking that sentence seriously instead of bolting a button combo onto it.

Directions worth considering¶

1. Separate "make the noise stop" from "end the commitment"¶

Most reaches for an override are not "I want out of my commitment." They are "I want this sound to stop right now." Those are different needs and they currently share one control, which is why the control has to be both easy and hard.

Split them:

Short press — silences the current escalation for a few minutes. Enforcement continues; the window is still active; the criterion still isn't met. It will come back.
Long press with a countdown — ends enforcement entirely for 24 hours.

The impulsive 6am case is served by the first and never touches the second. That alone removes most of the pressure to make the real override hard, because the real override stops being the thing people reach for casually.

2. Make the override loud instead of difficult¶

Break-glass, not lock-and-key. A fire alarm is behind glass you can break with your elbow — trivially easy, and impossible to do unnoticed.

Triggering it is free: one button, no tools, no app, no network, works flat on the wrist.
It is total: it stops everything for 24 hours, not just the alarm you're annoyed by. You cannot override one inconvenient window and keep your streak on the rest.
It is visible: logged on the watch, surfaced in the app, counted in the weekly summary.
Optionally witnessed: if — and only if — you chose this in a calm moment, it notifies a person you nominated.

That last one is the product's own thesis applied to its own escape hatch. Impulse is self-binding: past-you constrains future-you. The override's visibility is a legitimate thing for past-you to turn up. Its availability is not.

3. The countdown is the feature, not the delay¶

If the long press runs ~10 seconds with the watch actively narrating — ring goes red, buzzer ticks down, maybe a haptic pulse per second — then the hold time is doing three useful jobs at once:

It prevents accidental triggering, which is the only thing "both buttons" was ever really buying.
It is deliberation time. Ten seconds of a device telling you what is about to happen is the difference between an impulse and a decision, and it costs someone in a genuine emergency ten seconds.
It is inherently visible to anyone in the room, which is the point of direction 2.

A single button can do this. Two buttons were never needed.

4. Floor, not mode¶

The instinct in the Todos.md note was a lenient default mode and a stricter power-user mode. The strict direction should be rejected, and §11.2 already says why: the stop cannot be disabled, capped, or configured away by the user. A device that can be configured into having no unconditional stop is precisely the artefact behind the coercion narrative in §12.8 — and the configuration would be done by the same person, in the same optimistic mood, who sets the commitments.

What does work is a floor with a ceiling you can raise:

Floor (never configurable): long press → 24-hour full stop, on the watch alone, always.
Above the floor, users may make it more visible — notify a nominated person, shorter streak forgiveness, whatever.
Users may never make it less available.

Self-binding on the override is allowed to increase what stopping costs socially. It is never allowed to increase what stopping costs physically.

5. The vulnerable-user case is a §11.3 problem, not a §11.2 problem¶

The note worries about a 14-year-old with an eating disorder who cannot unscrew a case in a bad state. That worry is correct and the conclusion should be stronger than "give minors a different mode":

Age can't be verified by this device, so a minor mode is a checkbox, and the users it most needs to catch are the ones who won't tick it.
A mode that makes stopping harder for minors inverts the duty of care. If anything, the vulnerable configuration should stop more easily.
Most importantly: someone in crisis should rarely be relying on the override at all. If they are, the device was allowed to enforce too hard for too long, and that is a primitive-bounds failure — §11.3's max window duration, minimum gap, daily cap, escalation cap. Those bounds are what keep the override from being the only thing standing between a person and relief.

So the honest sequencing is: BLK-02 (primitive bounds) is load-bearing for safety in a way BLK-01 alone cannot be. Getting the override right does not rescue an unbounded primitive.

launch-plan.md §11.4 already says to keep the device blind to the substrate of restriction, so it will never know a window is about food. That is right, and it means the bounds have to be unconditional — you cannot special-case the dangerous uses, because you deliberately can't see them.

6. Fail-open is part of the safety story and already half-built¶

Some of §11.2's motivating scenarios are not override cases at all — they're fault cases. A wear sensor alarming all night in a hotel is a bug, and the fix is that faults resolve to not-enforcing. The anchor already does this (§4.7 fail-open when it has no valid time or no stored schedule). Worth auditing the watch for the same property on the sensor and clock paths during the Zephyr port, while the code is being rewritten anyway.

What Board V1 can actually support¶

One user button on P0.05 (back of the board, also the wake button), plus S1 on the module RESET pad. Concretely:

Everything above is buildable with the one button — short press to silence, long press with countdown to override — as long as the wake function and the override share it cleanly.
The reset button should stay a reset. Making it part of the safety mechanism means the safety mechanism is behind the case.
Open question: whether the nRF54LM20A can read its RESET pad as an ordinary input at all (remappable via UICR on some Nordic parts, not others). Worth confirming during the port — but the design above deliberately doesn't need it.
Note for the next spin: if the override matters as much as §11.2 says, it may deserve a button that isn't also the wake button and isn't on the back of the case.

Open questions¶

These are the decisions this document can't make.

Does the short-press silence exist, and for how long? It is the piece that makes everything else affordable, but it is also a small, sanctioned way to not comply.
What does the 24-hour stop actually stop? All enforcement, or all enforcement and the anchors' independent beeping? The anchors enforce when the watch is removed — if they don't honour the override, it isn't unconditional.
How does the override interact with §9's commitment integrity? It has to bypass the quarantine gate entirely — otherwise a safety stop is subject to a 24-hour delay, which is absurd. Check this doesn't reopen the loosening loophole the gate exists to close.
Is the nominated-witness idea worth building at all, or is it a feature that sounds good and gets used by nobody?
Does any of this survive contact with a clinician? BLK-14 is the right test, and it should be asked specifically: would a patient of yours be able to use this stop, in the state they'd need it?

What is already decided and shouldn't be relitigated¶

There is an unconditional stop. Not negotiable; §11.2 is a safety requirement, and a device that locks and escalates without one is defective.
It works on the watch alone — no app, no network, no account.
It cannot be disabled or configured away, by the user or by a mode.
It costs the "inescapable" claim, which §10 forbids anyway. The honest promise is better and is already written: you can always stop; the friction is that stopping is total and visible, not that it's impossible.