Internet-Draft ai-systems.txt November 2026
Briggeman Expires 5 May 2027 [Page]
Workgroup:
Network Working Group
Published:
Intended Status:
Informational
Expires:
Author:
P. Briggeman

ai-systems.txt: A Well-Known File for Declaring AI Systems and Their Measured Capabilities

Abstract

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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 5 May 2027.

▲

Table of Contents

1. 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:

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

The file is not a trust mechanism by itself: a declaration can be wrong or dishonest, and the format's defence is falsifiability (Section 14), 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 [RFC9309], the IETF aipref work, and the existing "ai.txt" proposals [AI-TXT]; 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.

1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Grammar is given in Augmented Backus-Naur Form (ABNF) [RFC5234]. 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 Section 12) are used throughout.

2. 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.

Table 1: 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 Section 12.1. 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.

3. Location and Discovery

  1. The file MUST be served over HTTPS at "https://<domain>/.well-known/ai-systems.txt" (well-known URIs per [RFC8615]).
  2. A JSON mirror with identical content SHOULD be served at "https://<domain>/.well-known/ai-systems.json" (Section 11).
  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" (Section 10).
  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.

4. File Format

4.1. 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.

4.2. Dates and Numbers

Dates are YYYY-MM-DD. Timestamps (Expires) are RFC 3339 [RFC3339] 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.

4.3. ABNF (Informative Summary) 

file        = header *( stanza )
header      = *( field-line / comment / blank )
stanza      = system-line *( field-line / eval-block /
                            comment / blank )
system-line = "System:" SP value CRLF
eval-block  = eval-line *( eval-field )
eval-line   = "Evaluation:" SP value CRLF
eval-field  = ("Evaluator" / "Score" / "Conditions" / "Measured" /
               "Evidence" / "Attestation" / "Tier") ":" SP value CRLF
field-line  = field-name ":" SP value CRLF
comment     = "#" *( VCHAR ) CRLF

5. Header Fields

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

Table 2: 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 [RFC9116] 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 (Section 10).
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.

6. System Stanza Fields

Each stanza declares one system.

Table 3: 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 Section 18.
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" (Section 8).
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.

7. Evaluation Blocks

Each evaluation block describes one measured claim.

Table 4: 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).

8. 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.

9. Freshness, Versioning, and Change

10. Signing

11. 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 Section 4.2. An abridged JSON Schema (draft 2020-12) for the mirror is given in Appendix B. On any conflict between the text file and the mirror, the signed text file wins.

12. 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 (Section 10).
  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 [EPOCH] 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.

12.1. 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.

13. 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 Section 12 and publishes its test results against the reference test suite (valid, expired, broken, contradicted, and rumor cases).

14. Security Considerations

15. Privacy Considerations

The file contains only public, organisational information. Personal data SHOULD NOT appear beyond role-based contacts (as in [RFC9116] 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.

17. 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?

18. IANA Considerations

18.1. Well-Known URI Registration

This document requests registration of the following values in the "Well-Known URIs" registry [RFC8615]:

URI suffix: ai-systems.txt
Change controller: Peter Briggeman (pbriggeman@gmail.com)
Specification document(s): [this document]
Status: provisional
Related information: The reference implementation, validator, and
test suite are maintained at
https://github.com/pbriggeman/ai-systems-txt

URI suffix: ai-systems.json
Change controller: Peter Briggeman (pbriggeman@gmail.com)
Specification document(s): [this document], Section "JSON Mirror"
Status: provisional
Related information: JSON mirror of ai-systems.txt; on any conflict
the signed text file prevails.

18.2. Field-Name Registry

This document also suggests a future field-name registry (name, cardinality, status, reference), modelled on the registry established for [RFC9116], 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 Section 5, Section 6, and Section 7.

19. References

19.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC3339]
Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, , <https://www.rfc-editor.org/info/rfc3339>.
[RFC5234]
Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, , <https://www.rfc-editor.org/info/rfc5234>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8615]
Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, , <https://www.rfc-editor.org/info/rfc8615>.

19.2. Informative References

