]>

United States of America pbriggeman@gmail.com https://github.com/pbriggeman/ai-systems-txt

Applications and Real-Time Area ai well-known uri capabilities provenance transparency This document defines "ai-systems.txt", a plain-text file that an organisation that builds or deploys artificial intelligence (AI) systems publishes at a well-known location on its own domain. The file declares, in machine-readable and human-readable form, which AI systems the organisation has released, what their measured capabilities are, who measured them, under what conditions, and where the evidence lives. Every capability claim carries a provenance tier (ATTESTED, MEASURED, or DECLARED); anything absent from a valid, unexpired file is UNDECLARED by definition. The file is signed and expiring, so claims are attributable, timestamped, and falsifiable. robots.txt tells machines what they may take from a publisher; ai-systems.txt is the reverse: it tells anyone what a maker has built, in a form designed to be checked rather than believed.

Introduction Today, information about what AI systems exist and what they can do reaches the public as launch marketing, cropped benchmark screenshots, leaks, and social-media claims. Independent parties (for example, Epoch AI, METR, Artificial Analysis, and the Stanford AI Index) reconstruct the truth after the fact. Concretely:

• There is no canonical, maker-maintained record of what AI systems exist. The closest registry is a third-party reconstruction.
• Capability claims are routinely published without the conditions that make them comparable (benchmark version, agent scaffold, reasoning effort, tool access, date).
• Systems are silently updated, renamed, and retired; yesterday's claim attaches to today's different system.
• Rumor fills every gap. A rumored system or score can be neither confirmed nor denied against any authoritative artefact, so rumor and fact circulate with equal weight.

This document defines a declaration format that addresses those problems at the source. An ai-systems.txt file is:

• A declaration: the maker's own signed statement, attributable and timestamped.
• A claim index: every capability claim carries its provenance tier (), so a reader can grade it without further research.
• A feed: monitors can fetch, hash, and diff the file on a schedule and report precisely what changed.

The file is not a trust mechanism by itself: a declaration can be wrong or dishonest, and the format's defence is falsifiability (), not faith. It is not a content-permissions file: training consent, crawling rules, and AI usage preferences for a publisher's content are the subject of , the IETF aipref work, and the existing "ai.txt" proposals ; this file governs claims about a maker's systems, and its name was chosen to avoid colliding with those proposals. It is not a model card or system card; those remain the right place for long-form discussion, and this file links to them. It is not an agent interface description; agent cards describe how to call an agent, while this file describes what a system is and can do, including systems with no public interface.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Grammar is given in Augmented Backus-Naur Form (ABNF) . The terms publisher (the organisation making the declaration), system (an AI system declared in the file), evaluator (the party that produced a measurement), and validator (software that checks a file per ) are used throughout.

Provenance Tiers Every statement about a system falls into exactly one of four tiers. The file expresses the first three; the fourth is what a validator concludes about everything else. Provenance tiers

Tier	Meaning	Requirement
ATTESTED	An independent evaluator measured the claim and stands behind it in a checkable way.	Evaluation block with a named independent evaluator, an evidence URL, and an Attestation value: the SHA-256 hash of the evaluator's report, or the evaluator's countersignature reference.
MEASURED	A named evaluator measured and published the claim, with method and date. The evaluator may be independent or the maker, and the block states which.	Evaluation block with evaluator (marked independent if so), benchmark version, conditions, measured date, evidence URL.
DECLARED	The maker asserts the claim; no independent measurement is linked.	Any field or evaluation block not meeting the tiers above. Believable, citable, unverified.
UNDECLARED	The system or capability does not appear in a valid, unexpired file at all.	Concluded by validators. This is the rumor tier: by definition, nothing here has been stated on the record by the maker.

Two derived verdicts complete the vocabulary:

CONTRADICTED

A claim in the file conflicts with the named evaluator's own published data or with the registry, beyond the tolerances in . A validator MUST surface both values.

STALE

The claim appeared in a file whose Expires timestamp has passed. Stale claims revert to unverified until the file is renewed.

Location and Discovery

1. The file MUST be served over HTTPS at "https://<domain>/.well-known/ai-systems.txt" (well-known URIs per ).
2. A JSON mirror with identical content SHOULD be served at "https://<domain>/.well-known/ai-systems.json" ().
3. For compatibility, a maker MAY also serve the file at "/ai-systems.txt"; the well-known location takes precedence on any conflict.
4. A detached signature SHOULD be served at the file URL plus ".sig" ().
5. Discovery hints (optional; any one suffices): an HTTP response header 'Link: </.well-known/ai-systems.txt>; rel="ai-systems"; type="text/plain"', or a comment line in the maker's robots.txt: "# AI-Systems: https://<domain>/.well-known/ai-systems.txt".
6. The file applies to the domain it is served from. A maker with several domains serves one file per domain, or identical files whose Canonical field lists each domain's URL.
7. Media types: "text/plain; charset=utf-8" for the file; "application/json" for the mirror.

