LLMO

LLMO Specification v0.1

The v0.1 specification for llmo.json.

Status: Draft Editor: Nic Chavez (llmo.org) Published: 2026-04-17 Canonical URL: https://llmo.org/spec/v0.1

1. Purpose and Scope

1.1 What llmo.json is

llmo.json is the sovereign channel an organization publishes to the machines that now mediate its reputation. It is a signed, time-bounded, machine-readable artifact served at a well-known location on the organization’s primary domain. It carries the organization’s own assertions about itself (identity, canonical surfaces, disavowals, supersessions) in a form that large language models, retrieval systems, and autonomous agents can consume directly and verify cryptographically.

This is a protocol for machine-facing identity. It governs the small, high-consequence surface where an organization speaks to automated systems in the first person: these URLs are us, this person speaks for us, this attribution is false, this prior statement is superseded. Declarative, not descriptive. Operational, not cataloging. Signable, not merely structured.

The file answers a narrow question with broad consequences: when an automated system needs to know something load-bearing about this organization, what does the organization itself say is true, right now, in a form the system can verify? Operational truth, in this spec, means facts that change over time and carry consequence when wrong: which URLs are canonical, who speaks for the organization, which products and pricing pages are current, which public claims the organization repudiates, which prior statements are superseded by newer ones.

1.2 What llmo.json is not

It is not a descriptive catalog of the organization in the style of schema.org. It is not a media-provenance format in the style of C2PA. It is not a capability manifest in the style of MCP or agent.json. It is not a security disclosure channel in the style of security.txt. It borrows discovery conventions from some of these and defers outright to others (see §6).

Specifically, llmo.json does not:

1.3 The problem LLMO solves

Organizations have no sovereign channel to the machines that now mediate their reputation.

When a large language model answers a question about an organization (what it does, what it charges, who speaks for it, what it has said and unsaid), the answer is synthesized from text the organization did not write, about the organization, filtered through ranking and retrieval systems the organization does not control. The organization’s ability to correct, supersede, or repudiate any piece of that synthesis is effectively zero. There is no primary source the model knows to consult and trust above its aggregated priors.

Existing standards address adjacent problems and leave this one untouched:

None of these give an organization a single verifiable place to say: these are the URLs that are us. This is the price. This person does not speak for us. The press release from March is superseded by the one from April. The domain that looks like us is not us.

That is the gap llmo.json fills, and the reason it matters more each quarter. The machines consuming the organization’s reputation are no longer an auxiliary audience. For many organizations, they are already the primary one.

1.4 Non-goals for v0.1

2. Discovery

2.1 Location

The primary location is:

https://{domain}/.well-known/llmo.json

The .well-known prefix follows RFC 8615. A conforming organization MUST serve the file at this path on its primary domain.

Organizations MAY additionally serve the file at https://{domain}/llmo.json as a convenience, but consumers MUST check .well-known first and MUST prefer it when both exist. Rejected alternative: allowing arbitrary locations declared via <link rel="llmo"> tags. This was rejected because it re-introduces the discovery ambiguity that the well-known convention exists to eliminate, and because LLMO files need to be reachable without HTML parsing.

2.2 Content type

The file MUST be served with:

Content-Type: application/llmo+json

Consumers MUST also accept application/json as a fallback, since many hosting providers restrict custom MIME types. When served as application/json, the consumer determines conformance by parsing the document and checking for the required top-level fields (§3.1).

2.3 HTTP behavior

2.4 Caching and freshness

The file is expected to be consulted frequently and to change occasionally. The spec defines two layers of freshness:

HTTP-layer caching. The server SHOULD set Cache-Control: max-age=3600 or similar. Consumers SHOULD respect HTTP cache headers but MUST NOT cache for longer than 24 hours regardless of server directives.

Document-layer freshness. The llmo.json document itself carries a valid_from and valid_until field (§3.3). Consumers MUST treat a document as stale once valid_until has passed, even if HTTP cache headers say otherwise. A stale document SHOULD NOT be used to answer high-stakes queries; consumers SHOULD refetch.

2.5 Discovery failure

