AUTHOR’S WORD — 1 row here show a completed status that nothing derived The pill on this row was typed, not measured: decision-4-the-lead-s-situation-gets-a-s. Every other status on this page comes from that row’s own PR, commit or decision links; this one name nothing a machine can read, so nothing can contradict it when the work changes. To make the same claim checkable, write one of these on the row and it derives on the next tick: prs (a PR ref — read from GitHub), completion_evidence (owner/repo@<full 40-char sha> — checked against the default branch), shipped_without_pr (why no PR can exist), or decision (the id that settled it). A row that is not owed a build says so with unbuilt; one a decision retired says so with canceled.
Clara platform: execution

Clara platform: execution

The long-term Clara architecture in small pieces, by area of the product. Seven areas, each a lane that moves on its own; each card says the problem, what we build, what is done and what is next. Shipped counts only work proven in production.

Status is DERIVED from each row’s own PR, decision and prod-evidence links by bin/refresh-tracker clara-platform-execution — never typed. Last refreshed 2026-10-16 17:01Z.

The seven areas

Seven areas of the product, each its own lane, all moving at once; nothing waits on a gate. The numbers are names, not an order. Real dependencies: areas 2 and 3 read the person picture from area 1, and that reader is merged; areas 0, 4 and 5 stand alone. Rows in the table below are grouped by area. The phone line is its own area with its own long-term page, not restated here. Minimum slice per area is the line Fede reads: done, half, or what is missing and whose call it is.