[AI-TXT]
Car, L., "The ai.txt File: AI Usage Preferences and Licensing", Work in Progress, Internet-Draft, draft-car-ai-txt-wellknown-00, , <https://datatracker.ietf.org/doc/draft-car-ai-txt-wellknown-00/>.
[EPOCH]
Epoch AI, "Epoch AI Data: AI Models Dataset and Benchmarking Hub", , <https://epoch.ai/data>.
[REFIMPL]
Briggeman, P., "ai-systems.txt: Specification, Reference Validator, and Test Suite", , <https://github.com/pbriggeman/ai-systems-txt>.
[RFC9116]
Foudil, E. and Y. Shafranovich, "A File Format to Aid in Security Vulnerability Disclosure", RFC 9116, , <https://www.rfc-editor.org/info/rfc9116>.
[RFC9309]
Kessler, M., Zawinski, H., and S. Illyes, "Robots Exclusion Protocol", RFC 9309, , <https://www.rfc-editor.org/info/rfc9309>.

Appendix A. 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.

# ai-systems.txt - EXAMPLE ONLY (fictional maker, fictional system)
AISystems-Version: 0.2
Publisher: Example AI, Inc.
Canonical: https://example-ai.com/.well-known/ai-systems.txt
Contact: mailto:ai-systems@example-ai.com
Expires: 2027-01-29T00:00:00Z
Signature: https://example-ai.com/.well-known/ai-systems.txt.sig
Systems-Index: https://example-ai.com/.well-known/ai-systems.json
Policy: https://example-ai.com/transparency

System: Example-9
Version: 9.2 (build 2026-09-28)
Status: general-availability
Released: 2026-09-30
Predecessor: Example-8.5
Modalities: text-in, image-in, text-out, tool-use
Access: api
Registry-ID: epoch:example-9
Registry-ID: openrouter:example-ai/example-9
Endpoint: https://api.example-ai.com/v1
Context-Window: 1000000
Parameters: Undisclosed
Training-Compute: Undisclosed
Training-Data-Cutoff: 2026-03-31
System-Card: https://example-ai.com/system-cards/example-9

Evaluation: Epoch Capabilities Index
Evaluator: Epoch AI (independent)
Score: ECI 158
Conditions: hub default, all component benchmarks as published
Measured: 2026-10-12
Evidence: https://epoch.ai/benchmarks
Tier: MEASURED

Evaluation: METR Time Horizon 1.1 (50% horizon)
Evaluator: METR (independent)
Score: 11.5 hours
Conditions: scaffold=triframe, private task suite
Measured: 2026-10-03
Evidence: https://metr.org/time-horizons
Attestation: sha256:00000000000000000000000000000000000000000000
             000000000000000000000000
Tier: ATTESTED

Evaluation: SWE-bench Verified (2026-01 release)
Evaluator: Example AI (self)
Score: 74.2%
Conditions: scaffold=standard-agent, effort=high,
            tools=terminal+editor
Measured: 2026-09-14
Evidence: https://example-ai.com/evals/example-9-swebench
Tier: DECLARED

Safety-Evaluation: UK AISI pre-deployment eval, autonomy + cyber
  scope, 2026-09-20, https://example-ai.com/safety/aisi-2026-09

Appendix B. JSON Schema for the JSON Mirror (Abridged) 

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "ai-systems.json",
  "type": "object",
  "required": ["ai_systems_version", "header", "systems"],
  "properties": {
    "ai_systems_version": {"type": "string"},
    "header": {
      "type": "object",
      "required": ["Publisher", "Canonical", "Contact",
                   "Expires", "Signature"]
    },
    "systems": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["System", "Version", "Status", "Released",
                     "Modalities", "Access", "Parameters",
                     "Training-Compute", "evaluations"],
        "properties": {
          "Status": {"enum": ["research", "preview",
                     "general-availability", "deprecated",
                     "retired"]},
          "Parameters": {"type": ["number", "string"]},
          "Training-Compute": {"type": ["number", "string"]}
        }
      }
    }
  }
}

Note: "Parameters" and "Training-Compute" accept a number or the string "Undisclosed". The full schema is maintained with the reference implementation [REFIMPL].

Appendix C. 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.

Author's Address

Peter Briggeman
United States of America
URI: https://github.com/pbriggeman/ai-systems-txt