ISO Week 21 of 2026: v0.1.10

This page mirrors spec releases that landed in ISO week 21 of 2026 (2026-05-18 to 2026-05-24), consolidated from the canonical changelog. The changelog is the source of truth; this page is the periodic public surface that surfaces what shipped without requiring a reader to scan the full changelog.

Per ADR-0008: /updates/ is auto-generated from changelog releases; human-curated long-form lives at blog.llmo.org (planned).

[0.1.10] - 2026-05-19

v0.1.10 adds a resolver-side fallback location for publishers whose primary-domain serving topology is owned by a hosted-platform edge (Shopify, BigCommerce, Wix, Squarespace, and similar SaaS commerce platforms; certain CMS platforms with restrictive /.well-known/ policies). The signed document is unchanged; the addition is purely additive per ADR-0006. Rationale, considered alternatives, and security analysis recorded in ADR-0013. Accepted under ADR-0012 pre-launch authorship privilege; no LIP filed.

Added

• §2.6 Resolver fallback for SaaS-hosted publishers specifying the fixed-subdomain fallback https://llmo.<primary_domain>/.well-known/llmo.json as a single non-heuristic alternate location. Consumers SHOULD attempt the fallback when, and only when, the primary path is structurally absent (HTTP 404, DNS NXDOMAIN, or TCP connection refused on port 443). Primary path remains authoritative when it returns a usable response; resolvers SHOULD negative-cache the primary’s absence-class result for a bounded window (recommended default: 5 minutes) to bound lookup amplification.
• §8.13 Reservation of the _llmo.<primary_domain> DNS namespace for future discovery added as an Open Question for Future Versions. The reservation is namespace-only; v0.1 does not pre-specify record shape or value format. One particular TXT-URL shape was considered for v0.1.10 and not adopted, with reasoning recorded in ADR-0013. Future versions are free to define a different shape at this namespace without being constrained by the considered-and-not-adopted shape.

Changed

• §2.1 Location amended: organizations whose primary-domain serving topology does not permit publication under /.well-known/ MAY satisfy the location MUST by serving the file at the §2.6 fallback location instead.
• §2.5 Discovery failure rewritten to distinguish absence-class failures (HTTP 404, DNS NXDOMAIN, TCP connection refused on 443), which trigger the §2.6 fallback, from presence-with-failure modes (5xx, 4xx other than 404, TLS handshake errors, response timeouts, 200 with malformed content), which do not. Reinforces the prohibition on heuristic discovery beyond the single fixed-subdomain fallback.
• §5.2 rule S3 expanded: entity.primary_domain matches the domain serving the file, or the file is served at llmo.<entity.primary_domain> under the §2.6 fallback. The expansion is strictly broader; documents conforming to S3 under v0.1.0 through v0.1.9 continue to conform unchanged.

Migration

• No publisher action required. Publishers currently serving at https://<primary_domain>/.well-known/llmo.json continue to conform exactly as before. Publishers blocked from primary-path serving by their hosting platform now have a defined fallback location with documented resolver behavior; rollout of llmo.com-side infrastructure for that population proceeds in the llmo.com repo.
• Resolver implementers SHOULD update to attempt the §2.6 fallback when the primary path returns 404, NXDOMAIN, or connection refused. Resolvers that do not implement the fallback remain conformant under the SHOULD-class language; documents at fallback-only publishers are discoverable to resolvers that have adopted the SHOULD-clause, and that population grows as the spec is adopted.
• No schema change. static/spec/v0.1/schema.json is untouched; rule S3 changes are spec-text-only since S3 binds the serving domain to a document field, not to a schema constraint.