Skip to main content
Before you can correct what an agent believes, you need to find the memory in question and understand its current state — its content, provenance, verification status, and any pending governance actions. AtomicMemory’s governance surfaces guide you from discovery through correction in a structured workflow, whether you are working in the governance UI or calling the operator action API directly.

​
Memory Explorer (/memory)

The Memory Explorer is the starting point for all governance work. It presents every memory in a filterable table so you can locate records by user scope, namespace, or date range before drilling into any individual entry. Two columns are specific to governance:
  • VERIFICATION — indicates whether a human analyst has reviewed this memory. Unverified memories may be accurate but have not been confirmed by an operator.
  • ACTION STATE — shows any pending governance action on this memory (for example, a correction that has been submitted but not yet applied, or a flag awaiting resolution).
Use the filter chips at the top of the table to narrow by user scope, namespace, or date range. This is especially useful when investigating a specific user’s belief state or auditing a time-bounded incident.

​
Memory Inspector (/memory/[memoryId])

Clicking any row in the Memory Explorer opens the Memory Inspector, a 60/40 split view with the memory detail on the left and the analyst correction panel on the right. The detail card shows:
  • Full memory content
  • Provenance (how and when this memory was created)
  • Creation date and version lineage
  • Audit lineage — a link to every operator action that has touched this record
The analyst correction panel on the right gives you four actions:
ActionWhat it does
VerifyMark this memory as reviewed by an analyst; requires evidence
SupersedeMark this memory as replaced by a newer claim
Adjust confidenceChange the confidence level attributed to this claim
Add reasonAnnotate this memory with a correction reason for the audit record

​
Conflict Queue (/conflicts)

When the same user holds two contradictory claims about the same subject, AtomicMemory routes the newer claim to the Conflict Queue rather than silently overwriting the trusted value. The queue presents a side-by-side view of the trusted claim on the left and the incoming claim on the right. You have four resolution actions:
1

Keep trusted

Dismiss the incoming claim. The existing memory is retained unchanged. Use this when the new claim is incorrect or unreliable.
2

Keep new

Replace the trusted claim with the incoming one. The prior version is versioned and preserved in lineage.
3

Merge

Combine information from both claims into a single updated memory. Use this when both contain accurate but incomplete information.
4

Defer

Leave the conflict unresolved for now. The record remains in the queue for a later review. The agent continues operating on the trusted claim until the conflict is resolved.
The Promote action (available in some queue states) is gated on evidence — you must provide an evidence acknowledgement before a claim from an untrusted source can replace a verified trusted record. This prevents external inputs from poisoning your agent’s belief state without operator review.

​
Quarantine Queue (/quarantine)

The Quarantine Queue is a write-time policy gate. When a memory write fails a policy check — for example, it matches a sensitive-content rule or a trust-threshold condition — it lands in quarantine rather than being written to the memory store. Each quarantine entry shows:
  • The policy rule that triggered quarantine
  • A content-free reason (the sensitive content is not surfaced in the reason string)
  • The transport category: quarantine, review_required, or route
You have three actions available on each entry:
ActionEffect
ReleaseApprove the memory and write it to the store. Sensitive-content releases require an evidence acknowledgement.
RejectDiscard the memory. It is not written to the store and a rejection is recorded in the audit log.
EscalateFlag for senior review. The entry stays in the queue and is marked for escalation.
Releasing a quarantined memory with sensitive content requires you to check an evidence acknowledgement. This gate is intentional — it ensures that no sensitive memory enters the store without an explicit operator decision that is recorded in the audit log.

​
Via the operator action API

For programmatic governance — bulk corrections, scripted redaction pipelines, or integration with your own tooling — the Core API exposes operator actions authenticated with the CORE_ADMIN_API_KEY.
Fix a memory’s content in place. The prior version is preserved in lineage.
curl -X POST http://localhost:17350/v1/governance/memories/{memoryId}/actions \
  -H "Authorization: Bearer $CORE_ADMIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "action": "correct",
    "content": "The corrected memory content goes here.",
    "reason": "Revenue figure updated after Q2 audit."
  }'
hard_delete and delete_by_scope are irreversible. There is no recovery path once these actions are confirmed. Always use dry_run: true before confirming a delete_by_scope operation, and confirm the affected record count matches your expectation before proceeding.
Every operator action — regardless of whether it is triggered from the UI or the API — is recorded in the tamper-evident audit log with the authenticated session user as the actor. See the Audit Log page for details on reading and verifying the receipt chain.