How to Assess and Improve Content Completeness for AI

An AI assistant confidently tells a customer your return window is 30 days. It is actually 14. The model was not hallucinating in the abstract; it stitched together a plausible answer because the authoritative content, the current policy, structured and unambiguous, was not there to retrieve. This is the failure mode that content completeness exists to prevent, and it is quietly the biggest lever most teams have over AI output quality. Retrieval-augmented and agentic systems can only be as good as the content they can find, parse, and trust.

Sanity is the Content Operating System for the AI era, an intelligent backend that treats content as structured, queryable, governed data rather than a wall of rendered HTML an LLM has to guess its way through. That distinction is where completeness lives. Completeness is not "do we have a page about this," it is "does the answer exist in a shape a machine can retrieve with confidence, cite, and keep current."

This guide reframes completeness as an engineering property you can measure, not a vibe. We will cover how to audit coverage against real questions, how structure changes what "complete" means, how to close gaps without drowning your team, and how a structured content backend makes the whole loop observable.

Why AI exposes the gaps your website always had

Every content estate has holes. For years they stayed invisible because a human visitor would land on a page, not find the answer, and quietly bounce or open a support ticket. The gap was real, but it was diffuse and unmeasured. AI removes that cushion. A retrieval system asked a question it cannot answer well does not bounce; it produces a confident, wrong, or half-right response that a customer acts on. The cost of an incomplete content estate moves from a soft conversion loss to a hard trust liability.

The deeper problem is that most content was authored for reading, not for retrieval. A returns policy buried three paragraphs into a general "customer support" page, with the actual window expressed as prose inside a sentence, is technically present and functionally invisible. A chunked retriever might grab the surrounding paragraph and miss the number. An answer engine might weight a stale blog post above the canonical policy because the blog post happens to phrase the question the way the user did.

Completeness for AI therefore has three failure axes, not one. Coverage: does the answer exist at all. Granularity: does it exist as a discrete, retrievable unit rather than embedded in unrelated prose. Freshness: is the retrievable version the current one, or has an old copy outlived its replacement. A page-centric CMS can pass a human eyeball test on all three and still fail every one at machine scale, because the human reads the whole page and reconciles contradictions the retriever never sees. Naming these axes is the first move, because it turns "our AI gives bad answers" into a set of measurable, fixable conditions rather than a general anxiety about model quality.

Start from the questions, not the content inventory

The instinct when assessing completeness is to inventory what you have: count the pages, tag them, build a spreadsheet of topics. This is backwards. An inventory tells you what exists; it cannot tell you what is missing, and missing is the entire point. The only reliable map of completeness is the set of questions your users and agents actually ask, scored against whether an authoritative answer can be retrieved for each.

Build that question set from real signal. Support-ticket subject lines, site-search queries that returned nothing, chat logs from your existing assistant, and sales objection trackers are all gap detectors that already exist in your organization. Cluster them into intents. For each intent, run the retrieval your production system actually uses and grade the result: is there a canonical source, is it the top hit, does it contain the specific fact, and is that fact current. A question that returns a plausible-but-assembled answer with no single authoritative source is a completeness gap even though nothing looks broken.

This is where a query-first backend earns its place. In Sanity, GROQ lets you interrogate the Content Lake directly for structural coverage: which product types have no `faq` references, which policies lack an `effectiveDate`, which localized documents are missing a translation for a market you serve. You are not eyeballing a sitemap; you are asking the store, in one round trip, to return exactly the shape of the gap. Pair that structural query with the intent list and you get a completeness matrix: the questions on one axis, the retrievable, current, discrete answers on the other, and the empty cells are your backlog, ranked by how often the question is actually asked.

Structure is what makes an answer retrievable, not just present

A fact rendered as a sentence inside a paragraph is present. The same fact expressed as a typed field is retrievable, comparable, and safe to cite. That gap is the difference between content an AI can use and content it has to reverse-engineer. "Free shipping over $50" living in marketing prose is one hallucination away from becoming "$40" in an answer; the same threshold stored as a numeric field with a currency and a region is a value a system reads, not interprets.