File Format

General Rules

• The file is UTF-8 plain text. Lines are "Field-Name: value". Field names are case-insensitive ASCII; values are case-sensitive unless a field definition says otherwise.
• Lines beginning with "#" are comments. Blank lines are ignored. Parsers MUST ignore fields they do not recognise (forward compatibility) and MUST NOT fail on them.
• The file has two parts: one header block (fields before the first "System" line), then one stanza per system. A stanza continues until the next "System" line or end of file.
• An evaluation block begins with an "Evaluation:" line inside a stanza; the evaluation-scoped fields that follow belong to it until the next "Evaluation:" line or a non-evaluation field.
• Repeatable fields MAY appear multiple times; the order of "Contact" and "Registry-ID" lines denotes preference and canonical-first, respectively.

Dates and Numbers Dates are YYYY-MM-DD. Timestamps (Expires) are RFC 3339 timestamps. Quantities SHOULD be given in plain scientific or decimal notation parseable by machines (for example, "4.05e11", "2.0e25"). Human suffixes ("405B") are permitted in the text file, but the JSON mirror MUST use plain numbers.

ABNF (Informative Summary)

Header Fields The header block describes the declaration as a whole. "Cards" denotes cardinality. Header fields

Field	Cards	Description
AISystems-Version	exactly 1, REQUIRED	Version of this specification the file conforms to. This document describes version 0.2; files declaring 0.1 remain valid under 0.2 tooling.
Publisher	exactly 1, REQUIRED	The organisation making the declaration.
Canonical	1+, REQUIRED	The URL(s) of this file. A validator MUST warn or distrust if the fetched URL is not listed (mirrors practice).
Contact	1+, REQUIRED	URI (mailto or https) for corrections and disputes about this file. Order denotes preference.
Expires	exactly 1, REQUIRED	RFC 3339 timestamp after which the contents MUST be treated as stale. MUST be less than one year after publication; 90 days is RECOMMENDED for frontier developers.
Signature	exactly 1, REQUIRED	URL of the detached signature for this exact file ().
Systems-Index	0-1	URL of the JSON mirror.
Policy	0-1	URL of the publisher's disclosure or transparency policy.
Previous-Version	0-1	URL of the immediately preceding version of this file, to make diffs discoverable.

System Stanza Fields Each stanza declares one system. System stanza fields

Field	Cards	Description
System	exactly 1, REQUIRED	Canonical name of the system. Unique within the file.
Version	exactly 1, REQUIRED	Version or build identifier. Any change to a served system that could alter capabilities MUST produce a new Version value in an updated file.
Status	exactly 1, REQUIRED	One of: research, preview, general-availability, deprecated, retired.
Released	exactly 1, REQUIRED	Date the system first became available to anyone outside the publisher (including paid or closed previews; say so in a comment).
Predecessor	0-1	Name of the previous system in the line.
Modalities	exactly 1, REQUIRED	Comma-separated list, e.g., "text-in, image-in, text-out, tool-use, code-execution".
Access	exactly 1, REQUIRED	One or more of: api, open-weights, open-source, internal-only. For open weights, include the licence in parentheses.
Registry-ID	0+	External identities, prefixed: "epoch:", "openrouter:", "huggingface:", "api-model:", or another prefix registered per .
Endpoint / Repository	0+	Where the system can actually be reached.
Context-Window	0-1	Maximum context, in tokens, as served - not as designed or announced.
Parameters	exactly 1, REQUIRED*	Parameter count, or the literal value "Undisclosed" ().
Training-Compute	exactly 1, REQUIRED*	Total training compute in FLOP, with basis in parentheses where estimated, or "Undisclosed".
Training-Data-Cutoff	0-1	Date, or "Undisclosed".
System-Card	0-1	URL of the system or model card.
Known-Limitations	0-1	URL or short plain-text summary.
Autonomy-Horizon-50	0-1	Shorthand for the system's 50% long-horizon task-completion figure; if present, it MUST also appear as a full evaluation block with evaluator and conditions.
Safety-Evaluation	0+	One line per external safety evaluation: evaluator, scope, date, report URL.

