Memory across repeat calls: identity, consent, and expiry

TL;DR: Persist repeat-call memory only with an exact subject, allowed purpose, current consent state, provenance, and explicit expiry. Recheck those boundaries after waiting and reject late writes from revoked consent revisions so a previous call cannot silently restore withdrawn memory.

---

A returning caller asks the agent to remember a harmless preference. On the next call, the system finds that preference and treats the entire old conversation as reusable context.

The convenience is real, but the data boundary changed. A preference, a transient task detail, and a historical account observation do not share the same purpose or lifetime simply because they appeared in one call.

Begin with a memory eligibility contract. Every persisted record needs an owner, a reason it can be used, evidence of the state under which it was stored, and a clear end to its eligibility.

This guide provides a generic immutable record, a small admission function, and runnable consent and expiry fixtures. It separates authentication, authorization, memory consent, source freshness, and physical deletion instead of treating one flag as permission for every operation.

All records and identifiers are synthetic. The examples describe generic application boundaries, not private 60db Agent architecture, legal compliance certification, or measured production behavior.

Table of contents

1. Decide what should persist
2. Resolve identity before recall
3. Model purpose and consent revisions
4. Run a memory eligibility contract
5. Make expiry an explicit outcome
6. Reject late reads and writes
7. Trace memory without copying conversations
8. Handle deletion and derived records
9. Validate the repeat-call experience
10. Deploy a narrow memory feature
11. Review the memory lifecycle as separate decisions
12. Keep authority separate from convenient storage
13. Frequently asked questions
14. Begin with one explicit preference

Decide what should persist

Cross-call memory should solve a defined returning-caller problem. A response-language preference can reduce repeated setup, while retaining an entire unfinished transcript may add sensitive context that the next task does not need.

Classify facts by purpose and change rate. Durable preferences, current account state, completed business records, and transient conversation details need different treatment even when a model can summarize all of them into one paragraph.

A preference can be useful memory when the person explicitly wants it reused. Current account state usually needs an authoritative read because the value can change outside the voice system between calls.

A completed booking belongs in the business system of record. Memory can retain an authorized reference where justified, but it should not become a second independent database that silently disagrees with the actual booking.

An unfinished task needs an explicit resumption policy. A later call may concern a different goal, and automatic resumption can expose the previous task or apply old assumptions before the person has confirmed what they want now.

The resumption guide discusses continuity inside a conversation. Across calls, add renewed identity, purpose, and eligibility checks before carrying that continuity forward.

LangGraph's public persistence documentation distinguishes thread-scoped checkpoints from longer-lived stores. That is a useful storage distinction, while your application still decides what data is allowed in either place.

A thread identifier is not a person identifier. Likewise, a store namespace can organize records without proving that the current caller is entitled to the data in that namespace.

Write down the smallest useful record for the feature. For a language preference, the canonical value and its provenance may be enough; a raw transcript and recording are unnecessary for ordinary reuse.

A smaller record is easier to inspect and delete. It also makes it harder for irrelevant old statements to influence a new task through broad prompt context.

The local versus managed voice AI guide helps identify which services receive the record. Evaluate actual data flow and access controls rather than assuming that a memory feature is private because it runs in one favored deployment style.

Resolve identity before recall

A returning endpoint does not establish a returning person. Shared phones, assistants calling on someone else's behalf, reassigned numbers, and forwarded calls all break that assumption.

NIST's digital authentication guidance distinguishes authenticated subjects and sessions. Use a suitable verified identity flow for the application's risk rather than treating a familiar caller ID as proof of the memory owner.

The shared-phone isolation guide focuses on that boundary. Before verification, the agent can provide public help without revealing whether private history exists for the endpoint.

Identity is still not full authorization. A verified person may lack access to a particular account, purpose, or historical record, so the data-access path needs a current permission decision.

OWASP's authorization guidance recommends deny-by-default behavior and validating permissions on each request. Apply that principle to memory recall as well as business APIs.

Keep tenant and subject as separate scope dimensions where the product has tenants. A subject identifier that is unique only within a tenant can collide when a cache or store forgets the tenant dimension.

