How to Build an AI Feature Claim Ledger

How to Build an AI Feature Claim Ledger

Build an AI feature claim ledger by giving every public statement its own record. Capture the exact claim, source, evidence state, product and version, account and region scope, observation or test, approved wording, uncertainty, owner, correction history, and refresh trigger.

The ledger prevents a preview, launch, documentation page, limited rollout, hands-on test, and later retirement from collapsing into one timeless sentence.

stateDiagram-v2
    [*] --> Rumored
    Rumored --> Announced
    Announced --> Documented
    Documented --> Enabled
    Enabled --> Observed
    Observed --> Measured
    Measured --> Changed
    Documented --> Changed
    Enabled --> Deprecated
    Changed --> Deprecated
    Deprecated --> Retired

Make the claim atomic

"Meta AI can search Reels" is a useful headline but a weak ledger record.

Which Meta AI surface? Which account type, country, language, device, and date? Does "search" mean the system returns Reel cards after an explicit prompt, searches every eligible Reel, or lets a user filter and rank a defined corpus? Was the behavior documented, observed, or inferred?

A stronger record might say: "On the recording date, the host's Meta AI web session returned a set of Reel cards after English natural-language prompts about fashion and home products." That wording can be checked against E026. It does not claim current availability or disclose an unseen architecture.

One record should be capable of becoming false through new evidence.

Preserve the source and its role

Record the original URL, publisher, author, publication date, retrieval date, title, archived copy where permitted, and the exact section supporting the claim.

Then label the source role. A publisher announcement establishes what the company announced. Documentation establishes the stated product contract for a version. A model card establishes the publisher's artifact description and evaluations. A hands-on test establishes observed behavior in the tested environment. An independent evaluation establishes its own measured result.

NIST's AI Resource Center frames testing, evaluation, verification, and validation as operational work. The ledger should preserve which kind of evidence exists instead of replacing all of it with "verified."

Use states that describe reality

Keep the states plain enough that writers, product teams, and agents apply them consistently.

States can coexist across scopes. A feature may be enabled in one country and only announced in another. Do not force one global status.

Record scope before writing public prose

At minimum, capture product, feature, version, model, platform, device, account, plan, organization setting, region, language, date, audience, data source, and integration.

Also record what the source does not specify.

Meta's Llama 3.1 release announcement and model card provide a concrete example. The announcement tells the release story. The model card defines model artifacts and technical scope. The Community License governs legal terms. A claim about availability, model behavior, and permission may need all three plus a test.

Attach an observation record

For a hands-on claim, store the date, tester, environment, account, input, expected result, actual result, latency, repetitions, failure cases, media or logs, and any data that cannot be shared.

One success should be written as one observed success. Reliability needs repeated, representative tests and a denominator.

Avoid turning "worked for me" into "works." Avoid turning "did not appear in my account" into "does not exist."

For model claims, [[How to Verify an AI Model Claim Before Release]] provides the evidence ladder. For retrieval features, [[How to Evaluate Semantic Search for a Media Library]] provides a deeper evaluation.

Store approved wording beside the evidence

Give the publishing agent language it may use, language it must qualify, and language it must not use.

The approved sentence should include the time and scope when they matter. The record should also name the destination pages that rely on it.

This is where the ledger becomes useful for GEO and SEO. A clear answer can remain direct without pretending the fact is universal. Structured fields make it easier to update every dependent page when the state changes.

Make correction append-only

Do not overwrite the pre-release state after launch. Add a dated revision that points to the superseding evidence, explains the difference, and updates the current wording.

E026 expected a roughly 408B model. Meta released Llama 3.1 405B. The correction should preserve both facts: what the episode said before release and what the official artifact later established.

History protects trust and produces useful editorial context. Silent replacement destroys both.

Set a refresh trigger and owner

Time alone is a weak refresh strategy. Use events.

A claim may require review when the publisher changes documentation, a model or app version changes, terms are revised, a rollout expands, a feature disappears, an evaluation is published, a test fails, a region changes, or a dependent page is scheduled for publication.

Assign one owner. The ledger can notify several people, but someone must decide whether evidence changes public wording.

A reusable Markdown record

The working record can remain human-readable:

Claim:
Product and feature:
Evidence state:
Scope:
Source and source role:
Observed test:
Current public wording:
Uncertainty:
Supersedes:
Used by:
Owner:
Refresh trigger:
Last checked:

This is intentionally not a public bullet list. It is an internal record schema. Footprint or another publishing agent should read it before drafting, preserve the source boundary, and refuse to promote a weaker evidence state into a stronger claim.

This method was developed with AI assistance from E026, current NIST and Meta sources, and the linked ledger framework. Dalton Anderson remains the author. It does not verify any feature by itself. Editorial, product, technical, legal, source, accessibility, and founder review are required before publication or operational use. Publication is not authorized.