What the standard requires
A security or provider-specific statement in this atlas is only as good as the page it came from, on the day it was read, under the conditions that page describes. Cloud providers change documented behaviour several times a year, often without changing the URL. So any statement a design might lean on carries four things with it:
- The exact source. The narrowest page that says it: the provider's documentation page for that feature, the specification's changelog, the official incident report. Not the provider's home page, and not a blog post quoting the documentation.
- The date it was checked. The day somebody read the statement against that page. Not the page's own publication date, and not the date the atlas edition was published.
- The conditions it holds under. The edition, licence, Region, version, protocol revision or preview status the statement depends on. "Tokens can live up to 28 hours" is true only where both client and resource take part in continuous access evaluation.
- The evidence tier. T1 for a primary source, T2 for a faithful copy of one, T3 for reputable secondary reporting. Statements at T4 or T5 aren't registered as verified claims at all; they are labelled in the text as unverified.
Which statements are registered
A statement is registered as a verified claim when it meets any of these tests:
- It describes how a provider grants, denies or revokes access: policy evaluation order, deny semantics, token lifetimes, permission inheritance, consent.
- It states a date a design depends on: a retirement, an end of enablement, a release, a regulatory deadline.
- It gives a number a design is sized against: a propagation delay, a version skew window, a limit.
- It records what happened in an incident and is used to argue for a design choice.
Architectural reasoning built from those facts isn't registered. It is labelled as inference in the text, so that you can check the reasoning yourself.
How a claim appears on a page
A registered statement reads as ordinary prose, followed by a bracketed number. The number links to the claim's row in the Verified claims table at the foot of the page, which gives the statement in one sentence, a link to the exact source page, the date it was checked, the evidence tier, and the conditions it holds under.
The Markdown version of every page, and the text the Copy for LLM button copies, carry the same table. A model that quotes the statement can quote its source, date and conditions with it.
How claims are rechecked
Every registered claim is read against its source again before each edition, and whenever a provider announces a change to the feature. When a source no longer says what the claim says, one of three things happens:
| What the check finds | What changes |
|---|---|
| The source says the same thing | The checked date moves forward |
| The source says something different | The statement and the page text are corrected, and the correction is recorded on the evidence page |
| The source no longer says it at all | The statement is cut back to what the source still supports, and the rest is labelled unverified |
What the standard doesn't promise
A checked date is a statement about the past. It says a person read the page on that day and it said this; it doesn't say the page still does. Providers roll out changes by Region and by tenant, and preview features change without notice. Treat the source link as the authority and the atlas as a map to it. Before you commit a design to a claim, read the source yourself and test the behaviour in your own tenant or account.
Where to look
- The evidence page holds the full verification ledger, the corrections made in each edition, and the questions still open.
- Each chapter's Verified claims table lists the claims that chapter makes.
- Every source is listed in full in each page's Sources section, linked to the publisher.