One door out

The design for the single gate every outgoing message passes through — what it decides, what beats what, and how we stop anyone building a second way out.

2026-08-29 · Status: Proposed — design only · Nothing here has shipped

Mute, end to end →The switch this gate enforces. Knowing when not to answer →Why Clara talks when she shouldn't.

The invariant

Every message that leaves the system passes one gate, and the gate's answer is law.

Two halves, and the second is the hard one. One gate means there is no other way out — not a lane with its own rules, not a client someone can call directly. Its answer is law means no caller may soften it, retry it, or decide their message is special.

Why it is not true today

There are three layers of checks, not one, and they cover overlapping but different sets of lanes. Messages Clara writes herself get the full set. Messages sent by workflows get fewer. And five lanes call the texting client directly — turnover nudges, a renewal picture-message, two internal notices, and follow-ups on an open question — skipping the shared gate entirely. The code documents that gap itself. It is why muting a person by hand last night took four records and still left a hole.

The biggest hole, and why it is not simply a bug

The instinct is to call that a bug and remove it. That would be wrong. The exemption exists for a good reason: an operational alert to our own staff must not be blocked because a resident once opted out of marketing. Genuine internal mail has to pass.

The actual defect is that the claim is asserted by the caller and never verified. The code says "this one is internal" and the gate believes it. Nothing confirms the recipient is a member of staff. Among the lanes that use it: bulk sends, forward-to-a-manager, notes about unknown callers, holdover renewal notices, and tour confirmations — that last one worth a second look, since a tour confirmation goes to a prospect.

So the design job is not a ban. It is: prove that all 44 really do target staff, and make the 45th prove it too — a check that runs in the build rather than a rule people remember.

The rule we already wrote and never enforced

We decided this once before. The standing rule is one check, at every door, failing closed. Today 24 different modules call that check — and there is no list of the doors and no test that walks them. A new door added tomorrow turns nothing red; it simply exists, unchecked, until someone finds it during an incident.

That gap is the real reason the test rig below has to exist. The decision was correct and is three months old; what was missing was anything that notices when reality drifts away from it.

Two principles from last night

Fix at the altitude of the class, not the instance. Two separate leaks into the ops feed surfaced the same day. Patching each would have left the third. The fix went into the one place all such messages are emitted, and closed the whole class.
A proof that bypasses the gate it claims to prove is worse than no proof. One bench run called the checking function directly instead of sending through the door where the bug actually lived. It came back 8 out of 8 green while the feature was dead in production. A green run you cannot trust is more dangerous than a red one, because it ends the investigation. The rig must make it structurally hard to claim a door works without going through it.

What the gate decides

One question, asked once, at the last point before a message reaches a carrier: may this specific message go to this specific person right now? Everything else — what the message says, whether it is a good idea, whether it repeats — belongs upstream. The gate is not a critic; it is a door.

Precedence — what beats what

Rule	Meaning
Three levels of "stop"	Marketing only (a renewal opt-out), all outreach (a general opt-out), and muted
Muted ignores message type	Every other level grades by what kind of message it is. Muted does not: labelling a send "operational" must not walk through a mute.
Their opt-out beats our mute	If a person has said STOP, that holds no matter what we set. Mute is our decision; opt-out is theirs and is a legal boundary.
Unmuting never clears an opt-out	Turning our switch off restores normal conversation only for people who never opted out. It can never revive contact with someone who asked us to stop. This exact bug was caught in review before merge.
A human's deliberate send passes a mute — and only a mute	A person pressing send is the one exception, and it is scoped precisely: it clears the muted level, never an opt-out, never a legal hold.
Emergency and safety always pass	At every level, logged as the exception each time.

The rule that keeps it one door

Nothing outside the gate may hold a messaging client. Not a workflow, not a script, not a new lane written next quarter. The gate owns the carrier connections; everyone else asks the gate.

Enforced by the build, not by memory: a check that fails the build when any file outside the gate imports a messaging client. Design intent, stated plainly — a rule that depends on reviewers noticing is the rule that produced today's five bypass lanes.

How we would prove it

What already exists, so this does not overclaim novelty: a nightly canary watches suppression on one property — useful, but it is not required and it does not block anything before merge; and about fourteen unit tests pin the decision table itself. What does not exist is any test rig whose subject is the gate. That is the gap.

So the new rig deliberately does not re-argue the decision table — those unit tests own it — and it never re-implements the checking logic; it imports the real functions, because a rig with its own copy of the rules proves only that the copy agrees with itself. What it adds:

Pin the doors. Enumerate every place a message can leave and freeze that list, so a new door fails the build the day it is written rather than being found during an incident.
Go through the doors, not around them — text, email and the phone leg exercised for real. Per the principle above, this is the difference between a proof and a comfortable number.
A fixture corpus, and the same answer every run. No network, no clock, no ordering luck — an intermittent guard is one people learn to re-run.
It blocks before merge, not overnight afterwards.

One practical constraint on that last point: only five checks are required on the main branch, and our pinning jobs deliberately run after a push rather than on every pull request — a cost decision from 2026-08-21 that we are not reversing. So this rides inside the unit-test check that is already required, rather than arriving as a new gate of its own.

The choices that are genuinely open

1. What should the gate do when it cannot reach its own records?

In plain terms

Today a lookup failure blocks marketing but lets everything else through, so a database blip cannot swallow a lease document or a safety notice. The muted level inherits that.

