Global, Regional, and Jurisdictional Memory

A Nucleus is an isolated memory database boundary. Choose its placement when it is created, then store Memory Cells in scopes inside that Nucleus. Use separate Nuclei when global availability, regional latency, regulated storage, credentials, ownership, retention, or deletion policy require different boundaries.

Placement controls the Durable Object SQLite hot-memory route and R2 archive selection. It does not, by itself, configure every processing, logging, encryption-key, analytics, or legal control in the surrounding Cloudflare account.

Choose the correct placement

Supported Durable Object region hints are wnam, enam, sam, weur, eeur, apac, oc, afr, and me. Supported R2 location hints are wnam, enam, weur, eeur, apac, and oc. Supported jurisdictions are eu and fedramp.

Regional placement is available to Pro and Enterprise workspaces. Jurisdictional placement requires Enterprise.

Reference architecture

The implementation examples use the same three memory databases:

flowchart TD
  A["Trusted server data policy"] --> B{"Required boundary"}
  B -->|Global knowledge| C["product-knowledge-global"]
  B -->|Western Europe latency| D["support-operations-weur"]
  B -->|EU storage jurisdiction| E["regulated-cases-eu"]
  C --> F["Global Nucleus token and scopes"]
  D --> G["Regional Nucleus token and scopes"]
  E --> H["EU jurisdictional token and scopes"]

• product-knowledge-global stores approved product documentation used by agents worldwide.
• support-operations-weur stores non-regulated operational lessons near Western European users as a latency preference.
• regulated-cases-eu stores minimized EU-regulated case memory using jurisdictional storage resources.

The browser and model never choose the Nucleus. A trusted server classifies the data and uses the credential bound to the approved destination.

Implement in every supported language

Each implementation provisions the same Nuclei, constructs isolated runtime clients, writes memory, recalls EU case context inside one boundary, and checks placement readiness.

The REST helpers are required because Nucleus creation and placement inspection are not yet exposed as typed methods by every SDK. They use the same public /v1/nuclei contract and keep workspace credentials out of runtime memory clients.

Shared environment contract

All implementations read secrets from the host environment or secret manager:

NEUTRON_API_URL
NEUTRON_WORKSPACE_API_KEY
NEUTRON_GLOBAL_TOKEN
NEUTRON_WEUR_TOKEN
NEUTRON_EU_TOKEN

Use the workspace key only for provisioning. Provision one Nucleus access token per Nucleus and ensure a regional or global token cannot access the EU-regulated Nucleus.

Recall inside one boundary

If the EU agent needs globally approved product knowledge, install or copy that approved knowledge into kb:approved-products inside regulated-cases-eu. Neutron does not perform one recall across multiple Nuclei, and the application must not weaken the boundary merely to reuse global memory.

Keep raw regulated payloads in the system that owns them when a minimized, source-linked summary is sufficient for the agent.

Verify placement before use

Every language implementation checks both /v1/nuclei/regulated-cases-eu/placement and /v1/nuclei/regulated-cases-eu/health.

For jurisdictional storage, fail production readiness when the required jurisdiction subnamespace is unavailable or the matching R2 binding is missing. Neutron reports warnings such as jurisdictional_do_subnamespace_unavailable and jurisdictional_archive_bucket_missing; it does not silently archive jurisdictional data into the default bucket.

regionalServicesRequired, metadataBoundaryRequired, and geoKeyManagerRequired express requirements. They do not configure Cloudflare Regional Services, Customer Metadata Boundary, or Geo Key Manager automatically.

Treat placement as immutable

Neutron rejects an in-place placement update after memory storage may exist. To move from regional to jurisdictional storage:

1. Create a new jurisdictional Nucleus with the required account resources.
2. Verify its placement and health warnings.
3. Export only authorized, minimized records through an explicit migration workflow.
4. Import them into reviewed scopes in the new Nucleus.
5. Verify counts, retrieval boundaries, tombstones, retention, and audit events.
6. Rotate clients to the new Nucleus-scoped token.
7. Disable or soft-delete the old Nucleus according to policy.

Do not use dual writes as an unreviewed migration shortcut. They can create inconsistent deletion, retention, and residency behavior.

Production checklist

• Maintain a documented mapping from data class and jurisdiction to one Nucleus.
• Use separate Nucleus tokens and secret-manager entries for each placement boundary.
• Keep scopes narrow inside each Nucleus; placement does not replace authorization.
• Verify Durable Object, R2, processing, log, metadata, key, backup, analytics, and contract controls independently.
• Confirm derived services such as semantic indexes meet the workload's residency policy before enabling them.
• Keep sensitive context caching disabled unless explicitly reviewed and authorized.
• Test that a global or regional credential cannot read jurisdictional memory.
• Test deletion, queue, archive, cache, and compaction paths for non-resurrection.
• Obtain legal and compliance review before making a customer-facing residency commitment.