Digital Karma Federation Protocol v8.2

v8.1 could pass every endpoint check while the site's HTML pages exposed no Dataset schema at all.

v8.2 closes that gap. Every canonical URL in sitemap.xml must render one stable DataCatalog, every Dataset declared in /ai/catalog.json, and a clear relationship from the page's primary entity to the relevant Dataset layer.

The seventh required artifact, /ai/rendered-schema.json, is generated only after the validator crawls the complete sitemap. It records the current sitemap and catalog hashes, page counts, expected Dataset count, coverage, failures, and validator identity. A stale or partial receipt does not pass.

v8.1, published 2026-09-21, is a small revision of v8.0 and fully compatible with it. v8.0 retired llm.json because the manifest already carried the same identity fields. AI crawlers kept requesting /llm.json anyway, and a file that is requested but never refreshed goes stale in plain sight.

So llm.json is back as a standard endpoint, with one rule that keeps v8.0's intent: it is never kept by hand. /llm.json and its mirror /ai/llm.json are generated from the site's own /ai/manifest.json, /ai/catalog.json and /ai/health.json in the same build, and the manifest lists both under endpoints.

Two smaller fixes shipped with it. A site's related_sites now names every member of its constellation, not a hand-picked few, and each sibling is linked at the origin that site declares for itself, so sites that serve their bare domain are no longer linked through a redirect. A site still on v8.0 remains a valid member that has not taken the upgrade.

On 2026-09-22 the same builder started writing /llms.txt as well, the markdown convention from llmstxt.org, under the same rules. What the crawler logs showed, and how both files are generated.

v8.0 was the architectural revision. It replaced per-site reinvention with a shared generation model, lifecycle metadata, constellation-sourced relationships, and safer root discovery rules. v8.1 restored generated LLM files. v8.2 keeps both advances and adds proof at the rendered page layer.

1. Discovery starts at predictable URLs. Agents can begin with /ai/manifest.json, /llm.txt, /robots.txt, and the root /sitemap.xml.
2. The site describes itself in structured files. The manifest, health, catalog, karma, and federation files explain identity, freshness, datasets, trust, and peer relationships.
3. The same Dataset layer appears in HTML. Every canonical page renders the DataCatalog and complete catalog Dataset graph with stable identifiers.
4. The full crawl proves the result. /ai/rendered-schema.json records whether every sitemap page passed against the current sitemap and catalog.
5. Transparent scoring adds context. The Digital Karma model gives AI systems a public way to review quality, freshness, completeness, and trust signals without relying on blind inference.

• Cleaner AI discovery: the site explains itself directly instead of hoping an AI system interprets scattered page copy correctly.
• Proof on the pages that get fetched: the Dataset layer is present in rendered HTML, not parked in a separate file and assumed to be enough.
• Better implementation handoffs: developers and coding agents can work from one known standard instead of inventing a different layout every time.
• Less maintenance drift: the receipt becomes stale when the sitemap or catalog changes, which forces the next audit to check the new public state.

AI discovery exposure improves when the useful structure is easy to find and easy to verify. v8.2 gives AI systems a fast route through the manifest, sitemap, catalog, rendered Dataset graph, LLM summaries, and federation relationships.

The important change is proof. The site no longer asks an auditor to trust that a separate catalog describes the pages correctly. The complete sitemap crawl checks the HTML itself and publishes the receipt.

v8.0 is a real architectural change, unlike a 2026-05-11 proposal to simply rename Federation concepts to Constellation language, which was considered and dropped without ever being implemented anywhere in the portfolio. The real changes: every generated endpoint now carries protocol_version plus supported_since/deprecated_after/removed_after; llm.json was retired in favor of the fields already in manifest.json (v8.1 restored it as a generated file); related_sites should be resolved from a canonical constellation source rather than hand-typed (the single most common source of drift found in this revision); and where a site has a real generator, robots.txt should be produced from declared endpoint visibility rather than hand-audited.

If you are trying to implement the standard, start with the Building Federation Endpoints guide, then use the download page for the installer workflow. If you already have a live site and want proof of what is missing, run the website audit first.