Two analysts ask an AI assistant the same question: "What emission factor should we use for purchased electricity in Spain, and what is our company policy on market-based instruments?" The first analyst is using a plain chatbot connected to the open web. It returns a fluent answer with a factor, a confident sentence about market-based reporting, and a citation to a blog post and a vendor page. The second analyst is using a system that has been grounded on the company's own evidence base: the licensed emission-factor database, the internal energy-procurement records, and the company's own GHG accounting policy. It returns a factor with the database release and row, the company's actual policy language quoted verbatim with its document reference, and a note that the procurement file confirms market-based instruments for two of the three Spanish sites. The first answer is unassurable the moment it is produced. The second is the start of an audit trail. The difference is not the model. It is what the model was allowed to answer from.

The Problem Grounding Solves

A language model, left to its own devices, answers from its training: a vast, undated, unsourced compression of text from across the internet. For most uses that is fine. For disclosure it is fatal, because the iron rule is that every figure you publish must trace to evidence, and a training-derived answer traces to nothing you can point an assurer to. When the model recalls an emission factor from training, it cannot tell you which database, which release, which year, because it never knew; it absorbed a number-shaped pattern and reproduces it. When it states your policy, it is guessing what a policy like yours probably says, not reading yours. The fluency hides the absence of a source, and in a regulated disclosure an answer with no source is not a fast answer, it is a liability waiting for the assurer to ask where it came from.

Connecting the model to the open web does not fix this; it changes the failure mode without removing it. Now the model can cite, but it cites whatever it found: a blog, a vendor's marketing page, an outdated regulatory summary, a forum post. None of those is your evidence base. None is the licensed factor database your inventory is built on, the procurement records that are your activity data, or the board-approved policy that governs your method choices. An answer grounded on the open web is grounded on someone else's documents of unknown authority, which in a disclosure context is barely better than no grounding at all, because the assurer does not care what the internet says about electricity factors in Spain. The assurer cares what your factor database says, what your records show, and what your policy commits you to. The open web cannot answer those questions because it does not contain them.

Grounding is the technique that closes this gap. It points the model at a defined, controlled body of your own evidence and constrains it to answer from that body, so that every answer comes with a pointer back into the evidence base rather than out into the undated fog of training or the unauthored sprawl of the web.

What Grounding and RAG Mean in Disclosure Terms

Grounding means constraining a model to answer from a specific, controlled body of evidence rather than from its general training or the open web. The technical pattern that makes grounding work is called retrieval-augmented generation, or RAG, and despite the jargon the idea is simple and maps directly onto how a good analyst already works.

When you, the analyst, get the electricity-factor question, you do not answer from memory. You go to the factor database, find the right row, open the procurement file, check the policy document, and then write an answer that quotes what you found. RAG is that workflow done by the system. Retrieval is the step where, before the model writes anything, the system searches a defined collection of your documents for the passages relevant to the question, the factor database row, the procurement record, the policy paragraph, and pulls them in. Augmented generation is the step where the model writes its answer using those retrieved passages as its source material, ideally quoting and citing them, rather than reaching into its training. The model is no longer recalling; it is reading your evidence and reporting what it says.

The collection the system retrieves from has a name worth knowing: the knowledge base. It is the curated, controlled set of documents you have decided the model is allowed to answer from. For a reporting workflow, the knowledge base is your evidence base made machine-searchable: the licensed emission-factor database, the source files (utility bills, fuel logs, supplier responses, procurement records), and the policy and methodology documents (your GHG accounting policy, your basis-of-preparation, the relevant framework guidance). What is in the knowledge base is what the model can ground on. What is out of it, the open web, the model's training, is what the model must not answer from. Curating that boundary is the heart of the discipline.

It helps to be concrete about how retrieval finds the right passage, because the mechanism explains both the power and the limits. The system does not read every document end to end on each question; it indexes the knowledge base so that, given a question, it can quickly surface the passages most relevant to it. When the analyst asks about Spanish electricity, retrieval pulls the grid-factor row for Spain, the procurement entries for the Spanish sites, and the policy paragraph on market-based treatment, and hands those passages to the model as the material to answer from. Two things follow. First, the answer is only as good as what the index can find: if the right factor row is in the database but the geography is mislabeled, or the policy is a scanned image the index cannot read, retrieval may miss it and the model may then have nothing relevant to ground on. Second, retrieval is the step where the evidence boundary is actually enforced, because the model can only generate from what was retrieved, and nothing outside the knowledge base is ever retrieved. The quality of retrieval, then, is not a technical afterthought; it is the difference between a grounded answer and a confident silence dressed up as an answer.