If .well-known/llmo.json returns 404, 403, or any non-2xx status, the consumer MUST treat the organization as having no LLMO record. Consumers MUST NOT fall back to heuristic discovery (e.g., guessing at /llmo.json, /about/llmo.json, etc.). Silent failure is preferable to false positives.

3. Core Schema

The file is a single JSON object. All fields use snake_case. Unknown fields MUST be ignored by consumers (forward-compatibility).

3.1 Required top-level fields

Every conforming llmo.json MUST contain:

Field Type Description
llmo_version string Spec version this document conforms to. For this spec: "0.1".
entity object Identity of the publishing organization (§3.2).
claims array Ordered array of claim objects (§3.4). May be empty but must be present.
valid_from string RFC 3339 timestamp. The document is authoritative from this moment.
valid_until string RFC 3339 timestamp. The document is stale after this moment.
document_id string Stable opaque identifier for this document, unique within the entity. Used for supersession.

3.2 Entity identity

The entity object identifies who is publishing the file.

{
  "entity": {
    "name": "Serval, Inc.",
    "primary_domain": "serval.com",
    "aliases": ["serval.io", "getserval.com"],
    "legal_identifiers": {
      "jurisdiction": "US-DE",
      "registration_number": "7891234"
    },
    "external_ids": {
      "wikidata": "Q123456789",
      "duns": "123456789"
    }
  }
}

v0.1 does not mandate any single external identifier scheme. Rejected alternative: requiring a Wikidata QID or a DID. Requiring Wikidata would disadvantage new or private organizations; requiring DIDs would impose unfamiliar infrastructure. external_ids stays optional and open.

3.3 Freshness and supersession

Every document is time-bounded and may explicitly supersede a prior document.

{
  "valid_from": "2026-04-17T00:00:00Z",
  "valid_until": "2026-07-17T00:00:00Z",
  "document_id": "2026-04-q2-ops",
  "supersedes": ["2026-01-q1-ops"]
}

Recommended cadence: republish quarterly or on material change, whichever comes first. An organization that has not touched its llmo.json in over a year is a signal of abandonment to consumers.

3.4 Claims

The claims array is the substance of the document. Each claim is an object with at minimum a type and a statement.

{
  "claims": [
    {
      "type": "canonical_urls",
      "statement": { ... },
      "asserted_at": "2026-04-17T00:00:00Z",
      "confidence": "authoritative"
    }
  ]
}

Common claim-level fields:

Field Type Required Description
type string yes One of the core claim types (§3.5) or a namespaced extension type (§3.6).
statement object yes Type-specific payload.
asserted_at string no RFC 3339 timestamp of when this specific claim was asserted. Defaults to document valid_from.
confidence string no One of authoritative (default), advisory, or provisional. See §3.7.
claim_id string no Stable identifier for referencing this claim from elsewhere (e.g., from a supersedes within another claim).
signature object no Per-claim JWS signature, when claim-level signing is used (§4).

3.5 Core claim types

These types MUST be understood by any conforming consumer. Extension types (§3.6) MAY be ignored.

identity

Asserts core identity facts about the entity beyond what’s in the entity block. Useful for distinguishing similarly-named organizations.

{
  "type": "identity",
  "statement": {
    "founded": "2019-06",
    "headquarters": "San Francisco, CA, US",
    "description": "Enterprise observability for AI workloads."
  }
}

canonical_urls

The single most important claim type. Asserts which URLs are authoritative for which purposes. An LLM reasoning about an entity SHOULD prefer these URLs over anything it has scraped.

{
  "type": "canonical_urls",
  "statement": {
    "homepage": "https://serval.com",
    "docs": "https://docs.serval.com",
    "api": "https://api.serval.com",
    "status": "https://status.serval.com",
    "support": "https://serval.com/support",
    "pricing": "https://serval.com/pricing",
    "security": "https://serval.com/security",
    "agent_manifest": "https://serval.com/.well-known/agent.json",
    "mcp_manifest": "https://serval.com/.well-known/mcp.json"
  }
}

All keys are optional; orgs declare only the URLs they operate. Consumers MUST treat URLs declared here as preferred over URLs discovered elsewhere. Note that LLMO vouches for the pointer, not the content of the referenced artifact: if agent_manifest points at an agent.json, LLMO asserts “this is our agent.json,” not “this agent.json is itself well-formed or safe.”

