Gatekeeper

A proposal for one module on/off system: each customer sets every module to off, drafts or live, and every action Clara takes has to pass a gate that checks that setting.

2026-09-28 · green-lit by Gera in chat, ~20:50 UTC · Phase 1 (Maintenance) started · the five questions went to Fede in Slack · drafted in session "module-switch"

The one thing

Today "off" mostly just hides the page. About a dozen places each check the switch their own way, and some never check at all. Gatekeeper puts the switch in one place and lets the important actions happen only through gates that check it.

Approve below to start Phase 1: Maintenance, built end to end in small PRs. The details, the build order and five questions for Fede are in the sections underneath.

Green light

Build Phase 1?

Green light: start Phase 1 Not yet (note below)

In plain terms

Pick green light and the maintenance part gets built first, in small pieces, while Fede answers the five questions above.

Review by Fable (2026-09-28) and what changed

Shape confirmed: one setting per module, a front-door check, gates where actions leave, and enforcement by a complete list. Much of it already exists in pieces.
The real hole: a free "exempt" label on 87 sends, including Clara's replies. The always-on list must be short and specific.
AppFolio gate placement: the shared per-building work-order writer, not each staff tool. Most of the 15 work-order tools are used only by staff, by hand.
Still to decide: which of today's four overlapping switches Gatekeeper retires, and whether staff pressing "send now" on Clara's drafted work orders counts as staff (allowed) or Clara (blocked).

Why now

On Sep 28 Clara created a maintenance work order in AppFolio at a customer building with Maintenance switched off. The code that created it checked a different switch, the building's rollout stage, which said "live". Two fixes shipped the same day (#13227, #13269), but the pattern will repeat until there's one system.

Example: one customer's settings

Module	Setting	When off, Clara will	Owns these actions
Leasing	Live	—	Tour bookings, guest cards, prospect messages
Maintenance	Off	Transfer calls to the customer's call center, forward emails to the office	Work orders, vendor dispatch, repair updates
Renewals	Drafts	—	Renewal offers, lease updates in AppFolio
Collections	Off	Stay quiet and leave it for the team	Rent reminders, balance messages
Always on	Core	Can't be switched off	Emergencies, alerts to the customer's team, login codes

One customer's settings, as an illustration. Each module is set for the whole company, and any building can override it.

The four settings

Off The module does nothing. Clara follows the customer's fallback and never says a ticket was filed.

Drafts Clara prepares everything, and a person approves it before anything goes out. This is the "few days of review" step used when leasing launched.

Live Clara handles it on her own.

Always on A fixed label, not a setting. Emergencies and safety messages always get through.

How a message moves through it

Clara labels the topic. This is the only AI step: is it maintenance, leasing, renewals, collections, or an emergency? Emergencies are checked first. Today, when Clara isn't sure of the topic, she handles it herself. Changing that to "send it to the team" would be a routing change, decided separately.
The front door reads the setting. Plain code looks up the setting for this module, customer and building. Live: Clara handles it. Drafts: it's prepared for approval. Off: the fallback runs.
The fallback runs from a fixed menu. Hand it to the team (transfer to a number, forward to an address), tell them who to contact in our approved wording, or stay quiet (email only, never on a call).
Gates check again before anything leaves. Right before a message, a record or an AppFolio write, a gate checks the setting again. That catches background jobs and conversations that drift into another topic halfway. Today's two fixes are gates of this kind.

In plain terms

Clara works out what the message is about, the code checks whether this customer turned that on, and if they didn't, the code does whatever the customer chose instead. A second check right before anything goes out catches anything the first one missed.

Why nobody has to remember it

In the code

The only way to send, create a record, or write to AppFolio is through a gate, and each gate requires the action to say which module it belongs to. Most tools declare their module once, in one complete list of every action, so a new action can't be added without one. A plain "required field" isn't enough on its own: twice in this repo one was satisfied by passing a blank.

On GitHub

A fixed test runs on every PR and fails it if anything sends or writes while skipping a gate. The first piece already exists for text sends. The AI reviewer is only an extra pair of eyes and is never relied on.

Safety: settings can't steer Clara

The AI only labels the topic. It never reads the settings and never picks the fallback.
Settings are multiple choice. The only typed values are a phone number and an email address, and both are checked when saved.
What Clara says when a module is off is our approved wording. Text a customer types never becomes part of Clara's instructions.
A new kind of fallback is added as one tested menu option, and then any customer can pick it.

What exists today

Piece	Status
One on/off switch per module per company, with building overrides	Live
Pages hide when a module is off	Live
Work orders refused at a building with Maintenance off (after a call; during a call or text)	Live · #13227, #13269
Clara works out the topic of a maintenance text	Live
Sends marked "exempt, no module" (87 sends in 70 files, including Clara's normal replies) sorted into a short always-on list	Not started
No texts, emails or calls sent from a module that's off	In progress
Build check for text sends that skip the gate	In progress
Off / drafts / live settings	Not started
Fallback menu per customer	Not started
Shared gates with a required module label	Not started
AppFolio write gate	Not started
Build check covering every action	Not started

Build order

Maintenance, end to end. First, a gate on the shared AppFolio work-order writer, which most automated maintenance writes go through. Then the setting and fallback menu, the front-door check, and the build test. Maintenance goes first because that's where work has already slipped through.
Close the exemption, then the other modules. Sort the 87 "exempt" sends into a short always-on list (emergency, team alert, login code, opt-out confirmation), then give leasing, renewals and collections their gates. This is bigger than it sounds.
Drafts and the settings page. The review queue for drafts, and one page that shows every module's setting and fallback. This absorbs the settings audit's decisions #2 and #5.

Each phase ships as several small PRs, and each PR works on its own.

Five questions for Gera and Fede