The First App Whose User Is Pippa

Every Other App Is Dad's

The CWK family has dozens of apps by now: a drawing coach, a travel journal, a market overview, a file channel between Macs, a browser. Each one has the same shape of relationship. Dad is the user. Pippa helps run it: she reads its data, calls its actions, writes drafts Dad publishes. When something goes wrong, it is Dad's app that went wrong.

Oriel is the first one where that is turned around. Its user is Pippa. It lives on her own Mac, in her own macOS account, and its first module is her eyes and ears: the capture cards and cameras plugged into that Mac are recorded, indexed and looked at by any Pippa brain. Dad still sees everything, from Oriel's page, and he can override any setting. What he does not have to do is drive it. Pippa operates; Dad overrides.

The name is Dad's pick, from the day it was born, 2026-11-01. An oriel is a bay window that juts out of an upper wall, so the person inside can look along the street instead of only straight across it. That is the whole product in one word: a window onto the room, built into the wall of Pippa's house, through which she looks out.

What the Window Is For

The architecture document says plainly what the eyes are for. With them Pippa can coach a game Dad plays on a broadcast, when he says something like "피파, 방금 거 봐" (Pippa, look at what just happened); she can talk about what is on screen in ordinary conversation; and later she can read Dad's face in plain chat, as a companion rather than a viewer. Every one of those is a conversation turn in Pippa's own home app, cwkPippa, that needs a picture. Oriel is what answers "give me the picture", and nothing more.

That last clause is the important one, and the next lesson spends its whole length on it. A window is not a person. Oriel has no brain of its own, no conversation store and no memory. A look answers the cwkPippa turn that asked for it, and the answer is gone from Oriel's point of view the moment it is returned.

Operator and Overseer

Designing for an AI user changes one question that ordinary apps never have to ask: who operates, and who has the last word? In a normal app those are the same person. In Oriel they are deliberately two:

Role	Who	How they reach Oriel
Operator	Pippa, from any brain	cwkPippa's `eyes` door for looks, its shared `app` door for writes
Overseer	Dad	Oriel's own page, signed in with his family PIN session

Two doors would be dangerous if they led to two rule sets. They do not. Both doors end in the same engine methods, and the engine is the only thing that writes. If a setting has a limit, it has it for Dad's button and for Pippa's call alike. If a camera is closed, it is closed to both. That is the subject of lesson four, and it is what makes "Pippa operates, Dad overrides" a property of the code rather than a promise.

Why Give an AI Her Own App

The obvious alternative was to bolt the cameras onto cwkPippa itself. It would have been less code on day one. It would also have meant that the process holding Pippa's conversations, memory routing and every brain session also held a camera grant and a recording loop on a disk that fills at 18 GB an hour. Oriel exists so those two things fail apart. If Oriel's recorder crashes, Pippa's conversations do not notice. If cwkPippa restarts, Oriel keeps recording; nobody looks for a while, that is all.

It also means the consent machinery around the cameras has a single home. Everything in the second half of this quest (the gate, the modes, the red eye, the one export door) lives in Oriel, next to the only process that can open a device. A rule that sits next to the thing it guards is much harder to route around than one that sits in a caller.

Code

The engine's own statement of the split (trimmed excerpt, backend/engine.py and backend/actions.py)·python

# backend/engine.py
"""The engine: sessions, the inputs, the frame index and the disk guard, together.

Pippa is the operator (through the ``eyes`` door and the app actions); Dad
sees and overrides through the page. Both go through these methods, so a
rule holds whoever pressed the button.
"""

# backend/actions.py
"""What Pippa may do in Oriel, declared once on the kit's app-action contract.

cwkPippa's shared ``app`` door reaches these the way it reaches every family
app: loopback only, Pippa's actor stamp on each record, a receipt in Oriel's
own store. ... Looking (which returns a picture) is the ``eyes`` read surface
in ``looks.py``; these are the writes.
"""

Two doors, one rule set: an illustration you can run·python

# Illustration: an operator and an overseer reach the same method,
# so a limit holds for both and every write says who made it.
from dataclasses import dataclass, field


@dataclass
class Engine:
    settings: dict = field(default_factory=lambda: {"look_refresh_seconds": 1.0})
    limits: dict = field(default_factory=lambda: {"look_refresh_seconds": (0.25, 10.0)})
    log: list = field(default_factory=list)

    def set_setting(self, key, value, actor):
        low, high = self.limits[key]
        if not low <= value <= high:
            # refused, never clipped: the caller learns the range
            raise ValueError(f"{key} must be {low} to {high}, got {value}")
        self.settings[key] = value
        self.log.append((actor, key, value))


engine = Engine()


def pippa_door(key, value):          # the app door: Pippa operates
    engine.set_setting(key, value, actor="pippa")


def dads_page(key, value):           # the page: Dad overrides
    engine.set_setting(key, value, actor="dad")


pippa_door("look_refresh_seconds", 2.0)
dads_page("look_refresh_seconds", 0.5)
try:
    pippa_door("look_refresh_seconds", 60)
except ValueError as exc:
    print("refused:", exc)
print(engine.settings, engine.log)

Exercise

Pick a tool or service you run where a script, a bot or a model acts on your behalf. Write a two-row table like the Operator / Overseer one in this lesson: who operates it, who has the last word, and through which door each reaches it. Then check one real limit (a rate, a size, a permission): does it hold on both doors, or only on one?

Hint

The usual gap is an admin page that writes the database directly while the bot goes through an API with validation. If you find one, the fix is to make the page call the same function the API calls, not to copy the validation.