Back to course syllabus
Automate with permission, recovery, and cost controlsIf needed: implementation cases · 3 / 4

AI research synthesis: when the source changes after the brief

A research team used retrieval to draft a regulatory brief, then a source revision landed before the meeting and forced a claim-by-claim re-check.

DECISION TOPICField cases
LESSON OUTPUT · retrieval trialUPDATED · Oct 24, 2026
PATH READ0 / 4
HOW TO USE THIS LESSON

Read with one real task in mind, then complete the workbench. The lesson is done when another person can review what you made.

The brief was finished on Monday afternoon. It summarized five sources, quoted the relevant passages, and gave the leadership team a clear recommendation. At 6:40 on Monday evening, one of the sources published a revision. The recommendation was no longer wrong in every detail, but two of its claims had changed status.

The team did not ask the model to “review the brief again.” It re-ran the source register, marked the dependent claims, and rebuilt the answer from the current version. This case shows the drill that made that possible.

The brief was right on Monday

A research brief is a snapshot. It is correct only relative to a set of sources at a point in time. The snapshot has three parts:

  • the claims the reader will act on;
  • the passages that support each claim;
  • the source versions those passages came from.

Most AI research workflows preserve the first two and lose the third. The draft cites a document title, perhaps a link, but not the version or effective date. When the source changes, the team cannot tell which claims are affected.

The fix is not a better summarization prompt. It is a source register that travels with the brief.

Freeze the source register, not just the prompt

Before drafting, the team recorded one row per source:

FieldWhy it matters
Source ID and titleStable reference for the claim table
Version or revisionDistinguishes the current text from the one the model saw
Effective dateAnswers “when did this become true?”
Retrieved atShows how fresh the snapshot is
OwnerNames the person who can confirm the source
Access scopeShows who may read the passage and the brief
Change signalURL, feed, release note, or manual check that reveals a revision

The register does not need a complex system. A spreadsheet with a version column is enough to start. The important part is that the brief’s claims point to a row, not just to a title.

The team also separated source of truth from source of convenience. A vendor blog, a summary page, or a search snippet can help locate the official document. It cannot become the authority just because it is easier to retrieve.

Example: the guidance that changed overnight

The brief said: “Providers must notify affected users within 72 hours.”

The model cited the guidance document, section 4.2. The passage did support the sentence at the time of retrieval. On Monday evening, the regulator published a revision: the deadline remained 72 hours for one category, but a new category was added with a 30-day window and a different notification channel.

The model’s answer was not fabricated. It was version-locked. The retrieval index still contained the old chunk; the citation still pointed to a real passage; the claim was true for the old scope and false for the new one.

The team’s re-check had four steps:

  1. Compare the source register’s version with the current published version.
  2. Identify the claims whose supporting passage changed.
  3. Re-retrieve the current passage and re-run the claim check.
  4. Mark the brief’s status as “updated,” “unchanged,” or “cannot verify.”

The revised brief did not simply replace “72 hours” with “30 days.” It separated the two categories, cited the new section, and told the reader which cases still fell under the original rule. The distinction was the value; a single number would have been misleading.

Counterexample: two vendor documents that disagree

A second source set contained two vendor documents with different retention periods: one said 30 days, the other said 90 days. The model averaged them into “approximately 60 days.” That sentence had no source at all.

The team’s rule was: do not average disagreement. When two authorized sources conflict, the brief must show both, name the scope of each, and route the decision to an owner. A synthesis that hides the conflict is not a synthesis; it is a guess with a citation-shaped surface.

The revised passage looked like this:

  • Vendor A’s current security addendum says 30 days for the standard plan.
  • Vendor B’s current data-processing addendum says 90 days for the enterprise plan.
  • The difference is plan scope, not a contradiction in the same plan.
  • The procurement owner must confirm which plan the team is buying before the brief states a single number.

The model could assemble the comparison. It could not decide which contract applied.

What to re-run after a source changes

