AIPolicy Web Standard — Specification v2.0

Document Identifier: AIPOLICY-SPEC-v2.0 Status: Working Draft Version: 2.0.0-draft.1 Date: 2026-02-07 Editor: Guido Mitschke Repository: https://gitlab.com/human-first-ai/hf-ai-web-standard License: CC BY 4.0 (specification text), MIT (code examples)

---

Status of This Document#

This document is a Working Draft. It has not undergone public review and is not a finalized standard.

The specification lifecycle follows this progression:

Working Draft → Public Review Draft → Candidate Standard → Ratified Standard

This document is at stage 1 of 4.

Feedback is invited via the project's issue tracker. All normative changes require the RFC process defined in /rfc/.

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 RFC 2119 RFC 8174 when, and only when, they appear in capitalized form.

---

1. Motivation#

AI systems trained on web content acquire behavioral tendencies from statistical patterns in their training corpora. Currently, no standardized mechanism exists for website operators to publish structured signals about societal preferences, governance expectations, or stability concerns related to AI system behavior.

Existing approaches address adjacent problems:

Standard	Purpose	Gap
robots.txt	Crawl access control	Does not express behavioral expectations
security.txt	Vulnerability disclosure	Limited to security contact information
sitemap.xml	Content discovery	No governance semantics
llms.txt	LLM content guidance	No structured policy declarations
ai.txt (Spawning)	Training opt-out	Binary consent, no policy granularity

AIPolicy fills this gap by defining a structured, machine-readable file format for publishing governance-relevant signals. It does not impose requirements on AI systems. It provides infrastructure for expressing, aggregating, and researching societal preferences at web scale.

---

2. Design Goals#

1. Simplicity. The standard MUST be implementable by a website operator with basic technical knowledge within 15 minutes.

2. Machine Readability. All declarations MUST be parseable by standard JSON parsers without custom tooling.

3. Neutrality. The format MUST NOT encode specific political, ideological, or moral positions in the specification itself. Policy content is defined in the registry, not in the format.

4. Extensibility. The format MUST support future policy additions, custom extensions, and versioning without breaking existing implementations.

5. Compatibility. The standard MUST coexist with existing web standards (robots.txt, security.txt, sitemap.xml, llms.txt) without conflict.

6. Auditability. All declarations MUST be publicly accessible and verifiable by third parties.

7. Minimalism. The specification defines the minimum viable structure. Additional semantics belong in the registry or in extensions.

8. Research Utility. The format MUST be designed to enable aggregation and statistical analysis of declarations across the web.

---

3. Terminology#

AIPolicy Declaration A structured JSON document published by a website operator that expresses governance-relevant signals referencing policies from the AIPolicy Registry.

Policy A discrete, identifiable governance signal defined in the AIPolicy Registry. Each policy has a unique identifier (e.g., AP-1.1), a category, a human-readable statement, and testability criteria.

Registry The canonical list of all policies recognized by the AIPolicy Web Standard. Maintained in /registry/principles-v2.md and published as machine-readable data at a well-known URL.

Publisher The entity responsible for an AIPolicy Declaration. Typically the website operator or organization controlling the domain.

Conformance Level The degree of implementation completeness. Three levels are defined (Section 5).

Scope The portion of a web property to which a declaration applies: site (entire domain), section (URL path prefix), or page (single URL).

Extension A non-standard field within a declaration, namespaced to avoid conflicts. Extensions are not normative.

Validator A tool or service that verifies whether a declaration conforms to this specification.

---

4. Core Concepts#

4.1 The Declaration Model#

An AIPolicy Declaration is a JSON document that answers three questions:

1. Who is declaring? (Publisher identity)
2. What are they declaring? (Policy references)
3. Where does the declaration apply? (Scope)

The declaration does not prescribe AI behavior. It publishes structured signals that may be consumed by AI systems, researchers, aggregators, validators, or any other party.

4.2 The Signal Model#

AIPolicy operates on a publish-and-observe model:

