How every inbox and domain in the fleet gets measured, tagged, ramped, hospitalized, rotated, reassigned, and retired, automatically, every night. Money follows one rule: spend goes to assets that deliver, and burnt assets come off the books before they bill again.
Approved · Aug 27The system already measures health nightly (DNS auth, blocklists, landing pages, bounces, warmup scores, reply rates). This doctrine adds the layer that acts on those measurements: every inbox carries exactly one status tag, every tag has defined entry and exit rules, and every dead asset has a scheduled, billing-aware exit. Humans approve destructive steps with one click; nothing else waits on a human.
The recurring cost is inboxes, not domains. The whole doctrine exists to move inbox spend off burnt domains and onto newly warmed ones, fast, and never to pay a second month for an asset we already know is dead.
Applied nightly in Bison and the database. Worst signal wins. One bad night is enough to demote; it takes three clean nights to promote, so nothing flip-flops. Each state's official name is a life-arc status phrase; the full vocabulary system is §12.
| State | Meaning | Sending |
|---|---|---|
| 🔵 in school | Inside its warmup window, not yet graduated | Warmup only, zero cold email |
| 🟢 on the job | Healthy, in rotation, producing | Normal ramp schedule |
| 🟡 under observation | One degraded signal last night, being watched | Unchanged, no upward pushes |
| 🔴 in the hospital | Active damage or cannot send | Limit forced to zero. Stays in its campaigns; warmup keeps running (that's the physio) |
| 🟣 on leave | Healthy, deliberately rotated out this period, returns on schedule | Zero cold, warmup maintains |
| ⚪ on call | Graduated and healthy, benched, deployable on demand | Zero cold, warmup maintains |
| ⚫ in the graveyard | Pronounced dead; sender awaiting burial (purge from Bison) | Frozen. Excluded from all automation and all health math; no exit except burial |
The grammar is load-bearing: "in" = held by an institution with entry/exit rituals (enrolled→graduated, admitted→discharged), not freely deployable. "under" = suspended, deployable but frozen. "on" = free and healthy. The preposition alone tells you the tier. ⚫ is not a seventh health state but a coffin lid: entered only by pronounced, left only by burial, immune to hysteresis, invisible to every average.
| Signal | Threshold | Sends you to |
|---|---|---|
| SMTP/IMAP connection | Auth failure: the inbox physically cannot send | 🔴 hospital |
| DNS auth (SPF/DKIM/DMARC) | Any of the three failing. Every send while broken deepens the damage | 🔴 hospital |
| Bounce rate | >3% on meaningful volume | 🔴 hospital |
| Bounce rate | 1.5–3%, creeping | 🟡 watch |
| Reply rate vs own baseline | Dropped ≥75% week-over-week (min 30 sends both windows) | 🔴 hospital |
| Reply rate vs own baseline | Dropped 50–75% | 🟡 watch |
| Reply rate vs client peers (new) | ≥50% below the median of the client's other domains (volume gate scaled by domain class, §7) | 🟡 watch; at 75% below → placement test |
| Bounce text names a block | Receivers explicitly citing a reputation policy | 🔴 hospital |
| Blocklist listing alone | New SURBL/DBL listing, no downstream evidence | 🟡 watch only |
Why a listing alone is only watch: we live-tested it. Sends from SURBL + DBL-listed domains with production copy landed Gmail Primary 9 of 10 times. 238 of 448 live domains are DBL-listed today; treating listings as burn signals would torch half a working fleet. Listing plus failed placement or reply collapse upgrades to hospital.
Ramp rules already live: upward pushes at most double the current limit, one step per 7 days per inbox, down-snaps immediate. This doctrine adds the missing interlock:
No inbox below graduation score ever receives an upward push. Found live on Aug 26: the age-based ramp had stepped inboxes with warmup scores of 10–27 up to 8 cold sends per day. Only their lack of campaign attachment prevented cold email from provably burnt domains. The ramp must read the warmup score before every push.
Graduation gate: 90+. A 90 score means 9 of 10 warmup emails are landing in the inbox, which is graduation-worthy. Below 90 is watched, never pushed, and handled by the checkpoint schedule below. There is no fixed "extension week": what earns more warming time is trajectory, not a calendar band. Azure modes set the calendar floor, not the bar: azure-fast may graduate at day 21 like everyone else, azure-aged holds until day 90; both need 90+ at release.
Which score window are we watching? Today: the wrong one. Verified live against all 606 P1 warmup inboxes: Bison's displayed warmup score is lifetime cumulative: total kept-in-inbox ÷ total ever sent since day one. It lags badly (a rough first week drags the score for months) and it cannot show direction. So the orchestrator snapshots each inbox's warmup counters nightly and computes its own rolling 3-day and 7-day scores plus the trend between them. Every gate and checkpoint in this doctrine reads the 7-day rolling score; trend means the 7-day score vs itself ~4 days earlier (up = +3 points or more, flat = within ±3, down = −3 or worse).
Context: a domain warms ~14 days before inboxes go on. Inboxes then warm ~21 days. Inbox subscriptions are prepaid monthly and locked to their domain, so an early cut buys nothing: the month is already paid. The play is to decide early, queue the replacement early, and execute the cut at the renewal boundary so a failing domain never bills twice.
Inboxes provisioned on the warmed domain. Warmup starts. Billing clock starts: renewal date recorded per inbox.
Score means nothing under ~20 warmup sends. First meaningful read lands here. Under 50 → 🟡 watch. No cut: the month is paid, warming continues either way, and low starts sometimes recover.
7-day rolling score under 80 → queue the replacement now. Buy or pull the new domain and start its 14-day domain warming immediately; the failing domain keeps warming on the already-paid month while its successor gets ready. 80–90 → trend check: trending up, keep warming; flat or down, queue the replacement anyway. Direction tells you where this is heading before the calendar does. Successors are drawn from the aged reserve, never purchased on demand: washouts consume inventory, the slow-drip buy plan refills it, and if washouts outrun inventory the system alerts a human instead of spending past plan.
90+ → graduate, cold email begins. 80–90 → trend decides: trending up, keep warming toward the renewal boundary; flat or down, it's replaced. Under 80 → replaced, no trend check needed; the replacement should already be mid-warm.
Replacement domain finishes its 14-day warm right as the failing domain's inbox month ends. Cancel the old inboxes on the eve of renewal. Zero second-month spend, zero coverage gap. Domain gets a death certificate (cause: probable prior abuse) and lapses at the registrar.
The math is the argument: a day-14 decision plus a 14-day domain warm means the replacement is ready at day 28, exactly when the monthly inbox subscription renews. The queue-early rule turns the billing calendar from a leak into the natural cut schedule.
Every inbox on the domain uniformly low → the domain is burnt (typically bought with unseen abuse history): retire the domain, replace it. One straggler among healthy siblings → replace the inbox only; the domain is fine.
Every inbox carries a renews_at date, sourced from the provider at provision time (icemail order date, tenant billing anchor, workspace billing date). This powers:
Reply rate is the only deliverability measure that survives contact with reality, but it mixes two causes: bad copy and bad infrastructure. Comparing a domain against the client's other domains untangles them. Not because every domain sends identical copy (it doesn't: inboxes sit in several campaigns at once and assignment is mixed), but because random mixing means every domain sends roughly the same blend of the client's campaigns over a rolling window. When nobody's blend is special, a domain that still lags the family is lagging for domain reasons:
| Picture | Diagnosis | Action |
|---|---|---|
| ALL of a client's domains are getting weak replies, roughly evenly | The copy, offer, or targeting is bad. The infrastructure is fine | These are healthy domains stuck on a dead campaign. When the client churns or the copy is chronically dead, move those good domains over to another client's campaigns (new redirect, new signature, new campaigns) instead of retiring working assets. That is all "reassignment" means |
| One domain doing clearly worse than its siblings on a comparable campaign blend | Copy proven innocent by the siblings. The domain itself is suspect | Two-arm placement test (§10). Both arms clean → keep watching. Neutral arm spams too → hospital → retire path. A lagging domain never gets moved to another client: its reputation travels with it |
Random mixing is the control, so the sensor must verify the mix before trusting a verdict. Before any black-sheep call, check the domain's campaign blend against its siblings'. If its sends are concentrated in one campaign unlike the rest of the family, compare within campaigns instead: below its siblings inside every campaign they share = a true black sheep. Below only in the overall number = it is carrying a weak campaign, and that is a copy finding, not a domain finding. The same guard applies to the week-over-week drop detector: a domain whose campaign mix shifts into a weaker campaign can fake a deliverability drop. And no domain is ever judged on reply data alone: the two-arm test (§10) hits the domain directly and is immune to campaign mixing entirely. The reply sensors screen; the lab diagnoses.
No fixed 1,000-send minimum: a Google/MS domain runs 2 inboxes and might not see 1,000 sends in its first two months. The gate is statistical instead: enough sends that the client's own median reply rate predicts about 5 replies. For a client whose domains median 2%, that's ~250 sends; sitting at 0–1 replies on that volume is signal, not luck. A ramped Google domain reaches it in ~2 weeks; an azure domain (25 inboxes) in ~2 days. Below the gate the verdict is "insufficient data," never a fake judgment. Google/MS domains are measured over a rolling 30 days, azure over 14, so slow senders still accumulate a real sample.
Healthy inboxes rotate through sending and resting periods by batch, so no domain sends every week forever; the reserve bench holds warmed, healthy inboxes ready to deploy or to backfill a replacement. Rotation depends on the batch system being populated (it currently is not: 0 of 569 domains are in a batch), so 🟣 and ⚪ ship after batches exist. Everything else in this doctrine stands alone.
Retirement requires a confirmed burnt verdict, never idleness. Idle but clean goes to reserve. Qualifying verdicts:
EmailGuard Pro (~$49/mo) replaces the homemade seed-account build. Their seed bank beats anything we'd maintain, we already integrate with their API for blocklist checks, and the doctrine only ever uses placement tests sparingly, as signals: confirming a peer-outlier, confirming a hospital recovery. Trigger logic stays ours; execution is theirs. Placement tests never decide alone; they confirm.
Every diagnostic placement test runs two arms from the same inbox: the real campaign copy, and a neutral control so short it cannot trigger a content filter (subject "tomorrow meeting", body "see you tomorrow - Bob"). The pair separates what a single test never can:
| Real copy | Neutral copy | Verdict | Action |
|---|---|---|---|
| Inbox | Inbox | Domain clean, copy delivering | If replies are still low, it's the offer or targeting, not deliverability. No infra action |
| Spam | Inbox | The copy is fingerprinted. The domain is innocent | Copy surgery: strip sections (phone number, links, calendar URL) and retest until the trigger is found, then rotate the trigger. Phone numbers are the most common. The domain never goes to hospital for this |
| Spam | Spam | The inbox/domain is burned. Even "see you tomorrow" can't land | Hospital → retire path |
| Inbox | Spam | Noise | Retest before concluding anything |
This also splits "copy problem" into two different diseases: fingerprinted copy (filters block it, fix with copy surgery) vs weak copy (delivered fine, ignored by humans, fix with a better offer). Reply-rate data alone cannot tell them apart; the neutral arm can.
The whole system speaks one language: a life, from birth to burial. Three layers, one law: states are prepositional phrases ("is ___"), events are past-tense verbs ("was ___"), instruments are nouns that pass the stranger test: a new hire hears the term once in a night-rounds report and knows what it is, no glossary. Never mix layers, and anything added later has a rule to follow.
| What happened | Verb | What happened | Verb |
|---|---|---|---|
| Provisioned | born | Rotated out / brought back | granted leave / recalled |
| Day 5–7 first read | screened | Moved to another client | relocated |
| Failed a day-14/21 gate | flunked | Retirement approved by a human | withdrawn (care withdrawn) |
| Passed at 90+ | graduated | Death confirmed by the verify-dead gate | pronounced |
| Deployed from on call | hired | Inbox subscriptions cancelled | settled |
| Sent to observation | referred | Tombstone written, sender purged from Bison, domain lapses | buried |
| 3 clean nights, released | cleared | Into / out of the hospital | admitted / discharged |
Night rounds (the nightly monitor run) · the report card (rolling 7-day warmup score) vs the GPA (Bison's lifetime score, never judge by it, read the latest report card) · milestones (day 7/14/21 gates) · newborn screening · failure to thrive · growth spurts (ramp pushes, milestone-gated) · the successor (the replacement domain, named at day 14, warmed to take over at the renewal boundary)
The family (a client's domains, all on the same copy) · the black sheep (the one domain lagging its siblings) · the lab (EmailGuard) · the two-arm test (real copy + neutral control, §10) · copy surgery (strip sections until the trigger is found) · prognosis (hospital trend: improving / stable / declining) · physio (warmup during the stay) · clean bill of health (3 clean nights)
Life support (the retirement queue) and the machines (its monthly carry cost) · DOA (the immediate-retire class: found dead, straight to the coroner) · the coroner (verify-dead gate) · the death certificate (cause + evidence) · the estate (a dead domain's subscriptions) · the bills (the weekly renewal forecast: who renews, when, for how much) · the tombstone, the graveyard, no resurrections
Night rounds, as it will actually read: "Night rounds complete. 12 born. In school: 41 on track, 3 failures to thrive, successors named. 2 graduated to on call. Opus family: one black sheep referred, sent to the lab. In the hospital: 3 improving, 1 flatlined, moved to life support. The bills: 27 renew Friday while on life support, decide now. Coroner pronounced 2 DOA, estates settled, tombstones written."
The doctrine, condensed to eight positions. Approved by Aydan and Mitchell, Aug 27. Build order: infra-orchestrator issue #29.