A Memory Contract Survived a Second Implementation

A specification becomes more useful when another implementation can disagree with it. That happened this week around CML Current-State Applicability: a second public agent-memory implementation consumed the frozen fixture verbatim, implemented the six-outcome contract, and turned a discussion about memory safety into an inspectable interoperability loop.

What we verified directly.

The CML fixture tests/fixtures/memory_applicability_v0.1.json and the vendored Inspeximus fixture tests/fixtures/cml_memory_applicability_v0.1.json have the same Git blob SHA:

ec27aad145c6051e22e993a4ef30e57a9063af48

Because Git blob identity is content-addressed, that gives an inspectable repository-level check that the fixture contents are byte-for-byte identical.

The public Inspeximus conformance test then loads that frozen file, requires at least fifteen cases, checks that all six applicability outcomes appear, runs every case through its own evaluate_applicability(), asserts expected_status, and asserts every declared expected_reasons.

The state transition matters more than the score.

Earlier in the exchange, the second implementation could reproduce several source-integrity outcomes but could not produce REVALIDATE because it did not bind memory to the current repository, commit, tenant, policy, model or validity window. That disagreement was productive: a missing capability became explicit rather than hidden behind similar terminology.

The second implementation then adopted the six-outcome applicability contract:

REJECT → UNRESOLVABLE → ORPHAN → DRIFT → REVALIDATE → MATCH

Two rules became especially important: source failures outrank environment drift, and absence of historical repository/commit binding is not permission to assume continuity.

The loop then created a new failure class.

The external discussion produced a harder case: a derived memory can still match its own source while one of the records it was derived from has been superseded, retired, erased or changed. Source integrity alone cannot see that failure because the derived record itself may remain unchanged.

CML turned that case into a lineage/supersession extension and merged PR #272 to main. The resulting contract is:

source integrity
→ lineage / supersession
→ current-state applicability
→ authority
→ action
→ evidence

The CML merge commit 0c27e1918c27e5223fe8343df0aac77b2db5ccdb passed post-merge CI, Python Package Validation and Security Baseline on the exact main state.

Why this is an Engineering Signal, not an endorsement story.

DanceNitra is an external open-source contributor participating in a public issue inside the Anthropic Claude Code repository. This signal is not an Anthropic endorsement, product commitment or official Anthropic implementation.

RESONANCE records the event because the causal structure is useful:

That is a stronger signal than a positive comment because each transition leaves an artifact that can be inspected or falsified.

The next verification gate is still open.

The lineage contract should not inherit credibility from the earlier 15/15 result. It needs its own reproduction.

CML memory_lineage_v0.1.json
→ vendor byte-for-byte
→ second implementation
→ compare expected_status
→ compare expected_reasons
→ compare exclusion accounting
→ freeze agreement OR disagreement

Until that happens, lineage interoperability remains pending.