The Conformance Registry

1. Formal role

The AI Visible Directory is the canonical conformance registry for the AI Discovery Files specification. This means:

1. Public ledger. The Directory is a public record of which publishers have been verified against the specification, what conformance class each publisher achieves, and when each publisher was last re-checked. Anyone can read the Directory; verification records are not paywalled, gated, or available only to subscribers.
2. Single source of truth for verified conformance. A publisher who claims "Directory-verified" conformance has a record in the Directory. A publisher who has no Directory record cannot claim Directory-verified conformance, regardless of their actual technical state.
3. Issuer of conformance certification marks. When certification marks (visual badges) ship, the Directory will be the only authority that issues them. Self-declared publishers MUST NOT display Directory-issued badges. (See the Certification section of the conformance specification for the current state of certification marks.)
4. Operates the reference validator. Verification uses the AI Visibility Checker, which is the reference implementation of the specification's validator-output contract. The Directory does not run a different or competing validator.
5. Public re-check cadence. The Directory commits to a documented re-check cadence (see section 5). A publisher's listing reflects their most recent verification, not the state of the site at any moment.

This formal role is established here in the specification rather than implied by the Directory's operation. The Directory has played this role in practice since publication of the specification; this page makes the role explicit so external implementers, tooling authors, and academic citations have a single document to point at.

2. Operator

The AI Visible Directory is operated by AI Visibility (a 365i product). Operational responsibility includes:

• Running the directory infrastructure (hosting, database, public web surface)
• Operating the reference validator (the AI Visibility Checker) that produces verification reports
• Applying the verification process (see section 4) consistently across all submissions
• Maintaining the re-check cadence (see section 5)
• Publishing the editorial process under which Directory-listing decisions are made (see governance)
• Responding to publisher disputes (see section 7)

The Directory's operational role and the specification's editorial role are deliberately co-located at AI Visibility while the specification is in its early years. As the specification matures, this MAY be revisited (see the roadmap entry on standards-body engagement). Any change to the Directory's operator would be a substantive specification change handled under the governance process.

3. What the registry records

For each publisher with a Directory listing, the registry records:

Publisher identity

The publisher's canonical name and primary host (as declared in their identity.json, or as supplied by the publisher at submission time and reconciled against their files).

Submission metadata

The submission date, the submitter's verified contact (typically email), and the publisher's category from the directory's category taxonomy.

Conformance class achieved

The highest class the publisher's files satisfy at verification time: Essential, Recommended, or Complete. If the publisher does not satisfy any class, the record exists but no class is awarded.

Per-file scores

For each of the 10 AI Discovery Files, a binary present/absent flag plus a validity assessment from the reference validator. The full validator output (conforming to the validator-output schema) is retained for the Directory's own audit purposes.

Last verification timestamp

When the most recent automated or on-demand verification ran.

Change history

The sequence of verification events for the publisher: each timestamp, the resulting class, and a delta summary (e.g. "Recommended → Essential after identity.json removed"). Change history is what makes the Directory a public ledger rather than a snapshot.

Status flags

Whether the publisher is currently listed as active, paused (publisher requested), under review (disputed), or removed (see section 8).

The Directory does not record analytics about AI traffic, prompt-test outcomes, search rankings, or any other AI-visibility output measurement. The Directory's scope is the same as the specification's scope: inputs to AI systems, not outputs from them.

4. Verification process

When a publisher submits their site to the Directory:

1. Submission. The publisher supplies their host (e.g. https://example.com), their primary contact email, and a category from the directory's taxonomy. They confirm they are authorised to act on behalf of the publisher.
2. Domain control verification. Before the listing is published, the publisher demonstrates control of the host. The default method is a verification token placed at /.well-known/ai-visibility-verify.txt; an alternative DNS TXT method is also supported. This step exists so a third party cannot list a publisher they don't represent.
3. Automated validation. The Directory runs the reference validator (the AI Visibility Checker) against the publisher's host. The validator follows the seven-stage processing model and produces output conforming to the validator-output schema.
4. Conformance class assignment. Based on the validator output, the Directory assigns the publisher the highest conformance class their files satisfy: Essential, Recommended, or Complete. If no class is satisfied, the listing is created but no class is awarded.
5. Listing publication. The verified record is published to the Directory's public surface. The publisher receives a confirmation email pointing at their listing.

Every step is documented in the verification record. A publisher can request a copy of the validator output that produced their verification result via support.

5. Re-check cadence

The Directory commits to two cadences:

• Automated quarterly re-check. Every listed publisher is re-validated on a quarterly schedule. The schedule is staggered to spread load; a publisher's exact re-check date is not fixed but falls within the quarter. The most recent verification timestamp on a listing tells the reader when the displayed class was last confirmed.
• On-demand re-check. A publisher who has just deployed changes can request an on-demand re-check from their account dashboard at any time. On-demand re-checks are rate-limited (currently one per 24 hours per host) to prevent abuse. The next quarterly re-check still runs on schedule even if an on-demand check has been performed.

When a re-check finds that a publisher's files no longer satisfy their listed class:

1. The publisher is notified by email with the validator's findings and the date the next quarterly re-check is scheduled.
2. The listing is downgraded to whatever class the publisher's files currently satisfy (which may be a lower class or "no class").
3. The change history records the downgrade event with timestamp, prior class, and new class.
4. The publisher may at any time fix the issue and request an on-demand re-check to restore the prior class.

Downgrades are not penalties; they are an accurate record of what the validator found at the time of the re-check. The change history shows the trajectory.

6. Self-declaration vs Directory verification

The specification recognises two parallel forms of conformance claim, documented in detail on the conformance specification:

Both forms are legitimate. Self-declaration costs the publisher nothing and is available immediately. Directory verification adds independent confirmation, a public record, automated re-checks, and (forthcoming) certification badges. Publishers in regulated industries, in B2B contexts where buyers verify supplier claims, or those who plan to display badges on marketing surfaces typically benefit from Directory verification. Publishers who simply want their files to work for AI consumers can self-declare and skip the Directory entirely.

7. Disputes and corrections

A publisher who disagrees with their Directory verification result may raise a dispute. Common disputes and the process:

"The validator gave me the wrong class"

The publisher provides the validator output ID (or asks the Directory to re-run the validator with verbose output) and a description of why they believe the result is wrong. The Directory re-runs the validator under the dispute and either confirms or corrects the listing. If the validator was wrong, the underlying bug is filed against the reference implementation.

"My listing shows information I didn't approve"

The Directory pulls only what the publisher's own files declare and what the publisher supplied at submission. If a value the publisher considers private has been listed, the publisher reviews their own files (the source of truth) and confirms the Directory's listing matches them. If the Directory is showing something not in the publisher's files or submission, the Directory corrects the listing.

"Someone else listed my site"

The domain control verification step in section 4 is intended to prevent this. If it has failed somehow, the legitimate publisher contacts support with evidence of control and the Directory transfers or removes the listing.

"I have been removed and disagree"

Removals (section 8) are recorded with a reason. The publisher can dispute the reason. If the Directory accepts the dispute, the listing is reinstated and the change history records both events.

Disputes are tracked publicly enough that a pattern of unfair Directory decisions would be observable; the editorial process under which decisions are made is documented on the governance page.

8. Removal from the registry

A publisher's listing MAY be removed for the following reasons:

• Publisher request. The publisher requests removal. Their record is deleted from the public Directory; the change history shows the removal date but no further identifying information.
• Loss of host control. The publisher fails repeated domain-control re-verifications (the Directory periodically re-checks that the verification token / DNS record is still present). After a documented grace period and notifications, the listing is removed because the Directory can no longer confirm the publisher operates the host.
• Site no longer operational. The publisher's host returns 5xx, DNS failure, or no longer responds across multiple re-checks over multiple quarters. The listing is removed as obsolete.
• Material misrepresentation. If the Directory determines that a publisher's listing is being used to misrepresent identity (e.g. a phishing operation listing itself with stolen branding), the listing is removed and a brief public note records that the listing was removed for misrepresentation. This is rare and is governed under the editorial process.

Removal is reversible only by the publisher providing the relevant evidence (re-establishing host control, providing accurate identity, etc.) and re-submitting under the verification process.

9. Data protection

The Directory operates under UK GDPR. The site's privacy policy is the authoritative source for what personal data is processed, why, and how long it is retained. Three points specifically about the conformance registry:

• Submitter contact email. The submission contact is processed under legitimate interest for the purpose of running the verification process and notifying the publisher of re-check outcomes. It is not displayed publicly unless the publisher also publishes it in their own files.
• Public listing data. Identity information shown on a publisher's Directory listing is derived from the publisher's own AI Discovery Files (especially identity.json), which the publisher already publishes to the open web. The Directory does not introduce private data into the public record.
• Right to erasure. Publishers may request removal at any time (see section 8). Erasure removes the public listing and the contact data; verification logs may be retained in operational records for a limited period for audit purposes per the privacy policy.

10. The registry role vs other implementations

The implementations page lists five current conformant implementations. The AI Visible Directory's role as registry is distinct from the others:

A third party MAY operate their own validator (and the specification welcomes that; see third-party implementations). However, only the Directory can issue Directory-verified conformance status under this specification. A third party could operate a competing verification surface, but its claims would not be "Directory-verified" in the specification's sense.

References

• Conformance specification: the three conformance classes, publisher conformance criteria, validator conformance criteria, self-declaration rules.
• Governance and Editorial Process: how editorial and Directory-listing decisions are made and recorded.
• Processing Model: the algorithm the reference validator follows when verifying a publisher.
• Validator-output JSON Schema: the contract the reference validator's output conforms to.
• Implementations: the AI Visible Directory listed as a Registry + Validator implementation.
• Privacy Policy: authoritative source for personal-data processing in the Directory.
• Roadmap: Directory formal role: planning context for this page.
• Roadmap: conformance certification mark: the forthcoming visual badges issued exclusively by the Directory.