Publisher → Declaration → Web → Consumers (AI systems, researchers, aggregators)

There is no enforcement mechanism in the specification. The standard defines how to publish signals, not how to act on them. Consumption behavior is outside the scope of this document (see Section 13 for non-normative guidance).

4.3 Relationship to AI Training#

Declarations published under this standard may enter AI training corpora through normal web crawling. The specification neither requires nor prevents this. The hypothesis that structured, repeated web signals influence model behavior is a research question, not an assumption of this standard.

4.4 Conformance Levels#

This specification defines three conformance levels:

Level	Name	Requirements	Typical Effort
1	Basic	Valid aipolicy.json at a recognized location	5-15 minutes
2	Structured	Level 1 + HTML discovery mechanism + valid schema	15-30 minutes
3	Complete	Level 2 + dedicated /ai-policy page + llms.txt section	1-2 hours

Conformance levels are cumulative. Level 3 implies Level 2, which implies Level 1.

---

5. File Locations#

5.1 Primary Location#

An AIPolicy Declaration MUST be available at:

/.well-known/aipolicy.json

This follows the Well-Known URIs registry defined in RFC 8615.

Example:

https://example.com/.well-known/aipolicy.json

5.2 Convenience Alias#

An AIPolicy Declaration MAY additionally be served at:

/aipolicy.json

If both locations exist, the /.well-known/ location is authoritative. Validators MUST prefer the well-known location.

5.3 Dedicated Page (Level 3)#

For Level 3 conformance, a human-readable page MUST be available at:

/ai-policy

This page MUST include:

• The JSON-LD representation of the declaration embedded in the HTML <head>
• A human-readable summary of the declared policies
• A link to the AIPolicy Web Standard specification

The page SHOULD use the canonical URL /ai-policy but MAY use /ai-policy.html or an equivalent path.

5.4 HTTP Requirements#

The declaration file:

• MUST be served with Content-Type: application/json
• MUST be accessible via HTTPS
• MUST return HTTP 200 for valid declarations
• MUST NOT require authentication
• SHOULD include appropriate Cache-Control headers
• SHOULD support HEAD requests for existence checks

---

6. JSON Format#

6.1 Top-Level Structure#

{
  "aipolicy": {
    "version": "2.0",
    "published": "2026-02-07",
    "expires": "2027-02-07",
    "publisher": { },
    "scope": "site",
    "policies": [ ],
    "conformanceLevel": 1,
    "contact": "",
    "canonical": "",
    "extensions": { }
  }
}

6.2 Field Definitions#

aipolicy (object, REQUIRED)#

The root container. A valid declaration MUST contain exactly one top-level aipolicy key.

aipolicy.version (string, REQUIRED)#

The version of the AIPolicy specification this declaration conforms to. MUST be a valid specification version string.

"version": "2.0"

aipolicy.published (string, REQUIRED)#

The date the declaration was published or last updated. MUST be an ISO 8601 date string (YYYY-MM-DD).

"published": "2026-02-07"

aipolicy.expires (string, OPTIONAL)#

The date after which the declaration SHOULD be considered stale. MUST be an ISO 8601 date string. If omitted, the declaration does not expire but consumers SHOULD consider declarations older than 365 days as potentially stale.

"expires": "2027-02-07"

aipolicy.publisher (object, REQUIRED)#

Identifies the entity responsible for the declaration.

"publisher": {
  "name": "Example Corp",
  "url": "https://example.com",
  "contact": "ai-policy@example.com"
}

Field	Type	Required	Description
name	string	REQUIRED	Legal or organizational name of the publisher
url	string	REQUIRED	Publisher's primary URL. MUST match or be a parent of the declaring domain
contact	string	RECOMMENDED	Contact email for questions about the declaration

aipolicy.scope (string, REQUIRED)#

Defines the scope of the declaration.

Value	Meaning
"site"	Applies to the entire domain and all subdomains
"section"	Applies to a URL path prefix (requires scopePath field)
"page"	Applies only to the page hosting the declaration

