neutron AIGather evidence before using private memory
Keeping a useful memory is only part of the job. Establish who can retrieve it, how revocation reaches your own systems and what evidence your production review requires. Use a disposable Nucleus and synthetic records for these checks.
Repeatable API checks
Run the downloadable evaluation. Confirm the positive read first, then a tombstoned forget response, then absence from both recall and fresh context. A deletion-only check without a successful positive control proves little.
For cross-Nucleus access, create two disposable Nuclei and use Nucleus A's token to request Nucleus B. Expect HTTP 403 and no returned memories. A workspace key can authorise several linked Nuclei, so it is not the credential for this negative test. Within a Nucleus, your backend must reject a user requesting another user's Scope before calling Neutron AI.
Your application must also invalidate previously issued context, cached model prompts, automation state, downstream copies and any separate vector database. A tombstone cannot retract a prompt already sent to a model.
Queue, archive, cache and compaction evidence
The public API runner checks immediately observable behaviour. Neutron may use internal retrieval and embedding services; the runner does not invoke your application model provider. It cannot replay production queues or inspect Cloudflare internals. The source verification suite contains deterministic regressions for these paths:
pnpm --dir services/edge-api exec vitest run \
test/evaluationJourney.test.ts test/forget.test.ts test/queue.test.ts
queue.test.ts checks stale tombstone jobs, cleanup retry after a Vectorize failure, deletion racing compressed/raw archive writes, and rejection of work for deleted Nuclei. These tests use controlled storage adapters; a pass is source-level evidence, not independent certification or proof of every production configuration.
For your production review, request the release's test summary, exact runtime/deployment revision, retention configuration and a bounded operator-led queue/archive/cache/compaction replay check for your configuration. Do not infer asynchronous non-resurrection solely from an immediate empty recall. Keep the workload synthetic and record failures as well as successes.
Control and plan checklist
| Requirement | Public evaluation path | Before production |
|---|---|---|
| Scoped recall and deletion | Available for a Free synthetic trial | Verify your end-user mapping and downstream invalidation |
| Workspace audit export | Pro or Enterprise | Request a sanitised sample and agreed evaluation access; do not assume Free includes exports |
| Regional placement | Pro or Enterprise, best-effort hint | Check the actual placement receipt and wider processing boundary |
| Jurisdictional durable storage | Enterprise; supported eu and fedramp profiles | Verify configuration, subprocessors, processing/log locality and written terms |
| Residency, SLA, recovery objectives or certification | No blanket public guarantee | Require the specific evidence, scope and commitment in an Order |
Free and Developer Nuclei use Global placement. A regional hint is not legal residency. A jurisdictional storage profile is not by itself a promise that every request, log, backup or downstream model call stays in that jurisdiction. A fedramp configuration label is not a Neutron AI FedRAMP authorisation.
Request the review you need
Use evaluation and security help with your required region, data classification, expected volume, identity requirements, deletion obligations, audit format and recovery objectives. Ask which controls are available now, which need configuration and which need an Order. Request dated evidence and a scope rather than relying on a badge.
Do not send customer memory, credentials, private keys or access tokens. Read the security model, placement guide, DPA and subprocessor list. No independent SOC 2, ISO 27001 or FedRAMP status is asserted by this evaluation pack. Commitments apply only as set out in the applicable contract.