Editorial policy
How the technical writing on this site is commissioned, sourced, reviewed, tested and corrected.
Why a consultancy publishes its editorial standards
Everything here is written by a company that also sells the work it describes — a conflict worth naming rather than hiding. If a page of ours is going to make you change a BGP export policy or drop a DNS TTL from 300s to 30s before a cutover, you are entitled to know who wrote it, what it was checked against, and what happens when it turns out to be wrong.
Cloud networking is also a field where confident, outdated writing is the norm: a page that was accurate about a provider's cross-zone load balancing behaviour in 2021 can be quietly wrong today, and nothing on it will say so. This policy covers both the standard a piece meets before publication and the maintenance it gets after, across every technical insight, guideline and blog post.
Who writes
Content is written by the practitioners on the delivery team described on our team page — network architects, DevOps engineers and performance analysts — not by a separate content function. Whoever writes about transit gateway topologies designs them on client engagements; whoever writes about failover sits in the cutover call at 02:00.
We publish under the CloudRoute engineering team rather than inventing personal bylines for pages several people touched. Each subject area has an internal specialist who owns approval for it; ask who reviewed a page and we will tell you.
How a piece is made
Nothing here is commissioned from a keyword list. A page exists because a question came up in client work often enough to be worth answering once, properly, in public.
| Stage | What happens | Gate |
|---|---|---|
| Commission | A recurring client question, incident pattern or provider change becomes a brief with a defined scope. | Real question, not already answered here. |
| Research | Primary sources gathered and read: provider documentation, RFCs, standards text, release notes. | Every load-bearing claim has a source or a test. |
| Draft | The practitioner writes it, including the cases where the advice does not apply. | Trade-offs are stated, not just the recommendation. |
| Specialist review | The area owner reviews for technical accuracy; a second pass checks structure, links and accessibility. | The reviewer would hand the page to a client. |
| Publish | Live, with a publication date and, for provider behaviour, a last-verified date. | Dates visible to the reader. |
| Re-review | The page returns to the owner on a schedule and after significant provider changes. | Still correct, updated, or withdrawn. |
Client deliverables get the same review discipline; see our delivery process.
Sourcing standards
Primary sources first, in this order of preference:
- Provider documentation — AWS, Google Cloud, Azure and Cloudflare docs and release notes for anything describing what a provider actually does, as in our provider-specific insights.
- RFCs, IETF drafts and published standards — for protocol behaviour. If we say BGP does something, the reference is the specification, not a post that paraphrased it. We flag a citation of a draft rather than a published RFC, because drafts change.
- Our own measurements — where a claim is testable, as described below.
- Secondary sources — for context, clearly identified, never the sole basis of a claim.
Provider behaviour changes without notice, and defaults change more often than documented limits do. Anything here describing a provider's current behaviour carries the date it was checked, so you can judge how much weight it still deserves. Treat any undated claim about a provider default, here or anywhere, as a hypothesis to verify in your own account.
Where sources conflict — documentation against observed behaviour, or two provider documents against each other — we say so and describe both. We do not pick the version that makes the recommendation tidier.
Testing claims
Where a claim is testable, we test it in our own accounts before publishing: failover timings against health-check intervals, DNS behaviour against configured TTLs, path selection under prefix withdrawal, MTU edge cases. Conditions are stated, because a number without its conditions is decoration.
Where a claim cannot be tested that way, we label it. Three kinds of statement, kept distinct:
- Measured — we ran it, under stated conditions, in our own environment.
- Documented — the provider or the specification says so, as of the stated date.
- Recommendation from experience — a judgement formed across engagements. Useful, but not a measurement, and we do not dress it up as one.
Availability and latency figures on this site are design targets and SLOs an architecture aims at, stated as such. They are not achieved results, and we do not present client outcomes as anonymised statistics — see how we talk about results.
Use of AI
Disclosure. We use AI tools to assist with research, outlining and first drafts. Every piece published on this site is then edited, fact-checked against primary sources and approved by a human on the delivery team before it goes live, and that person is accountable for it. We do not publish unreviewed generated text. Where AI output could not be verified against a primary source or a test, it does not survive review.
The reason is practical. Language models are confidently wrong about exactly what this site covers: current provider quotas, default timeouts, which knob exists in which console. Treating generated text as a draft to be checked, never as a source, is the only way we have found to use these tools without degrading what we publish.
Independence
We name the providers and tools we actually use in delivery, and criticise them where criticism is warranted. Concretely:
- We do not sell links, sponsored posts or paid placements, and take no payment to mention or recommend a product.
- We are not a reseller and take no referral fees on the platforms we recommend.
- Any commercial relationship that could reasonably affect a recommendation is disclosed on the page carrying it.
- Recommendations are made against your architecture and constraints; our engagement shapes are structured so advice does not depend on a particular platform being chosen.
Corrections
If something here is wrong, tell us. Email [email protected] with the URL and what you believe is incorrect. A link to the contradicting documentation or RFC section is ideal; what you observed is enough. It reaches the engineers who would answer it, and you get a reply within one business day during office hours of Mon–Fri, 9:00–18:00 Pacific.
Verified factual errors are fixed promptly. Where a correction materially changes the advice — a wrong value, a reversed conclusion, a procedure that would not have worked — we note it and its date on the page rather than editing silently. Typographical fixes carry no note. If we disagree with a reported error, we say why rather than leaving it unanswered.
Review cycle
Pages describing provider behaviour are re-reviewed at least annually by the specialist who owns the area, and sooner when a provider ships a change that affects them: a new interconnect product, altered load balancer health-check semantics, a deprecation notice. Protocol material follows the same annual cycle but moves less, since RFCs do not.
Re-review has three outcomes — confirmed with its verification date advanced, updated, or withdrawn because it no longer describes a real situation. We would rather remove a page than leave a stale one earning traffic. Other questions about how we work sit in the FAQ.
Found something wrong, or want the reasoning behind a page?
Send the URL and what you observed. Editorial questions are answered the same way technical ones are — directly, by the people who wrote the page.
Start a conversation Read the technical insights