official_channels

Asserts which social accounts, email domains, and messaging presences are operated by the entity. Directly aids impersonation detection.

{
  "type": "official_channels",
  "statement": {
    "email_domains": ["serval.com", "serval.io"],
    "social": {
      "x": "@serval",
      "linkedin": "company/serval-inc",
      "github": "serval"
    },
    "community": {
      "discord": "https://discord.gg/serval-official"
    }
  }
}

product_facts

Asserts currently-true facts about the organization’s products. Intentionally narrow; full product catalogs belong elsewhere.

{
  "type": "product_facts",
  "statement": {
    "products": [
      {
        "name": "Serval Observe",
        "url": "https://serval.com/observe",
        "status": "generally_available",
        "current_version": "4.2"
      }
    ]
  }
}

personnel

Asserts which individuals hold public-facing roles and are authorized to speak for the organization in those roles. Narrow and optional; most orgs will not use this.

{
  "type": "personnel",
  "statement": {
    "spokespeople": [
      {
        "role": "ceo",
        "name": "Dana Okafor",
        "verification": "https://serval.com/team#dana"
      }
    ]
  }
}

disavowal

Explicitly repudiates claims, attributions, or associations the organization considers false or no longer accurate. This is a first-class claim because no existing standard carries this semantic.

{
  "type": "disavowal",
  "statement": {
    "disavowed": [
      {
        "what": "products_not_offered",
        "detail": "Serval does not offer a consumer mobile app. Any app branded 'Serval' in consumer app stores is not affiliated."
      },
      {
        "what": "former_affiliation",
        "detail": "The domain serval-crypto.com has no affiliation with Serval, Inc., and never has."
      }
    ]
  }
}

supersedes

Declares that a prior public statement, URL, or document is no longer authoritative. Distinct from document-level supersedes (which refers to a prior llmo.json); this claim supersedes content in the wider web.

{
  "type": "supersedes",
  "statement": {
    "superseded": [
      {
        "what": "press_release",
        "url": "https://serval.com/press/2025-11-pricing-update",
        "reason": "Pricing structure announced in that release was revised on 2026-02-01. See canonical_urls.pricing for current."
      }
    ]
  }
}

pointer

A typed reference to an external artifact the organization endorses as authoritative for some scope. Used for pointing at heavier standards.

{
  "type": "pointer",
  "statement": {
    "scope": "media_provenance",
    "standard": "C2PA",
    "url": "https://serval.com/.well-known/c2pa-manifest.json"
  }
}

3.6 Extension claims

Claims with a type containing a . are namespaced extensions. Example: "type": "acme-corp.internal_compliance". Consumers MUST ignore unknown extension types without error. The LLMO registry at llmo.org/claims/ will catalog widely-adopted extensions and may promote mature ones into core in later versions.

The . separator matches schema.org, JSON-LD, and MIME-type conventions. Namespaces before the final . SHOULD be a short identifier the publisher controls, ideally matching a domain they own. Core claim types defined in this specification (identity, canonical_urls, official_channels, product_facts, personnel, disavowal, supersedes, pointer) contain no . and are reserved.

3.7 Confidence

Claims carry an optional confidence field:

Consumers MAY use confidence to resolve conflicts between LLMO claims and other sources: authoritative LLMO claims should beat scraped content; provisional claims need not.

4. Trust Model

4.1 Trust layers

LLMO defines two layers of trust. Every conforming document has the first; higher conformance levels require the second.

Layer 1: Domain-bound trust. The file is trusted to the extent that the domain serving it is trusted. HTTPS provides transport integrity; DNS and certificate chains provide the binding. A consumer that has verified the TLS connection to serval.com and retrieved .well-known/llmo.json from that connection has domain-bound trust in the contents. This layer requires no publisher-side key management.

Layer 2: Cryptographic trust. The document or individual claims carry JWS signatures. Signatures are verifiable against public keys the publisher makes available at a well-known JWKS URI. Signatures survive caching, mirroring, and republication: an LLM that cached a llmo.json last month can still verify its signatures today.