Do not ask a caller to confirm a private memory before authenticating them. "Are you still dealing with the issue from your last appointment?" can disclose sensitive history even if the system withholds the detailed record afterward.

A neutral identity step should avoid confirming record existence. If the task can continue without private recall, offer that route while the required verification is unavailable.

Identity can change during a call. A phone may be handed to someone else, or the caller may clarify that they represent another person, and prepared recall must be invalidated before continuing under the new scope.

Treat that transition as a new authorization context. Do not update only the displayed name while leaving the old subject's memory bundle in the response prompt or output queue.

The query correction guide supplies the revision pattern for invalidating dependent work. An identity change needs at least as much care as a corrected search condition because it changes who may receive the evidence.

Model purpose and consent revisions

Consent to remember one preference is narrower than permission to retain and reuse every spoken fact. Represent the allowed purpose explicitly so a record approved for one feature cannot silently become general context for another.

Separate the ability to write memory from the ability to read it. A task may permit temporary use of a fact without allowing durable storage, and a storage policy may restrict later recall to the same purpose.

Use a revision for the current consent state. A record created under an older revision can be rejected after revocation, even if a delayed writer tries to save it after deletion has already started.

A later regrant should create a new revision. Do not assume that allowing memory again restores every historical record that was previously revoked or deleted.

The policy can require explicit migration or fresh collection for old records. Whatever rule you choose, make it visible in the record contract and fixtures instead of relying on the physical presence of an old row.

The comparison table describes approaches rather than compliance categories. A check means a property is explicitly represented; a cross means that property needs another mechanism.

A revision is an ordering and eligibility tool. It does not prove the caller received an adequate explanation or that a particular consent policy satisfies every jurisdiction and business requirement.

This guide concerns the engineering contract. Define the user-facing choice and applicable requirements with the responsible product, privacy, and legal owners rather than presenting the sample flag as a universal compliance solution.

Run a memory eligibility contract

Save the complete fence as memory_eligibility.py and run Python 3.11 or later. It implements eligibility for one immutable candidate record and uses event-driven fixtures to force a revocation while a read is waiting.

The trusted adapter owns authentication, authorization, consent collection, current revision allocation, storage transactions, and clock policy. Constructing Access is not an authentication mechanism.

A successful outcome means the record may be used at this local boundary under the supplied trusted state. It does not establish future eligibility, physical deletion, source truth, or permission to perform a business action.

import asyncio
import math
from dataclasses import dataclass, replace, FrozenInstanceError


@dataclass(frozen=True)
class Memory:
    tenant: str
    subject: str
    purpose: str
    consent_revision: int
    expires_at: float
    value: str
    source: str

    def __post_init__(self):
        strings = (self.tenant, self.subject, self.purpose,
                   self.value, self.source)
        if any(type(v) is not str or not v for v in strings):
            raise ValueError("nonempty string fields required")
        if type(self.consent_revision) is not int or self.consent_revision < 0:
            raise ValueError("invalid consent revision")
        if type(self.expires_at) not in (int, float) or not math.isfinite(self.expires_at):
            raise ValueError("finite expiry required")


@dataclass(frozen=True)
class Access:
    tenant: str
    subject: str
    purpose: str
    consent_revision: int
    allowed: bool
    consent: bool


def eligible(record, access, now):
    if type(now) not in (int, float) or not math.isfinite(now):
        raise ValueError("finite current time required")
    if not access.allowed:
        return "unauthorized", None
    if not access.consent:
        return "revoked", None
    if record is None:
        return "missing", None
    if (record.tenant, record.subject) != (access.tenant, access.subject):
        return "wrong_owner", None
    if record.purpose != access.purpose:
        return "wrong_purpose", None
    if record.consent_revision != access.consent_revision:
        return "stale_consent", None
    if now >= record.expires_at:
        return "expired", None
    return "eligible", record.value


async def read_after_wait(record, current_access, clock, wait):
    await wait()
    return eligible(record, current_access(), clock())