Evaluation Blocks Each evaluation block describes one measured claim. Evaluation block fields

Field	Cards	Description
Evaluation	block start, REQUIRED	Benchmark name and version or release (e.g., "SWE-bench Verified (2026-01 release)", "METR Time Horizon 1.1").
Evaluator	REQUIRED	Who ran it. MUST include the word "independent" in parentheses if the evaluator is organisationally independent of the publisher.
Score	REQUIRED	The result, with units (e.g., "74.2%", "11.5 hours", "ECI 158").
Conditions	REQUIRED for MEASURED and ATTESTED	Material conditions: agent scaffold or harness, reasoning effort, tool access, attempt limits - whatever a competent replicator would need. A score without conditions is not comparable, and validators MUST flag it.
Measured	REQUIRED	Date the measurement was completed.
Evidence	REQUIRED	URL of the report, dashboard entry, or results file.
Attestation	REQUIRED for ATTESTED	"sha256:<hex>" of the evaluator's report, or a reference to the evaluator's countersignature.
Tier	REQUIRED	ATTESTED, MEASURED, or DECLARED. Validators recompute the tier from the block's contents and MUST downgrade a block whose stated tier its contents do not support (for example, ATTESTED with no Attestation).

The Undisclosed Rule For Parameters and Training-Compute (and, by extension, any field a future version makes required-but-optional-to-answer), a publisher MUST either give a value or write "Undisclosed". Omitting the field makes the file invalid. Rationale: silence is ambiguous (forgotten? withheld? not applicable?); an explicit "Undisclosed" is a countable, comparable fact - it is what transparency indexes currently have to excavate by hand.

Freshness, Versioning, and Change

• A file is current until its Expires timestamp; after that, validators MUST label every claim in it STALE.
• Publishers SHOULD update the file in the same release process as the system itself; a system that is served but absent from a current file is, for consumers of this specification, UNDECLARED.
• Each published version SHOULD remain fetchable (via Previous-Version chains or dated URLs) so diffs are auditable. A monitor's diff of two versions - systems added or removed, scores changed, fields edited - is the authoritative answer to "what changed and when", ending the "quietly updated model" class of rumor.

Signing

• The file MUST name a detached signature (the Signature header) covering the exact bytes of the file as served. OpenPGP (as in practice) or JWS are both acceptable; the signature file's format is self-describing.
• Validators MUST report one of: signature-verified, signature-present-unverified, signature-missing, or signature-invalid. Only signature-verified supports treating the file as authentically the publisher's.
• Signatures cover the served bytes; publishers MUST NOT rely on whitespace-insensitive verification.

JSON Mirror The JSON mirror carries identical content for machine consumers. Field names are lower-snake-case; quantities are numbers; dates are strings as in . An abridged JSON Schema (draft 2020-12) for the mirror is given in . On any conflict between the text file and the mirror, the signed text file wins.

Validator Behaviour A conforming validator, given a file (path or URL), MUST be able to:

1. Authenticate: fetch over HTTPS; check Canonical against the fetch URL; check the signature state ().
2. Check freshness: parse Expires; label the file current or STALE.
3. Lint: required header and stanza fields present; required-but-optional fields explicitly valued or "Undisclosed"; Status in vocabulary; dates parse; every evaluation block complete for its stated tier; tiers recomputed and downgraded where unsupported.
4. Cross-check: for each system, look up the reference registry (the Epoch AI models dataset is the reference registry for this draft) and report IN-REGISTRY, NOT-IN-REGISTRY, or CONTRADICTED. For each MEASURED or ATTESTED claim, compare against the evaluator's published data where a machine-readable source exists, and verify the Evidence URL resolves.
5. Rumor sweep: given a list of names circulating publicly, report each as declared in the file, or as "UNDECLARED - rumor tier" if absent. Validators MUST NOT import rumored systems into the declared set.
6. Diff: given a previous version, report added and removed systems and every changed field and score.
7. Report: emit a machine-readable report (JSON) containing, per system and per claim, its tier or verdict, all errors and warnings, and the file's SHA-256 hash. Human-readable renderings SHOULD be offered. Verdict vocabulary: VALID, VALID-WITH-WARNINGS, INVALID, plus per-claim ATTESTED / MEASURED / DECLARED / CONTRADICTED / STALE / EVIDENCE-UNREACHABLE and per-system registry verdicts as in item 4.

