A memory accepted is a memory kept

The failure that kills trust in a memory system is not bad retrieval. It is silent loss: a commit call that returned 200, hit a transient LLM timeout during extraction, and vanished. Nobody notices for weeks, because the absence of a memory looks the same as never having stored one. Illumina's write path is built so that acceptance is a durability promise.

Every write is a workflow

Each write-side operation runs as a durable Temporal workflow: commit, file commit, consolidation, automation refresh, webhook delivery. Workflow state survives process restarts and deploys, so a commit that was mid-extraction when a node died resumes where it stopped instead of evaporating. Transient failures, like a flaky embedding call or a rate-limited extraction model, retry within bounded policies rather than falling on the client to handle.

Duplicates collapse instead of double-ingesting

Workflow ids embed a hash of the request content. Send the same commit request twice, whether from a client retry loop, an at-least-once queue, or a user who clicked twice, and the second request collapses onto the in-flight run. Same workflow, same result, one ingestion.

That makes retries safe by construction. Client code can retry a commit on any ambiguous failure without checking first whether the previous attempt landed, because the content hash guarantees the answer is one memory either way.

Background work never starves customer writes

Ingestion and consolidation run on isolated Temporal task queues. A bulk backfill of two years of documents queues behind other backfills, not in front of the commit call your agent just issued. Consolidation passes chew through corroboration grouping on their own queue with the same isolation. Interactive latency stays flat while heavy background work drains at its own pace.

Dead letters you can actually retry

Some writes exhaust their retries: a document over the size limit, input that breaks extraction. Those dead-letter with their terminal error attached, so the failure is inspectable instead of buried in worker logs.

Recovery is one call:

curl "https://api.illumina.sh/v1/default/namespaces/demo/operations?state=failed" \
  -H "Authorization: Bearer $ILLUMINA_API_KEY"

curl -X POST "https://api.illumina.sh/v1/default/namespaces/demo/operations/$OP_ID/retry" \
  -H "Authorization: Bearer $ILLUMINA_API_KEY"

The retry re-starts the workflow from the input Illumina recorded when it accepted the write. It is recovery of work you already submitted, not a new intake billed a second time. Anything that has not dead-lettered answers 409 rather than running twice. Fix the cause, retry, done.

Restore one tenant, touch no one else

Durability extends past the write path. Backup and restore are workspace-scoped, so restoring one workspace means restoring that workspace's rows and nothing else. No full-database rollback that drags every tenant back six hours to repair one, and no engineer hand-carving a tenant's data out of a global snapshot under pressure.

Memory only compounds if it survives. Retrieval quality, consolidation, automations: everything downstream assumes writes stick. The write path is where that assumption gets earned, which is why every piece of it, from the content hash in the workflow id to the retry endpoint, exists to make one statement true: if Illumina accepted it, Illumina kept it.