ISO Week 20 of 2026: v0.1.9, v0.1.8, v0.1.7

This page mirrors spec releases that landed in ISO week 20 of 2026 (2026-05-11 to 2026-05-17), 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.9] - 2026-05-12

v0.1.9 lands two normative changes accepted on the same day under editor authorship privilege during the pre-announcement Goldilocks period (see ADR-0012): LIP-4 introduces a Key Transparency registry as a Strict-tier requirement (rule X7) with a 14-day grace period from this release date before enforcement begins; LIP-5 adds a normative category discriminator to the disavowal claim type’s disavowed[] items and binds rule S6 to a closed two-value enum, closing the documentation-versus-enforcement gap deferred since v0.1.5.

Both LIPs transitioned Draft → Final on 2026-05-12 with the LIP-1 §10 14-day governance window observed informally and the LIP-4 §5 X7 grace period revised from 90 days to 14 days. Per ADR-0012, full window observance resumes for substantive normative changes after the v0.1 public announcement.

Added

• LIP-4 Final introduces a Key Transparency (KT) registry: a public, append-only log of (domain, kid, jwk_thumbprint, doc_url, doc_id, observed_at) records, each a compact JWS signed by the publisher’s private key with the public JWK inline in the protected header per RFC 7515 §4.1.3. SHA-384 thumbprints per RFC 7638 throughout for ~128-bit post-quantum collision resistance under Grover. Rule X7 (KT registry inclusion required for Strict tier) added to spec §5.3. The registry is hash-committed via periodic signed snapshots so the historical record of registered keys survives any future signature-algorithm break. Reference implementation runs at https://llmo.org/kt/v1/.
• LIP-5 Final adds a normative category field to entries in disavowal.disavowed[] arrays. The field is a closed enum: self_statement (publisher disavows own past content) or impersonation_defense (publisher disavows third party falsely representing affiliation). statement_disavowal.disavowed[].items.required now contains ["what", "detail", "category"]. Spec §3.5 documents the per-value semantic.
• Implementer-facing endpoint spec at /spec/v0.1/kt-registry-endpoints/ documenting every endpoint of the KT registry API: POST /kt/v1/entries, GET /kt/v1/entries, GET /kt/v1/entries/{id}, GET /kt/v1/log.jsonl, GET /kt/v1/snapshot/latest, GET /kt/v1/snapshot/{id}. Plus D1 schema, KV namespace, federation considerations.
• Test vector suite for LIP-4 entries at /spec/v0.1/test-vectors/kt/: 3 positive (one per supported algorithm) and 10 negative (one per defined registry error code). Generator at scripts/test-vectors/generate-kt-vectors.mjs.

Changed

• §3.5 disavowal claim type documents the new category discriminator with definitions for self_statement and impersonation_defense. Worked example updated to include the field on both entries.
• §5.2 rule S6 updated with the binding rule text. Documents whose disavowal entries are missing the field or carry an out-of-enum value MUST NOT be evaluated at Standard tier or higher; the document evaluates at Minimal tier with note s6_disavowal_out_of_scope.
• §5.4 deferral note for S6 informational-only status (in force v0.1.5 through v0.1.8) closed. Reference validators bind S6 to tier outcome starting with v0.1.9; CLI gains the same binding in llmo@0.1.13.
• static/spec/v0.1/schema.json in-place patch: statement_disavowal.disavowed[] items add category to required and enum-restrict the value. Schema $id unchanged (in-place v0.1.x patch convention per ADR-0006).

Migration

• Documents conforming to v0.1.0 through v0.1.8 that include a disavowal claim without category fields on each disavowed[] entry fail M3 schema validation against the v0.1.9 schema. Affected publishers add the field with the appropriate enum value. Pre-launch the only such document is the steward’s own at llmo.org, updated in the same release window.
• Strict-tier consumers begin enforcing X7 starting 2026-05-26 (14 days after this release). During the grace period the kt_uninlogged note is surfaced advisorily but does not downgrade tier.
• Documents with no disavowal claim and a registered signing key are unaffected.

[0.1.8] - 2026-05-11

