# Claim Verification Standard

> The rule every security and cloud provider claim in the atlas follows: an exact source, the date it was checked, the conditions it holds under and its tier.

- Web page: https://www.alesanalytics.com/architecture/verification-standard
- Markdown: https://www.alesanalytics.com/architecture/verification-standard.md
- Part of: [Enterprise Architecture Atlas](https://www.alesanalytics.com/architecture.md), section "Reference"
- Last verified: 13 October 2026
- Publisher: Ales Analytics

## 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:

1. **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.
2. **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.
3. **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.
4. **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 |

> **An example from this edition.**
>
> Earlier editions recorded that Restricted SharePoint Search retires on 31 January 2027. On 13 October 2026, Microsoft's page (last updated 18 August 2026) still stated that new enablement is blocked from 31 July 2026, but no longer gave a final retirement date. The claim was cut back to the enablement block, the end date was downgraded to unverified, and the pages that relied on it were corrected.

## 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](https://www.alesanalytics.com/architecture/evidence.md) 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.

Should you have any questions regarding this page, please contact us at solutions@alesanalytics.com.

## Sources

1. [Restricted SharePoint Search](https://learn.microsoft.com/en-us/sharepoint/restricted-sharepoint-search). Microsoft, 2026. Retiring: new enablement blocked from 31 July 2026. Described by Microsoft as temporary, and not a security boundary.
2. [Continuous access evaluation in Microsoft Entra](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation). Microsoft, 2026. Tokens up to 28 hours in CAE sessions, revoked on critical events at participating resources.

## Where to go next

- Previous: [Evidence, Verification and Open Questions](https://www.alesanalytics.com/architecture/evidence.md)
- Next: [Enterprise Architecture Glossary](https://www.alesanalytics.com/architecture/glossary.md)
- Overview and every page: [Enterprise Architecture Atlas](https://www.alesanalytics.com/architecture.md)
- The whole site in one file: https://www.alesanalytics.com/llms-full.txt