# What should the source record behind an AI answer contain?

> Seven parts that make an AI answer checkable, from the source and record ID to attestation dates and unknowns, shown on seven real company lookups.

- URL: https://ikag.dev/blog/what-the-source-record-behind-an-ai-answer-contains
- Author: Ronit Ahuja, Founder, IKAG (https://ikag.dev/authors/ronit-ahuja)
- Published: 2026-10-15
- Updated: 2026-10-15
- Reading time: 4 min
- Publisher: IKAG

## Overview

A source record is the evidence attached to a value: which source stated it, which record, a link to that record, when the source last attested it, how the value was matched, and what the record did not establish. A link to a web page is not enough. In seven real company lookups, the records established 19 of 63 requested fields; the other 44 came back as unknown, each with a reason.

## Key points

- A useful source record names the source, the record and its identifier, a link to it, when the source attested the fact, how the value was matched, and what the record does not say.
- Freshness belongs to the source, not the fetch: a value fetched today can describe a record last updated months ago.
- In seven real lookups by IKAG’s first capability, 19 of 63 requested fields were established. The other 44 were reported as unknown with a reason, never filled in.
- Unknown is an answer. An agent that says what it could not establish is easier to check than one that fills every field.

Most AI answers come with a link, if they come with anything. A link tells you where the answer says it came from. It does not tell you which record stated the value, how old that record is, or what the record left out. For answers you need to rely on, that is the information that matters. This article sets out what a source record should contain and shows it on real lookups.

## What is a source record?

A source record is the evidence attached to a single value in an answer. If an assistant tells you a company is incorporated in California, the source record says which source stated that, in which record, when the source last attested it, and how confident the match was. It is attached to the value, not to the answer as a whole, because different values in one answer often come from different places.

The idea is not new. Provenance standards such as the W3C’s PROV model have described where data comes from for years. What is new is that AI agents now assemble answers from many sources at once, and a reader has to be able to take any one value apart.

## The seven parts of a useful record

| Part            | The question it answers                  | Example from a real lookup                 |
| --------------- | ---------------------------------------- | ------------------------------------------ |
| Source          | Who stated this?                         | SEC EDGAR, a primary registry              |
| Record          | Which record, exactly?                   | The SEC company record for CIK 0000320193  |
| Link            | Where can I see it?                      | The record’s address at the source         |
| Attested        | When did the source last state it?       | Not stated by this source, so left blank   |
| Match           | How was the entity identified?           | By exact identifier, not by name           |
| Agreement       | Does any other source agree or disagree? | Wikidata gives the same name               |
| Not established | What did the record not say?             | Whether the company is active; its website |

Two of these parts do most of the work. The record identifier lets anyone open the same record and check it. The “not established” list stops a reader from assuming the answer covered everything they asked.

## Freshness belongs to the source, not the fetch

An agent that fetched a record five seconds ago will be tempted to call its values current. That is a mistake. The record may have been last updated months ago, and some sources do not say at all.

In IKAG’s tests, GLEIF dated each record: Apple’s was last updated on 3 March 2026, however recently it was fetched. The SEC’s company facts carried no such date, so the values were never called current, even straight after fetching them. A good record keeps the source’s date where there is one and leaves the field empty where there is not.

## What real lookups return

We asked IKAG’s first capability, company legal identity, for the same nine fields in seven different ways, on public records captured between 29 August and 7 October 2026. Across the seven requests, 19 of the 63 requested fields were established. The other 44 came back as unknown, each with a reason.

**Chart: Fields established per request, out of 9, in seven real lookups**

| Item | Value | Note |
| --- | --- | --- |
| SEC CIK and Wikidata ID | 4 of 9 |  |
| SEC CIK only | 4 of 9 |  |
| LEI only | 5 of 9 |  |
| Fund LEI only | 6 of 9 |  |
| LEI and SEC CIK | 0 of 9 | No primary record linked the two, so neither was assumed |
| Wikidata ID only | 0 of 9 | Community data corroborates; it never proves |
| Fund name only | 0 of 9 | Three entities matched the name; none was picked |

Each request asked for the same nine fields of company legal identity. Red bars are requests where the honest answer was that nothing could be established. Source: [IKAG: seven requests to the first capability, on captured public records](https://ikag.dev/agents#runs).

The three empty requests are not failures. In one, a request named an LEI and an SEC CIK that no primary record linked, so the capability did not assume they were the same company. In another, it had only a Wikidata ID, and community data can agree with a value but never prove one. In the third, a fund’s name matched three entities, and a name never selects a company.

**Chart: How often each requested field was established, in the same seven lookups**

| Item | Value |
| --- | --- |
| Legal name | 4 of 7 |
| Identifiers | 4 of 7 |
| Jurisdiction | 4 of 7 |
| Entity status | 2 of 7 |
| Registered address | 2 of 7 |
| Latest filing | 2 of 7 |
| Legal form | 1 of 7 |
| Registration jurisdiction | 0 of 7 |
| Official website | 0 of 7 |

Some fields are rarely stated by these registries at all. Reporting them as unknown is more useful than filling them from elsewhere without a record. Source: [IKAG: seven requests to the first capability, on captured public records](https://ikag.dev/agents#runs).

Some fields are simply rare in these registries. None of the seven lookups established a registration jurisdiction or an official website from the records consulted. The right answer for those fields is unknown, not a value borrowed from somewhere without a record.

## Unknown is an answer

There are two kinds of unknown, and a record should say which one it is.

- **Not observed.** The sources consulted were the right ones, and none of them stated the value. More sources might help.
- **Insufficient evidence.** The request could not be tied to one entity with confidence, so no value was attached at all. More identifiers might help.

An agent that reports unknowns this way gives you something to act on. An agent that fills every field gives you something to doubt.

## How to show it without burying the answer

A record does not have to clutter the answer. The pattern that works is progressive: the value first, a small mark that it has a source, and the full record one step away, behind a “view sources” control. The unknowns sit under their own “what’s still unknown” control, so they are visible to anyone who looks and invisible to anyone who does not need them.

The assistant decides how much of this to show. The source record’s job is to exist, complete, so that the assistant, or you, can.

## Questions

### Is a link to a web page a source record?

Not on its own. A link shows where an answer says it came from. A source record also names the record, the date the source attested the fact, and what the record does not establish, so the claim can be checked without guessing.

### What is the difference between attested and retrieved?

Retrieved is when a system fetched the data. Attested is when the source itself stated or last updated the fact. Only the second tells you how current the fact is.

### Should an agent fill a missing field from another source?

Only if that source is suitable for the field and the value comes back with its own record. Otherwise the honest answer is unknown, with the reason.

### Does a source record make an answer correct?

No. Records can be wrong or out of date. A source record makes an answer checkable: you can see what stated it and when, and decide whether to rely on it.

## Sources

- [IKAG for builders: seven requests to the first capability](https://ikag.dev/agents#runs)
- [W3C PROV-O: The PROV Ontology (30 April 2013)](https://www.w3.org/TR/prov-o/)
- [GLEIF API: LEI record HWUPKR0MPOU8FGXBT394](https://api.gleif.org/api/v1/lei-records/HWUPKR0MPOU8FGXBT394)
- [SEC: EDGAR application programming interfaces](https://www.sec.gov/search-filings/edgar-application-programming-interfaces)
- [Wikidata: item Q312](https://www.wikidata.org/wiki/Q312)