What an AI Visibility Evidence Ledger Records

The ledger answers “what did we actually observe?”

AI visibility work regularly collapses evidence into labels:

Crawler accessible
Schema valid
ChatGPT visible
Competitor winning
Fix successful

Those labels are difficult to audit. The evidence ledger stores the underlying observation.

For a public page:

requested_url
final_url
status
content_type
body_hash
expected_product_identity
canonical
selected_market
structured_entities
challenge_indicators
timestamp
collection_method

For an AI answer:

prompt_id
exact_prompt
provider
visible_mode
market
language
run_status
answer
source_urls
matched_products
competitors
fact_errors
timestamp

Product identity connects the records

The ledger associates evidence with a commerce entity:

• shop
• product
• variant
• market
• identifiers
• canonical page
• feed item
• supporting documents

A URL redirect does not automatically create a new product. A product title match does not automatically prove two records are the same variant.

The identity agent records the match method and confidence.

Observations should be append-only

When a price changes, the old observation should not be overwritten. It remains part of the timeline:

09:00 Shopify variant: CAD 129, in stock
09:04 public page: CAD 129, in stock
09:11 feed record: CAD 119, in stock
13:30 feed record: CAD 129, in stock

This history explains the freshness window and prevents a later investigation from assuming the feed was always correct.

Findings reference evidence

A finding is a conclusion attached to records:

Finding:
Feed price is stale for variant RCB-BRN-12.

Evidence:
Shopify variant observation 381
Public page observation 382
Feed observation 386

Confidence:
High

The agent does not paste the same facts into a separate narrative with no provenance.

Changes also belong in the ledger

Every proposed and executed fix should store:

• finding IDs
• current and proposed values
• affected Shopify objects or files
• risk
• approver
• prior values or backup
• execution result
• public verification records
• rollback state

This creates a change graph connecting cause, decision, action, and outcome.

Provider failures need first-class records

A timeout, refusal, authentication error, quota error, or tool failure is not a non-mention.

If failures are discarded, visibility rates become biased. The ledger preserves the run status so denominators can use completed observations only.

Attribution reads from the ledger

Attribution needs chronology and stable IDs. It asks:

• Which change happened?
• Which products and prompts were affected?
• Did the corrected fact appear later?
• Did the canonical source become cited?
• What else changed in the window?
• Was a legitimate referral or order attributed?

Without the evidence ledger, the answer depends on memory and screenshots. With it, Attribute can report the level of association actually supported.