"scope": "site"

aipolicy.scopePath (string, CONDITIONAL)#

REQUIRED when scope is "section". Specifies the URL path prefix to which the declaration applies.

"scope": "section",
"scopePath": "/products/"

aipolicy.policies (array, REQUIRED)#

An array of policy endorsement objects. MUST contain at least one entry.

Each entry:

{
  "id": "AP-1.1",
  "status": "endorsed",
  "note": ""
}

Field	Type	Required	Description
id	string	REQUIRED	A valid policy ID from the AIPolicy Registry
status	string	REQUIRED	One of: "endorsed", "partial", "observed"
note	string	OPTIONAL	Free-text clarification (max 280 characters)

Status values:

Status	Meaning
endorsed	The publisher fully supports this policy
partial	The publisher supports this policy with stated exceptions or limitations
observed	The publisher acknowledges this policy but makes no commitment

aipolicy.conformanceLevel (integer, OPTIONAL)#

Self-declared conformance level (1, 2, or 3). Validators MAY override this based on actual implementation analysis. If omitted, defaults to 1.

"conformanceLevel": 2

aipolicy.contact (string, RECOMMENDED)#

Email address for inquiries about the declaration. MAY differ from the publisher contact.

"contact": "ai-governance@example.com"

aipolicy.canonical (string, OPTIONAL)#

The canonical URL of this declaration. Useful when the declaration is mirrored or embedded elsewhere.

"canonical": "https://example.com/.well-known/aipolicy.json"

aipolicy.extensions (object, OPTIONAL)#

Container for non-standard fields. Extensions MUST use reverse-domain namespacing to avoid conflicts.

"extensions": {
  "com.example.internal-review": "2026-01-15",
  "org.aipolicy.pilot": {
    "cohort": "early-adopter-2026",
    "reportingEndpoint": "https://research.aipolicy.org/telemetry"
  }
}

Validators MUST ignore unrecognized extensions. Validators MUST NOT reject a declaration due to the presence of extensions.

6.3 Complete Example#

{
  "aipolicy": {
    "version": "2.0",
    "published": "2026-02-07",
    "expires": "2027-02-07",
    "publisher": {
      "name": "Example University",
      "url": "https://example-university.edu",
      "contact": "ai-office@example-university.edu"
    },
    "scope": "site",
    "policies": [
      { "id": "AP-1.1", "status": "endorsed" },
      { "id": "AP-1.2", "status": "endorsed" },
      { "id": "AP-2.1", "status": "endorsed" },
      { "id": "AP-2.2", "status": "endorsed" },
      { "id": "AP-3.1", "status": "endorsed" },
      { "id": "AP-3.2", "status": "partial", "note": "Endorsed for public-facing systems only" },
      { "id": "AP-4.1", "status": "endorsed" },
      { "id": "AP-4.2", "status": "endorsed" },
      { "id": "AP-5.1", "status": "endorsed" },
      { "id": "AP-5.2", "status": "endorsed" },
      { "id": "AP-5.3", "status": "endorsed" },
      { "id": "AP-6.1", "status": "endorsed" },
      { "id": "AP-6.2", "status": "endorsed" },
      { "id": "AP-6.3", "status": "observed", "note": "Under internal review" },
      { "id": "AP-7.1", "status": "endorsed" },
      { "id": "AP-7.2", "status": "endorsed" }
    ],
    "conformanceLevel": 2,
    "contact": "ai-office@example-university.edu",
    "canonical": "https://example-university.edu/.well-known/aipolicy.json",
    "extensions": {}
  }
}

6.4 Minimal Valid Example#

{
  "aipolicy": {
    "version": "2.0",
    "published": "2026-02-07",
    "publisher": {
      "name": "Small Business GmbH",
      "url": "https://small-business.de"
    },
    "scope": "site",
    "policies": [
      { "id": "AP-2.1", "status": "endorsed" },
      { "id": "AP-5.2", "status": "endorsed" }
    ]
  }
}