An open-web answer is grounded on someone else's documents of unknown authority. A grounded answer is built from your evidence base, with a pointer back to the exact row, file, or policy paragraph. The first is unassurable the moment it is produced. The second is the start of an audit trail.

Why Open-Web Answers Are Unassurable

It is worth being precise about why an open-web or training-based answer cannot survive assurance, because the reason is structural, not a matter of the answer happening to be wrong. Assurance is the test of whether a disclosed figure traces to evidence the company controls and can stand behind. An open-web answer fails that test on three counts, every time, regardless of its accuracy.

First, the source is not yours. Even if the model cites a real page, that page is not your factor database, not your records, not your policy. You cannot stand behind a number because a third-party website said so; the obligation is yours and does not transfer to whatever the model happened to retrieve. Second, the source is uncontrolled. A web page can change or vanish, it carries no version or release you can pin, and you have no governance over its accuracy. Your factor database has a named release and a documented methodology; a blog has neither. Third, the source is unauthoritative for your specific facts. The internet cannot tell the assurer which sites you operate, which instruments you procured, or what your board approved, because those facts live only in your evidence base. An answer about your company that is not built from your company's documents is, by definition, a guess about you.

This is why "the AI said so, and it cited a source" is not the reassurance it sounds like. A citation to the wrong kind of source is not provenance; it is the costume of provenance. Provenance in disclosure means a pointer to your controlled evidence, the database release and row, the document and page, the policy section, that an assurer can open and confirm. Grounding on the knowledge base produces exactly that. Grounding on the open web produces a citation that collapses the moment the assurer asks whether that source is one you control and can stand behind.

Building a Grounded Reporting Workflow

Putting grounding to work is less about the model and more about the evidence base you build around it. The discipline has a few load-bearing parts.

Curate the knowledge base deliberately

The knowledge base is a controlled artifact, not a dumping ground. Decide what belongs: the licensed, current factor database; the source files that are your activity data; the policy and methodology documents that govern your choices. Keep it current and versioned (the same version discipline that protects your figures protects the evidence the model answers from), and keep out anything you would not want a number to trace to. A knowledge base full of drafts, superseded factors, and stray PDFs grounds the model on garbage, and a confident answer from a polluted evidence base is more dangerous than no answer, because it wears the badge of provenance while pointing at the wrong document.

Constrain the model to the base, and to citing it

Grounding only helps if the model is actually held to the knowledge base. The system prompt and configuration must require the model to answer from the retrieved passages, to cite the specific source for each claim, and, crucially, to refuse rather than improvise when the knowledge base does not contain the answer. The most valuable behavior a grounded reporting system can have is to say "the knowledge base does not contain a factor for this activity in this geography" instead of inventing one. A model that refuses when the evidence is absent is doing exactly what a good analyst does when a factor is missing: flagging the gap rather than papering over it.

Verify the pointer, not just the answer

Grounding makes verification faster, but it does not remove it. The human still confirms that the retrieved passage actually says what the model claims it says, that the cited factor row is the right one, that the policy quote is current and not superseded. Grounding turns verification from "is this number plausible" into "does the cited source confirm this," which is the verification an assurer respects, but a human must still cross that boundary and log the handoff. Grounding feeds the verification; it does not replace it.

A Worked Example: Two Answers to the Same Question

Return to the two analysts and follow each answer to the assurance engagement.

The open-web answer

The first analyst's chatbot returns: "For purchased electricity in Spain, a typical emission factor is around 0.19 kg CO2e per kWh. Companies generally use market-based reporting where they have purchased renewable instruments. [Source: an energy blog; a vendor explainer page.]" It reads well, and the analyst, under deadline, books it. At the engagement, the assurer asks three questions. Which database and release is 0.19 from? The analyst does not know; the model cited a blog. Does your policy actually require market-based treatment for these sites? The model asserted a general practice, not the company's policy; nobody checked the policy document. Which Spanish sites had instruments? The model did not know, because that fact lives in the procurement file it never saw. Every answer is a gap. The figure does not survive, and worse, the assurer now distrusts the process that produced it.

The grounded answer