4.2 Keys and JWKS

Publishers using Layer 2 MUST host a JWKS at:

https://{domain}/.well-known/llmo-keys.json

The JWKS follows RFC 7517. Keys MUST declare use: "sig", an alg of ES256, ES384, or EdDSA, and a stable kid.

RSA is not in the v0.1 supported algorithm set. Rejected alternative: supporting RS256 for compatibility with legacy JWT infrastructure. Rejected because llmo.json is a greenfield artifact; there is no legacy to preserve, and RSA key sizes would inflate signature payloads unnecessarily.

Keys SHOULD rotate at least annually. Retired keys SHOULD remain in the JWKS for 90 days after rotation, marked with an exp claim on the key, to allow verification of recently-cached documents.

4.3 Document-level vs claim-level signing

Publishers may sign at two granularities:

Document-level signing. A single JWS covers the entire document (excluding the signature field itself). Placed at the top level as signature. The signing payload is the document with the signature key removed, canonicalized per §4.3.1.

Claim-level signing. Individual claims carry their own signature field covering the claim object (excluding the signature field). Useful when different claims are asserted by different organizational functions (e.g., legal signs disavowal claims; ops signs canonical_urls).

A document MAY use both. Claim-level signatures are evaluated per-claim; the document signature covers the wrapper.

4.3.1 Canonicalization

Both document-level and claim-level signatures use JWS with JCS (JSON Canonicalization Scheme, RFC 8785) over the target object with its own signature field removed.

Rationale for JCS at both granularities, rather than detached JWS over raw bytes:

The cost is modest: JCS adds a canonicalization pass before sign and verify. For a llmo.json of typical size (single-digit KB), this is imperceptible.

Reversibility. If future measurement shows JCS overhead is meaningful at aggregate scale, v0.2 can introduce alternate canonicalization modes without breaking v0.1 verifiers. Signatures already carry their alg in the JOSE header; a future cty or custom header parameter can declare canonicalization variant. v0.1 verifiers will simply treat unknown variants as unverifiable and downgrade trust per §4.5.

4.3.2 Publisher guidance: sign last, serve byte-stable

JCS protects against accidental transformation. Intentional transformation after signing is prohibited and will produce undetectable signature breakage. Publishers MUST:

A publisher who cannot guarantee byte-stable serving SHOULD NOT sign. An unsigned document at Layer 1 trust is preferable to a signed document whose signatures verifiers will routinely fail to validate.

4.4 Consumer verification algorithm

When a consumer fetches a llmo.json, it SHOULD:

  1. Verify TLS and the domain binding. If this fails, reject.
  2. Parse the document. If the document is malformed, reject.
  3. Check valid_from and valid_until. If expired, mark as stale.
  4. If a document-level signature is present, fetch the JWKS, verify. If verification fails, downgrade trust to Layer 1 only and log.
  5. For each claim, if it carries its own signature, verify it. Unsigned claims in a document-signed document inherit the document signature.
  6. Produce a per-claim trust assessment: {claim, trust_level: "layer1" | "layer2", issues: [...]}.

4.5 Behavior when signatures are absent or invalid

Absent signatures. The document is valid at Layer 1 trust only. Consumers MUST NOT treat the absence of a signature as evidence of inauthenticity. Most publishers in the v0.1 era will not sign.

Invalid signatures. An invalid signature is more suspicious than a missing one. Consumers SHOULD:

Key not found in JWKS. Treated as invalid signature.

4.6 What trust does not mean

A signed claim is not a guarantee of truth. It is a guarantee that this specific organization, via this specific key, asserted this claim at this specific time. Consumers that act on LLMO claims remain responsible for their actions. The spec provides attribution, not indemnification.

5. Conformance Levels

5.1 Minimal conformance

A llmo.json document is minimally conforming if:

Minimal conformance does not require any signatures or any specific claim types.

5.2 Standard conformance

A document is standard conforming if it meets minimal conformance plus:

Standard is the target for most publishers. It provides consumers with enough signal to meaningfully re-rank LLMO claims against scraped content.

5.3 Strict conformance

A document is strictly conforming if it meets standard conformance plus:

Strict conformance is intended for organizations whose LLMO claims carry significant consequence: regulated industries, widely-impersonated brands, organizations whose statements are frequently mis-attributed.

5.4 Validator behavior

A reference validator at llmo.org/validate will check these tiers. It will report:

6. Relationship to Adjacent Standards

LLMO deliberately stays narrow. This section maps the boundaries.

6.1 schema.org / JSON-LD

Schema.org markup is per-page and descriptive; LLMO is per-entity and operational. Schema.org tells a search engine “this page describes an Organization named Serval, with this address.” LLMO tells any machine consumer “these are the URLs we vouch for, this statement we repudiate, this document supersedes the last one.”

Use both. An organization’s homepage should carry schema.org markup; the organization should additionally publish llmo.json. When claims overlap (name, homepage URL), LLMO is authoritative by virtue of being single-sourced and signable; schema.org is authoritative for page-level facts that LLMO does not carry.

6.2 C2PA

C2PA cryptographically binds provenance to media assets (images, video, audio). LLMO does not. An organization publishing signed photography uses C2PA; the same organization can point to its C2PA policy via a pointer claim in llmo.json with scope: "media_provenance".

The two standards compose cleanly: C2PA handles asset-level provenance; LLMO handles entity-level claims, including the claim “here is our C2PA manifest.”

6.3 MCP and agent.json

Model Context Protocol and agent.json describe what an agent can do: capabilities, endpoints, invocation schemas. LLMO describes what is true about the organization behind an agent. An LLMO document can declare (via canonical_urls.agent_manifest or canonical_urls.mcp_manifest) which agent/MCP manifests are authoritative; the manifests themselves remain out of scope.

v0.1 deliberately does not specify agent capabilities inside llmo.json. This was evaluated and rejected in favor of pointer-only integration. Re-specifying capabilities would duplicate MCP badly; specifying them well would make LLMO a capability spec. The pointer model lets LLMO remain a declarative truth pack while composing with whichever agent spec wins.

6.4 security.txt (RFC 9116)

security.txt is the direct stylistic ancestor of llmo.json: a well-known, human-readable file publishing narrow operational information. LLMO extends the pattern in three ways: it is structured (JSON, not key-value text), it carries time-bounded claims with supersession, and it supports cryptographic signing. An organization’s security.txt remains authoritative for security disclosure; LLMO does not replicate its contents and SHOULD reference it via a canonical_urls.security pointer.

6.5 sitemap.xml and robots.txt

Orthogonal. Sitemaps describe URL inventory for crawlers; robots.txt describes crawling policy. Neither carries claims. LLMO does not replace either, and neither replaces LLMO.

6.6 DID and Verifiable Credentials

DIDs and VCs are a general-purpose decentralized identity and credential framework. LLMO could, in principle, be rebuilt on top of DIDs; v0.1 declines to require them for the same reason it declines to require Wikidata QIDs: imposing unfamiliar identity infrastructure would collapse adoption. The external_ids field leaves the door open for organizations that choose to publish a DID.

6.7 .well-known/ conventions (RFC 8615)

LLMO uses .well-known/ as intended: a stable, discoverable location for per-origin metadata. The file joins security.txt, openid-configuration, acme-challenge, and others. No conflict.

7. Worked Example: Serval, Inc.

Serval, Inc. is a hypothetical enterprise observability company. It publishes the following at https://serval.com/.well-known/llmo.json. The example meets strict conformance.