def tests_sync(record, access):
    assert eligible(record, access, 0) == ("eligible", "English")
    assert eligible(record, access, 10) == ("expired", None)
    assert eligible(None, access, 0) == ("missing", None)
    for changed, expected in (
        (replace(access, tenant="other"), "wrong_owner"),
        (replace(access, subject="other"), "wrong_owner"),
        (replace(access, purpose="unrelated"), "wrong_purpose"),
        (replace(access, consent_revision=1), "stale_consent"),
        (replace(access, consent=False), "revoked"),
        (replace(access, allowed=False), "unauthorized"),
    ):
        assert eligible(record, changed, 0) == (expected, None)
    try:
        record.value = "changed"
        raise AssertionError("record was writable")
    except FrozenInstanceError:
        pass
    regranted = replace(access, consent_revision=2)
    assert eligible(record, regranted, 0) == ("stale_consent", None)
    for bad in (float("nan"), float("inf")):
        try:
            replace(record, expires_at=bad)
            raise AssertionError("invalid expiry accepted")
        except ValueError:
            pass


async def tests():
    record = Memory("demo-tenant", "demo-subject", "language", 0,
                    10.0, "English", "synthetic-explicit-preference")
    access = Access("demo-tenant", "demo-subject", "language", 0,
                    True, True)
    tests_sync(record, access)
    started, release = asyncio.Event(), asyncio.Event()
    live = [access]

    async def wait():
        started.set()
        await release.wait()

    task = asyncio.create_task(read_after_wait(record, lambda: live[0],
                                               lambda: 0.0, wait))
    await started.wait()
    live[0] = replace(access, consent=False, consent_revision=1)
    release.set()
    assert await task == ("revoked", None)
    # The same gate is required atomically before a late durable write.
    assert eligible(record, live[0], 0) == ("revoked", None)
    print("synthetic memory eligibility fixtures passed")


if __name__ == "__main__":
    asyncio.run(tests())

Python's dataclasses documentation describes frozen attributes. The supported record uses immutable scalars, so the example does not retain caller-owned mutable dictionaries inside an apparently frozen wrapper.

The late-write assertion checks the decision a storage adapter must enforce. It does not implement an atomic database write, and applying the check separately from a later write would leave a race the adapter must close.

For a real store, make consent-revision validation and the protected write atomic under that store's transaction or compare-and-set contract. Preserve the same negative fixture against the real adapter before claiming late-write protection in deployment.

Make expiry an explicit outcome

Expiry means the record has reached the end of its eligible lifetime. Missing means no candidate record was found, and revoked means current consent disallows use, so the controller should keep those outcomes distinct.

A missing preference can lead to a neutral question. A revoked preference should not cause the agent to recollect the same information through repeated pressure or silently reenable memory.

Use the exact deadline comparator in tests. This guide treats equality with expires_at as expired, eliminating uncertainty about whether a record survives one more local admission at the boundary.

Storage expiration can help remove bytes, but the read path still needs an eligibility check. Redis documents EXPIRE as a storage lifetime mechanism; its cleanup behavior is not a substitute for the application's consent and owner checks.

A record can be physically present and ineligible. It can also have been removed from the main store while an in-flight reader still holds its value, which is why recall must recheck before use.

Do not refresh a lifetime merely because the record was read. Sliding expiration can turn a narrowly retained preference into effectively permanent memory for a frequent caller unless that behavior is an explicit accepted policy.

A deliberate update can create a new record with a new lifetime. Preserve the relationship to the source and consent revision so the application can distinguish a fresh user choice from a background reread of old data.

Current account facts need source freshness in addition to memory expiry. The answer caching guide shows why a record can be within its memory lifetime while its financial or operational value is already obsolete.

Reject late reads and writes

The dangerous revocation race begins with work authorized under an old consent revision. The caller withdraws permission, deletion runs, and a delayed worker writes the old memory back afterward.

A boolean checked only when the worker starts cannot prevent this. The worker must present the consent revision it used, and the storage boundary must compare it with current state before committing.

Revocation should advance the revision even when there are no records to delete. That barrier protects against work still in flight, which a scan of current rows cannot see.

