Fail closed on alarms, Low Power Mode, and screen-recording starts

When narrative content drives a physical actuator, three interrupt paths look like "just restore state" until they are not: a local alarm or calendar alert takes focus mid-session, the OS flips Low Power Mode / Battery Saver on, and screen recording or casting starts. Each needs a default that fails closed — toward idle, toward re-arm only after a named beat, toward interrupt-clear ≠ motor authority.

on system_alarm_or_calendar_interrupt():
    ramp_to(IDLE, at=next_beat_boundary)
    armed = false
    on interrupt_dismissed():
        # do NOT auto-resume motors
        await user_resume(); await next_named_beat(); arm()

on low_power_mode_on():
    ramp_to(IDLE, at=next_beat_boundary)
    armed = false
    on low_power_mode_off():
        # power-policy recovery ≠ intensity resume
        await user_resume(); await next_named_beat(); arm()

on screen_recording_or_cast_start():
    ramp_to(IDLE, at=next_beat_boundary)
    armed = false
    on recording_or_cast_stop():
        # privacy restored ≠ motor envelope restored
        await user_resume(); await next_named_beat(); arm()

The alarm rule is easy to mix up with an incoming call or a push-open. A phone call is a telephony interrupt; a push open is inbound navigation; a local alarm or calendar banner is a scheduled on-device interrupt. All three should idle the device, and none should treat "the banner is gone" as consent to continue intensity.

The Low Power Mode rule sits next to — but is not — "battery percentage as a non-event." Percent charge should not drive motors. The OS saver switch changes process and radio budgets; enabling it should disarm, and disabling it should not put the previous motor envelope back on.

The screen-recording / cast rule is a privacy-boundary decision: once the display is captured or mirrored, motors must not stay armed. Ending the capture restores a private screen; it must not silently continue the last beat.

Buyers can test all three without code: fire a timer mid-session and see whether dismissing it restarts the device, flip Low Power Mode on then off and watch intensity, and start then stop a screen recording. 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.