When the docs have changed

Every document in this hub carries freshness.verified_at and a provenance list with the URL and the date it was read. Every one of them was read on 2026-10-21 and every tier is asserted — which is the only tier an author may write. Google Cloud will move on. This is what to do when it has.

1. First, decide which of four things is happening

Symptom	Likely cause	Where to go
a call fails with an error this hub documents	nothing is stale. Follow the catalogue row	reference/<family>/errors.md
a call fails with an error no catalogue names	the hub is incomplete, not wrong	§3 — file it
a flag, field or role name is rejected	the surface changed	§2, then §3
a product is named differently, or is retired	a rename or retirement	§3 urgently — this is the class that does most damage

The fourth row matters most. Two examples from this hub's own first release: Cloud Deployment Manager "reached end of support on March 31, 2026", and the page at the Dataproc overview URL is now titled "Managed Service for Apache Spark". A hub that is wrong about a retirement is worse than no hub, because it is confidently wrong.

2. Check in this order — cheapest first

1. Read the document's provenance. It gives the URL and the read date. Open that URL.
2. Compare the specific claim, not the whole page. A page that has been restructured may still say the same

thing.

1. Check whether the page itself prints a newer update date than the read: date in provenance.
2. Check for a second, more specific page that disagrees. A retirement page and a what's-new page can

disagree; prefer the more specific or newer one, and record both — the disagreement is itself information.

1. Only then conclude the hub is wrong. The most common outcome at step 2 is that the hub is right and the

call is doing something slightly different.

3. The drift report

Report it in this shape. Every field is one that a maintainer would otherwise have to re-derive:

document:        reference/iac/deployment-manager-status.md
claim:           "reached end of support on March 31, 2026"
observed:        <what you saw instead, verbatim>
source checked:  <the URL from provenance>
source now says: <verbatim text from the page today>
page date now:   <the page's own last-updated date today>
read date in hub: 2026-10-21
class:           rename | retirement | surface change | new error | incomplete | contradiction
blast radius:    <which other documents repeat this claim — grep `covers` for the term>

blast radius is the field people leave out and the one that saves the most time. A fact in this hub is usually in two or three places: a reference, an error catalogue row, and a parity guide. Fixing one leaves the others wrong, and a reader who meets the stale copy trusts it.

4. What not to do

• Do not "fix" a document from memory. The rule this whole hub is built on is that every fact comes from a

page that was read. A memory-sourced correction is how a hub starts drifting faster than the vendor does.

• Do not delete a claim because a page no longer mentions it. An absence on a page today is not evidence

the fact was never true. Record the absence as an absence — this hub does that in a dozen places, and each one says which page was silent.

• Do not raise the freshness tier. asserted is the only tier an author may write. A stronger tier is

refused by the platform, and would be a claim about verification that nobody performed.

5. Where the hub already admits it does not know

Each family's release note has an "absences recorded rather than filled in" section and a "known missing" list. Before filing a drift report, check whether what you found is already there — several of the most likely questions (log retention periods, Spanner's capacity minimum, Config Connector's deletion policy, the Migrate-to-VMs cut-over mechanics) are recorded as deliberately unanswered.

changelog/2026-10-21-release-notes.md collects them.