Not every change requires a full rebuild. The team used a small impact rule:

ChangeRe-runDo not re-run
Typo or formattingNothing; note the revisionRetrieval or claim checks
New example in the same sectionThe affected claim onlyThe whole source set
Changed deadline, eligibility, or priceEvery claim that cites the sectionUnrelated sections
New category or exceptionThe claim table and the recommendationHistorical background
Source withdrawn or access revokedThe dependent claims and the handoff noteOther sources

The rule is based on claim dependency, not on how much the document changed. A one-line change to a deadline can invalidate the recommendation; a long new introduction may change nothing.

The team also kept a “last verified” date per claim, not only per article. That made the stale section visible without re-reading the whole brief.

No-answer is a valid output

When the current source could not be accessed, the team did not ask the model to infer the answer from the old version. The brief said: “Cannot verify the current deadline; the source is behind a login; the owner is confirming access.”

That sentence felt less useful than a confident answer. It was more useful than a wrong one. A no-answer output has three parts:

  • what could not be verified;
  • why the available evidence was insufficient;
  • who can resolve it and by when.

The model can draft this note from the retrieval trace. It cannot decide that the missing source is “probably the same.” That decision belongs to the owner.

The handoff note

The brief was for a meeting, not a archive. The team added a five-line handoff note at the top:

  1. What changed. The guidance revision added a new category and a 30-day window.
  2. Which claims moved. The 72-hour statement is now scoped to the original category; the new category is not covered.
  3. What the recommendation is now. Proceed for the original category; pause the new category until the owner confirms the notification channel.
  4. What is still unknown. Whether the new channel applies to existing customers.
  5. Next check. Re-open the guidance after the owner call, and re-run the two dependent claims.

The note is not a summary of the whole brief. It is a decision aid for the person who has to act. It also gives the next reviewer a precise place to start.

Boundary

This drill fits policy, regulatory, security, and vendor research where sources have versions and owners. It does not fit fast-moving news, opinion synthesis, or topics where no authoritative source exists. It also does not replace the source owner’s judgment: the model can mark a claim stale, but only the owner can confirm the new interpretation. If the team cannot access the current source, the correct output is a no-answer note, not a more persuasive paragraph.

SOURCES CHECKED

Which first-party sources informed this guide?

Sources anchor definitions, risk boundaries, or operational facts. The decision framework and workbench are original to AI Vista.

  1. NIST AI Risk Management Framework — PlaybookChecked 2026-10-24
  2. W3C — PROV OverviewChecked 2026-10-24
  3. Google Cloud — Retrieval-augmented generationChecked 2026-10-24

AI tools may assist with research, outlining, and language editing. Facts, cases, and final wording are reviewed by the editor. Report an error through the contact page.

TAKEAWAY TOOL

RAG retrieval trial

Test which evidence the system finds before asking it to write an answer.

retrieval / trial
USE THIS WHENWhen a RAG answer fails or its index changes
YOU WILL GETA repeatable query-level retrieval diagnosis
HOW TO USE01—03
  1. 01
    Describe the taskDescribe the result with a sanitized summary.
  2. 02
    Fill the decision fieldsRecord input categories, risk, evidence pointers, and handoff.
  3. 03
    Ask a colleague to reviewThe tool is ready when someone else can restate the decision.
DONE WHENFields are complete, boundaries are clear, and the result is reviewable.
Edits save automatically

LESSON READ

Finish the workbench, then mark it read.

The read state updates the syllabus and your course progress.

  1. 01Fields filled
  2. 02Case tested
  3. 03Reviewable

GUIDE PRACTICE NOTES

Leave a judgment you can review later.

The fictional examples below show the format. Your own notes stay in this browser. Record what worked, which boundary failed, or one question worth testing.

↗
RELATED GUIDEAI research synthesis: when the source changes after the briefSee examples and local notes →
0 examples and local notesINSIGHTS · QUESTIONS · IDEAS