A regrant should advance it again. Old work from before revocation remains obsolete, and the new state can accept explicitly collected or migrated records under the new revision.

For reads, apply the same principle after waiting. The event-driven fixture holds the read, changes consent, and releases it, proving that old eligibility cannot be treated as a lasting permission token.

OWASP's session management guidance describes session invalidation and lifetime concerns. Keep your authenticated session and memory-consent lifetimes separate, then require both to be current when private recall needs them.

A caller ending the call can also invalidate pending output. Closing the conversation should prevent prepared private memory from being replayed by an exact retry or delayed completion.

The shutdown semantics guide covers terminal ownership. Memory retrieval completion can remain historical evidence while the closed response remains ineligible to speak.

Trace memory without copying conversations

A memory decision needs enough evidence to explain why a record was eligible or withheld. It rarely needs the full prior conversation in every ordinary log event.

Record owner scope, purpose, source reference, consent revision, expiry policy, and outcome. Separate those fields from the actual value so routine operational access does not automatically reveal the preference or historical fact.

W3C's PROV overview offers a provenance vocabulary. The practical goal here is a trace from the persisted record to its source and the activity that created or transformed it.

A summary should preserve its source relationship. If the source was deleted or its reuse authority changed, the derived summary should not become an orphan that continues to supply the same facts indefinitely.

Use synthetic canary values for isolation tests. A harmless phrase stored under one subject can establish that another subject never receives it without exposing a real person's data during debugging.

The voice observability guide explains boundary-oriented telemetry. Add memory admission events to that trace while keeping authentication secrets, raw transcripts, and private values out of broad log streams.

Keep original revision and clock inputs for synthetic reproduction. A derived label such as stale_consent is useful, but the original record and current revision explain why the label was correct.

Do not claim a successful deletion from a missing read alone. Missing can result from the wrong namespace, an unavailable replica, an expired key, or an access filter, so deletion completion needs its own evidence.

Handle deletion and derived records

Deletion is a workflow across the representations your application created. A primary memory row, embedding, cached answer, generated audio asset, and diagnostic copy can all carry the same original fact.

Define the scope before implementing the button. The user-facing operation should say what it affects, while engineering records should identify the owning stores and completion evidence.

A tombstone or revocation barrier can prevent old work from restoring deleted data. It is not the same as removing every retained byte, so report those states separately.

Backups and required retention need an explicit policy outside the sample program. Do not promise immediate physical erasure everywhere because the online memory lookup now returns missing.

A deletion request can race with a new explicit preference. Use identity and revision boundaries to distinguish newly authorized input from a delayed old write rather than deleting or reviving records based only on arrival time.

If the system supports selective deletion, preserve purpose-level boundaries. Removing a language preference should not accidentally remove the system-of-record booking, and deleting task memory should not leave its derived personalized answer reusable elsewhere.

The workflow enforcement guide separates conversational context from business authority. A memory deletion operation should not mutate business records unless that action is explicitly part of the accepted product contract.

Validate the repeat-call experience

Validate both eligibility and the caller-facing behavior. A correct rejection can still create a confusing experience if the agent claims to remember something and then refuses to explain what it meant.

Before verification, the response should remain neutral about private history. After verification and admission, it can use the eligible preference without reciting unnecessary details from the previous call.

A community question asks about sharing context across assistant threads. That is an application-design question as well as a storage question: decide which identity and purpose authorize each cross-thread transfer.

Do not turn a forum example into a current product guarantee. SDK and service contracts change, while the application still owns its memory scope and negative isolation tests.

Build repeat-call fixtures that vary one boundary at a time. Keep the subject fixed and revoke consent, keep consent fixed and cross the expiry deadline, then change the subject while preserving the endpoint.

The voice regression guide provides the replay pattern. Retain exact expected outcomes so a fluent answer cannot pass a test that should have withheld memory.

For usability, ask whether the caller can correct or decline the remembered preference. The agent should apply the new accepted choice without using the old memory as evidence that the caller must still want it.

The spoken correction guide helps model that replacement. A preference update should be explicit current state, with prior versions retained only where the approved audit and retention policy calls for them.