v0.1.8 (in progress, additive) introduces six new core claim types (contact_points, categories, locations, hours, attributes, operational_status), five new top-level optional fields (revocation_registry, dns_corroboration, publication_history, delegates_to, delegated_from), provenance_markers on the claim envelope, and structured verification forms on entity.external_ids plus a new irs_ein well-known key. Every conforming v0.1 document validates unchanged. Schema $id and llmo_version are unchanged.

Added

• Five new top-level optional fields in static/spec/v0.1/schema.json and documented in §3.1: revocation_registry (URL pointer to /.well-known/llmo-revocations.json; registry wire format deferred), dns_corroboration ({txt_record, hash_alg} for out-of-band integrity corroboration; hash algorithm values sha-256, sha-384, sha-512), publication_history (URL pointer to a third-party append-only log; interchange format deferred), delegates_to and delegated_from (arrays of domain strings establishing the delegation graph; asserted but not yet evaluated as a trust primitive).
• Six new core claim types in §3.5 and the schema’s claim.type oneOf core branch: contact_points (typed contact addresses with verification metadata; schema enforces required verification_proof and verified_at when verification_status is verified via if/then), categories (schema.org Organization subtype URIs plus NAICS codes), locations (postal address, WGS84 coordinates, service area with oneOf of radius / polygon / bounding_box / named_places, business_type enum, per-location publisher_id), hours (regular weekly schedule keyed by day-of-week, calendar exceptions, named alternate sub-schedules; 24:00 permitted as a close time only; is_overnight flag for periods spanning midnight), attributes (open map drawing canonical names from the controlled vocabulary at /glossary/#attributes), operational_status (open / opening_soon / temporarily_closed / permanently_closed; schema enforces required effective_date when status is not open).
• Optional provenance_markers field on the claim envelope (§3.4): array of advisory string markers recording how the builder agent derived each claim. Inside the signed payload. Consumers MAY use as confidence or freshness signal; MUST NOT treat as authoritative. See ADR-0007. Distinct from the media_provenance scope on pointer claims, which is C2PA-attested media origin.
• entity.name accepts an array of {name, locale, primary} entries for internationalized names alongside the v0.1 single-string form. Schema enforces exactly one primary: true via contains with minContains: 1, maxContains: 1. Locale is RFC 5646.
• entity.external_ids per documented well-known key accepts a structured {value, verification_method, verification_proof, verified_at} object alongside the v0.1 plain-string form. Verification method enum: domain_proof, signed_attestation, registry_lookup, none. Proof and timestamp required when method is not none (schema-enforced via if/then). Custom keys via additionalProperties also accept the structured form.
• New entity.external_ids well-known key: irs_ein (U.S. Internal Revenue Service Employer Identification Number) with pattern ^[0-9]{2}-[0-9]{7}$. Existing well-known keys wikidata, duns, lei, did gain the structured form with per-key value patterns preserved.
• Four new canonical_urls well-known keys: appointment, menu, reservations, order. additionalProperties remains open.
• product_facts per-product entries extended with kind (enum product or service, default product), price (oneOf of {amount, currency} with ISO 4217 alphabetic currency code, or symbolic value free / varies / call_for_quote), description (max 2048 chars), category (schema.org type URI).
• identity statement extended with price_range integer 1 to 4 mapping to $, $$, $$$, $$$$. Spec text adds SHOULD-level soft cap of approximately 500 characters on description for LLM consumption efficiency; schema hard cap of 2048 unchanged.
• New §3.8 documenting six reserved top-level namespaces (posts, reviews, qa, media_pointers, advertising_extensions, consumer_metadata). Reservation lives in spec prose only; schema top level remains additionalProperties: true with no enforcement. Publishers MUST NOT populate these keys in v0.1.8.
• Wire-format compatibility note in §3.8: v0.1.8 is purely additive over v0.1; every conforming v0.1 document validates against the v0.1.8 schema unchanged. Schema $id remains https://llmo.org/spec/v0.1/schema.json per the in-place patch convention documented in ADR-0006. llmo_version remains const: "0.1" for the lifetime of the v0.1 minor version.

Changed

• Schema-first encoding of three conditional constraints that earlier versions would have punted to validator code: contact_points entry if {verification_status: verified} then required: [verification_proof, verified_at]; operational_status if {status: not open} then required: [effective_date]; entity.name array form contains {primary: true} with minContains: 1, maxContains: 1. Schema is the source of truth; CLI and validator.js inherit these checks via schema validation rather than reimplementing.
• Eight new entries in the schema’s $defs map: locale_name, structured_external_id, day_schedule, plus the six new statement_* types for the new core claim types. Eight new branches in claim.allOf mapping each new claim type to its statement schema.

Migration notes

• Publishers: nothing required. Populate the new optional fields when convenient. The Claude builder skill / GH action (see ADR-0007) will populate them automatically on the publisher’s behalf, including provenance_markers (the agent’s per-claim audit trail), location entries, hours, attributes, and the structured external_ids verification form.
• Validators and consumers: updating the schema reference is a no-op since the canonical URL is unchanged. The new conditional-required constraints (verified contact points; non-open operational status; entity.name array primary count) fire automatically through schema validation. Reserved-namespace keys are ignored at the schema level (top-level additionalProperties: true remains); future patch versions may give them meaning.
• CLI vendored schema sync: the CLI’s vendored copy of schema.json should be refreshed in a paired PR in the openllmo/cli repo after v0.1.8 lands. This is downstream work tracked separately.
• Cryptographic layer: untouched. ES256, ES384, EdDSA; JCS (RFC 8785); JWS (RFC 7515); JWKS at /.well-known/llmo-keys.json are all unchanged.

[0.1.7] - 2026-05-11

v0.1.7 bundles the comprehensive test-vector expansion from PR #74 and removes the in-spec changelog mirror that was creating drift. Every conformance rule v0.1 defines now has at least one exercising vector; the validator and CLI harnesses (scripts/test-vectors/verify-vectors.mjs and scripts/test-vectors/verify-schema.mjs) report 31/31 passing against the canonical schema. Four drift findings between reference implementations and spec text were surfaced and filed to BACKLOG. ES384 and EdDSA gain their first strict-tier vectors, closing the gap with §4.2’s algorithm registry. Appendix B of /spec/v0.1/ becomes a pointer to this changelog, eliminating the duplicate-source drift risk.

Added

• Strict-tier test vectors for ES384 (signed-strict-es384.json and key/payload counterparts) and EdDSA (signed-strict-eddsa.json and key/payload counterparts) under /spec/v0.1/test-vectors/. The §4.2 algorithm registry permits ES256, ES384, and EdDSA; the test vector set previously covered only ES256. The new vectors complete coverage. content/spec/v0.1/test-vectors.md gains entries describing them.
• Comprehensive test-vector expansion under /spec/v0.1/test-vectors/ covering every conformance rule v0.1 defines. New negative vectors for S1, S2, S4 (three failure modes), S5, S6, X1 (alg, kid, malformed protected header, b64:false, crit non-empty), X4, X5 (corrupted document signature), and X6 (corrupted per-claim signature); schema and minimal-tier negatives for malformed claim.type, malformed founded field, bad llmo_version, and over-365-day windows; warning vectors for W1 and W2; edge-case vectors at 365-day and 366-day window boundaries, namespaced extension claim types, the impersonation-defense disavowal scope, and spokesperson verification URLs. content/spec/v0.1/test-vectors.md gains a coverage matrix table mapping each rule to its enforcing implementations and exercising vectors, organized vector-file subsections (positive, negative-by-rule, warning, edge), and a Drift findings section documenting where validator.js and CLI behavior diverge from spec text. Two harnesses landed at scripts/test-vectors/: verify-vectors.mjs runs CLI verify against every vector and asserts expected tier and rule outcomes (31/31 passing); verify-schema.mjs validates each vector against the canonical /spec/v0.1/schema.json (31/31 passing). The expansion surfaced four drift findings, each filed as a separate BACKLOG item: §5.2 S6 unimplemented in both reference implementations, §4.3.1 b64/crit rejection unimplemented in both, CLI does not enforce S4 or X4, and the CLI vendored schema lags canonical.

Changed

• Appendix B of the v0.1 specification document replaced with a pointer to this changelog. The standalone changelog at /spec/changelog/ is the single source of truth for version history; the in-spec mirror was removed to eliminate drift.