Microsoft's AI Readiness Assessment asks organizations to evaluate seven areas: business strategy, AI governance and security, data foundations, AI strategy and experience, organization and culture, infrastructure for AI, and model management.
Scott Abel recently pointed out what is not named among those pillars: technical documentation.
That omission matters. An organization can have a model strategy, usable infrastructure, governance controls, and an ambitious adoption plan while the knowledge its AI systems depend on is obsolete, contradictory, poorly scoped, or impossible to trace back to an authoritative source.
But “documentation should be part of AI readiness” is still only the beginning of the argument.
If documentation belongs in an AI-readiness framework, what would we actually test?
AI Readiness Needs a Knowledge Layer
The useful question is not whether documentation exists. Most established organizations have plenty of it.
The useful question is whether the organization can reliably determine:
- which information is authoritative,
- who owns it,
- when it was last verified,
- which product, version, environment, and audience it applies to,
- whether a system can retrieve the right fragment without losing necessary context,
- where an answer came from,
- who is allowed to see it,
- what happens when sources disagree,
- how knowledge changes when the product changes, and
- whether important answers can be tested after those changes.
That is a knowledge-readiness problem.
A polished documentation portal can fail it. A modest documentation set with clear ownership, structure, versioning, and lifecycle rules can perform surprisingly well.
So rather than inventing a decorative “eighth pillar,” I would assess the documentation layer directly.
A Ten-Part Documentation Readiness Test
Use red, yellow, and green rather than pretending there is a magical universal score.
Green means the capability is explicit, maintained, and supported by the system. Yellow means people generally know how it works, but the answer depends on convention or individual memory. Red means the organization cannot answer reliably.
| Dimension | What “ready” looks like | Warning signs |
|---|---|---|
| 1. Authority | The organization can identify the canonical source for a procedure, policy, product fact, or configuration. | Several plausible pages exist and people resolve the conflict by asking whoever has been around longest. |
| 2. Ownership | Important content has a responsible owner or owning team with authority to correct it. | Everyone can edit the page, but nobody is accountable for whether it is right. |
| 3. Freshness and lifecycle | Content has review, retirement, and replacement rules appropriate to the risk of being wrong. | Old content remains searchable indefinitely because deleting anything feels dangerous. |
| 4. Scope | Product, version, environment, audience, geography, and other applicability boundaries are explicit where they matter. | The reader has to infer whether instructions apply to version 3.2, 4.0, cloud, on-premises, administrators, or customers. |
| 5. Structure and retrievability | Knowledge can be retrieved at a useful level without stripping away prerequisites, warnings, conditions, or related context. | The only source is a large document whose sections were written for linear reading rather than reliable reuse. |
| 6. Provenance | Answers can point back to the source material and the organization can inspect how a conclusion was produced. | An answer sounds plausible, but nobody can determine which source supplied the claim. |
| 7. Access boundaries | Retrieval respects audience, permission, confidentiality, and regulatory boundaries. | The AI can technically retrieve content that the person asking the question should never receive. |
| 8. Contradiction handling | The organization has rules for detecting and resolving conflicting sources rather than silently treating them as equally valid. | Two departments publish different answers and the system is expected to “figure it out.” |
| 9. Change synchronization | Product, policy, process, and configuration changes have a defined path into the knowledge system. | Documentation updates depend on somebody remembering to tell the writer after release. |
| 10. Testability | Important questions and workflows can be regression-tested after content, retrieval, model, or product changes. | The organization discovers that an answer became wrong when a customer reports it. |
The Important Part Is the Yellow
Red is easy to understand. Something is missing.
Yellow is more interesting because it describes a large amount of real organizational knowledge.
A support lead knows which article is current. An engineer knows that one configuration step changed two releases ago. A technical writer knows which internal page outranks the public one. A product manager remembers why an exception exists. A security administrator knows which procedure is technically accurate but no longer approved.
The organization can function because people carry the relationships among those facts in their heads.
That arrangement is fragile even before AI enters the picture. AI simply makes the dependency more visible because the system cannot reliably use distinctions that were never represented in the content, metadata, workflow, or governance model.
The goal is not to remove human judgment. It is to stop requiring human rescue for distinctions the knowledge system should already know how to represent.
A Successful Retrieval Is Not Necessarily a Successful Answer
This distinction matters when organizations evaluate retrieval-augmented generation systems, copilots, support assistants, internal search, and other AI-powered knowledge tools.
A retrieval system can successfully find a page that contains the right keywords and still return the wrong knowledge.
The source might be obsolete. It might describe the wrong version. It might be internal guidance presented as customer policy. It might omit the prerequisite that makes the procedure safe. It might contradict another source that the model also retrieved.
That is why documentation readiness cannot be reduced to “we indexed the knowledge base.”
The knowledge base has to carry enough information about itself for both people and systems to make useful decisions about what should be trusted, combined, excluded, or escalated.
Documentation Readiness Is Governance Work
This is not a technical-writer-only checklist.
Writers can identify gaps in structure, terminology, reuse, source authority, and lifecycle. But ownership usually crosses product, engineering, support, security, legal, operations, and leadership. Access boundaries may belong to security. Release synchronization may belong to engineering and product operations. Canonical-source rules may require several teams to stop publishing competing versions of the same truth.
That is exactly why documentation belongs in AI-readiness conversations.
The AI system is being asked to operate across organizational boundaries that people have historically patched together through conversation, memory, and escalation. If those boundaries matter to the answer, the knowledge system needs to represent them deliberately.
Start Before the Model Rollout
An organization does not need to perfect all ten dimensions before experimenting with AI.
It does need to know where the red and yellow areas are.
That changes the questions teams ask during implementation. Instead of only asking which model to use or how many documents to index, they can ask:
- Which sources are safe to treat as authoritative?
- Which content needs version or audience metadata first?
- Which knowledge domains contain unresolved contradictions?
- Which answers carry enough risk that provenance and regression testing are required?
- Which content cannot be exposed to every user who can access the assistant?
- Which product changes need to trigger documentation and AI-answer tests together?
Those questions turn “AI readiness” into something operational.
Scott Abel is right to point out that technical documentation is missing from the named pillars of Microsoft's assessment. The next useful step is to define what readiness in that layer actually looks like.
Because an organization is not AI-ready merely when it can give a model access to its information.
It is AI-ready when it can govern the knowledge that the model is expected to use.
Could your organization answer these ten questions without relying on one particular person to explain what is really current?