Deploy a narrow memory feature

Begin with one low-sensitivity explicit preference and a clear way to decline, change, or remove it. This makes the feature's purpose and failure behavior inspectable before broader recall is introduced.

Do not begin by summarizing every call into long-term memory. A summary can preserve private details and mistaken inferences that the next caller never intended to reuse.

Keep the non-memory path functional. If identity verification or memory storage is unavailable, the agent can ask for the necessary current preference or continue with public help rather than guessing from endpoint history.

Measure useful avoided repetition alongside wrong-owner, revoked, expired, and stale-revision rejections. A rising recall rate is not automatically good if the system is broadening the circumstances under which old data is used.

The cost per successful task guide helps keep the denominator honest. A small convenience saving cannot justify counting an incorrectly personalized call as a success.

This article reports no production recall rate or privacy incident reduction. Its runnable program verifies a local decision contract, while real storage atomicity, authentication, deletion, and physical audio behavior need their own adapter evidence.

Review the memory lifecycle as separate decisions

Memory collection, durable write, retrieval, answer construction, and deletion happen at different times. A single allowed result at collection cannot prove that every later step remains eligible.

Draw the lifecycle using the actual stores your feature reaches. Include the source record, derived summaries, search representations, answer caches, prepared output, and the authority state each operation must consult.

Keep the drawing generic in public documentation if implementation details are private. Internally, make the concrete ownership and deletion routes inspectable enough that an engineer can identify the responsible adapter for a failed boundary.

At collection, distinguish an explicit user preference from an inferred behavior. Choosing a language for one call may be a temporary convenience rather than a request to persist that language across future calls.

At durable write, validate the current scope and consent revision in the storage transaction. Work that began before revocation should not become eligible because its result happened to arrive after the caller changed their choice.

At retrieval, constrain candidate selection before private content enters a model or broad search consumer. A final answer filter cannot undo the earlier exposure of another subject's memory to an unauthorized processing path.

At answer construction, carry the record's eligibility evidence with the approved claim. The response builder should not receive a bare value whose owner, purpose, and expiry were discarded by a convenient helper.

At output admission, recheck the current response generation and any record conditions that can change during waiting. The audio backpressure guide describes why a held item can become obsolete even while its queue is empty.

At deletion, mark online ineligibility and physical cleanup as separate states. A revoked record can be blocked immediately under a current authority check while cleanup proceeds across the approved retention and backup workflow.

This separation helps the caller-facing explanation stay accurate. Saying memory is no longer used can be supported by an eligibility barrier; saying every byte is erased needs the broader deletion evidence your actual system can provide.

A tombstone needs its own lifetime policy. Removing it too early can allow a delayed writer to recreate an old record if that writer's delivery window outlives the barrier.

Choose that retention using the real retry and recovery contract. Do not invent a universal duration, and do not leave a permanent identifier merely because keeping every tombstone is easier than documenting the delivery boundary.

Failure recovery must preserve revision identity. If consent state restarts at an old number after a process failure, a delayed record could appear current unless a durable owner or new identity epoch prevents that collision.

The compact reference program assumes trusted current state and does not implement restart persistence. Your adapter tests should restart the relevant component with an old write still pending and assert that the recovered authority rejects it.

Distributed replicas introduce another boundary. A stale consent replica can authorize a record after revocation unless your design specifies where the authoritative comparison occurs and what consistency the protected operation requires.

Keep that requirement attached to the use case. A public preference suggestion and disclosure of sensitive historical information can have different consequences, but both need an explicit policy rather than an accidental replica choice.

Do not hide an unavailable authority service behind a generic cache miss. Missing memory can permit a fresh neutral question, while unavailable eligibility evidence may require withholding the private record until the trusted state can be established.

Use typed outcomes in operational traces so those states remain visible. The reference separates missing, expired, revoked, wrong-owner, wrong-purpose, stale-consent, and unauthorized results for that reason.

The order of those outcomes is part of the contract. For example, an unauthorized request should not learn whether a matching private record exists through a detailed internal disposition accidentally exposed to the caller.