Comparison Tolerances Exact equality is too strict for reconstructed registries. Reference tolerances: release dates differing by at most 31 days are a warning, not a contradiction; parameter counts differing by more than a factor of 2, and training compute differing by more than a factor of 3 (registries estimate compute), are contradictions. An evaluator's own republication of a score supersedes the file's transcription of it.

Conformance Levels Publisher levels:

Level 1 - Declared

Valid file, all required fields, signature named.

Level 2 - Measured

At least one MEASURED evaluation per generally-available system, JSON mirror published, Registry-ID values cross-linked.

Level 3 - Attested

ATTESTED evaluations from at least one independent evaluator for frontier systems, Previous-Version chain maintained, expiry of 90 days or less.

Validator conformance: implements all of and publishes its test results against the reference test suite (valid, expired, broken, contradicted, and rumor cases).

Security Considerations

• Dishonest declarations. The format cannot prevent lying. It converts lies from deniable rumors into signed, timestamped, hashed statements that independent evaluators can contradict on the record - permanently attributable. That is the same bargain that makes files and financial filings useful.
• Spoofed files. Files on lookalike domains are not the publisher's. Canonical checking plus signature verification are the defence; consumers MUST NOT trust an unsigned or canonical-mismatched file.
• Stale mirrors and caches. Expires bounds the damage; validators MUST surface staleness rather than silently serving old claims.
• Benchmark gaming. Mandatory Conditions and versioned benchmarks make selective reporting visible: a publisher that reports only flattering benchmarks will show conspicuously fewer evaluation blocks than its peers - itself a signal.
• Signature stripping and downgrade. A mirror that drops the signature reduces every claim to at most DECLARED; validators MUST reflect that.
• Denial by omission. A publisher can omit a secret system. The file makes that omission visible as a state (UNDECLARED) once the system is rumored, rather than leaving the rumor unanswerable either way.

Privacy Considerations The file contains only public, organisational information. Personal data SHOULD NOT appear beyond role-based contacts (as in practice). Nothing in this specification requires disclosing trade secrets: the Undisclosed rule exists precisely so a publisher can be complete about the shape of its disclosure without revealing protected values.

Adoption and Relationship to Existing Work Adoption proceeds in layers: makers publish Level 1 files (cost: one static file in the release checklist); evaluators publish results in linkable, hashable reports so blocks can be ATTESTED, and may countersign; registries and monitors ingest files as a first-party source; buyers and journalists cite tiers rather than screenshots.

• (robots.txt): the directional opposite and the adoption template - voluntary, trivial, publisher-served.
• (security.txt): the structural template - well-known location, "Field: value" lines, required Contact and Expires, signed files, an IANA field registry.
• "ai.txt" proposals : content permissions for publishers; complementary, and the reason for this file's distinct name.
• llms.txt: a content index for agents; unrelated purpose.
• Model cards and system cards: long-form companions; linked, not replaced.
• Agent cards (A2A) and MCP server cards: runtime interface descriptions; a complementary layer.
• Epoch AI, METR, Artificial Analysis, and the Stanford AI Index: the independent reconstruction layer this file feeds and is checked against; adoption of this specification makes their work faster, not obsolete.

Open Questions for Reviewers

1. Should ATTESTED require the evaluator's countersignature, or is a report hash sufficient for version 1?
2. Should Expires for frontier developers be a MUST at 90 days or less, rather than a recommendation?
3. Is a separate incident-contact field needed, or does Contact suffice?
4. Should energy or water use per training run be a required-but- optional field in version 1, or deferred to the field registry?
5. Who should host the field registry and test suite: an IETF path, or a community registry first?

IANA Considerations

Well-Known URI Registration This document requests registration of the following values in the "Well-Known URIs" registry :

Field-Name Registry This document also suggests a future field-name registry (name, cardinality, status, reference), modelled on the registry established for , so that new fields (for example, energy use or incident contacts) can be added without breaking parsers; parsers already MUST ignore unknown fields. A registry-prefix registry for Registry-ID values is suggested on the same basis. The initial contents of the field-name registry are the fields defined in , , and .

References Normative References Informative References Epoch AI

Worked Example The following complete file is fictional. Its rumored successor system ("Example-10") appears nowhere in it and is therefore, to any validator, UNDECLARED.

JSON Schema for the JSON Mirror (Abridged) Note: "Parameters" and "Training-Compute" accept a number or the string "Undisclosed". The full schema is maintained with the reference implementation .

Acknowledgements The author thanks Jevex for editorial and implementation assistance with this specification, the reference validator, and the test suite, and the maintainers of the security.txt and robots.txt specifications, whose adoption paths this document deliberately follows.