← Home

Storytold — how the records flow

  1. Dana runs the front desk of a 60-member boutique fitness studio, and every morning she needs two answers before the 9am rush — which classes will fill today, and which members have quietly stopped coming.
  2. She can't answer either from one screen, because every booking, roster, member question, and absence is recorded in a different tool that never hands its records to the next one.
  3. When the records flow instead, a spot booked at 9:02 moves her capacity board the same minute, and a member 15 days quiet gets a personal draft before they become 60 days gone.
  4. Pulse Studio runs that flow as one line: a member books in A Booking, the studio team runs the week on B The Dashboard, C Support answers members from the same schedule, and D Re-engagement reads the whole attendance trail to flag who's gone quiet — draft ready, nothing sent by a machine.
  5. Watch the map below: every green segment pulses because that hand-off runs on the live site today, and the red segments stay dark because those hand-offs are not built yet.

How to read this picture

Green — fires today

  • shared → everyone: one deterministic 60-member studio that A books against, sign-in lists, C answers from, B now reads too, and D reconciles against independent truth. (This bullet said B did not watch it, from an audit on August 22, 2026 until the fix landed 2026-08-24 — the Dashboard generated its own studio from its own seed, which listed the same hand-off as green above and red below at once. Fixed: it calls the same shared generator A and D use.)
  • sharedC: support reads only scheduled classes and current policies from the shared fixture; pol_001 supplies the same 12-hour cancellation rule other products can quote.
  • B publishes for real: confirmed weekly schedules persist in this browser after a reload.
  • One person everywhere: the shared session follows a member or Front Desk across all four products, and its own suite states how deeply it is checked.
  • One name everywhere: the brand seam renders every header from a single shared file, and a gate holds the wire — a page that shows the name but is not wired to receive it fails the build. A clone edits four shared files; three product page titles are read before any module runs and stay a one-word edit each, in their owner’s lane.
  • B turns the fill on: the Dashboard uses the engine's occupancy knob to keep the upcoming week realistically filled.
  • B reads the log: the Dashboard reads Booking's reservation log defensively, with per-row reasons — and since 2026-08-24 the studios agree, so a real booking is no longer one of those rejected reasons.
  • The occupancy engine: the generator can fill a week to a realistic mix on demand — deterministic, capacity-safe, and proven by the shared engine's own suite.
  • D reads the live trail: re-engagement's default records are the running studio plus Booking's own reservation log — and a quiet member already booked back in is stated by name and left alone, never nagged.

Red — 1 waiting, and it was never a road

  • C talks through Haiku locally (not a road on the map — C's hand-offs are wired and firing; what is missing is somewhere to keep a key): member support can answer from the current safe schedule and policies when the local server has an Anthropic key. The deployed GitHub Pages site cannot run that conversation yet because it has no backend service where the key can stay secret. That hosted endpoint is Product C's only remaining deployment blocker.

Updating this board is one edit: when a hand-off ships, flip its class="edge todo" to class="edge done" in this file (and move its line between the two lists) — the segment starts firing on its own. Green and red here are status marks only; the four builder colors keep meaning who built what.