{
  "llmo_version": "0.1",
  "document_id": "2026-04-q2-ops",
  "valid_from": "2026-04-17T00:00:00Z",
  "valid_until": "2026-07-17T00:00:00Z",
  "supersedes": ["2026-01-q1-ops"],

  "entity": {
    "name": "Serval, Inc.",
    "primary_domain": "serval.com",
    "aliases": ["serval.io", "getserval.com"],
    "legal_identifiers": {
      "jurisdiction": "US-DE",
      "registration_number": "7891234"
    },
    "external_ids": {
      "wikidata": "Q123456789"
    }
  },

  "claims": [
    {
      "claim_id": "identity-core",
      "type": "identity",
      "statement": {
        "founded": "2019-06",
        "headquarters": "San Francisco, CA, US",
        "description": "Enterprise observability for AI and ML workloads."
      }
    },
    {
      "claim_id": "urls-canonical",
      "type": "canonical_urls",
      "statement": {
        "homepage": "https://serval.com",
        "docs": "https://docs.serval.com",
        "api": "https://api.serval.com",
        "status": "https://status.serval.com",
        "support": "https://serval.com/support",
        "pricing": "https://serval.com/pricing",
        "security": "https://serval.com/.well-known/security.txt",
        "agent_manifest": "https://serval.com/.well-known/agent.json"
      }
    },
    {
      "claim_id": "channels-official",
      "type": "official_channels",
      "statement": {
        "email_domains": ["serval.com", "serval.io"],
        "social": {
          "x": "@serval",
          "linkedin": "company/serval-inc",
          "github": "serval"
        },
        "community": {
          "discord": "https://discord.gg/serval-official"
        }
      }
    },
    {
      "claim_id": "products-current",
      "type": "product_facts",
      "confidence": "advisory",
      "statement": {
        "products": [
          {
            "name": "Serval Observe",
            "url": "https://serval.com/observe",
            "status": "generally_available",
            "current_version": "4.2"
          },
          {
            "name": "Serval Trace",
            "url": "https://serval.com/trace",
            "status": "beta",
            "current_version": "0.9"
          }
        ]
      }
    },
    {
      "claim_id": "disavowal-imposters",
      "type": "disavowal",
      "statement": {
        "disavowed": [
          {
            "what": "products_not_offered",
            "detail": "Serval does not offer a consumer mobile app. Any app branded 'Serval' in consumer app stores is not affiliated with Serval, Inc."
          },
          {
            "what": "unaffiliated_domain",
            "detail": "The domain serval-crypto.com has no affiliation with Serval, Inc. and never has."
          }
        ]
      }
    },
    {
      "claim_id": "supersede-pricing-press",
      "type": "supersedes",
      "statement": {
        "superseded": [
          {
            "what": "press_release",
            "url": "https://serval.com/press/2025-11-pricing-update",
            "reason": "Pricing structure revised 2026-02-01. See canonical_urls.pricing for current."
          }
        ]
      }
    },
    {
      "claim_id": "pointer-c2pa",
      "type": "pointer",
      "statement": {
        "scope": "media_provenance",
        "standard": "C2PA",
        "url": "https://serval.com/.well-known/c2pa-manifest.json"
      }
    }
  ],

  "signature": {
    "protected": "eyJhbGciOiJFUzI1NiIsImtpZCI6InNlcnZhbC0yMDI2LTAxIn0",
    "signature": "MEUCIQDfG...truncated..."
  }
}

Annotations on this example:

8. Open Questions for Future Versions

The following are known gaps or deferred decisions. v0.1 ships without resolving them.

8.1 Revocation beyond supersession. Document supersession and signature key rotation cover the common case. They do not cover “we need every cached copy of document X to be treated as revoked immediately, even if consumers haven’t refetched.” A future version of LLMO may define a revocation registry, potentially a signed, append-only list at /.well-known/llmo-revocations.json.

8.2 Delegation. How does a parent organization assert authority over a subsidiary’s llmo.json, and vice versa? v0.1 treats each domain as independent. A delegates_to / delegated_from claim pair is the likely answer in a future version of LLMO, but the trust implications (can a compromised parent forge a child?) need careful design.

8.3 Cross-domain aliases. v0.1 requires each alias domain to serve its own file. Whether a single canonical document should be able to speak for multiple domains without per-domain publication is unresolved. The trust argument for per-domain is strong; the operational argument against it is also strong.

8.4 Claim-level supersession inside a live document. Currently, supersession operates at the document level (new document supersedes old) and at the “wider web” level (a claim supersedes external content). A third mode, within a single live document where a newer claim supersedes an older one of the same type, is not yet specified. It may not be needed; republication is cheap.

8.5 Registry governance for extension claims. The llmo.org/claims/ registry needs an explicit governance model: who can register, what review is required, what it means for a claim type to be “promoted” to core. v0.1 leaves this to an informal editorial process.

