LLMS Amplifier Artifact Schema — v1

This page is the schema profile for the AI-readable files published by the LLMS Amplifier WordPress plugin. Sites running the plugin reference this URL in the Link: <…>; rel="profile" HTTP header on their artifact files and in the generator.schema field of their llms-index.json.

Version policy: the v1 schema is stable. Changes are strictly additive — new optional fields and sections may appear, but existing fields never change meaning, type, or disappear. A breaking revision would be published at a new URL (…/schema/v2) and announced in the plugin changelog.

The artifact family

A site running LLMS Amplifier publishes some or all of these files at its public root (each also available under /.well-known/ where noted):

Strict and legacy manifests

The strict profile introduced in v2.8.5 renders llms.txt as a structured Markdown manifest with one title, an optional summary blockquote, and linked resource sections. It supports root and configured subdirectory manifests. The legacy profile remains available. The full readable file is rendered independently; strict selection of a concise manifest does not require truncating the owner’s complete context or evidence.

Generated companion resources are distinct from uploaded supplemental files. They do not depend on supplemental uploads, JSON indexing, or publication of llms-full.txt. Each companion appears only when its source and publication conditions allow it. Public availability and URL collisions are checked; on headless sites, the matching bytes must be deployed before a strict manifest can safely refer to them. When JSON indexing is enabled, available companions also appear in files.resources with their paths, public URLs, media types, sizes, and SHA-256 hashes.

Optional url values give explicit public resource URLs; path identifies the public path, while also_at identifies an additional location when supplied. Do not assume that companions or page Markdown inherit the /.well-known/ aliases of the three root aggregate files.

llms-index.json — structure

The index is a single JSON object. Two sections are always present: generator and files. Every other section is optional and appears only when the site has that data.

generator (required)

"generator": {
  "plugin": "LLMS Amplifier",
  "version": "2.8.6",
  "schema": "https://brianwinum.com/llms-amplifier/schema/v1",
  "generated_at": "2026-10-29T00:00:00+00:00"
}

files (required)

An inventory of published artifact resources, with integrity fingerprints where available. This is not an exhaustive sitemap of every page representation, and the index does not list itself with a self-referential hash. Resource entries vary by enabled modules, available content, scope, and publication state:

"files": {
  "manifest_version": "1.0",
  "resources": [
    {
      "id": "llms-txt",
      "path": "/llms.txt",
      "also_at": "/.well-known/llms.txt",
      "type": "text/vnd.llms-amplifier.manifest+markdown",
      "rel": "alternate contents",
      "description": "Content index in Markdown",
      "size_bytes": 25029,
      "sha256": "…hex…",
      "last_modified": "2026-08-24T00:00:00+00:00"
    }
  ]
}

Supplemental-document entries additionally carry a category field (e.g. faq-paa, reviews, brand, custom).

Optional sections

Consumers should ignore unknown fields and sections — additive growth is the compatibility contract.

Publication identity and integrity

Modern publications can include a top-level publication object. Its publication_id identifies a distinct published artifact set; published_at is the publication timestamp, and content_digest is the generator’s aggregate content digest. A regeneration that leaves the publication unchanged preserves its identity. These fields describe the publication, rather than the time of every generation attempt.

{
  "publication": {
    "publication_id": "example-publication-id",
    "published_at": "2026-10-29T00:00:00+00:00",
    "content_digest": "<64 lowercase hexadecimal characters>"
  }
}

A publication ID is useful for change detection and deduplication; it is not proof that every fetched file belongs to that publication. For each resource carrying size_bytes and sha256, compare the downloaded body’s byte count and SHA-256 with the advertised values. Hash the unmodified body bytes after HTTP content decoding, before text normalization or Markdown parsing. The built-in text resources describe the bytes served publicly, which may differ from their on-disk encoding.

If a size, hash, or publication identity disagrees, retry the index and affected resource with cache revalidation or bypass. If the mismatch persists, reject that combination rather than treating it as a consistent publication. Missing fingerprints are not evidence of verified integrity. On a headless installation, verify the deployed public files, not only the WordPress origin.

When the Knowledge Bundle is published, files.resources can also contain its /okf/manifest.json resource. The bundle manifest records manifest_version, publication_id, published_at, content_digest, coverage, and a files inventory. Bundle coverage can be bounded by the site’s configured limits; presence of a bundle does not promise that every eligible page is included.

Content signals — example

{
  "content_signals": {
    "policy": "https://contentsignals.org/",
    "signals": {
      "search": "yes",
      "ai-input": "yes",
      "ai-train": "no"
    }
  }
}

HTTP headers on artifact responses

The built-in aggregate artifact routes emit machine-readable Link headers as applicable. Headers vary by resource; the following list is not a promise that every companion or page Markdown response carries every relation:

• Link: <…/.well-known/llms-index.json>; rel="canonical" — the canonical index location
• Link: <site public root>; rel="about" — the site the artifacts describe (the public front end, which differs from the WordPress origin on headless installs)
• Link: <https://brianwinum.com/llms-amplifier/schema/v1>; rel="profile" — this page
• Link: <https://creativecommons.org/licenses/by/4.0/>; rel="license" — only when the site opted into CC attribution

The built-in artifact handlers use X-Content-Type-Options: nosniff and avoid setting cookies. Sites choose whether artifacts are indexable; the default is X-Robots-Tag: noindex. Companion Markdown responses can carry rel="describedby" links to their covering llms.txt. Cache policies and additional headers depend on the route and enabled features; a proxy or CDN can alter the final response.

Markdown Pages and optional same-URL negotiation

The Markdown Pages module publishes dedicated .md URLs and their discovery links for eligible content, including /index.md for an eligible static homepage. These addresses return Markdown independently of the request’s Accept header and do not require Vary: Accept. Distinct URLs are the recommended mode behind full-page caches and CDNs.

Same-URL negotiation is a separate advanced setting and is off by default. When enabled, an eligible ordinary page request with an explicit Accept: text/markdown token can receive Markdown instead of HTML. The plugin sends Vary: Accept and private/no-store cache controls on both representations, together with supported cache-bypass signals. A cache or CDN that ignores these controls can still serve the wrong representation; purge all affected cache layers and verify public responses before relying on negotiation. If the checks fail, leave same-URL negotiation off and use dedicated Markdown Pages.

Exclusion rules, access restrictions, route ownership, and rendering availability still apply. Enabling either feature does not make every page eligible. On headless sites, publishing routes at the public front end requires the corresponding deployment support.

Separate Abilities import contract

This page describes published artifacts. It is not the JSON input schema for Abilities Connectivity, MCP, or the dashboard’s Validate Envelope and Import Envelope tools. Obtain that schema from the target installation with llms-amplifier/get-content-schema or Discovery → Abilities Connectivity → View Content Schema; the target’s live schema is authoritative.

The import contract is currently version 2, introduced in v2.8.5, with manifest_content for structured manifest selections. Original v1 categories remain accepted; manifest_content requires explicit contract_version: 2. An import contract version does not change this artifact profile’s /schema/v1 URL.

Import envelopes reject unknown keys and apply category-level semantics: present replaces the whole category, absent preserves it, and explicit null clears it. In contrast, consumers of published artifact JSON should ignore unknown additive fields. MCP content updates require the fresh read’s snapshot_token as if_match. Validation does not write content. Do not use an example from this artifact page as an import envelope.

Schema v1 · Reviewed against LLMS Amplifier v2.8.6 on October 29, 2026 · Maintained by Brian Winum · Plugin changelog.