For review: v1.0 draft charter (call for consensus)

Hello all,

As promised in my welcome note, here is the v1.0 draft charter, circulated
for your review and consensus ratification.

A short orientation before the text:

  - The charter fixes our scope before technical work begins: we work one
    layer above the protocol — interoperability profiles, a use-case
    catalogue, and a conformance/test surface — all of which normatively
    reference the externally maintained protocol specification (the IETF
    Independent Submission draft `draft-saihm-memory-protocol`) rather than
    restate it. See sections 2 and 3.

  - Section 2.1 records a deliberate de-confliction measure: while that
    draft is under the Independent Submissions Editor's consideration, the
    group will not develop or publish a competing normative specification of
    the protocol. This keeps our work complementary to the protocol's single
    normative home.

  - Section 5.1 states plainly that a Community Group does not produce W3C
    Recommendations or other standards; our outputs are Community Group
    Reports.

  - Adopting a charter is optional under the Community Group process; we are
    choosing to adopt one to make our scope explicit. Until ratified it is
    non-binding.

Process: per the decision process in section 9, I'm calling for consensus on
this charter. Please send comments, suggested changes, or objections on-list.
Absent sustained objection, I propose we adopt v1.0 on Friday 19 June 2026;
if there is substantive discussion we'll extend and revise rather than rush
it. Volunteers for the first deliverables (section 5) are very welcome.

The full draft follows below.

With thanks,
Russell Jackson
Chair, AI Agent Memory Interoperability Community Group


----------------------------------------------------------------------
v1.0 DRAFT CHARTER (full text follows)
----------------------------------------------------------------------

# Charter — AI Agent Memory Interoperability Community Group (v1.0 DRAFT)

**Group:** AI Agent Memory Interoperability Community Group
**Group home:** https://www.w3.org/community/ai-agent-memory-interop/
**Short name:** `ai-agent-memory-interop`
**Status:** v1.0 DRAFT — circulated for participant ratification
**Date:** 2026-06-04

> This is a draft charter prepared for ratification by the Group's participants. Adopting a charter is optional under the W3C Community Group process; this Group elects to adopt one to fix its scope before technical work begins. Until ratified, it is non-binding. On ratification it governs the Group's work and may be revised per the *Amendments* section.

---

## 1. Goals

The mission of the AI Agent Memory Interoperability Community Group is to make AI agent memory **portable and verifiable across vendors, models, agent frameworks, and tool ecosystems** by developing, in the open and royalty-free:

- cross-vendor **interoperability profiles**,
- a documented **use-case catalogue**, and
- a **conformance and test surface** (criteria, test vectors, and a test suite)

that **build upon and normatively reference an externally-maintained protocol specification** for AI agent memory, rather than re-specifying that protocol within this Group.

The Group operates one layer **above** the protocol. Its purpose is to help independent implementations interoperate and to let adopters verify conformance — not to define, fork, or maintain a second copy of the underlying protocol.

## 2. Referenced protocol specification

