Standards first. Receiver policy second. Heuristics last.

Every technical guide is built in layers. The protocol layer uses current IETF RFCs. The receiver layer uses first-party sender documentation from mailbox providers. Only after those two layers are clear do we add operational examples such as gradual ramp schedules or pause rules.

How numbers are handled

We do not label a daily send count as universally safe. A number is either a receiver requirement, a measured example, or an illustrative scenario. The article should say which one it is. Sudden changes in bounce, complaint, filtering or reply behavior matter more than a number copied from another sender.

How drafting and automation are used

Research starts with primary RFCs and first-party receiver documentation. AI may assist with outlining, drafting and repository QA, but it is not treated as a source of protocol facts. Claims about SPF, DKIM, DMARC, SMTP or IMAP are tied back to the cited standards or provider documentation, while numerical ramps and operating scenarios are labeled as examples rather than universal limits.

How changes are maintained

Protocol pages are checked against RFC Editor. Receiver requirements are checked against official sender documentation. Material changes should trigger an article update date and source-note review.

Quality controls

The repository contains separate structural and content QA commands. Structural errors are build-blocking. Content targets such as minimum length or missing real contributor configuration are warnings so CI does not create false outages.