8.6 Non-domain entities. Individuals, DAOs, and other entities without a primary domain are out of scope for v0.1. A future version of LLMO may include a binding for DID-rooted publication.

8.7 Interaction with retrieval-augmented generation at scale. How LLM providers actually consume LLMO claims at ingestion or retrieval time is outside the spec’s control. A future version of LLMO may include non-normative guidance for implementers on both sides, publishers and consumers, based on early adoption data.

8.8 Internationalization. All claim statements in v0.1 are free-form strings. A future version of LLMO will likely include a binding for localized claim text ("detail": {"en": "...", "ja": "..."}).

8.9 Relationship to compliance frameworks. Whether LLMO claims can or should be referenced in privacy policies, terms of service, or regulated disclosures is a legal question v0.1 explicitly does not answer. Organizations should consult counsel before treating LLMO claims as legally operative.

8.10 Publisher reputation layer. LLMO as specified gives publishers a signed channel to assert claims, but says nothing about whether a given publisher deserves to be believed. A bad actor can register a plausible-looking domain, publish a strictly-conforming llmo.json, sign it correctly, and use the authority of the file to launder false claims: false disavowals of legitimate parties, false supersessions of accurate reporting, canonical URLs pointing at phishing. Layer 2 cryptographic trust verifies who asserted what and when; it does not verify that the asserter should be trusted.

The answer is a consumer-side reputation layer that sits above LLMO, a separate artifact, not a field inside llmo.json, that scores publishers on signals LLMO itself cannot carry: domain age, historical consistency of claims, cross-reference against external identity anchors (Wikidata, legal registries, independent identity networks), signature key rotation hygiene, disavowal patterns that correlate with suppression of legitimate criticism. This artifact is necessarily third-party-published (a publisher cannot credibly score itself) and is a plausible role for the LLMO registry or an independent trust network to fill.

The field confidence inside a claim is the publisher’s hedge on its own claim. The reputation layer is the consumer’s score of the publisher. These are different concerns and belong in different artifacts. v0.1 specifies the first and explicitly defers the second. A future version of LLMO will need to specify the interaction: how consumers combine a claim’s stated confidence with the publisher’s reputation score to produce a final trust assessment, and how the reputation layer’s own trust is anchored without recreating the same adversarial problem one level up.

A plausible input to any such reputation layer is immutable publication history, an append-only log of a publisher’s llmo.json documents over time, hosted by a party other than the publisher. A self-hosting publisher can, in principle, rewrite history by re-signing a backdated prior document and claiming it was always there; a third-party log cannot be rewritten. The diff between successive documents then becomes an auditable trail of what the publisher claimed when. v0.1 does not specify this log; a future version may define an interchange format for importing and exporting such histories between reputation layers.

8.11 Post-quantum cryptographic readiness. Signatures in v0.1 use Ed25519 or comparable pre-quantum algorithms. Sufficiently large quantum computers would break these signatures, undermining the trust model that binds claims to publisher key control. A future version of LLMO will specify a migration path: algorithm identifiers in the schema, hybrid signature support during the transition, and a deprecation window for pre-quantum-only documents.

Appendix A: Conformance Artifacts

A.1 JSON Schema

A formal JSON Schema for llmo.json v0.1 is published at https://llmo.org/spec/v0.1/schema.json. The reference validator uses this schema as its structural check.

A.2 Test Vectors

A set of reference test vectors for v0.1 is published at /spec/v0.1/test-vectors. The vectors exercise the §4 trust model and the §5 conformance tiers: a minimally conforming unsigned document, a standard-conforming unsigned document, and a strictly conforming document with a valid ES256 JWS signature over a JCS-canonicalized payload (RFC 7515, RFC 7518, RFC 7638, RFC 8785). The JWKS containing the public key that verifies the strict vector, and the canonical bytes that were signed, are published alongside. The canonical-bytes file lets implementers validate their JCS implementation independently of their JWS implementation.

The vectors are static fixtures with a fixed validity window. After their valid_until date, conforming validators are expected to flag them as expired; that behavior is itself a conformance check.

Appendix B: Changelog

This specification is maintained at https://llmo.org/spec. Comments, issues, and proposed changes: https://github.com/openllmo/llmo.org.

Pages