AI knowledge
AI knowledge and retrieval readiness depend on whether the system can find the right source, respect access, explain its context, and expose uncertainty.
State what users need to ask, which knowledge domains are in scope, what sources are authoritative, and what the system must decline. A bounded question makes evaluation possible.
The AI and machine-learning services route provides an internal path when retrieval readiness needs technical review.
Name the source owner, update responsibility, access rule, review condition, retention boundary, and escalation route. Retrieval should not expose information simply because it is technically discoverable.
Use clear titles, scope, dates, owners, definitions, relationships, and content boundaries. Separate instructions, exceptions, and obsolete material.
Define representative questions, expected source evidence, reviewer, acceptance condition, unsafe answer response, and unresolved ambiguity. Test missing, conflicting, restricted, and stale information.
Review unanswered questions, challenged answers, stale sources, access exceptions, and repeated ambiguity. Feed findings to the source and service owners.
A large document library is not necessarily ready. Size does not prove authority, freshness, structure, access clarity, or evaluation readiness.
Pointing an assistant at an existing knowledge base is a common early AI decision in service operations, and it is often made on the strength of how much content already exists. The more useful question is what the assistant will do with an article that is out of date, contradicts another article or was written for a different region. A retrieval system will find that article as readily as a good one and will present it with the same fluency. The knowledge manager is therefore deciding less about volume than about the consequence of each defect the assistant will meet in production.
The decision is easiest to make by listing the people who will ask the assistant questions and the answers they will act on. A question about how to reset a password for a service desk audience carries a different risk from a question about eligibility for a benefit or the handling of a disputed charge. Where the answer is acted on without a second check, the source must be trustworthy for that answer specifically, and the knowledge base as a whole cannot be treated as the unit of readiness.
Human readers forgive a great deal. They notice that an article is old, skip the paragraph that does not apply and phone a colleague when something looks wrong. A retrieval system does none of that. It matches the question against the text, selects the closest passage and composes an answer from it. The defects that matter for retrieval are therefore the ones that change which passage is selected or how it reads once lifted out of its page.
| Defect | What the assistant does with it | Readiness response |
|---|---|---|
| Two articles give different answers to the same question | May select either one, or blend them into a sentence that is wrong for both | Name one authoritative article and retire or link the other |
| An exception is buried in a paragraph about the general rule | Quotes the general rule and omits the exception | Move exceptions into their own labeled section with the conditions stated |
| Article has no owner or review condition | Gives no signal that the content may have changed | Assign an owner and a review trigger before the article is indexed |
| Screenshots or steps refer to a superseded interface | Describes steps that no longer exist | Retire the article or rewrite it against the current interface |
| Restricted procedure sits in a public article | Shares it with anyone who asks the right question | Move it behind the appropriate access rule, or remove it from the indexed source |
The fixes in the right-hand column are mostly editorial and structural. They do not require new technology, and they usually improve the knowledge base for human readers as well. That is a useful argument to make internally, because it means the readiness work is not wasted if the assistant project stalls.
Retrieval readiness depends on being able to say what a correct answer looks like and where it should come from. Before any assistant is configured, the team should write a set of representative questions, record the source article or passage that a correct answer must draw on, and record what the assistant should do when the source is missing. Writing the expected source is a step many teams skip, and without it no one can tell later whether a plausible-sounding answer was actually supported.
The question set should include the awkward cases: questions that span two topics, questions that use the wrong term for the process, questions whose answer depends on the requester's location or role, and questions about things the knowledge base deliberately does not cover. The last group is often the most revealing. An assistant that answers confidently about topics outside its scope is a governance problem regardless of how accurate its answers are on the topics it does cover.
A knowledge base that was safe to browse may not be safe to search through an assistant. Browsing requires a person to find a page, and many organizations have relied on that friction without naming it. An assistant removes the friction. Anything in the index can become answerable to any user who can reach the assistant unless retrieval enforces access, including content meant for a narrower group. The readiness check should therefore compare the access rules on each source with the access rules on the assistant, and confirm that retrieval respects the requester's role rather than the crawler's. The access, privacy and segregation of duties page covers reviewing effective access and the boundaries around sensitive information, which is the same review these rules need.
Retention needs the same attention. A cached answer that quotes a source after the source has been withdrawn continues to circulate. Decide how long retrieved passages may be stored and how a withdrawal reaches the index.
Retrieval readiness is not a state that the knowledge base reaches and keeps. Sources change, products are retired, policies are reissued and users find new ways of phrasing their questions. A knowledge loop captures the signals that show where the content is failing. Those signals include questions that receive no answer, answers that users challenge, sources that are cited but found to be stale, and repeated questions that point to a gap no article covers. Each signal needs an owner, usually the author or the service owner of the affected source, and a route for the fix to reach the index. Without that route the assistant appears to degrade over time, and the blame falls on the model rather than on the content it was given.
The loop also feeds the existing self-service work. A question that the assistant cannot answer is often a question that the public article library cannot answer either, so the same backlog can improve both. The knowledge and self-service optimization page covers connecting real questions to clear articles, ownership and feedback.
On ServiceNow an assistant can draw on the knowledge base and the service catalog, and it may reach the user through a virtual agent or a portal. The readiness questions are the same as on any other platform, but the platform offers two useful controls: knowledge article lifecycle states, which can keep drafts and retired articles out of the index, and role-based visibility, which can limit what a requester sees. Whether those controls are configured correctly is one of the first things a readiness review should check. The Now Assist and virtual agent self-service page covers defining the task a conversation should complete and where automation should stop.
Three misreadings often cause wasted effort. The first treats the size of the library as evidence of readiness. Size says nothing about whether the content is current, authoritative or accessible to the right people. The second assumes that a better model will compensate for weak content. A stronger model may produce smoother answers from the same contradictory sources, which can make the errors harder to spot. The third assumes that readiness is decided once. The right test is whether the knowledge is maintained in a way that keeps pace with the decisions it supports, which is an operating question rather than a technical one.
Answer this from the question set, not from the article list. The authoritative source is the one the expected answer cites, and it should be named explicitly so that conflicts can be resolved in its favor.
It should say that it does not have a supported answer and route the user to a person or to a defined next step. A fallback that generates a plausible answer is the failure mode to rule out at this stage.
Test it. Withdraw a test article, ask the question it answered and confirm that the assistant no longer quotes it, including in any cached answers the system keeps.
A named owner in the knowledge team, with a regular review slot. Unreviewed gaps accumulate quietly and become the next incident.
If a knowledge base is about to become the source for an assistant, a sample of the questions users ask, the articles that currently answer them and the access rules on each source make a good starting set. Start a conversation about your retrieval readiness.
Bring the knowledge source, access boundary, or evaluation question that needs a clear retrieval model.
Discuss AI retrievalGuides from the Oblytech ServiceNow library that explain the practice behind this page.