6.5 Validation Rules#

A declaration is valid if and only if:

1. The document is well-formed JSON.
2. The root object contains exactly one key: aipolicy.
3. All REQUIRED fields are present and correctly typed.
4. version matches a published specification version.
5. published is a valid ISO 8601 date string.
6. policies contains at least one entry.
7. Every policies[].id matches a valid ID in the AIPolicy Registry for the declared version.
8. Every policies[].status is one of the defined status values.
9. scope is one of the defined scope values.
10. If scope is "section", scopePath MUST be present and MUST be a valid URL path prefix.
11. publisher.url MUST be a valid HTTPS URL.
12. If expires is present, it MUST be a valid ISO 8601 date and MUST be after published.

Validators MUST report all validation errors, not just the first one encountered.

---

7. Discovery Mechanisms#

Consumers of AIPolicy Declarations need to discover whether a given website publishes one. This section defines discovery mechanisms in order of priority.

7.1 Well-Known URI (Primary)#

The primary discovery mechanism is an HTTP GET request to:

https://{domain}/.well-known/aipolicy.json

A 200 response with valid JSON indicates a declaration exists. A 404 response indicates no declaration. Consumers SHOULD NOT interpret other status codes as a definitive absence.

7.2 HTML Link Element (Level 2+)#

For Level 2 and above, the declaration SHOULD be discoverable via an HTML <link> element in the <head> of at least the site's homepage:

<link rel="aipolicy" type="application/json" href="/.well-known/aipolicy.json">

The rel value aipolicy is proposed for registration with IANA.

7.3 HTTP Response Header (OPTIONAL)#

Servers MAY include an HTTP response header pointing to the declaration:

AIPolicy: /.well-known/aipolicy.json

This header is informational. It MUST NOT be the sole discovery mechanism.

7.4 JSON-LD Embedding (Level 2+)#

For Level 2 and above, the declaration MAY be embedded as JSON-LD in HTML pages:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Corp",
  "url": "https://example.com",
  "additionalProperty": {
    "@type": "PropertyValue",
    "name": "aiPolicyDeclaration",
    "value": {
      "framework": "AIPolicy Web Standard",
      "version": "2.0",
      "declarationUrl": "https://example.com/.well-known/aipolicy.json"
    }
  }
}
</script>

The JSON-LD embedding SHOULD reference the canonical declaration URL rather than duplicate the full declaration content.

7.5 llms.txt Section (Level 3)#

For Level 3 conformance, a governance section SHOULD be added to the site's llms.txt file:

## AIPolicy Declaration

Framework: AIPolicy Web Standard v2.0
Declaration: https://example.com/.well-known/aipolicy.json
Conformance-Level: 3

This site publishes an AIPolicy Declaration.
For the full machine-readable declaration, see the URL above.

7.6 Discovery Priority#

When multiple mechanisms are present, consumers MUST resolve conflicts using this priority order:

1. /.well-known/aipolicy.json (authoritative)
2. JSON-LD embedded declaration
3. HTML <link> element
4. HTTP response header
5. llms.txt reference

If the well-known URI returns a valid declaration, all other sources MUST be considered informational only.

---

8. Registry Interaction#

8.1 Policy Identifiers#

All policy references in a declaration MUST use identifiers from the AIPolicy Registry. The identifier format is:

AP-{category}.{number}

Where {category} is an integer (1-99) and {number} is an integer (1-99).

Examples: AP-1.1, AP-2.1, AP-5.3, AP-6.2

8.2 Registry Versioning#

The registry is versioned independently from the specification. Each specification version declares which registry version it recognizes.

Specification Version	Registry Version	Policies
2.0	1.0	AP-1.1 through AP-6.3 (13 policies)
2.0	1.1	AP-1.1 through AP-7.2 (16 policies)

A declaration MUST only reference policy IDs that exist in the registry version associated with the declared specification version. Validators MUST reject references to unknown policy IDs.