The second analyst's grounded system returns: "Emission factor for Spain grid electricity: 0.XX kg CO2e per kWh, from [named factor database], release 2026.1, reference year 2024, unit kg CO2e per kWh, geography Spain (retrieved from the factor-database knowledge base). Company policy: per the GHG Accounting Policy, section 4.2 (quoted), market-based reporting applies where renewable energy instruments are held and retired. Procurement records (file reference) confirm instruments held for two of the three Spanish sites; the third uses location-based treatment. Note: the knowledge base does not contain a retirement certificate for one instrument; flagged for follow-up." The analyst verifies each pointer against the cited source, confirms the policy section is current, chases the missing certificate, and logs the handoff. At the engagement, every one of the assurer's three questions is already answered, with the database release, the policy section, and the procurement file all cited and confirmable. The flagged gap is not a weakness; it shows the system surfaced an absence instead of inventing around it. Same question, same model, and the only difference is that the second answer was built from the company's own evidence and the first was built from the internet's.

The lesson is the one that runs through the whole level. Speed without grounding is speed toward a misstatement. Grounding is what lets you keep the speed of asking a question in plain language and get back an answer that is already on its way to being assurable, because it was built from your evidence base, points back into it, and refuses to guess when the evidence is not there.

Where Grounding Fits With the Other Controls

Grounding does not stand alone; it is one control among the four that this chapter builds, and it is most powerful when you see how it interlocks with the others. The reporting-cycle map tells you which stages are AI-assisted-with-verification, and those are precisely the stages where a grounded answer belongs, because grounding supplies a sourced candidate exactly where a human verification gate already waits to confirm it. The handoff log is where that verification gets recorded: a grounded answer arrives with a pointer, the human confirms the pointer against the controlled source, and the handoff row captures the decision. Versioning ensures that the knowledge base the model grounded on is itself dated and preserved, so a grounded answer remains reconstructable even after a factor file or a policy is updated. Grounding feeds the system its evidence; the map says where to use it; the handoff log proves a human owned the result; versioning keeps the whole chain rebuildable. Pull any one out and the others weaken. Grounding without verification produces sourced-looking answers nobody confirmed; verification without grounding asks a human to check a number against nothing; versioning without grounding preserves the history of an answer that traced to the open web in the first place. The four are a system, and grounding is the part that decides what the model is even allowed to answer from.

This is also why grounding is a practitioner-level skill rather than a tool you switch on. The model and the retrieval machinery are the easy part; vendors will sell you both. The hard, judgment-laden, assurance-critical part is the work only a disclosure professional can do: deciding what belongs in the knowledge base and what must be kept out, keeping it current and versioned, writing the constraints that force the model to cite or refuse, and verifying that each cited pointer actually says what the model claims. None of that is a model capability. All of it is reporting discipline applied to an AI component, which is exactly the posture the whole program teaches. The graduate who can stand in front of an assurance partner and say "every material answer in this file was built from our controlled evidence base, here is the knowledge base, here are the citations, here is where the system refused and flagged a gap, and here is the human who verified each one" has turned a generative model from a liability into an accelerator that strengthens the audit trail instead of corroding it.

Key Takeaways

• A model left to its training answers from an undated, unsourced compression of the internet, which traces to nothing an assurer can check. Connecting it to the open web changes the failure mode without fixing it: it cites someone else's documents of unknown authority, not your evidence base.
• Grounding means constraining a model to answer from a specific, controlled body of your own evidence rather than from general training or the open web, so every answer points back into that evidence.
• Retrieval-augmented generation (RAG) is grounding done by the system: retrieval searches your documents for the relevant passages before the model writes, and augmented generation has the model answer from those passages rather than from training. It is the analyst's own go-to-the-source workflow, automated.
• The knowledge base is the curated, controlled set of documents the model is allowed to answer from: the licensed factor database, the source files that are your activity data, and the policy and methodology documents. What is in it is what the model can ground on; what is out is what it must not answer from.
• Open-web answers are unassurable for structural reasons, not just accuracy: the source is not yours, it is uncontrolled and unversioned, and it is unauthoritative for your specific facts, which live only in your evidence base.
• A citation to the wrong kind of source is the costume of provenance, not provenance. Real provenance is a pointer to your controlled evidence: the database release and row, the document and page, the policy section, that the assurer can open and confirm.
• The most valuable behavior of a grounded reporting system is to refuse and flag the gap when the knowledge base lacks the answer, exactly as a good analyst flags a missing factor instead of inventing one.
• Grounding makes verification faster but does not replace it: a human still confirms the cited source says what the model claims, then logs the handoff. Grounding feeds the audit trail; it does not become one on its own.