Introduction
Documentation that describes everything in the same confident voice is useless for planning, because it hides the difference between something you can build on and something that may change. These pages label maturity, and this page says what the labels mean.
The four labels
Label | Means | You can | You should not |
| Generally available. Supported, stable, documented | Build on it, depend on it, put it in a contract | — |
| Usable and supported, but still changing | Try it, pilot it, give feedback | Depend on its exact behaviour, or on it in a compliance commitment |
| Being built. Not available to you yet | Plan around it arriving, with your account team | Assume a date |
| Intended. Not started, not committed | Tell us it matters to you | Plan around it at all |
Why the KB labels at all
AI governance is bought and deployed under regulatory pressure, and that produces a specific failure: a team reads a documentation page, assumes the capability exists today, and writes it into a policy document, a customer commitment or an audit response. When the capability turns out to be partial, the cost is not a delayed feature — it is a statement already made to somebody who relied on it.
"The most expensive documentation error is not being wrong. It is being confident about something that is only nearly true."
Pages that are partly true
Some pages describe a capability that exists in part. Rather than badging the whole page optimistically or omitting it, those pages say in the body, at the top, in plain language which part exists and which does not.
Two current examples, so the convention is concrete rather than abstract:
Escalation & Notifications — escalation through assignment and status is GA. Automated notification does not exist, and the page says so before it says anything else.
Evidence & Export — the evidence record is GA. There is no export action, and the page tells you how to work without one.
These pages are deliberately not aspirational. If a future release adds the missing half, the page changes then.
Pages describing configured interfaces
A few surfaces — Cost Explorer and Monitoring — are configured interfaces rather than fixed screens. Their tiles, filters and groupings can change without a product release.
Those pages deliberately describe what the surface is for and how its numbers are produced rather than cataloguing every chart, and they say so. It is not vagueness; documenting a movable screen as fixed would produce instructions that look authoritative and are quietly wrong.
Open questions
Occasionally a page raises a question and declines to answer it — how a control behaves if its check times out, for instance, or which action wins when two controls match the same content.
These are cases where the answer is real but not established from the sources this documentation is written against. Guessing would be worse than the gap, because a plausible wrong answer gets designed around and never re-checked. Where you see one, and your design depends on it, the page tells you to ask your account team — and it will be updated when the answer lands.
What you can assume by default
An unlabelled page describes generally available behaviour. Labels appear where something is not GA, so the absence of a label is itself information.
What no label ever means is "this will not change". Products change; documentation follows. The labels tell you how much confidence to place in a page today, which is a different and more useful thing than a guarantee.