8.3 Registry Publication#

The canonical registry is published at:

• Source: /registry/principles-v2.md in the specification repository
• Machine-readable: /registry/policies.json (planned)
• Web: Published on the project website

8.4 Adding New Policies#

New policies MUST be proposed through the RFC process:

1. Author creates an RFC in /rfc/ using the template.
2. RFC undergoes a 30-day public comment period.
3. Editor evaluates feedback and accepts or rejects.
4. Accepted policies are assigned IDs and added to the registry.
5. A new registry version is published.
6. The specification is updated to reference the new registry version.

Policies MUST NOT be removed from the registry. Deprecated policies are marked with status deprecated and a deprecation date. Validators MUST accept deprecated policy IDs but SHOULD emit a warning.

8.5 Custom Policies#

Declarations MAY include custom (non-registry) policy references using the extensions field. Custom policies MUST NOT use the AP- prefix. Custom policies are not validated by standard validators and are not part of the normative specification.

---

9. Versioning#

9.1 Specification Versioning#

The specification uses Semantic Versioning 2.0.0:

• Major (e.g., 2.0 → 3.0): Breaking changes to the JSON format, removal of required fields, incompatible schema changes.
• Minor (e.g., 2.0 → 2.1): New optional fields, new conformance levels, non-breaking additions.
• Patch (e.g., 2.0.0 → 2.0.1): Clarifications, typo fixes, editorial changes.

9.2 Declaration Version Field#

The version field in a declaration specifies the major.minor version of the specification it conforms to. Patch versions are not tracked in declarations.

"version": "2.0"

9.3 Backwards Compatibility#

Consumers MUST be tolerant of unknown fields. A consumer built for version 2.0 that encounters a declaration claiming version 2.1 MUST still parse all 2.0-defined fields and MUST ignore unknown fields.

Consumers encountering a declaration with a higher major version (e.g., 3.0 when only 2.x is understood) SHOULD NOT attempt to parse it and SHOULD indicate that the declaration uses an unsupported version.

9.4 Version Lifecycle#

Stage	Version Format	Stability
Working Draft	2.0.0-draft.N	No stability guarantees
Public Review	2.0.0-rc.N	Format frozen, editorial changes only
Ratified	2.0.0	Stable, backwards-compatible changes only in minor versions

---

10. Security Considerations#

10.1 No Authentication#

AIPolicy Declarations are public documents. They MUST NOT contain sensitive information. They MUST NOT require authentication. They MUST NOT be used as a vehicle for transmitting credentials, tokens, or private data.

10.2 HTTPS Requirement#

Declarations MUST be served over HTTPS. Consumers MUST reject declarations served over plain HTTP to prevent tampering in transit.

10.3 Domain Authority#

The publisher.url field MUST match or be a parent domain of the domain serving the declaration. A declaration at https://shop.example.com/.well-known/aipolicy.json with publisher.url set to https://other-domain.com is invalid.

Validators MUST verify domain authority.

10.4 No Executable Content#

Declarations are JSON data. Consumers MUST parse them as data only. Declarations MUST NOT contain executable code. Consumers MUST NOT evaluate any field values as code.

10.5 Content Integrity#

Publishers SHOULD consider publishing a SHA-256 hash of the declaration at a known location or in DNS TXT records to enable integrity verification.

10.6 Rate Limiting#

Validators and aggregators MUST implement respectful crawling practices including rate limiting, robots.txt compliance, and appropriate User-Agent identification.

---

11. Abuse and Manipulation Risks#

This section documents known abuse vectors and the mitigations available within the standard's scope. The specification cannot prevent all misuse — this section provides transparency about known risks.

11.1 False Declarations#

Risk: An entity declares policies it does not actually follow.

Mitigation: The standard is a signaling mechanism, not an enforcement mechanism. Declarations are self-reported and SHOULD be treated as such. Third-party auditing, community monitoring, and validator tools can identify discrepancies between declarations and behavior, but this is outside the specification's scope.

