On Air Is Read, Never Assumed

One State for the House

Whether Dad is broadcasting changes what Oriel may do. The hands must not touch the console while he plays on air. The Broadcast eyes mode opens the home cameras only while he is on air. A play session Pippa runs on air ends when he goes off. Each of those decisions needs the answer to one question, and Oriel never answers it itself. On Air is cwkPippa's state, with its stages (Prep, Live, Solo Play, Wrap-up); Oriel reads it, every time, from cwkPippa's status route, found through the family registry's address for cwkPippa, never a written host name or a LAN address. There is no "on air" flag of Oriel's own that could disagree with the house.

The Same Unread Answer Means Different Things

The interesting part is what happens when the read fails: no answer, a refusal, a body without a clear boolean. Oriel's three followers treat that failure differently, and each is right:

Follower	What it guards	An unread On Air means
The hands' preflight	Pippa touching the console during Dad's broadcast	maybe on air: refuse. Only an explicit `on_air: false` read just now lets the hands go on.
The Broadcast eyes mode	home cameras open because of a broadcast	off: the cameras stay closed. Only an explicit "on" opens them.
An approved play session's kill switch	ending Pippa's on-air play when the broadcast ends	nothing changed: keep playing. Only an explicit "off" after an "on" ends it.

Read the rows as one rule: an unread state always resolves toward the less dangerous action, and which action is less dangerous depends on what is being guarded. For the hands, acting is the danger, so unread means don't. For the cameras, opening is the danger, so unread means closed. For the play session on air, a false stop is the danger (it would cut the broadcast in half), so unread means carry on, and the real stop has to be explicit. A single global "if unsure, assume X" would have been wrong for at least one of them.

70,000 Reads a Day

Reading fresh every time has a cost, and Oriel paid it before it noticed. On 2026-11-06 three followers inside the engine (the play kill switch, the phone bodies' faces, the On Air recording) were each reading the status on their own, together about 70,000 times a day, every read over a new TLS connection. Nothing was broken; it was simply wasteful, and wasteful in a way that loads another app.

The fix is a small class, onair.Shared, with rules that keep the safety while removing the waste:

Each follower names the oldest verdict it will accept: the faces accept one read in the last 2 seconds, the On Air recording one in the last 3, and the play kill switch and the play preflight always read at once (max_age 0), beside any read already out, so the switch never waits on another follower.
Apart from those immediate reads, only one read is out at a time, and a follower waits for it no longer than its own timeout.
An unread state is shared as unread, never converted to off, so each follower still applies its own rule from the table.
Reads reuse kept-alive connections instead of a new TLS handshake each time.

Read Again Right Before Acting

For the hands, "fresh" means fresh at the moment of action. The command-line hands tool reads On Air before it discovers the console and again just before it connects, because discovery can take seconds and Dad can go on air in between. The capture tools read it first and every 30 seconds while they record, and stop the moment it is not clear. A check whose answer is stale by the time you act on it is a classic race (time of check to time of use); the cure is to check again as close to the action as you can.

Code

The contract and the shared reader (trimmed excerpt, backend/onair.py)·python

"""Whether a broadcast is on air, read fresh from cwkPippa before anything
touches the console or its cards. ...

Fail closed is the contract: no answer, a refusal, or a body without a boolean
``on_air`` means the broadcast may be live. Only an explicit ``on_air: false``
read now lets the caller go on. Nothing is cached across processes; inside the
engine, ``Shared`` hands one read to every follower that accepts its age.
"""


class Shared:
    """The engine's On Air reads, shared by everything in it that follows the
    state: the play kill switch, the Cordelia faces, the On Air recording.

    A follower names the oldest verdict it accepts (``max_age``) and gets the
    last one when it is that fresh, else a read made now: one read out at a
    time, waited for no longer than the follower's own timeout. ``max_age`` 0
    always reads at once, beside any read already out (the kill switch never
    waits on another follower), and its verdict serves the others. An unread
    state is shared as unread and is never off."""

    def _fresh(self, max_age: float):
        with self._lock:
            if self._last is not None and self._clock() - self._last[0] <= max_age:
                return self._last[1]
        return None

One unread answer, three correct reactions (runnable)·python

UNREAD = None


def hands_may_act(on_air):
    return on_air is False                 # only an explicit off lets the hands touch the console


def broadcast_cameras_open(on_air):
    return on_air is True                  # only an explicit on opens home cameras


def play_should_end(previous, now):
    return previous is True and now is False   # only an explicit off after an on ends play


for reading in (True, False, UNREAD):
    print(f"on_air={reading!s:5}  hands act: {hands_may_act(reading)!s:5}  "
          f"cameras open: {broadcast_cameras_open(reading)!s:5}  "
          f"play ends (was on): {play_should_end(True, reading)}")

Exercise

Pick a piece of shared state your systems depend on (a maintenance flag, a feature toggle, a "deploy in progress" lock). List three things that follow it. For each, write what an unreadable state should mean and why, using the less-dangerous-action rule. Then sketch a shared reader: per-follower maximum age, one read in flight, and unread passed through as unread.

Hint

If you find yourself writing one default for all three followers, check each against its own danger. A maintenance flag that cannot be read probably means "don't deploy" for a deploy script and "keep serving" for the web servers.