Part 1 argued that documentation is AI's source material. This post defines what "AI-ready" actually means — and what it doesn't.

"AI-ready" isn't a new discipline. It's a subset of principles technical writers have used for years — Diátaxis, DITA, Every Page Is Page One, information mapping — held to a stricter standard, because retrieval doesn't forgive the inconsistencies human readers absorb without noticing. When retrieval breaks, it almost always traces back to one of five structural issues:

Information architecture
Content models
Metadata
Content-type separation
Maintenance discipline

1. Information architecture#

A human searching for how to configure a webhook recognizes adjacent content and skips it. Retrieval doesn't. It returns the chunks that match, and the model incorporates all of them.

When a single page covers installation, configuration, and troubleshooting, a question about configuration retrieves all three contexts. The answer is often technically accurate but practically wrong — correctly citing material the user didn't ask about.

One page, one purpose. Get this right, and everything downstream becomes tractable.

Rule: Each document has a single purpose.

2. Content models#

A content model defines the shape of a document type. Task guides need goal, prerequisites, steps, verification, and common errors. API references need endpoint, parameters, response, and error codes. The two are not interchangeable.

When every page of a given type follows the same model, retrieval can reliably locate structural elements — prerequisites in the same place, errors in the same place, verification in the same place. Without that uniformity, the system encounters the same logical content in different positions across pages and has to guess what each structure implies. The guesses become noise.

Content models have a useful authoring side effect: a page that doesn't fit the model is visibly wrong, which forces the question to surface before the inconsistency hardens into precedent.

Rule: Two pages of the same type share the same structure.

3. Metadata#

A deprecated page and a current page look identical if the difference is policy, not prose. The steps are logical, the screenshots plausible, the tone confident. Nothing in the text tells retrieval that the page describes a process that changed eight months ago.

Metadata makes that signal explicit:

Status — current, deprecated, experimental
Version — introduced, last verified
Applies to — plan, region, or product edition
Owner — the person responsible for keeping it current
Next review — when it gets revisited

Coverage beats complexity. A status field on every page is worth more than a sophisticated schema applied to 40% of pages. And unmaintained metadata is worse than missing metadata: a version field that lies about currency is a confident signal pointing the wrong direction.

Rule: High-coverage metadata beats complex taxonomies. Unmaintained metadata is misinformation.

4. Content-type separation#

Three content types do different jobs:

Conceptual — how something works
Procedural — how to do something
Reference — what something is

Diátaxis names these explicitly; DITA enforces the separation at the schema level. Both exist because mixing types confuses both readers and retrieval.

Embed a conceptual explanation inside a tutorial and retrieval may return it as instruction. Append a reference table to a task guide and the table becomes part of the task's context rather than standing on its own. The facts are right; the frame is wrong.

This failure mode is gradual. Early pages are categorized carefully. Later pages, written under deadline pressure, blur the types. Retrieval reflects the blur directly.

Rule: Keep task guides procedural. Link out to concepts and references.

5. Maintenance discipline#

Every structural property above degrades without stewardship. Features ship, behaviors change, edge cases appear, and pages that were AI-ready at launch drift into being confidently wrong.

A well-structured but outdated page is worse than a messy one. It's easier for retrieval to find, which means it's easier for the model to be wrong with conviction.

Maintenance needs to be built in:

Review intervals matched to page type (API references reviewed at release; concept pages quarterly)
Ownership assigned per page, not per team
Retirement workflow for content that no longer reflects the product
Change triggers that flag docs when the code they document changes

Rule: Review is non-optional. Ownership, intervals, and retirement rules are written down.

A fast diagnostic#

If AI output quality varies across topics, the shape of the inconsistency usually points to the cause:

Symptom	Likely cause
Correct facts, wrong procedure	Mixed content types or unclear page scope
Works on some features, breaks on others	Inconsistent content models
Confident but outdated answers	Missing or unmaintained metadata
"It depends" without using user context	Missing applicability metadata

The five work as a system#

None of these properties works in isolation. Strong IA without metadata can't signal that a well-scoped page is stale. Thorough metadata without content models produces inconsistent coverage. Separated content types without maintenance discipline become unreliable within a release cycle.

Retrieval depends on all five simultaneously. Teams that treat AI readiness as a systems problem — not a content-quality problem — get consistent results. Teams that don't, don't.

Part 3: who keeps all of this working over time.