Technical to Plain English

Rewrite technical content for a non-technical reader: same truth, no jargon, framed around what
it means for them rather than how it works.

1. Read the technical source (resolution notes, diagnosis, pasted vendor response — pull it
   from the ticket if referenced). Identify the three things the plain version must carry: what
   was wrong, what changed, and what it means for the reader.

2. Translate using these rules:
   - Replace every technical term with what it does, not a simpler synonym for what it is
     ("DNS wasn't resolving" -> "computers couldn't look up where to find the server").
   - Analogies are allowed when they clarify — keep them modest and accurate; an analogy that
     overstates certainty or severity is worse than jargon.
   - Lead with the reader's stake: impact and status first, mechanism second (only as much as
     they need).
   - Keep quantities honest but round ("about 40 machines," not "38 endpoints").
   - Sentence test: would a smart person with no IT background nod along? If a sentence needs
     IT knowledge, rewrite it.

3. Preserve exactness where it matters: dates, durations, what data was or wasn't affected, and
   any action the reader must take stay precise, never approximated away.

4. Output the plain-English version standing alone. If it's destined for an email, apply our
   house email tone (answer first, plain, no filler); if I just need the explanation, the text
   itself is the artifact.

Simplify the language, never the truth: no rounding "mostly fixed" up to "fixed," no dropping
caveats, no upgrading uncertainty into confidence. Never introduce cause claims the source
doesn't make. Security topics keep defensive-writing rules: "suspicious activity," not "hack,"
unless confirmed. Don't condescend — plain is respectful, not childish. If the source is
ambiguous or self-contradictory, flag it to me instead of picking an interpretation.