Editorial Methodology

1. Start with a real decision

A public page must serve a distinct intent: checking a limit, diagnosing an error, comparing choices, understanding a verified change, or using the observation in a practical tool. Keyword variants do not justify duplicate pages.

2. Prefer primary sources

We use official product documentation, help centers, API references, changelogs, and standards documentation. Community reports can reveal a question but do not establish a current limit on their own.

3. Store observations, not copied prose

Each externally factual value is tied to a platform, constraint, scope, value, qualifier, source, verification date, and status. Pages and tools reuse the same record so corrections propagate consistently.

4. Preserve history

When a verified limit changes, the prior observation becomes superseded and a new observation is appended. We do not invent effective dates: a dated changelog can establish a change date; a documentation check only establishes when we observed the current value.

5. Handle conditional limits explicitly

Plan, region, model, runtime, version, configuration, account tier, and feature state can all change the answer. Where an official source gives a default rather than a universal cap, we label it as such.

6. Review conflicts and freshness

If official sources conflict, we record the conflict, prefer the most specific and current source when justified, and avoid presenting false certainty. Volatile observations carry visible verification dates and are queued for recurring review.

7. Correct in public

Material factual corrections are logged on the corrections page. Small copy or accessibility fixes may be deployed without a factual correction entry.

Inspect the public source register for the first-party documents behind current observations and the change database for supported before-and-after events.