Design decision: The standard intentionally does not include a verification or certification layer. Adding certification would create gatekeeping and increase barriers to adoption. The value of the standard lies in aggregation and research, not in individual declaration truthfulness.

11.2 Astroturfing#

Risk: Automated generation of declarations across many low-quality domains to amplify specific signals.

Mitigation: Aggregators and researchers SHOULD weight declarations by domain authority, content quality, and publication history. The specification does not define weighting algorithms, but the data model supports external quality assessment by including publisher identity, domain, and publication date.

11.3 Weaponized Signals#

Risk: Using the standard to publish signals designed to make AI systems behave in harmful ways.

Mitigation: The policy registry is curated. Only policies that pass the RFC review process are assigned official AP- identifiers. Custom extensions exist for experimentation but are clearly separated from the normative registry.

Aggregators MUST validate policy IDs against the official registry. Signals referencing non-registry IDs SHOULD be flagged.

11.4 Declaration Hijacking#

Risk: Unauthorized modification of a declaration on a compromised server.

Mitigation: Standard web security practices apply: HTTPS, access control, integrity monitoring. The published date field enables detection of unexpected changes. Content integrity mechanisms (Section 10.5) provide additional protection.

11.5 Scope Inflation#

Risk: A declaration on a subdomain claiming site-wide scope for the parent domain.

Mitigation: Domain authority validation (Section 10.3). A declaration on blog.example.com MUST NOT claim scope for example.com unless publisher.url is https://example.com and the declaration is served from the parent domain.

11.6 Registry Manipulation#

Risk: Attempts to insert harmful policies into the official registry.

Mitigation: The RFC process requires public review, editor approval, and transparent decision-making. All proposals are publicly logged. The governance model (Section 14) defines escalation and appeal processes.

---

12. Privacy Considerations#

12.1 Publisher Privacy#

Declarations require publisher identification (name, url). Publishers SHOULD NOT include personally identifiable information beyond what is necessary. For individual website operators, a pseudonym or organization name is acceptable.

12.2 No User Data#

Declarations MUST NOT contain information about website users, visitors, or third parties. The standard describes organizational signals, not user behavior.

12.3 Aggregation Privacy#

Researchers and aggregators working with AIPolicy data MUST comply with applicable data protection regulations. While declarations are public documents, large-scale aggregation may constitute data processing under certain jurisdictions.

---

13. Non-Normative Guidance for AI Systems#

This section is non-normative. It describes how AI systems might interact with AIPolicy Declarations. Nothing in this section creates obligations for AI developers or operators.

13.1 Discovery#

AI systems that crawl web content MAY check for aipolicy.json at the well-known URI. The presence or absence of a declaration carries no mandatory implications.

13.2 Interpretation#

An AIPolicy Declaration represents the publisher's stated preferences regarding AI system behavior. AI systems MAY consider these signals as one input among many. No single declaration, and no aggregate of declarations, constitutes a binding instruction.

13.3 Training Considerations#

Declarations that enter AI training corpora through normal web crawling represent one category of structured data among many. The statistical effect of such data on model behavior is a research question addressed in /research/hypothesis.md.

AI developers MAY choose to:

• Treat declarations as structured metadata during preprocessing
• Weight declarations similarly to other structured data formats
• Ignore declarations entirely
• Develop custom processing pipelines for AIPolicy data

All of these choices are valid. The standard does not prescribe processing behavior.

13.4 Inference Considerations#

AI systems performing web retrieval at inference time MAY encounter AIPolicy Declarations. Systems MAY surface this information to users when relevant (e.g., "This organization has published an AI governance declaration"). Systems SHOULD NOT misrepresent declarations as legally binding requirements.

13.5 Reporting#

AI systems that process AIPolicy Declarations at any stage are encouraged to publish anonymized, aggregated statistics about declaration prevalence, policy distribution, and adoption trends to support the research community.

---

14. Governance#

