“Start the database before integration tests” can be a useful memory. After the tests switch to an in-memory implementation, the same note creates unnecessary work. Successful retrieval does not establish that a memory remains correct.

LoreKit creator Mads Thines's November 7 article proposes agreement on shared memory formats and meaning. Checked November 8, it is neither an accepted standard nor a performance benchmark. Beyond the briefing's observability framing, its central question is what must survive when records move between tools.

The same sentence is not necessarily the same memory

Copying only a sentence loses context: its repository, supporting code revision, author and next review date. A team policy and a model's one-off inference need not have the same authority even if their wording matches.

The article distinguishes an MCP interface from agreement on the record itself. Our engineering interpretation is that connected read/write APIs are insufficient when expiry or archival state disappears during transfer. Successful format conversion and operational equivalence need different checks.

Separate retrieval from eligibility

This is an original conceptual flow for applying memory to code work, not a diagram of LoreKit's implementation. Reaching a search result does not remove the need for access, scope and validity checks.

Retrieve candidate memories
      │
      ▼
Check read permission and applicable scope
      │
      ▼
Check source revision, expiry and review status
      ├── mismatch → hold; record reason for review
      └── match    → offer as context for this task
                             │
                             ▼
                     retain record ID and rationale

Deletion is not the only useful outcome. A held record with a reason can explain how an obsolete conclusion entered the workflow. Retention also extends the life of sensitive material, so content and audit metadata need separate retention policies.

A four-condition example

This reduced schema is CodeBridge's own example, not LoreKit field names or a proposed standard implementation. It runs on Node.js 18 or later and does not replace authorization.

const record = {
  id: 'test-db-requirement', scope: 'repo:example/app',
  source_revision: 'commit-A', expires_at: '2026-11-10T00:00:00Z',
  reviewed: true, content: 'Integration tests require a local database.'
};
function eligible(memory, context) {
  return memory.scope === context.scope
    && memory.source_revision === context.revision
    && memory.reviewed === true
    && Date.parse(memory.expires_at) > Date.parse(context.now);
}
console.log(eligible(record, {
  scope: 'repo:example/app', revision: 'commit-B',
  now: '2026-11-08T12:00:00Z'
}));

The output is false: the evidence points to commit-A while the task uses commit-B. The complete executable is retained at docs/editorial/2026-11-08/evidence/memory-validity.mjs. Run it with:

node docs/editorial/2026-11-08/evidence/memory-validity.mjs

Locally, we checked rejection after a revision change, expiry and missing review, plus acceptance of a matching revision. These are synthetic records with no model calls, external services or product installation.

Invalidating on every commit has a cost

This example is deliberately conservative. A documentation commit can reject every memory. Tracking the particular files, APIs or settings a note depends on could narrow invalidation, but introduces dependency mapping and ownership work.

Policy Benefit Added cost or risk
Compare the repository commit Simple, reproducible decision Unrelated edits also hold the memory
Compare relevant file hashes Narrower invalidation Indirect dependencies may be missed
Use expiry alone Easy to implement Misses code changes before expiry
Require owner review Allows contextual judgment Review queues and accountability

This is a design comparison, not measured performance. None guarantees truth. A signature or author field can help establish who wrote a record; it cannot establish correctness. Automatically promoting shared memory into executable instructions can also spread poisoned records or prompt injection.

Round-trip records before switching memory tools

Prepare valid, expired and archived records, plus one with an unknown extension field. Export from tool A, pass through B, then import back into A. Check identity, scope, source and state, not just the sentence body.

The useful question in LoreKit's proposal is whether another tool can interpret a memory correctly. Start by making one current note's application explainable: why did this record qualify for this task? That can be answered before installing another memory server.

Background: Context, session state and persistent memory.