0 Unlock and clean up · Switches and model choices on the vision page
Minimum slice
Done. Wave 1 is live, the switch audit is published and the model benchmarks finished with no swap. Wave 2 has one delete merged; the rest waits on Fede's pick. The loop harness and model registry are full scope, not minimum.
The problem today
About 117 fix-shaped switches sit in the code, off or on per customer, and nobody can say which is which. Three improvements shipped off everywhere; a safety guard sat unpressed at three customers.
What we build
One code path. A fix or a guard is the only behavior, live everywhere. A switch exists only for a brand-new capability a customer might want off. Plus a proof bench so swapping a model (Sonnet 5.5, Haiku 5.5, a voice model) is a measured decision, not a guess.
Done
Live: wave 1, all ten fix-shaped switches deleted (fifteen PRs), proven Oct 9 by the site's commit, the self-check and a clean error tracker.
Merged, not yet proven live: wave 2's first delete, the tour double-booking guard; wave 3's first delete, the per-building renewal flag (the renewals module mode is now the only gate); five more Oct 13 deletes (policy gate and its mode switch, escalation email bake gate, company email-review switch, unused vendor allowlist); then a dead promise-ledger guard and the never-enabled leasing fee-fabrication guard.
Measured: drafting evals, Sonnet 5 against 5.5, parity, no swap.
Next
Fede picks which wave 2 switches go (39 audited: 33 delete, 4 merge, 2 keep, 2 need his ruling); each delete gets a replay first.
Then the loop harness and the model registry (not started).
Waits on
Fede's pick on wave 2. Nothing else.
1 One picture of each person · The person picture on the vision page
Minimum slice
Mostly there: the shared reader is merged, the follow-up check reads it and is proven at the test property, and the first-reply decision runs on real leads but only logs for now.
The problem today
Clara texts a prospect who already applied, or who toured yesterday, because the follow-up sender only sees its own thread. 31 bad texts in the replay, every one avoidable with facts we already hold.
What we build
One shared reader that assembles everything we know about a person (our threads, tours, the AppFolio card, staff notes with private lines stripped) and hands it to every decision. Identity: how a PropFlow person is matched to the property-system record, and how a wrong match is undone.
Done
Live: the first-reply decision ran on two real Western Slope leads Oct 10 and ruled reply both times (log only; no send changed).
Merged, not yet proven live: the reader with card notes and conversations, the tour-happened and card-status facts, the wait-if-a-teammate-wrote fix. The follow-up check (row 15) is proven at Willows only.
Measured: two replays disagree: 30/31 (226 cases) vs 19/31 (row 15's run); good leads wrongly held about 12 of 186 vs 1 of 195.
Next
Make the first message read the picture too, and prove the follow-up check on a real customer.
The staff-notes classifier (row 13) is built only if the simpler facts prove not enough.
Waits on
Fede for the identity design (row 12). Areas 2 and 3 read from this.
2 One door for every message · The message door on the vision page
Minimum slice
Half. The stop / wait / send check sits in front of the first-stage and re-engagement follow-ups, and three sender bugs are fixed; all proven at Willows Oct 11. Three senders still bypass it.
The problem today
Six different senders can text a prospect. A teammate's hold on a lead stops the text but not the email. A refused tour text was recorded as sent, so chases started.
What we build
No automatic message leaves without one stop / wait / send check that knows the person. Gera's send gate is already that door for texts; this wires every sender and every channel through it, email included.
Done
Live: the stop / wait / send check and the three sender fixes (teammate-hold email, refused tour text, on-behalf note text), proven at Willows Oct 11; the text door (Gera's gate) already existed.
Merged, not yet proven live: nothing else.
Measured: see area 1; the replay numbers disagree.
Next
The human-handled write on stop and the post-tour chase.
Then the three bypass senders (row 16) and email.
Waits on
Nothing. Reads the person picture (area 1, merged).
3 Staff notifications and the front door · From the Oct 7 prospect on the vision page
Minimum slice
Front door done; one guest-card bug open. The front door is proven at Fairhaven and the staff-notification foundation is merged (one send function, eight sender batches).
The problem today
On Oct 7 one Western Slope prospect produced a chain of staff notifications and texts that a human coworker would never have sent: over-escalation, a lead sitting on a placeholder home, no front door.
What we build
Replay that prospect end to end, one before-and-after per failure, and settle the staff-notification rules and the front-door rule from it. Each fix is a real case first, then a small PR.
Done
Live: front door proven on a live Fairhaven call Oct 10 (tour filed on the real home); the one send function carried a real Western Slope tour confirmation Oct 9.
Merged, not yet proven live: the eight sender batches; guest cards from phone calls (Willows run found a foreign unit id landing on one record, issue open); text and email bookings on the company line now file on the real home (merged Oct 13); a prospect who switches homes mid-thread is toured at the home they picked (merged Oct 14). A card that cannot be created is now held and retried, not reported to staff (merged, not proven live).
Measured: nothing yet; the Oct 7 replay (row 18) is not started.
Next
Move the remaining ~25 staff senders in small batches, then the interrupt rules after Fede reviews them.
Fix the foreign unit id and the no-home-matched case.
Waits on
Fede's review of the interrupt design. Reads the person picture (area 1, merged).
4 Resident history · What the customer already has on the vision page
Minimum slice
Done. Redact and measure, the read-only inbox route and the replay set exist. Resident services stay off until Fede says otherwise.
The problem today
Clara joins mid-story. A resident has months of texts, emails and notes in AppFolio that Clara cannot see, so resident services cannot turn on anywhere without her acting blind.
What we build
A read-only pull of the customer's existing history into our training bucket, redacted with a leak check, first as a replay set, later as part of the person picture. Read-only, under request caps, never written back.
Done
Live: robot read of the account-wide inbox proven on Western Slope Oct 8 (40 conversations, 494 messages).
Merged, not yet proven live: nothing.
Measured: 85 households, median 60 items, 93% with history; replay set 117 conversations, 6,177 messages, leak check green.
Next
Replay Clara over the typed sample with the knowledge base attached; then the storage decision.
Turn-on design for one building is Fede's call.
Waits on
Fede, for any resident-services turn-on (rows 24, 25). Otherwise standalone.
5 Asks and the shared PMS core · Staff asks; one robot core on the vision page
Minimum slice
Not started; waits on Fede. The minimum slice is the decision on which property-system conversations come into Clara's picture (row 29). The noise flag and shared robot core are full scope.
The problem today
Staff asks arrive untyped, so an urgent one looks like a normal one. Every property system (AppFolio today, the next one tomorrow) rebuilds the same login, session, caps and reads.
What we build
A scope rule (what is an ask at all; notices never get a level) and a rule that types every real ask by urgency and finishes it on landing. One robot core layer every property system shares, so the second PMS is a thin adapter.
Done
Live: nothing.
Merged, not yet proven live: nothing.
Measured: labeler over 205 staff messages, 104 real asks; recognising the situation 99 to 100% on those 104 (Fede withdrew the three-doors idea Oct 9; nothing built).
Next
A 50-item read of real asks; planted controls for the noise flag.
The core-layer finish list.
Waits on
Fede's pick on row 29 (his Oct 11 steer: show staff-sent communications first).
6 The coworker lane · Staff talk to Clara on every channel on the vision page
Minimum slice
Live, not production ready. On at Fairhaven and, since Oct 11, Western Slope. Speed is fixed; Fede's Oct 12 call found a second round of wrong answers, and many fixes are merged, none proven live yet; the fuller-details batch is merged for renewals, work orders, guest cards, prospects, tours, tenants and conversations.
The problem today
A coworker who calls the main line is treated as a renter or a prospect: the phone recognizes only property managers, and only for the move-out walk. Text, chat and video already know staff; nothing lets staff act by voice. Only two real staff asks reached Clara by phone in 30 days, and both dead-ended.
What we build
One brain for staff on every channel: who they are and their role decided once at the door, the same lookups and actions behind every channel, with per-channel overrides (spoken on the phone). On the phone: a normal ElevenLabs agent with lookup tools (the earlier custom brain on the video answer line was deleted).
Done
Live: hand-off 2 s and lookups 0.5 to 0.8 s on the real Western Slope line Oct 12 (Fede's call: 9 s and 15 s); isolation proven nine ways.
Merged, not yet proven live: sixteen fixes (every unit detail on file, work orders by the number and by filters, guest-card names, tours last week and custom ranges, buildings by name, address or AppFolio number, the prospects list, the tenants list by past due, lease end, unit and name, the leases-ending count, staff calls no longer raising a prospect card, tenant name match, unit rent fallback, a fresh lookup for every phone question, portfolio stats by building or company-wide, a staff caller never handed to a resident specialist, a street address naming its own building); also fuller records for units, renewals, work orders, guest cards and prospects (merged Oct 13), and the phone and email of any person a lookup names; tours, tenants and conversations in full (#19391) also merged.
Measured: 4 of 4 of Fede's questions correct on the real line; 7 of 7 Fairhaven scenarios.
Next
Also merged Oct 15 · not proven live: every staff member reaching every home their company holds (#20023). A staff member never treated as a lead (#19819) is now merged · not proven live too. A staff call never filing a prospect card, and tours, tenants and conversations in full, are merged · not proven live; also merged · not proven live: a staff text on a company line staying on the staff thread, and invites that store nothing about buildings; next is the deploy.
Then a wide question-bank test on the real Western Slope line.
Waits on
Fede's own call must pass before it counts as production ready.
Overall
—
 
—
Shipped
—
Merged
—
In flight
—
Open
—
Waiting on you
Groups — click to filter
Status
—

Every row opens: when it was added, why it exists, and the links that prove it. Rows waiting on a human carry a Decide → link straight to the answerable question on the decisions page. Statuses are re-derived from live PR, decision and prod-evidence state by bin/refresh-trackers; nothing here is typed by hand, and merged is not shipped until a prod_evidence permalink says the fix was exercised in production.

PropFlow Docs