Skip to main content

Changelog

This version: 2026-09-01
Licence: CC BY 4.0 (text). Schemas, when published, under Apache 2.0.
Conventions: RFC 2119 keywords and addressed roles
Steward: Marrow (onmarrow.com), on behalf of the Agent Mediated Insurance (AMI) working group

This changelog records changes to the standards themselves, not to the website that publishes them. It is written for an implementer or reviewer asking one question: did any obligation, factual claim or governance term change?

Every entry carries one of three tags:

  • Substantive changes what a conformant implementer must do.
  • Correction fixes a claim in the text that was false or out of date. Corrections are described rather than silently applied.
  • Editorial changes the wording or presentation of a requirement that is otherwise unchanged.

Entries are grouped by document, substantive first.

Release 2026-09-01​

Documents in this release, each at its own version. Versions are unchanged by this release unless the entry below says otherwise.

DocumentVersion
Core Patterns0.2
Consent, Authority and Scopes0.2
New Business0.2
Information Access0.2
Complaints and Redress0.1
Oversight and Assurance0.1
Motor0.2
SMB0.2
Home0.2
Travel0.2
Life0.2, pre-draft and not open for comment
PetIn preparation, no document yet
Mid-Term Adjustment, Renewal, Claims, Servicing and CancellationScope stubs, not versioned

Across the standards​

  • Editorial. The requirement sentences already present in Core Patterns, Consent, Authority and Scopes, New Business and Information Access are now written in RFC 2119 form (MUST, MUST NOT, SHOULD, MAY), and each of those four documents gains a closing "How to conform" section stating the version an implementer declares, the roles the requirements address, and testable statements drawn from that document's own MUST requirements. Case and presentation only: no requirement was added, softened or strengthened, and no test asserts anything the document does not already require. Sentences that describe rather than require were left in lower case. The line-of-business documents still express their requirements in prose and will be converted in a later release.

Core Patterns​

  • Substantive. Section 3.10: records being complete, durable and available to the carrier's compliance function is now a MUST rather than a SHOULD. Everything else in 3.10 is a MUST, and the audit record is the evidence base the rest of the standard relies on, so a recommendation was the wrong strength. The recommendation in 3.13, about preferring layer-driven elicitation where the surface supports it, is deliberately left as a SHOULD.
  • Editorial. The "Rail" definition in section 2 now reads "Rail (the intermediation layer)", and requirement sentences address the intermediation layer by name. The role and its obligations are unchanged.
  • Editorial. First use of A2A now reads "A2A (Agent2Agent)", so the interoperability protocol cannot be mistaken for the name of these standards.
  • Substantive. Section 8 (Audit) now requires that every refused Class 2 or Class 3 action is recorded in the ledger with the reason for the refusal, alongside grants, exercises, confirmations, pre-authorisations and revocations. Previously only successful actions had to be recorded, which meant an implementation whose controls fired and one whose controls were never reached left the same trace, and the enforcement this standard depends on could not be evidenced. The disclosure-gate test in section 10 now asserts the refusal record, and the open question about whether refusals belong in the ledger is closed.
  • Correction. Section 2 is replaced in full. It previously said the Agentic Commerce Protocol was "live in ChatGPT since late 2025" and that AP2 was "donated to the FIDO Alliance in May 2026". Both were wrong. ChatGPT withdrew its native Instant Checkout in March 2026 and now uses ACP for discovery, with the purchase completed on the seller's own surface; AP2 was contributed to the FIDO Alliance on 28 April 2026 at v0.2. The section now also covers the Universal Commerce Protocol, the Visa and Mastercard agent-identity schemes, and MCP and the A2A (Agent2Agent) protocol, recording for each what is live, what is specified and what is still intent. It states the consequence that follows for implementers: because the consumer surfaces do not permit an insurance bind or a premium payment inside the conversation, the human-present confirmation required by section 6.2 takes place on a hosted confirmation surface reached from the conversation.
  • Correction. Section 4.3 is replaced in full. Scope grants map onto the commerce mandates where a surface supports them, and onto an equivalent recorded grant with the same fields and audit treatment where it does not, so the mapping is a binding for when the surface supports it rather than a dependency.
  • Correction. Section 5 is replaced in full. Agent identity is expressed against the current schemes, and the section now states plainly that the United Kingdom has no statutory definition of agent identity and no registry of agent operators, and that the AMI implementers register is an interim answer designed to defer to a national or network registry when one exists.
  • Correction. Section 4.4 item 5 and the cancel scope no longer state a flat 14-day cooling-off period. Cancellation rights are product-dependent: they now refer to the customer's statutory cancellation rights and the cooling-off period that applies to the product, 14 days for general insurance and 30 days for life and protection contracts.
  • Correction. The agent-identity naming in section 3 and in the open questions no longer uses withdrawn product names, and is aligned with the schemes described in section 2.
  • Editorial. Section 6 now states the cap semantics for amend and renew:auto explicitly, matching bind:limit and pay:limit. The obligation is unchanged: it was already stated in the scope ladder at 4.2, and section 6 is where the tiers are defined, so it is restated there rather than introduced.

New Business​

  • Correction. The open question about the cooling-off cancellation right no longer implies a single flat period. It refers to the customer's statutory cancellation right and the cooling-off period that applies to the product.

Motor​

  • Substantive. Section 4.2 now states that motor conviction data is criminal offence data under Article 10 UK GDPR, that processing it requires a condition under Schedule 1 of the Data Protection Act 2018, and that the enrich:dvla and enrich:cue scopes carry that requirement. The schema listed the convictions field and named its sources but never classified the data, which left the lawful-basis question unanswered for the one field in the document where it is hardest.

Life​

  • Substantive. A cancellation-rights rule is added to section 5, making the 30-day cooling-off period for a life or protection contract explicit and distinguishing it from the 14 days that applies to general insurance. The agent states the customer's cancellation rights before the application is submitted and again at fulfilment.
  • Editorial. The status of this document is now "Pre-draft. Being shaped with a UK life insurer before public comment." It is not open for public comment, the invitations to comment have been removed, and the version label reads "Pre-draft" for the same reason. No requirement in the document has changed.

Coming in later versions​

  • Editorial. Four single-screen scope stubs are added: mid-term adjustment, renewal, claims (FNOL and status), and servicing and cancellation. Each records the interaction's scope, its action risk class and the requirements that distinguish it from New Business, cross-referencing the scopes already defined in Consent, Authority and Scopes. Scope indicated, not open for comment: the stubs state no requirements.

Governance​

  • Licences adopted. The text of the standards is licensed under Creative Commons Attribution 4.0 International. The schemas and machine-readable artefacts, when published, will be licensed under the Apache License 2.0. Neither licence grants any right in the AMI or Marrow names or marks. See the licence.
  • Release-level dating adopted. The standards are released as a dated set, and each document keeps its own version number, listed in the table above. The set no longer carries a version number of its own. No document has been renumbered.