deliverlensWrite facts without causal language
Examples: “Two of three healthy personal Gmail seeds observed spam in runs A and B”; “Gmail Postmaster authentication showed a DKIM decline for the From domain”; “Yahoo SMTP deferrals increased after 14:00 UTC”; “complaints concentrated in import source Q.” Include counts, times, definitions, and limitations.
Then create hypotheses: “Stream X may be using the wrong DKIM tenant,” “source Q recipients did not expect the frequency,” or “the seed panel may not represent the business gateway segment.” Keep a clear boundary between the two lists.
Rank each hypothesis
Score impact, evidence strength, affected scope, urgency, reversibility, owner, and cost. Permission/suppression failures and reproducible SMTP/authentication errors usually outrank speculative content changes. A public blocklist hit on an unrelated web IP should not enter the plan.
Use a table:
| Hypothesis | Evidence for/against | Next test | Owner | Success/stop condition |
|---|---|---|---|---|
| Wrong DKIM config on stream X | failing aligned signature; other streams pass | fix staging tenant and send paired test | Sender ops | aligned DKIM passes twice |
Design one next test
Control sender, audience, timing, and infrastructure except for the intended variable. Use authorized recipients. Define result states including unknown. Record rollback before production changes.
For provider hypotheses, consult current official dashboards/guidance and preserve their scope. Google data is delayed and can omit low-volume periods; seeds are small controlled observations. Neither should be treated as universal.
Execute and close the loop
Contain harmful sending immediately where evidence supports it. Otherwise run the smallest safe test, collect fresh message/provider evidence, and mark the hypothesis supported, rejected, or still uncertain. Do not stack several fixes and then claim which one worked.
Publish a bounded plan
Show top actions, owners, deadlines, monitoring, rollback, and unresolved unknowns. Archive discarded hypotheses with reasons so they do not return as folklore.
A good plan reduces uncertainty and changes sender behavior safely. It does not promise an inbox percentage, and it can conclude that more representative evidence is needed before any production change.