Fail closed on radio loss, hardware stop, and sensor feeds in a beat-driven actuation loop

When narrative content drives a physical actuator, three paths look like "just more input" until they are not: the BLE link drops mid-session, a finger hits the on-device stop, and a heart-rate or mic stream arrives while motors are armed. Each needs a default that fails closed — toward idle, toward immediate halt, toward story-only influence.

on radio_loss(kind):              # BLE disconnect, out of range, link timeout
    ramp_to(IDLE, at=next_beat_boundary)
    armed = false
    on radio_reconnect():
        # do NOT auto-resume motors; wait for user to re-enter the story
        await user_resume(); await next_named_beat(); arm()

on hardware_stop_pressed():
    # always overrides story clock — no beat wait, no cloud ACK
    force_idle_now()
    armed = false
    story_clock.catch_up_after_halt()

on sensor_frame(stream, value):   # HR, motion, mic, …
    may_inform_narrative(stream, value)   # branch / mood / pacing OK
    # never: motors.intensity = f(value) without explicit grant
    motor_drive requires visible, revocable grant — not a silent sensor pipeline

The reconnect rule is the one that slips in most easily, because "restore the session" feels like good UX. Restoring narrative position is fine; restoring motor intensity because the radio came back is not something a transport layer gets to decide.

The hardware-stop rule is mostly a priority decision: if the story clock and the physical button can race, the button must win every time. Beat-boundary niceties apply to soft pauses; a kill switch is not a soft pause.

The sensor rule is a capability split: the same stream can feed the plot engine and must not feed the actuation engine unless the user has clearly armed that path.

Buyers can test all three without code: walk out of BLE range mid-session and see whether reconnecting restarts the device, press the on-device stop during a rising beat and see whether the story clock can override it, and ask the brand whether heart rate or mic can change intensity without a visible toggle. These map to questions like "how do AI stories control physical devices" and "Lovense alternative with AI stories."

This is the model CRAVE AI uses for story-controlled play on official devices: AI story-controlled vibrator. Principle write-up: narrative-to-device sync. Devices: AI sex toys.

Disclosure: I work on CRAVE AI. Adults-only product; no explicit content here.