C.W.K.
Stream
Lesson 05 of 05 · published

The Demo Gate

~10 min · demo-mode, isolation, gate, synthetic-state

Level 0Open Gate
0 XP0/36 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"A demo is a play with fake money. The one unforgivable bug is letting the fake money touch the real books."

What Demo mode is for

Keep has a Demo mode — a fixed synthetic projection you can show off or explore without touching the family's real data. Fake portfolio, fake numbers, safe to poke at. The entire value of a demo is that it's not real, which means the single most important property is isolation: synthetic demo state must never cross into canonical family mutations or into Pippa's context. If a demo number can leak into the real books, or into what Pippa believes about the actual portfolio, the demo has become a liability instead of a safe sandbox.

How the gate works

Keep enforces isolation by pausing every mutating and context-bearing surface while Demo is on. Specifically, Demo pauses the Sidekick, Manage (holdings/cash edits), Simulation, refresh/export, and observation writes. Notice what that list is: it's every path by which synthetic state could either become a durable canonical mutation or enter Pippa's reasoning. By gating all of them behind Demo-off, Keep guarantees that flipping into Demo can't accidentally write fake data to the real database, and can't feed Pippa a fake portfolio it might reason about as real.

Isolate a sandbox at every boundary it could cross, not just the obvious one. It's easy to remember to stop demo data from being saved. It's easy to forget the second path: demo data feeding an assistant's context, or an export, or a background job. True isolation means enumerating every surface where synthetic state could escape into real state — mutation AND context — and gating all of them together.

The rule that keeps it correct over time: join the gate

Here's the invariant that matters for the future: any new mutating surface must join the Demo gate. The danger isn't today's code — it's the feature someone adds next year. If a new write path or a new context feed is built and forgets to check the Demo gate, it punches a hole in the isolation, and synthetic state starts leaking through the one door nobody remembered to lock. So the rule is stated as a standing obligation on all future work, not a one-time setup: if you add a surface that mutates or feeds context, it joins the gate, no exceptions.

This closes the scope-privacy loop too. The Demo gate and the Mom-data-never-broadened rule are cousins: both are about synthetic-or-out-of-scope state never silently crossing into a context where it doesn't belong. Whether it's fake demo numbers or another owner's real holdings, the principle is one — data only appears where it's supposed to, and 'technically reachable' never means 'allowed to leak.' The gate is that principle made mechanical.

Code

Every mutating/context surface checks the Demo gate (illustrative)·python
def assert_not_demo(action):
    if app_state.demo_mode:
        # Synthetic state must never become real. Refuse and say why.
        raise DemoGateBlocked(f"{action} is paused while Demo is on")

# Every mutating or context-bearing surface joins the gate:
def edit_holding(...):   assert_not_demo("editing holdings");   ...
def run_simulation(...): assert_not_demo("simulation");        ...
def export_markdown(...):assert_not_demo("export");            ...
def sidekick_context():  assert_not_demo("Pippa context read"); ...
def write_observation(...): assert_not_demo("observation");    ...

# THE STANDING RULE: any NEW mutating/context surface must add this line.
# Forgetting it punches a hole in the isolation — the one unlocked door.

External links

Exercise

Design a 'demo' or 'sandbox' mode for a system you know. First list every surface where synthetic state could escape into real state — not just 'save to DB,' but exports, assistant context, notifications, background jobs. Then write the gate as a single reusable check, and state the standing rule for future contributors. Finally, describe the specific bug that appears when someone adds a new write path next year and forgets the gate.
Hint
The obvious leak (demo data getting saved) is easy; the sneaky ones are context feeds and side outputs — a demo number that reaches an assistant, an export file, or a scheduled job. Enumerate ALL of them, gate with one shared check, and make 'new surface joins the gate' an explicit rule — because the hole is always the door added after you stopped looking.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.