Memory is an authority and data-lifecycle boundary. A remembered statement can influence later actions, reveal another person’s information or survive long after its original purpose expires. Promotion helps, but a promoted row is not automatically true, current or authorized for the next reader.
October 16 revision: the former copy-paste database implementation is withdrawn. Its promotion function accepted a review for a different candidate without an approval record. Its anonymous recall predicate returned user-scoped rows. Unbounded immutable capture, evidence-count priority and operator-source durability also failed to establish entitlement, truth or retention. The reference below validates records; production storage, authentication, review, contradiction analysis and propagation adapters remain implementation obligations.
The canonical sources are Memory, Memory Fabric and the execution contract.
The lifecycle, with two different kinds of evidence
eligible source → scoped proposal → review of exact intent → authorized promotion
↓ ↓ ↓
bounded retention trusted decision current recall
└──────── correction / deletion with copy receipts ───┘Semantic evidence supports the proposed fact. Control evidence supports who may store, review, read or change that fact. A convincing source does not grant permission; a valid permission does not make a fact true.
The lifecycle operations are propose, promote, correct and delete. Propagation is separately pending, confirmed, failed or external_unknown. Admission of a deletion request and confirmed deletion are different outcomes.
Step 1 — admit before capture
Authenticate the current actor and derive owner, tenant, namespace, purpose and allowed readers from a trusted authority adapter. Do not accept these as self-authenticating request fields. Intersect the current owned mandate with every ancestor’s scope, audience, expiry and revocation. Validate provenance, content limits, classification, source permissions and actual processing route before placing text in a candidate store or embedding service.
A capture queue is already a data store. Give it finite retention, quotas, access controls, correction/deletion handling and an explicit cleanup owner. Append-only audit events can preserve minimal eligible metadata; they do not justify retaining all raw content forever. Do not copy sensitive content into an error, trace or rejected-candidate log by default.
Deduplicate by stable intent through protected atomic storage. A generated identifier alone neither authorizes a write nor prevents repeated proposals. Proposed candidates cannot assign themselves a public label or unrestricted readership.
Step 2 — review semantics and exact control intent
Review duplicates and contradictions within the authorized scope. Embedding similarity can retrieve candidates; it cannot prove equivalence or contradiction. A newer timestamp or longer evidence list is not a truth ranking. Resolve authority, source lineage, time scope, independent corroboration and applicability explicitly. Preserve unresolved conflicts and prevent their use where required.
The reviewer must see the exact candidate content reference, operation, owner/tenant/namespace/purpose/readers, retention, policy and derived-copy inventory. The reference binds the review to the complete lifecycle intent under contextos.memory_lifecycle_intent.v1. It rejects mismatched, expired, denied or untrusted observations. Trusted adapters must establish reviewer authenticity and current entitlement; setting verification_status: "verified" in client JSON does not establish either.
Tier names such as working, episodic, semantic and durable are application retention categories. They are not permission levels. Operator-origin material does not automatically deserve permanent retention, and automatic promotion is permitted only where the current policy and required review allow it. Separate proposer and required independent approvers.
Step 3 — validate using the actual reference
The repository exports MemoryLifecycleRecord, MemoryLifecycleContext and validateMemoryLifecycle. This wrapper delegates to that deterministic validator without inventing a second promotion policy:
import {
validateMemoryLifecycle,
type MemoryLifecycleRecord,
type MemoryLifecycleContext,
} from "@/lib/contextos/execution-boundary"
export function inspectMemoryIntent(
record: MemoryLifecycleRecord,
trustedContext: MemoryLifecycleContext,
evaluationTime: string,
) {
const result = validateMemoryLifecycle(record, trustedContext, evaluationTime)
return {
admitted: result.allowed,
reasons: result.reason_codes,
propagation: result.propagation_status,
completionVerified: result.completion_verified,
}
}evaluationTime is an explicit trusted UTC input. The validator performs no database write, source verification, copy discovery or erasure. It checks supplied bounded records and observations. The result must remain bound to the exact operation while a production adapter atomically verifies current state and performs the authorized transition; a prior positive result is not a reusable write capability.
The context carries current allowed readers/operations, required review, maximum retention, trusted observers, access observation, data-flow request/policy and known copy inventory. A complete record binds run/contract/operation/action identities and immutable artifact references. The real schema is published at /schemas/execution-contract.schema.json; abbreviated strings in a design document are not valid artifact digests.
The protected dispatcher must also enforce exact full-action approval where required, native risk, guardrails, active containment/credential/data controls, provider preconditions and original shared reservations. Applicable policy-expression errors stop compilation with structured diagnostics. None of these conditions is discharged merely by a memory review.
Step 4 — recall under current readership
Recall is a new authorized data flow. Derive its predicates from current authenticated scope, including owner, tenant, namespace, purpose, intended reader, subject, classification, source permissions, expiry, retraction and conflicts. Missing identity must not broaden a user-specific query. A tenant predicate supplied by a caller does not make cross-tenant access structurally impossible; enforce tenant isolation in the authenticated storage boundary as well.
Use deterministic tie breaking and bounded result/token limits. Refresh access and provenance before returning content, including cache hits. Retraction filters prevent future eligible recall, but do not erase previous prompts, caches, embeddings, summaries or exports. Prevent stale replicas from serving withdrawn content and track their state.
The compiler’s stage 5 consumes caller-supplied promoted_memory; it does not call a SQL recall function, authenticate readers or search a backend. Its PromotedMemory shape uses memory_ref, content, source_refs, freshness and optional hash/time fields. The application’s richer lifecycle storage record must be mapped deliberately. The compiler accepts a legacy string form with warnings for compatibility; that is not a governed memory service.
Step 5 — correct or delete every known copy
A correction can replace a fact’s usable content while retaining eligible minimal lineage. Whether raw prior content may remain depends on the applicable retention and legal basis, not the convenience of replay. A legal-hold exception escalates through its owner; it does not silently become indefinite retention.
Inventory the source and every derived index, embedding, summary, cache, trace, export and delegated copy. Bind each propagation receipt to the exact record, operation, intent digest and target artifact. Current verified receipts and a verified complete inventory are required for confirmed; missing external visibility remains external_unknown. Admission can be true while completion remains false, including a permitted deletion that failed downstream.
Govern all nine stages: collection, inference, tool input, tool output, telemetry, cache, memory, export and delegation. Actual recipients/processors, destination tenancy, purpose, residency and retention must be permitted independently. A claim that text was redacted needs trusted source/artifact/action/policy-bound transformation evidence and actual transformed bytes; a label is insufficient.
Durable workers and uncertain effects
Protect run, operation, approval and budget stores with atomic revisions, leases and generation fencing. Wake/resume must recheck current authority, review, active boundary and data eligibility. It retains original stable operation identity and shared spent/reserved capacity across children, review, retries and repair.
A provider timeout after a memory write can leave an unknown effect. Retry only under verified provider idempotency semantics and scope/window or authoritative absence; an idempotency-key string alone is insufficient. Cancellation intent is not observed stop. Reconciliation can establish a late fact without restoring an old worker’s ownership or resetting usage. Compensating writes are new governed effects.
A worked correction, without inventing policy authority
Suppose an operator reports that a customer’s identifier may be displayed only as its final four characters. First validate the operator’s identity, source permission and permitted purpose before capture. Treat the report as a candidate; an unsupported claim about a special agreement cannot create organization policy.
An entitled independent reviewer checks the authoritative agreement, exact proposed fact/readers/retention and conflicts. The protected adapter performs the currently authorized promotion and records trusted observations. Future recall checks the current reader and purpose. Actual output masking still belongs to the data boundary: recalling a preference cannot prove that every model, tool or telemetry processor received only masked content.
If the claim is retracted, suspend its eligible use and propagate the correction to known copies. Report pending or external unknown state until current target-specific receipts establish completion. No customer workflow or provider write is executed by this article.
Verification before a deployment claim
The repository’s tests/execution-boundary.test.ts exercises positive promotion, wrong owner/tenant/namespace/purpose/readers, unverified or expired access, missing review/provenance, excessive retention, pending deletion, failed/external propagation, missing copies and exact confirmation receipts. These are synthetic reference checks, not proof that a deployed database enforces isolation or that a processor erased data.
A deployment must supply useful recall/promotion evidence plus denial and fault cases: anonymous subject bypass, forged review, stale replica, concurrent correction, crash after provider commit, revoked parent, exhausted shared capacity, missing copy and unavailable external processor. Select exact control profiles and report current independent conformance evidence for the actual workflow, implementation, release and environment. Missing evidence is insufficient, not a passing default.