This is why completeness and structure are the same conversation. Portable Text keeps rich content as structured data with named blocks, marks, and annotations rather than a blob of HTML, which means a retriever can target the definition block, the code sample, or the annotated caveat as discrete units instead of grabbing an arbitrary character window. Reference fields let you model the relationships that answers actually depend on: a product references its warranty, its returns policy, and its compatible accessories, so a question about any one of them resolves through a graph rather than through keyword proximity on a page.

There is a counter-intuitive consequence here. Adding more prose can lower completeness. A long, hedge-filled paragraph that restates a policy three slightly different ways gives a retriever three candidate chunks that disagree, and the model may surface the weakest. A single typed field with one authoritative value gives it nothing to get wrong. Completeness is not maximized by volume; it is maximized by making each answerable question resolve to exactly one canonical, machine-readable unit. Structuring content is therefore not a nice-to-have that follows authoring; it is the mechanism by which "we wrote about it" becomes "a machine can answer it correctly."

Turn completeness into a metric your team can watch

An assessment you run once is an audit; an assessment that runs continuously is a system. Completeness degrades constantly because the world changes: policies update, products launch, promotions expire, markets get added, and every one of those events opens a new gap or staleness fault the moment it happens. Treating completeness as a project you finish guarantees you are measuring a snapshot that is already wrong.

Define a small number of completeness signals you can compute on demand and trend over time. Coverage rate: the share of your ranked intents that resolve to a canonical source. Structural completeness: the share of documents of a type that have their required answerable fields populated, for example every product having a non-empty `returnPolicy` reference and `warrantyMonths`. Freshness: the share of policy and pricing documents whose `effectiveDate` is within an acceptable window. Orphan rate: content that exists but nothing references, which is often stale or duplicate and a prime source of contradictory retrieval.

A structured backend makes these cheap to compute rather than aspirational. Sanity Functions can run on publish to validate that a document meets its completeness contract before it goes live, and to flag when a referenced policy has aged past its window. The Live Content API means a completeness dashboard reflects the real current state rather than a nightly export. Because the checks are queries against the same Content Lake the retriever reads, the metric measures the actual retrieval surface, not a proxy. The point is not the dashboard for its own sake; it is that "is our content complete for AI" stops being a quarterly opinion and becomes a number a content engineer can watch decline the day a market launches without its localized policy, and fix before an assistant starts guessing.

Close gaps without drowning your authors

Once you can see the gaps, the temptation is to assign all of them to humans and burn out the team. At enterprise scale the gap list is longer than any content team can hand-write, and much of it is not net-new thinking, it is transformation: an answer that exists in prose but needs to become a field, a policy that exists in English but needs six locales, a definition that exists once but needs to be attached to forty products that reference it. Treating every gap as original authoring is how completeness programs stall.

Split the backlog by what kind of work each gap actually is. Genuinely missing answers, where no authoritative source exists, need a human subject-matter owner and cannot be automated away; those are where scarce expert attention should go. Structural gaps, where the answer exists but in the wrong shape, are transformation work. Localization and enrichment gaps, where the answer exists in one place and needs to propagate, are propagation work. The last two categories are where automation belongs, and where the leverage is enormous.

This is the pillar where Sanity's approach compounds: legacy content systems force you to scale people to scale output, while a structured backend lets you scale output instead. The App SDK and Functions let you build in-Studio automation that drafts a first-pass structured field from existing prose, requests a translation, or flags a document that references an expired policy, always landing the result as a draft an editor reviews inside Content Releases rather than publishing unattended. Human judgment stays on the decisions that need it; the mechanical propagation of a known answer across the estate stops being a person's afternoon. Completeness becomes something a small team can actually keep ahead of, because the growing surface is met with automated transformation rather than linear headcount.