Discovery

This is informative setup guidance. It adds no wire requirement, policy field or new robots directive. The policy core and specification’s trust and discovery rules remain the authoritative contracts.

Publish the actual policy first

Publish the current native policy at your canonical HTTPS origin’s /odexa.json, for example https://example.com/odexa.json, with HTTP 200 and Content-Type: application/json. The endpoint is credential-free, same-origin and accepts no redirect under this draft. Its declared origin, scopes, terms and validity must describe the website where it is served. A link to protocol documentation alone is not that website’s policy.

An originator can publish a static policy without a Foundation account, provider or agreement service. Select static permissions deliberately using the policy core. A require_agreement rule needs an implemented service before a new agreement can be made; discovering the policy does not itself create one.

Optional robots.txt comment

Preserve the site’s existing User-agent, Allow, Disallow, Sitemap and other crawl configuration. Append an informational comment such as this, replacing example.com with the actual policy origin:

# Odexa usage policy: https://example.com/odexa.json

If the /llms.txt file below has also been published, a second comment can point to it:

# Guidance for agents: https://example.com/llms.txt

These are comments, not standard robot instructions. Ordinary robots parsers ignore them; agents that read the text may discover the links. Do not replace existing crawl restrictions with Allow: / to add Odexa, and do not treat a policy link as permission to ignore a crawl restriction. This guide does not define an Odexa: robots directive. Comments and extension-record handling are described in RFC 9309 sections 2.2.3–2.2.4; that protocol expressly separates crawl rules from access authorization.

Optional llms.txt

Publish a concise Markdown file at /llms.txt. The following example assumes the website’s policy is already available at https://example.com/odexa.json. Replace the title, description and policy origin with the site’s actual values; retain only links that exist.

# Example website

> Information and usage-policy links for agents visiting this website.

## Usage policy

- [This website's Odexa policy](https://example.com/odexa.json): Current machine-readable scopes, terms and obligations.

## Documentation

- [Odexa documentation](https://odexa.io/): Protocol guidance and implementation documentation.

Additional links can point to the website’s own published documentation or agent-friendly content. Keep policy rules in /odexa.json so this summary does not become a conflicting second policy. The llms.txt proposal provides guidance and links for agents; it does not authenticate a party, appoint a provider or record assent.

Advertise only implemented services

For a static policy deployment, leave /odexa-service.json out of these signposts. Add a link only after the corresponding service is implemented and its origin-owned authority document is published at that exact same-origin path. Merely naming a provider in robots comments, llms.txt or a documentation page does not delegate authority. Clients still obtain and validate the authoritative policy and service documents through the existing credential-free discovery and scoped-authority contracts.

The optional HTTP policy Link relation already described in the policy core can supplement these signposts. None of the hints overrides crawl rules, expands a policy’s scope, accepts an agreement, creates a payment obligation or guarantees that a bot will read or comply with it. The Foundation and documentation are non-commercial and implementation-neutral; the same guidance applies to direct operation and any explicitly appointed provider.

The current quickstart covers running the reference service separately. Its commands do not generate or deploy these robots and llms.txt additions.