Digital Karma Federation Protocol v8.0

v8.0 is not a plugin, a closed platform, or a hosted service. It is a repeatable file and discovery standard. A site publishes six required federation artifacts, keeps /robots.txt and /sitemap.xml at the root, uses Schema.org on primary pages, and exposes enough structured context for AI systems to understand what the site is, what it publishes, and how it relates to other trusted sites. What changed in v8.0 is not this shape -- it's how reliably that shape gets produced and kept current across many sites.

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. manifest.json, health.json, catalog.json, karma.json, and federation.json tell the agent what the site is, whether it is healthy, what data it publishes, and how it connects to peers -- and now carry a protocol_version plus a real lifecycle instead of an implicit assumption of currency.
3. Schema and entity files reduce guesswork. Primary pages and optional /entities/ files make the business, brand, services, and website relationships explicit.
4. Federation relationships add context. A site can point to related trusted properties, document bidirectional relationships, and publish deeper mapping files in /federation/ -- resolved from real constellation membership where a canonical source exists, not hand-typed.
5. Transparent scoring adds confidence. The Digital Karma model gives AI systems a public way to evaluate quality, freshness, completeness, and trust signals instead of relying on blind inference.

• Cleaner AI discovery: your site explains itself directly instead of hoping a model interprets scattered page copy correctly.
• Better implementation handoffs: developers and coding agents can work from a known standard instead of inventing a different layout every time.
• Portable governance: the same v8.0 rules can be applied across one site or an entire portfolio, from a shared reference template.
• Stronger trust signals: root discovery files, schema, datasets, and federation relationships create a more complete machine-readable footprint.
• Less maintenance drift: a shared generation engine and a single canonical source for peer relationships close the exact gap that caused most federation bugs before v8.0.

AI discovery exposure improves when a site becomes easier to crawl, classify, and trust. v8.0 helps by giving AI systems a fast path to the most useful context, and by making that context more likely to actually be accurate. Instead of parsing an entire site from scratch, agents can read the discovery files first, confirm the version and lifecycle, inspect the sitemap, traverse the knowledge base, and follow federation relationships to understand where the site fits.

• Manifest plus LLM summary: define the site in plain language and structured language (one document now, not two that can drift apart -- llm.json is retired).
• Root discovery files: keep crawl entry points in the canonical locations agents already check.
• Catalog plus datasets: expose structured assets that can be cited, indexed, and reused.
• Federation map: shows how authority and topic relationships extend beyond one isolated domain, resolved from real membership.
• Consistent version and lifecycle signals: help agents recognize the site as a maintained implementation rather than a partial experiment, and know when a field is genuinely deprecated versus just old.

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 is retired in favor of the fields already in manifest.json; 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 deployment repository for the installer workflow. If you already have a live site and want proof of what is missing, run the Federation Audit first.