@mnemom/agent-alignment-protocol 2.0.0 and @mnemom/agent-integrity-protocol 1.3.0. AIP has had no breaking changes since its 1.0.0 stability commitment — 1.1.0 through 1.3.0 are additive. AAP had one breaking release since 1.0.0: 2.0.0, which renamed two card fields. If you are upgrading from the 0.x series, start with the 1.0.0 section below, then apply the 2.0.0 section on top of it. If you are already on AAP 1.x, jump straight to Upgrading to AAP 2.0.0.
Upgrading to AAP 2.0.0
AAP 2.0.0 renamed two top-levelAlignmentCard fields (the unified-cards shape you see in the 1.0.0 examples below already anticipated this rename, so if you built against the unified card documented on this page you may already be compliant):
autonomy_envelope or audit_commitment field of its own.
This is a real major-version break: mnemom-api’s live
X-Mnemom-Schema unified card identity (unified/2026-04-15) already uses autonomy / audit, so a 1.x SDK reading a card straight from the API works fine — the break only bites your own code if it constructs an AlignmentCard object using the old autonomy_envelope=/audit_commitment= constructor keywords.Upgrading to AAP & AIP 1.0.0
Backward compatible. Existing 0.x alignment cards continue to work unchanged. The 1.0.0 server accepts every 0.x card shape. Update at your own pace.
The 1.0.0 stability commitment
The 1.0.0 release makes three explicit promises about what happens next:- Breaking changes now require a major bump to 2.0. Field renames, removals, type changes, or required-parameter additions cannot ship within 1.x.
- Each major version is supported for 18 months from the release of its successor (see API versioning). That 18-month window is longer than most APIs and reflects our commitment to agentic callers that cannot self-update in response to deprecation notices.
- Deprecation signals are explicit. Deprecated versions return
Deprecation,Sunset, andLinkresponse headers (see API versioning). No API version is deprecated as of this writing.
What changed
Nothing else changed. No alignment card schema edits, no endpoint removals, no signature changes.
Migration
Coming from 0.1.0? You can skip 0.5
The 0.x series was backward-compatible throughout — a0.1.0 card is still accepted by the 1.0.0 server. If you are on 0.1.0, you do not need to pass through the 0.1.0 → 0.5.0 guide first. Bump directly to 1.0.0 using the steps above; replace "0.5.0" with "1.0.0" wherever it appears in that guide’s examples.
The 0.5.0 guide remains online as a historical migration record (useful mainly for the YAML authoring and Trust Edges context it introduced, both of which carry forward unchanged).
What’s not in 1.0.0
Because 1.0.0 was a stability commitment rather than a redesign, several things were deliberately absent from that release:- No new endpoints. The API surface was the same as 0.5.x.
- No deprecations yet. No
DeprecationorSunsetheaders were emitted on any endpoint as of the 1.0.0 cut. - No unified agent card. The unified card shape (
autonomy,audit, unified alignment + protection cards) arrived shortly after, in mnemom-api’s ownunified/2026-04-15cutover, and later became the AAP 2.0.0 SDK shape (see above). - No changes to ZK proof formats or Merkle tree structure. Those are versioned separately by the AAP/AIP protocol specs, not by the SDK semver.
Where things stand now
AAP 2.0.0 shipped the card-field rename above. AIP has stayed at the 1.0.0 stability commitment through 1.3.0 — all additive, no breaking changes. A broader vision of unifying AAP alignment cards with policy YAML into a single agent-card format was floated in the 1.0.0-era CHANGELOGs; it has not shipped as of this writing, and no date is committed. Each SDK’s own breaking-change policy (a major bump required, per the 1.0.0 stability commitment above) is separate from mnemom-api’s own date-header API versioning — see API versioning for that policy’s 18-month support window, and pinX-Mnemom-Version in production so behavior stays stable until you choose to migrate.
Checklist
FAQ
Is 1.0.0 a breaking change from 0.x?
Is 1.0.0 a breaking change from 0.x?
No. The 1.0.0 server accepts every 0.x card shape, and no endpoint signatures changed. 1.0.0 is a commitment that future breaking changes require a major bump, not a redesign of the current surface.
Is AAP 2.0.0 a breaking change?
Is AAP 2.0.0 a breaking change?
Yes, but narrowly: two top-level
AlignmentCard field names moved (autonomy_envelope → autonomy, audit_commitment → audit). Field contents, endpoints, and AIP are unaffected. See Upgrading to AAP 2.0.0 above.Do I need to update all my agents at once?
Do I need to update all my agents at once?
No. Cards on different protocol versions coexist without issues. Roll the update at whatever cadence suits you.
What if I'm still on AIP 0.7.x with WindowManager?
What if I'm still on AIP 0.7.x with WindowManager?
AIP 0.8.0 (shipped the same day as 1.0.0 as the pre-1.0 audit) removed
WindowManager and createWindowState from public exports. Switch to createClient(), which manages window state internally, before jumping to a current AIP release.Will 1.x AIP get new features?
Will 1.x AIP get new features?
Yes — 1.1.0 through 1.3.0 have all been additive (new optional fields, no removals or renames).
See also
- API versioning — Pinning to a specific
X-Mnemom-Versiondate header and understanding the support window. - Alignment Card Management — Creating, claiming, and linking cards.
- Alignment Cards — Schema reference for the current card model.
- Upgrading to AAP 0.5.0 — Historical migration record for the
0.1.0 → 0.5.0jump. - Changelog — Full release history.