The normative definition of the AI agent memory protocol — the memory-cell shape and encoding, the cryptographic envelope and key derivation, the identity/signature binding, the audit-anchor receipt, the sharing contracts, and the cryptographic-erasure mechanism — is maintained **outside this Group**, in the IETF Independent Submission Stream document **`draft-saihm-memory-protocol`** (https://datatracker.ietf.org/doc/draft-saihm-memory-protocol/).

All Group deliverables reference that document normatively. Where this charter names a protocol element (e.g. an ML-DSA-65 identity binding or an HKDF-derived per-cell key), it does so only to scope **interoperability and conformance guidance for the element as defined in the referenced specification** — never to redefine it.

### 2.1 Relationship to the IETF Independent Submission (scope restriction)

`draft-saihm-memory-protocol` is under consideration in the IETF Independent Submission Stream. **While that submission is under the Independent Submissions Editor's consideration, this Group will not develop or publish a competing normative specification of the protocol** — that is, the Group will not produce a document that normatively defines the protocol's wire format, cryptographic constructions, key derivation, identity binding, or erasure mechanism independently of the referenced document.

This restriction is a deliberate de-confliction measure so that the Group's work complements, rather than interferes with, the evolution of the protocol in its single normative home. The restriction remains in force until the IETF Independent Submission concludes (the document is published as an RFC, or is withdrawn or declined). After that point the Group may, by the *Amendments* process, reconsider whether to host normative work — and if it intends to, it will coordinate with the relevant editor before doing so.

## 3. Scope

In scope:

- **Interoperability profiles** that constrain or clarify use of the referenced protocol for specific deployment contexts (for example: a baseline cross-vendor interoperability profile; a profile for regulated-data deployments), adding interoperability guidance without adding new normative protocol elements.
- A **use-case catalogue** capturing how portability, verifiable erasure, and cross-vendor migration are exercised in practice.
- **Conformance criteria, test vectors, and a test suite** by which an implementation can demonstrate conformance to the referenced specification and to the Group's profiles.
- A **regulatory crosswalk pack** (informative): mappings from the referenced protocol's capabilities to GDPR Article 17, the EU AI Act (Regulation (EU) 2024/1689), NIST AI RMF 1.0, ISO/IEC 27001:2022, ISO/IEC 42001:2023, and comparable regimes (HIPAA, PIPEDA, PIPL, LGPD).
- **Liaison and coordination notes** with the forums listed in §6.

## 4. Out of scope

- **Normative (re-)specification of the AI agent memory protocol itself.** The cell format and encoding, the cryptographic envelope and key derivation, the identity/signature binding, the audit-anchor receipt, the sharing contracts, and the erasure mechanism are defined normatively only in the referenced specification (§2); this Group references them and does not redefine, version, or fork them. See also the time-bound restriction in §2.1.
- Selection or endorsement of any specific blockchain or ledger (the referenced protocol is chain-agnostic).
- Vector-database or embedding-store semantics (orthogonal to memory portability).
- Agent runtime semantics (addressed in other forums).
- Tool-routing or tool-invocation semantics (addressed by the Model Context Protocol and its host foundation).

## 5. Deliverables

Each deliverable is a **Community Group Report** (or test software) that normatively references `draft-saihm-memory-protocol`. None re-specifies the protocol.

**First 12 months (target):**

1. **Use-case catalogue** — portability, verifiable erasure, cross-vendor migration, regulated-data handling.
2. **Baseline interoperability profile** — the minimum interoperability guidance two independent implementations need to exchange and verify memory cells per the referenced specification.
3. **Conformance and test-vector pack** — conformance criteria plus published test vectors for the referenced protocol's encoding, identity binding, envelope, and erasure-receipt verification.
4. **Regulatory crosswalk pack (informative)** — the mappings enumerated in §3.

**Candidate later work (subject to participant interest and §2.1):**

- A regulated-data interoperability profile.
- An open-source conformance test suite exercising the test vectors.

The Group expects to publish work as it stabilises and to maintain an errata/issues list against each Report.

### 5.1 Normative status / limitation

Per the W3C process, **a Community Group does not produce W3C Recommendations or other W3C standards.** Group deliverables are Community Group Reports. A Report may, if the Group elects, be advanced to a **Final Specification** under the W3C Community Final Specification Agreement; this provides patent commitments but is still not a W3C Recommendation. Placing any work on the W3C Recommendation track would require transitioning the work to a **W3C Working Group** under a separate, Member-reviewed charter. This charter does not commit W3C or its Members to any such transition.

## 6. Dependencies and liaisons

- **IETF Independent Submission Stream** — the normative home of the referenced protocol and this Group's primary upstream dependency. The Group tracks the document's status and aligns its profiles and test vectors to the published text. Coordination is conducted with respect for the restriction in §2.1.
- **Agentic AI Foundation (AAIF, Linux Foundation)** — hosts the reference implementation and surrounding ecosystem; a contribution/implementation track that this Group's specifications are intended to serve.
- **NIST** — the AI RMF and related guidance, engaged via use-case and public-comment contributions; informative crosswalk only.
- **ISO/IEC JTC 1/SC 42** — a possible future track via national-body engagement; this Group's output is intended to be cite-able by an SC 42 New Work Item Proposal should SC 42 choose to engage. No commitment is implied.

## 7. Community Group Process and contribution mechanics

This Group operates under the **W3C Community and Business Group Process** and the **W3C Community Contributor License Agreement (CLA)**:

- Anyone may participate by creating a W3C account, joining the Group at https://www.w3.org/community/ai-agent-memory-interop/join, and agreeing to the CLA.
- Substantive contributions to a specification are made under the CLA. Should the Group take a specification to a **Final Specification**, participants commit under the **W3C Community Final Specification Agreement** (royalty-free patent commitments).
- The reference implementation is published under the **Apache License 2.0**; the Group's IPR mode is **Royalty-Free**.
- All technical work — drafts, issues, decisions, and minutes — is conducted in public.

## 8. Communication

- **Group home:** https://www.w3.org/community/ai-agent-memory-interop/
- **Public mailing list:** the Group's W3C-hosted public list (`public-ai-agent-memory-interop@w3.org`).
- **Source and issues:** a public Git repository linked from the Group home once established.
- **Meetings (if any):** announced on the list with public minutes; meetings are not a substitute for on-list decision-making.

## 9. Decision process

The Group seeks **consensus**. Where a decision is needed:

1. The Chair calls for consensus on the list or in a minuted meeting.
2. Absent sustained objection, the proposal carries.
3. A participant who disagrees may record a formal objection; the Chair responds on the record and, where warranted, escalates per the W3C Community Group process.

Decisions made in a meeting are confirmed on the public list so that participants who could not attend can weigh in. Substantive decisions are not made off-list.

## 10. Chair / convener

The Group is convened by the **SAIHM Project** (Sovereign AI Horizontal Memory).

- W3C identity (project handle): `saihm` (W3C user 177015) — https://www.w3.org/users/177015/
- Role mailbox: architect@saihm.coti.global

The convener serves as initial Chair. The Group may select or add Chairs by the decision process in §9. The convener and Chair are identified by project handle and role mailbox; the W3C Community Group process does not require a personal name for this role beyond the account-holder identity W3C records on the Group page.

## 11. Amendments to this charter

This charter may be amended by the decision process in §9. Proposed amendments are circulated on the public list with at least a stated review period before adoption. Amendments that would broaden scope into normative protocol specification are additionally subject to §2.1 (the IETF-submission restriction) for as long as that restriction is in force. The charter version and date are updated on each adopted amendment.

## 12. References

- W3C Community and Business Group Process: https://www.w3.org/community/about/process/
- W3C Community Contributor License Agreement (CLA): https://www.w3.org/community/about/process/cla/
- W3C Community Final Specification Agreement (FSA): https://www.w3.org/community/about/process/final/
- IETF Internet-Draft (referenced protocol): https://datatracker.ietf.org/doc/draft-saihm-memory-protocol/
- NIST FIPS-204 (ML-DSA): https://csrc.nist.gov/pubs/fips/204/final
- SAIHM standards surface: https://saihm.coti.global/standards

Received on Friday, 5 June 2026 03:19:05 UTC