Keep it as is: block marketing, let the rest through, log loudly.Recommended A rare blip that silently swallows a signing link or an emergency notice is a worse failure than a rare message reaching a muted person. Risk: during an outage, a muted person could hear from us — so the log has to be an alert, not a line in a file. Fail closed on everything except emergency and safety. The strictest reading, and the one that makes "the gate's answer is law" literally true. Risk: an outage becomes a silent freeze on ordinary business messages, which is the failure nobody notices until a resident complains.

2. How do the five bypass lanes get fixed?

In plain terms

Five places send texts directly today. Either we rewrite each to go through the gate, or we make the client itself refuse to work outside the gate — which fixes all five at once, plus the sixth nobody has written yet.

Make the client the gate's private property — anything else calling it fails to build.Recommended One change closes the whole class rather than five instances, and it is the same move as the build rule above. Risk: it touches every one of those lanes at once, so it wants its own careful rollout with the channel tests in place first. Reroute the five lanes one at a time; leave the client open. Smaller, safer steps. Risk: nothing stops lane number six being written the same way next month — which is exactly how we got here.

The safety checks that rewrite her words — inspection findings

Separate from whether a message may leave: what our safety checks do to it on the way out. One of them rewrote a sentence into "I don't have that answer on file right now" and shipped it twice to a real prospect — the line he called robot-like. That prompted a full read of the pipeline, against the code and against 72,558 real turn records. It found more than one bad sentence.

1. The record of what a safety check did is wrong — and it is wrong in the flattering direction. When the promise check rewrites a sentence, it writes into the audit trail that it "replaced it with a backed first-person line". Then, about a thousand lines later, a second step quietly swaps that in for the degraded fallback — after the record has already been written. On 11 out of 11 sampled fires (100%), the trail says the good line shipped and the robot line is what actually went to the person.

This matters beyond one check: the yellow-dot explanation we gave last night was built on those records, so it was systematically optimistic about what customers actually received. Any frequency or quality claim resting on this check's audit trail is unreliable until it is fixed.

2. The live 5-touch prospect sequence passes through no content safety at all. Armed and running since 2026-06-20 at Camellia. It sends prospect-facing leasing copy with no fair-housing check, no personal-data scrub, no invention check — because the whole content pipeline lives inside the reply loop, and anything that calls the send path directly skips every bit of it. The shared send path has five stages and not one of them looks at content.

This is the same conclusion the mute work reached from the other direction. Suppression and content checks both belong at the one gate — that convergence is the strongest argument on this page.

What else the inspection found

There are 16 checks, not 6. The internal Pipeline Lab shows six — the six it can see. Nearly all sixteen can rewrite, replace, strip, splice or silence the final text.
A personal-data scrubber redacted a property's own emergency phone number out of gas-leak evacuation instructions — "call the emergency line at +[REDACTED]" — because its redact rule matches any run of 10 to 17 digits while its detect rule requires 12 or more. Four real fires. It happened on bench traffic, but the defect is identical on a real resident.
The fair-housing check runs once, first, and never looks again at what later checks substitute. That is safe today only because every later substitute happens to be a fixed phrase — a convention, not a guarantee. The same is true of the personal-data scrub: nothing after it is ever re-scanned.
We are half-blind to all of it. Five checks have no replay coverage at all; eight only leave a record when they fire, so we cannot even count how often they run; and three of the rewriting checks leave no reviewable record of the draft they changed. The review screen is blind to ten of the sixteen.

What this adds to the design above

The text that ships is the text that was graded. One cheap mechanical pass runs last, over whatever any check substituted, and every check records the final text. This turns two safe-by-convention holes into safe-by-construction, and kills the false audit trail.
Every outbound lane passes the same pipeline — content checks move to the gate, or the gate refuses a message nothing has graded. This closes the cadence bypass and makes this page's harness the single test surface for suppression and content.
A check never writes customer prose an engineer typed mid-sentence. Its options become: block and escalate using curated copy from one reviewed place, ask Clara for another draft under the constraint, or delete the offending clause with no replacement. Splicing a literal into the middle of her sentence is retired. For the promise check specifically, the cheapest fix is configuration, not code: the robot line is the fallback for "no owner on file", and that field is empty at every property but the bench.
Every altering check is visible — a before-and-after record for each rewrite, a trace entry whether or not it fired, and all sixteen listed in the review screen.
No permanently disarmed checks. Two are switched off by default and have never fired in production. Arm them behind the harness, or delete them.

Appendix — seed corpus for the future harness

An adversarial review of the mute and gate behaviour as it exists today ran independently — its job was to find ways a message could still reach someone who should hear nothing. The findings have landed: 38 cases, each with the exact place in the code and a recipe to reproduce it, sorted into leaks, ways around the gate, weaknesses, and things already covered.

The adversarial review →What was tried, and what got through.

The machine-readable corpus lives at ~/agents/006/mute-red-cases-2026-08-29.md — one entry per case with its anchor and reproduction recipe, ready to be turned into tests rather than re-derived.

The split matters. Anything that is a genuine defect in the mute already merged is being triaged now for immediate failing-test-first fixes — those do not wait for next week. Everything else becomes the seed corpus for this harness.

The classes worth naming, one line each:

One-shot fan-out — a fresh record created after a mute comes back unmuted.
Pre-gate feed posts — messages published to the ops feed before the gate is ever consulted.
The vendor dial chain is ungated — an outbound call path that never asks.
Unknown-category fall-through — a send whose type the gate does not recognise passes rather than stops.
Caller-controlled skips — a flag the calling code sets to bypass the check, which is the opposite of "the gate's answer is law".
Over-blocking on the human one-send rail — the failure in the other direction: a person's deliberate message refused when it should go.