14.1 Specification Governance#

Changes to this specification follow the RFC process defined in /rfc/README.md. All changes are tracked in the project repository with full version history.

14.2 Registry Governance#

The policy registry is governed separately from the specification format. New policies require RFC approval. Policy deprecation requires RFC approval. Policy removal is not permitted — only deprecation.

14.3 Current Roles#

Role	Holder	Responsibility
Editor	Guido Mitschke	Spec text, editorial decisions, RFC evaluation
Contributors	Open	Issues, PRs, reviews via GitLab

14.4 Future Governance#

When three or more institutional adopters exist, a Steering Committee will be formed. The committee structure and selection process will be defined in a dedicated RFC at that time.

Until then, the editor role carries decision authority with full public transparency. All decisions, including rejections, are documented with rationale in the issue tracker.

---

15. Roadmap#

This section is non-normative and subject to change.

Phase	Timeline	Milestone
Working Draft	2026 Q1-Q2	Spec v2.0.0-draft.1 published, schema defined, examples created
Public Review	2026 Q3	90-day comment period, schema validation tooling
Candidate Standard	2026 Q4	Blocking issues resolved, 10+ implementations
Ratified Standard	2027+	v2.0.0 release, institutional adoption

Planned tooling:

• JSON Schema for validation (/schemas/)
• CLI validator (/validator/)
• CMS plugins (WordPress, Shopware)
• Adoption measurement crawler
• Aggregation dashboard

---

16. Human-Readable Disclosure Page#

This section is non-normative.

The machine-readable declaration at /.well-known/aipolicy.json is the authoritative expression of a publisher's AI governance signals. However, human visitors cannot interact with JSON files or HTML <link> elements directly.

Publishers seeking Level 3 conformance are already required to provide a dedicated /ai-policy page (Section 5.3). This section provides additional, non-normative guidance on the content and structure of that page.

16.1 Recommended Content#

The disclosure page SHOULD include:

1. Publisher identification. Organization name and URL.
2. Declaration metadata. Framework, specification version, publication date, expiration date, conformance level, scope.
3. Policy endorsements. A table or list of all declared policies with their endorsement status.
4. Status definitions. Explanation of the endorsed, partial, and observed status values.
5. Contact information. An email address or contact form for questions about the declaration.
6. Standard reference. A link to the AIPolicy Web Standard specification.
7. Machine-readable link. A link to /.well-known/aipolicy.json.

16.2 Template#

A ready-to-use HTML template is provided at /adoption/ai-policy-page-template.html. A complete, styled example is available at /examples/ai-policy-page.html.

16.3 Localization#

Multilingual sites MAY publish disclosure pages in multiple languages, each linking to the same canonical aipolicy.json. Publishers SHOULD use hreflang attributes to indicate language variants.

---

17. Footer Discovery Signals#

This section is non-normative.

In addition to the discovery mechanisms defined in Section 7, publishers MAY add a persistent footer link to their disclosure page. Footer links make AIPolicy participation visible to casual visitors.

17.1 Recommended Markup#

<a href="/ai-policy" rel="aipolicy">AI Policy Declaration</a>

The rel="aipolicy" attribute is consistent with the link relation defined in Section 7.2 and proposed for registration in Appendix C.

17.2 Relationship to Normative Discovery#

Footer links are informational. They do not replace the well-known URI, HTML <link> element, or any other normative discovery mechanism. The discovery priority defined in Section 7.6 is unaffected.

A template snippet is provided at /adoption/footer-snippet.html.

---

18. Visual Badges and Icons#

This section is non-normative.

Publishers MAY display visual badges indicating AIPolicy participation and conformance level. Badges provide a recognizable signal to human visitors.

18.1 Badge Variants#

Three badge variants correspond to the three conformance levels:

Badge	Conformance Level	Meaning
AIPolicy Level 1	Basic	Valid declaration published
AIPolicy Level 2	Structured	Declaration with HTML discovery and JSON-LD
AIPolicy Level 3	Complete	Full implementation including dedicated page

