Editorial Policy

Publication standards

• A page must answer a distinct user question rather than mirror a nearby keyword with minor wording changes.
• A page must define a real workflow, boundary, validation step, or comparison frame that the user can apply.
• A page should make its scope visible: what it includes, what it excludes, and where the next page should take over.
• Pages that only restate generic provider concepts without workflow value are candidates for rejection, rewrite, or de-emphasis.

Review before publication or material revision

1. Define the user question, the likely search intent, and the main billing drivers before writing.
2. Compare the intended page with existing pages so parent pages, comparison pages, and support pages keep clearly different roles.
3. Check that included and excluded cost boundaries, unit assumptions, and validation steps are explicit.
4. Link the page into a complete workflow so the reader can estimate, validate, compare, or report an issue.
5. Run build and site checks before publishing material changes.

How overlap and page sprawl are handled

• A parent page should own broad education and route the reader toward narrower tools only when the narrower page adds a distinct next step.
• A support page should exist only if it clarifies a repeated decision, failure pattern, or validation step that the parent page cannot cover cleanly.
• When two pages drift toward the same job, the stronger page is expanded and the weaker page is rewritten, merged, or de-emphasized.
• Publishing an extra keyword variation is not treated as a win if it weakens the site's overall clarity or reviewability.

This policy prefers fewer pages with clearer roles over a larger archive of near-duplicates.

A page can be consolidated or removed when its job is already handled better elsewhere.

What can trigger revision or refresh

• Pricing structure, units, or included allowances materially change.
• User intent shifts enough that a page starts overlapping heavily with a nearby page.
• Search demand shows that a parent page should be strengthened before more narrow pages are added.
• A correction request, broken workflow, or repeated user confusion shows that the current page is no longer carrying its role clearly.

`Last updated` indicates when a page itself was last reviewed or materially revised. It should not be read as a promise that every linked provider rule changed on that exact date.

Corrections and feedback review

If you find a factual issue, unclear boundary, broken calculator path, or estimate mismatch, please report it so it can be reviewed against the page scope and source material.

After a correction is submitted, the first step is to classify the problem: factual error, boundary problem, workflow break, calculator bug, or page-overlap issue.

• Include the page URL and the specific statement, output, or workflow step that looks wrong.
• Share the provider, region, and billing unit if they matter to the issue.
• If the issue is a mismatch, include the inputs you used and the direction of the difference.
• If the issue is overlap or thinness, link the adjacent page that seems to be carrying the same job.

Review does not assume every report leads to the same outcome. Some issues require a factual correction, some need a boundary rewrite, some reveal that a page should be merged into a stronger workflow page, and some show that the existing page is carrying too much scope for one model.

A material revision means the page's scope, estimate logic, validation path, or interpretation guidance changed in a way that affects how the page should be used.

What this page does not govern

• Methodology governs how estimates are built, when they are unsafe, and how they should be validated.
• About explains what the site is for, who it serves, and what it does not pretend to replace.
• Contact is the operational page for help requests, bug reports, and correction intake.
• Privacy Policy governs browser-side handling and site usage data.

What we do not publish as final truth

• Official quotes or guaranteed final bill amounts.
• Pages that rely on generic filler without a distinct workflow outcome.
• Hidden formulas that cannot be traced back to measurable drivers or visible assumptions.
• Provider-specific statements that have not been checked against current official documentation.

When a page is rejected, rewritten, or reduced in prominence

• Rejected if it does not answer a distinct question or cannot support a real estimating workflow.
• Rewritten if the core topic matters but the page is carrying weak assumptions, vague boundaries, or a template-like structure.
• Merged or reduced in prominence if another page already serves the same user intent more clearly.
• Refreshed and kept if the page still owns a useful role and the underlying assumptions can be made explicit again.

A page can remain live but lose prominence when it still has reference value but no longer deserves strong navigation or recommendation placement.

Survival is not the same thing as recommendation: a page can continue to exist without continuing to deserve prominent routing.

Source material used in review

• Official provider pricing and product documentation from AWS, Azure, and Google Cloud.
• Billing exports, usage metrics, and unit definitions when explaining how to validate an estimate.
• Observed user workflows that move from raw usage inputs to a decision-ready estimate.

Provider documentation remains the source of truth for procurement decisions and final billing details.