Mute, end to end

One switch that means "stop talking to this person", and the smallest system that actually honours it.

2026-08-29 · Status: Proposed — pending review · Two-minute read

The invariant

A muted person hears nothing and triggers nothing — except one notification to our team — until unmuted; the only things that still reach them are what a human deliberately sends and emergency or safety notices.

Everything below follows from that sentence. If a behaviour is not derivable from it, it is not part of this feature.

Why we need it

Tonight we muted one prospect completely, by hand. That took:

What it took	Why
Four database records written by hand — two for the phone, two for the email	There is no "mute a person". There is an opt-out lane keyed to one identifier at a time, and neither record knows about the other.
Two background jobs cancelled by hand	Their timers live in the job engine, not the database. Nothing cancels them when a person is silenced, and one was not even safe on its error path.
The thread set to human-owned, separately	Muting does not change ownership and ownership does not mute. Two switches for one intention.
And one thing we could not do at all: stop the team-notice emails	The only control is property-wide — it would change notifications for every resident and prospect at that property. v1 closes this: the notices are inside the mute.

The whole of v1 — five parts

A flag on the person. On or off. One click each way; who and when are recorded automatically.
One unconditional check at the single point where messages leave the system — covering both the messages to them and the internal emails about them. Not graded by message type, not skippable by a lane, not bypassed for replies. That gate is its own design, on its own page: One door out — including how the levels rank, what beats what, and how we stop a second way out being built.
A badge wherever the person renders — the conversation, the list, anywhere staff might hit send.
Voice forwards the call before Clara ever picks up. The check runs at the phone layer, so a muted person's call is handed to the office and the assistant is never in the call at all. Final shape pending a feasibility verdict.
One notification to the team when a muted person writes in — so a human can decide whether to answer by hand.

Human takeover sends pass the check because a human pressed send. That is the whole exception — no extra apparatus around it.

Decided

Inbound calls go to a human, and Clara is never in the call. Fede: "not answer and transfer to a human." Not answer-then-offer, and not something written into Clara's instructions and hoped for — Fede on that approach: "no i dont want this." The forward happens at the phone layer before the assistant is ever brought in. Two failure defaults are defined so there is no undefined state: if the mute lookup errors, the call routes normally and we log it loudly; if the property has no transfer number on file, the caller gets a plain system recording — never Clara. Final shape pending a feasibility verdict from the build in flight.

The team gets one notification when a muted person writes in. Fede, 2026-08-29: "do we have alerts for when someone messages and they are muted so that the team can determine if we should reply manually? like smith has notifications in camellia." One message on the notification channel Camellia already uses — who wrote in, what they said, and a link to the conversation. A person decides to ignore it or reply by hand. It opens no ticket, starts no chase, and repeats are collapsed within a sensible window. It does not use the internal escalation-email lane, which mute switches off.

Defaults, so nothing is undefined

A muted person writes in → stored, no reply composed, nothing sent to them — and one notification to the team so a human can choose to answer by hand.
Anything on a timer aimed at them → cancelled when muted, not restored on unmute.
An answer we still owe them → stays open and visible to staff; it just stops chasing them.
Emergency and safety messages, and anything a person authored → still go, and are logged as the exception.
They text STOP → handled as today, before mute logic runs. Mute can never weaken an opt-out.
Mute covers the person — every phone and email we can tie to them, not one thread.
A manual send → does not lift the mute, and does not restart any sequence.
The automatic emails to our own team about them → stop too. The single "they wrote in" notification above is the one deliberate exception. Both decided, see below.

Not in v1

Scheduled or expiring mutes ("mute for 7 days").
Per-channel mutes ("texts but not email") — one person, one state.
Bulk mute across many conversations.
Any reason, tag or category on the mute.
A standalone control for the internal notices — they follow the mute, they are not their own switch.

Sending by hand

A person can still send one message as Clara into a muted thread — the mute survives it, and nothing re-arms. How that send works, and why it has to be one indivisible act, is its own design: When a human answers.

Companion pages: Knowing when not to answer (why Clara talks when she should not), One door out (the gate that enforces this), When a human answers (sending by hand). Mute is the blunt instrument that must always work — teaching Clara when to stop is how it stays rarely needed.