Article

Verifying sources in AI documents: what to require before delivery

A convincing report still needs evidence. Specify claim verification, source versions and human approval when building an AI document system.

By Aviel Shnaider · CTO, JuliusUpdated 6 min read

When commissioning an AI system that prepares reports, summaries or recommendations, polished wording is not enough. You need to know which claims have supporting sources, whether those sources actually support the statements attributed to them and who approved delivery. Define reference verification as part of the work performed by the system and team. A bibliography can help readers, but does not by itself establish that the text is supported or that checking occurred.

A story about responsibility for delivery

In October 2025, The Register reported corrections to a Deloitte report for an Australian government department following erroneous references, and disclosure of AI use in the revised version. That is historical news reporting. The department’s official publication page records a further correction in February 2026, replacing the version published in October 2025. The version discussed in the news report should therefore not be treated as current.

Our proposed lesson for software buyers is not that every AI-assisted document is invalid. It is that the purchase should include a checking process and delivery responsibility, not just text generation. Disclosing the tool helps explain the work, but does not replace verification. Even when a conclusion sounds reasonable, an invalid source requires correction and reconsideration of the claim based on it. The story alone does not establish the cause of every error.

Build a claim map, not only a bibliography

Ask for each material factual claim to be traceable to a source and a relevant location within it. Alongside the document name, retain its date, version and supporting passage. A source mentioning a topic is different from one supporting a sentence. For example, a product description does not establish that customers save time. Without evidence of savings, remove the figure or identify it as a hypothesis to test.

Separate sourced facts, author interpretation and recommendations. In a hypothetical customer-service report, enquiry volume is a datum, an explanation for an increase may be a hypothesis and adding a representative is a recommendation. Each needs a different check. The system should let readers and reviewers distinguish them rather than presenting every sentence with equal certainty. This is a specification example, not a result from a project we delivered.

Specify an acceptance check that can be demonstrated

Choose trial documents with known answers and cases where information is missing. Include a source superseded by a newer version, conflicting sources and an unavailable link. Ask the supplier to demonstrate the output in each situation. A useful result may be an acknowledgement of insufficient information rather than a complete paragraph. Decide in advance which errors block delivery and which require a note or a local correction.

During review, follow the claim to its source and read the surrounding context. Does a number cover the same period and population? Has a qualification changing its meaning disappeared? Does a quotation actually occur as displayed? Include these acceptance questions in the technology product specification. Do not settle for a demonstration in which every link opens: address availability and evidential support are separate checks, and both may matter.

What does Julius document in its publishing process?

Our documented publishing procedure requires retaining the original draft, recording evidence provenance and avoiding invented first-hand experience or client outcomes. It separates preparing an article, writing it to the content system and verifying the public page. This describes the procedure used for this publication; it is not a model-accuracy statistic or a promise of error-free content. Readers can inspect the article’s linked sources and what is attributed to them.

That separation is also useful in a product generating documents for customers. Create explicit states such as draft, under review and approved for delivery. When an important source is inaccessible or a claim unsupported, retain the review state and record the gap. Do not display approval simply because generation finished. Record who approved which version, so a later correction does not conceal the difference between the delivered document and the current one.

Who reviews, and what happens after correction?

Assign someone qualified to approve the relevant type of content. Give reviewers sources and notes, not just a formatted document. Where assessing a claim requires specialist knowledge, a language review alone is insufficient. Divide responsibility for source maintenance, output review and delivery. The delivered document should communicate relevant limitations without burdening readers with technical detail that does not help their decision.

If an error emerges, identify other claims depending on the same source and versions already delivered. Correct the content and retain an explanation of the change. In a hypothetical example, replacing a policy document may require reconsidering recommendations based on it even when their wording stays unchanged. Do not assume that replacing the hyperlink resolves the issue. Plan how users learn that a corrected version of their document exists.

What belongs in an AI development proposal?

Request a breakdown of permitted sources, version retention, claim-to-source checking and human approval. Compare proposals on review and correction effort as well as report-generation speed. Our guide to choosing AI developers addresses team selection; the narrower acceptance question here is whether you can establish the support behind each significant claim in the particular deliverable you are commissioning.

For a conversation with Julius about software development, bring a sample report, permitted sources and two claims that are difficult to verify today. Define who uses the output and which decision it supports. From there, plan a limited trial assessing evidence quality and review work before expanding production. A tool producing a large amount of text does not necessarily shorten the path to a document your team can stand behind.

In short

  • Verify support for material claims, not merely working links.
  • Distinguish facts, interpretation and recommendations.
  • Retain versions and human approval before delivery.

From our own work

Julius’s publishing procedure requires original drafts, evidence provenance and separate public-page verification. It is a documented process used for this article, not a model-accuracy or client-outcome claim.

Recurring questions

Does a reference list prove an AI report is reliable?

No. Check that the source is accessible, appropriate to the version and period, and supports the particular claim. A link about the same subject is insufficient. Request a path from the sentence to the relevant passage and its context.

What if no source supports a claim?

Do not present it as verified fact. Remove it, label it as a hypothesis or hold delivery for investigation according to its importance. Define in advance which evidence gaps block a document and who decides how they are resolved.

What should be checked when a source changes?

Reconsider the claims and recommendations depending on that source, not merely the replacement link. Retain document versions, an explanation and approval of the correction. If an earlier version was delivered, provide a way to notify recipients of the corrected one.

Sources

Keep reading

← Back to the cluster: From idea to MVP