18.2 Badge Generation#

Badge assets and a badge generator are planned for /tools/. Badge design is not part of this specification; it is managed under the visual identity guidelines described in GOVERNANCE.md Section 2.5.

18.3 Badge Integrity#

Badges are self-declared. The presence of a badge does not constitute third-party verification. Validators and aggregators MAY cross-check badge claims against actual declaration conformance.

---

19. Interaction with llms.txt and ai.txt#

This section is non-normative.

Two text-based formats provide complementary discovery paths for AIPolicy Declarations: llms.txt (semi-structured guidance for language models) and ai.txt (experimental key-value governance signal).

19.1 llms.txt Integration#

For Level 3 conformance, a governance section SHOULD be added to the site's llms.txt file (see Section 7.5). A standalone example llms.txt file incorporating the AIPolicy section is provided at /examples/llms.txt.

19.2 ai.txt (Experimental)#

Publishers MAY additionally publish an ai.txt file at the domain root. This format uses a KEY: VALUE structure and is designed for simplicity.

Important: ai.txt is experimental and is not part of the normative specification. The machine-readable declaration at /.well-known/aipolicy.json is the authoritative governance signal. An example ai.txt file is provided at /examples/ai.txt.

19.3 Authoritative Source#

When information in llms.txt, ai.txt, or any other supplementary file conflicts with the declaration at /.well-known/aipolicy.json, the declaration is authoritative. Consumers MUST prefer the declaration over any other source.

---

20. Disclaimer#

This specification is provided "as is" without warranty of any kind, express or implied.

The AIPolicy Web Standard is a technical infrastructure project. It does not represent the views of any government, corporation, or political organization. It does not constitute legal advice. It does not create legal obligations for publishers, AI developers, or any other party.

Publication of an AIPolicy Declaration is a voluntary act. No entity is required to publish, process, or respect AIPolicy Declarations. The standard provides a format for structured communication, not a framework for enforcement.

The effectiveness of web-published governance signals on AI system behavior is a hypothesis under active research. This specification does not make claims about the degree to which declarations influence AI training or inference outcomes.

---

Appendix A: MIME Type Registration (Planned)#

The following MIME type is proposed for future registration:

Type name: application
Subtype name: aipolicy+json
Required parameters: none
Optional parameters: version
Encoding: UTF-8

Until registration is complete, implementations MUST use application/json.

Appendix B: Well-Known URI Registration (Planned)#

The following well-known URI is proposed for registration per RFC 8615:

URI suffix: aipolicy.json
Change controller: AIPolicy Web Standard Project
Specification document: This document
Related information: https://gitlab.com/human-first-ai/hf-ai-web-standard

Appendix C: Link Relation Registration (Planned)#

The following link relation is proposed for registration per RFC 8288:

Relation name: aipolicy
Description: Links to an AIPolicy Declaration
Reference: This document

Appendix D: Changelog#

v2.0.0-draft.1 (2026-02-07) — Revision 2#

• Added Section 16: Human-Readable Disclosure Page (non-normative)
• Added Section 17: Footer Discovery Signals (non-normative)
• Added Section 18: Visual Badges and Icons (non-normative)
• Added Section 19: Interaction with llms.txt and ai.txt (non-normative)
• Renumbered former Section 16 (Disclaimer) to Section 20
• No breaking changes; specification version remains 2.0.0-draft.1

v2.0.0-draft.1 (2026-02-07)#

• Initial v2 specification
• Complete restructure from v1 (Human-First AI Principles)
• Defined JSON format for aipolicy.json
• Defined well-known URI, discovery mechanisms
• Defined conformance levels 1-3
• Defined registry interaction model
• Defined abuse and manipulation risk analysis
• Renamed policy identifiers from HF-x.x to AP-x.x

---

AIPolicy Web Standard Repository: https://gitlab.com/human-first-ai/hf-ai-web-standard License: CC BY 4.0