Using this documentation

A short guide to getting more out of this knowledge base: how it is organized, how to find things, and how to read the signals on a page.

If your question is "how is this written and how much should I trust it?", that is answered on About this documentation. This page is the practical companion.

How the site is organized

The knowledge base is a collection of sections, each covering one subject area — a product, a capability, or an area of engineering practice.

Sections are not chapters in a book, and they are not the same size. Each one is written and maintained by the team that owns the thing it describes, and each is published independently. A practical consequence: sections appear as their content is written, and a section you read last quarter may have grown since. Nothing is held back waiting for the rest to be finished.

Every section opens with an index page listing what is inside it and, where useful, suggesting a reading order. If you are new to a subject, start there rather than in search results — the index is where context lives.

Finding something

Search is the fastest route for anything you can name. It covers the full text of every page, not just titles, and it runs entirely in your browser — nothing you type is sent anywhere. Press / or s to jump straight to it.

Two habits make it work much better:

• Search for the phrase you expect to see on the page, not for a description of your problem. license expired will find more than what do I do when it stops working.
• Check the section a result belongs to before acting on it. The same term can mean different things in different products, and the result list shows you where each hit came from.

The left sidebar is the map. It shows every section, expands to the page you are on, and is worth a scan when you want to know what exists rather than find one fact.

The right-hand table of contents lists the headings on the current page. On long reference pages this is usually faster than scrolling.

Every heading is linkable. Hover a heading and a ¶ appears — that is a permanent anchor to that exact spot, which is what you want when sending someone a specific step rather than a whole page.

Reading a page

The icon tells you what kind of page it is

Every page declares what kind of document it is, and the icon beside it in the sidebar is derived from that. It is a small thing that saves a lot of time: you can tell how a page is meant to be read before you open it.

Icon	Kind	What to expect
	Concept	Explains what something is and why it matters. Read it when the vocabulary or the model is unfamiliar.
	Guide	Walks through accomplishing one task. Read the whole thing before starting; skip to the step you need on a return visit.
	Tutorial	Teaches by doing, and is meant to be followed start to finish. Skipping ahead usually does not work.
	Reference	Looked up, not read through. Complete rather than narrative.
	Runbook	An operational procedure with steps and checks. Follow it in order; the checks exist because something can go wrong at that point.
	FAQ	Answers to questions that come up repeatedly.
	Release notes	What changed in a specific release.
	Policy	A commitment — support terms, lifecycle, end-of-life. These are statements of what we will do.
	Section	A section index.

The distinction between a guide and a policy is the one worth internalizing. A guide tells you how something is done today; a policy tells you what we have committed to. If the two ever appear to conflict, the policy page is the one to raise with us.

The date tells you when the content changed

Each page shows a last update date at the foot. It is the date that page's content last changed — taken from the version history of the file itself — not the date the site was rebuilt. A page that has not changed in a year shows a date from a year ago, and that is honest rather than neglectful: some material is simply stable.

What the date does not tell you is whether the page has been reviewed recently against the system it describes. If accuracy is critical to a decision you are making, ask — that is faster than inferring.

Planned is always labeled as planned

Where something is planned rather than available, the page says so in the text. We do not document unreleased capability as though it exists. If a page describes something in the present tense, it is available now.

Commands and code

Code blocks have a copy button in the top-right corner. Where a command contains a value you must supply, it appears in angle brackets — <your-account-id> — and the surrounding text says where to get it. Anything in angle brackets is a placeholder, never a literal.

What is not here

• Internal engineering material. Standards, runbooks, and platform design records that do not affect what we deliver stay private. Where a practice does affect what you receive — release evidence, support commitments, version compatibility — it belongs on this site.
• Your contract. Support scope, terms, and entitlements are defined there and take precedence over anything written here.
• Version-specific documentation. Every reader currently sees the current documentation. Where behavior differs between versions, the page says so explicitly.

Reading comfort

The header carries a light/dark toggle, and controls to collapse the sidebar and the table of contents when you want the full width for a wide table or a long code block. Your choice is remembered on this device.

Something wrong, missing, or confusing?

All three are worth telling us about, and the third is the most useful. A page that is technically correct but sends readers down the wrong path is a real defect, and it is invisible to us from the inside.

If you followed a link here from somewhere else and landed on the wrong page, mention where the link was — external links going stale is exactly the sort of thing we want to catch.

Tell us about a page →

Every submission reaches a tracked queue and is read by a person.