Keep detailed reasons in the controlled diagnostic channel. The ordinary response can remain neutral while still giving authorized engineers enough evidence to investigate a misconfigured scope or an unexpectedly stale revision.

A record's source can also lose authority. If an inferred preference was corrected, the newer accepted choice should replace its use even when the old record has not reached its nominal expiration time.

The spoken self-correction guide explains why old and new values should not be concatenated. A memory update needs the same clarity about which field was replaced and which evidence remains historical.

Avoid merging conflicting preferences automatically. If two devices provide different current choices, resolve the domain rule or ask a narrow question rather than treating the most recently delivered message as the most recent human intent.

Delivery time and event time can differ. A delayed message from an earlier call should retain its original identity and revision evidence instead of overwriting current state merely because it arrived last.

For inference-derived records, preserve the distinction between an observation and an accepted fact. A caller repeatedly asking for slower speech is evidence about those interactions; storing a permanent accessibility profile can be a materially different feature requiring explicit product boundaries.

Do not expose inferred sensitive attributes through a friendly returning-caller greeting. The feature should reuse only eligible records for the stated purpose, not surprise the person with conclusions they never asked the system to retain.

A useful review asks what the system would say if memory were wrong. The caller should be able to correct a preference without a dispute, and the correction should invalidate dependent output before another old sentence is submitted.

The retrieval-to-speech guide covers short supported units. A remembered preference can shape presentation, while the factual answer still needs current eligible evidence for the question being asked.

Build a fixture matrix with one row per boundary and one expected recovery. Wrong-owner records are withheld, expired preferences can be recollected where appropriate, revoked memory remains unused, and unavailable authority does not become permission to guess.

For late writes, keep both orders. In one fixture the old write commits before revocation and is then made ineligible; in another revocation commits first and the old write must fail its atomic admission.

For regrant, test an old stored record and newly collected input separately. The old record stays stale under the new revision, while the new input can be admitted only through the current policy.

For a call ending, hold a read until shutdown completes and release it afterward. The result can be recorded for accounting but must not create a new response or restore the closed generation.

The playback evidence guide helps interpret what happened to any previously submitted audio. A later memory revocation cannot retract sound already heard, so report the actual boundary rather than promising retroactive non-disclosure.

For deletion, enumerate derived assets using lineage and test a harmless canary. The canary should become unavailable through every ordinary recall route covered by the deletion contract, while backup handling follows its separately stated policy.

A successful canary test is evidence for that route and fixture. It does not prove that no other copy exists anywhere, so retain the inventory and completion evidence needed for the broader claim.

Before enabling another memory class, compare it with the first feature's boundaries. A new class that changes identity requirements, consent purpose, source freshness, or deletion scope deserves its own review and fixtures instead of inheriting approval merely because both features use the same table.

Keep authority separate from convenient storage

A record schema is useful only when the real read and write paths consume its fields. Review helper functions that return a bare value, because they can erase the owner and consent evidence before the response builder needs to decide whether reuse is allowed.

Prefer passing an eligible record bundle with its decision inputs over copying its value into an unscoped conversation summary. The latter creates another memory representation whose deletion and authority rules may be undocumented.

Make storage failures explicit in the caller experience. A failed preference write should not produce a confident promise that the system will remember it next time, and a failed delete should not be reported as completed physical erasure.

The truthful waiting speech guide provides the general communication boundary. Describe work as pending while it is pending, and state the supported outcome only after the responsible adapter returns evidence for that outcome.

A successful online write also has a bounded meaning. It establishes acceptance under the storage contract, while future recall still depends on identity, purpose, consent revision, expiry, and the state of derived representations.

Keep those limitations in the feature's operational notes and test plan. That makes it possible to improve availability without quietly weakening privacy or reviving obsolete records as an emergency fallback.

---

Frequently asked questions

What should memory across repeat calls contain?

Persist the smallest explicit fact that solves the returning-caller task, with owner, purpose, source, consent revision, and expiry. A durable preference can be appropriate while raw transcripts and changing account facts need different treatment.

Is caller ID enough to recall private memory?

