Information Access Standards
Version: 0.1 (Draft for Comment)
Status: Working Draft
Steward: Marrow (onmarrow.com), on behalf of the Agent-to-Agent (A2A) working group
Scope: What information an AI agent can read on a user's behalf, how it is structured, and on what authority it may be read
This is the information plane of the A2A protocol: the nouns to the interaction standards' verbs. It defines the types of data an agent can access, the canonical shape of each, and the access class that governs what proof is required before a read. It depends on the A2A Core Patterns Standard (grounding and provenance) and the A2A Consent, Authority and Scopes Standard (read authority is expressed as scopes), and it is where the Defaqto relationship for canonical product data is formalised. Comments to standards@onmarrow.com.
1. Why the access class matters as much as the content
The Consent, Authority and Scopes Standard governs what an agent may do; this standard governs what it may read, and the two are the same kind of question. Reading a public product definition needs nothing. Reading a customer's policy schedule needs proof they are the policyholder. Pulling their DVLA record needs explicit per-source consent. So every piece of information an agent handles is classified not only by what it is but by the access class that determines the proof required before it can be read. Content and access class are declared together.
This standard also makes grounding enforceable: because every datum carries its provenance, the no-fabrication rule (Core Patterns 2.1) has something to check against. A fact with no source is not presentable, and this is the document that says what a source looks like.
2. The four metadata every datum carries
Every piece of information an agent handles carries four pieces of metadata, regardless of type:
- Canonical schema: the agreed shape, so the same fact means the same thing across carriers and surfaces.
- Access class: the proof required before a read (Section 3).
- Provenance: the authoritative source and a timestamp.
- Advice-or-information flag: whether presenting this datum, in this context, crosses into regulated advice (Core Patterns 2.3).
Provenance and the advice flag are not optional decoration. The first enforces grounding; the second enforces the advice boundary. Together they are what let a regulator trace any statement an agent made back to a source and a permitted basis.
3. Access classes and how they map to scopes
| Access class | Proof required | Scope (Consent and Authority) |
|---|---|---|
| Public | None | read:product (implicit) |
| Policyholder-authenticated | The user is authenticated as the policyholder | Authenticated identity plus carrier OAuth |
| Consented enrichment | Explicit consent, per source for sensitive sources | enrich:<source>, screen:medical |
| Derived | The data is generated by the agent or rail | None to read, but must carry provenance and the advice flag |
| Regulatory disclosure | None to read, but mandatory to surface at the right moment | n/a |
Read authority is therefore the same scope machinery as transaction authority: an agent that has not been granted enrich:dvla cannot read the DVLA record, exactly as an agent without bind:limit cannot bind.
4. The information taxonomy
4.1 Product and market data (public)
Definitions of products and cover types, the cover feature-and-benefit taxonomy, the exclusions taxonomy, the insurance glossary, and generic eligibility and appetite rules. An agent reads these freely to explain and compare. This is the layer the Defaqto relationship anchors (Section 5).
4.2 Policy data (policyholder-authenticated)
The customer's own policy: schedule, certificate, documents, cover in force, limits and excesses, endorsements and warranties, renewal terms, payment status, and the claims recorded on the policy. Reading any of this requires authenticated proof the user is the policyholder, typically the surface's verified user token plus carrier OAuth. This is the data the MTA, Renewal, Claims, and Servicing interactions read against.
4.3 Risk and enrichment data (mixed, mostly consented)
The authoritative sources that describe the risk: DVLA and MyLicence, CUE, MIAFTR, MID, Companies House, property and rebuild data, vet records, and medical screening. Some are public (Companies House); most require explicit per-source consent, and special-category sources (vet records, medical screening) always require their own consent and heightened protection. The LoB standards define which sources apply to which line.
4.4 Derived and advisory data (generated)
Comparisons, suitability assessments, and recommendations the agent or rail produces. These are readable without external proof but must carry provenance (what inputs they were derived from) and the advice-or-information flag, because a comparison presented as a recommendation can cross the advice boundary. A derived datum never launders an ungrounded fact into a presentable one: its provenance must resolve to grounded inputs.
4.5 Regulatory and disclosure data (public, mandatory to surface)
IPIDs, fair-value statements, signposting directories (for example the MoneyHelper travel directory), and required notices. These are public to read but carry a duty to surface at the right moment in an interaction, which the interaction standards specify.
5. The Defaqto-backed product-data model
Product and market data (Section 4.1) is structured as a layered model. Defaqto maintains the UK's canonical map of what insurance products contain and scores policies against a defined feature-and-benefit set per line; if Defaqto provides the canonical product and feature taxonomy, the agent gains one comparison vocabulary consistent across carriers, which is what makes like-for-like comparison real rather than a per-carrier guess.
The layers:
- Definitions layer: what a product and each cover type means. Canonical, public.
- Feature layer: the Defaqto feature-and-benefit taxonomy per line. The comparison vocabulary used at the comparison stage of every interaction.
- Exclusion and condition layer: the canonical taxonomy of what is not covered and what the customer must do (warranties, conditions).
- Eligibility and appetite layer: machine-readable rules for who and what is in scope, so eligibility pre-checks can run before a quote.
- Instance layer: a specific carrier's product expressed in the layers above, and a specific customer's policy as an authenticated instance of it (which is where the model meets policy data in Section 4.2).
Marrow's contribution is to wrap that product data in the access-control, provenance, and agent-facing schema this standard requires. The canonical content can be Defaqto's; the agent-safe, access-classed, provenance-bearing delivery of it is the rail's.
6. Provenance, freshness, and caching
Provenance carries a timestamp, and information has a freshness life. A quote has an explicit validity expiry and must not be presented as live past it. Rebuild-cost data should be rechecked at least every five years rather than relied on indefinitely (the home standard's basis). Enrichment results carry the time they were retrieved, and a stale enrichment must be refreshed or flagged before it is relied on for a bind. Public product data may be cached; policyholder-authenticated and consented data must respect the access class on every read, not only the first. The agent should prefer a fresh read over a stale cache wherever a material fact or a price depends on it.
7. How the interactions read against this model
Each interaction reads a characteristic set of classes. New Business reads product and market data (to explain and compare), risk and enrichment data (to assemble the request), and derived data (the comparison), and surfaces regulatory disclosure data before bind. MTA, Renewal, Claims, and Servicing additionally read policyholder-authenticated policy data, which is why they require authentication that New Business discovery does not. The access class is what makes that difference precise: the same agent reads more, and proves more, as it moves from discovery into a held policy.
8. Conformance and open questions
A conformant implementation classifies every datum by content and access class, attaches provenance and the advice flag to every datum, enforces the access class on every read (not only the first), and respects freshness and validity expiry. It expresses product and market data in the layered model of Section 5.
Open questions:
- The exact boundary between
enrich:companies-housestyle public sources that may be implied byprocess:personal-dataand those that need a discrete grant. - Whether provenance should be exposed to the customer on request as a transparency feature, and in what form.
- How the Defaqto feature taxonomy is versioned and how a carrier maps a non-standard feature that the taxonomy does not yet contain.
- Caching policy for consented enrichment: how long a consented read may be reused before re-consent is required.
- How derived suitability data is retained and audited given it can carry advice weight.
Published as an open standard. Marrow stewards the drafting but does not assert proprietary control over the interface; the canonical product data may be Defaqto's, and the compliance, enrichment, and audit implementations behind it are separate. Carriers, agent platforms, data providers, and regulators are invited to adopt, critique, and co-author future versions.