Caller ID identifies an endpoint under the transport's contract, not necessarily the person speaking. Shared and reassigned phones require a verified subject and current authorization before private recall.

How is memory different from account data?

Memory supports continuity under a defined reuse policy. Current account data belongs to an authoritative business source, and an old remembered observation should not silently replace a fresh read when the task needs present state.

Does consent to remember one fact cover everything?

Consent should be scoped to the explained purpose and supported feature. A language preference does not automatically authorize storing recordings, retaining all task details, or using the record for unrelated personalization.

Why use a consent revision?

A revision lets the storage and read boundaries reject work created under an obsolete consent state. It prevents delayed pre-revocation work from becoming eligible merely because it arrives after a deletion or later regrant.

Should regrant restore old memory?

Regrant should create a new revision, and old records should remain ineligible unless the product explicitly authorizes a controlled migration or fresh collection. Physical presence alone is not a valid restoration policy.

What happens at the expiry deadline?

The reference rejects memory when current time equals or exceeds its expiration time. Exact-boundary fixtures keep the read path independent of a storage engine's eventual cleanup timing.

Is expired the same as missing?

Expired means a found record failed its lifetime policy, while missing means no candidate was found. Keep the outcomes distinct for diagnostics and recovery when the controller must suppress prepared output.

Can a late write recreate revoked memory?

It can if the adapter checks consent only before starting work. Validate the record's consent revision atomically with the durable write, and test a delayed old write released after revocation.

Why recheck after a read waits?

Identity, authorization, consent, or expiry can change while the operation is suspended. Repeat eligibility at the protected use boundary, and repeat it again after any additional asynchronous step.

Does the sample implement database atomicity?

The sample implements a local eligibility decision and a late-write decision fixture. A real storage adapter must close the check-to-write race with its own transaction or compare-and-set contract before claiming deployed protection.

Can an authenticated caller access every memory?

Authentication establishes a subject under the identity system's assurance. Authorization, purpose, consent, record ownership, and lifetime still determine which memory that subject may use for the present task.

Should reading memory extend its life?

Read-based extension is a product policy that can create effectively permanent retention. Keep the original deadline unless an explicit accepted rule or a new authorized update establishes another lifetime.

How should remembered facts be corrected?

Apply the caller's current accepted correction to the relevant record and invalidate dependent prepared output. Preserve older versions only under the defined audit and retention policy, rather than presenting them as equally current preferences.

Does deleting the main row delete everything?

A main-row deletion does not prove removal of embeddings, cached text, audio, logs, or backups. Define the derived-data workflow and collect separate evidence for online ineligibility and the requested physical deletion scope.

Can memory be used before verification?

Public nonpersonal help can proceed before private recall. Avoid revealing whether private history exists, and keep the remembered value withheld until identity and the remaining eligibility boundaries pass.

What belongs in a memory trace?

Record scope, purpose, source reference, consent revision, expiry inputs, and disposition with minimal private content. Keep the original decision inputs available in a controlled reproduction path rather than relying only on a derived outcome label.

How should unavailable memory behave?

Unavailable memory should produce a truthful fallback, such as asking for a current preference when appropriate. It should not cause the agent to guess from a phone number, reuse an old unrestricted summary, or claim that the record was deleted.

What does the synthetic harness prove?

It proves the stated local owner, purpose, consent-revision, expiry, and immutable-record decisions under its fixtures. It does not establish legal compliance, authenticated identity, distributed storage correctness, or completed deletion across all representations.

Where should a team start?

Choose one explicit preference with a narrow purpose and an ordinary non-memory fallback. Test wrong-owner recall, revocation during a wait, exact expiry, regrant, and delayed old writes before expanding what the system remembers.

Begin with one explicit preference

Implement one record whose owner, purpose, source, and end of eligibility can be explained without a transcript. Run the local fixtures, then repeat the late-write race against the actual storage adapter that will commit the record.

Only expand recall after the repeat-call experience and deletion workflow preserve those boundaries. The useful evidence is a trace showing eligible reuse and correct withholding, with the remaining adapter responsibilities stated plainly.