Skip to main content
Governance in AtomicMemory means you are never left trusting a black box with what your agents believe. Every memory your system holds can be inspected, every incorrect claim can be corrected, every conflict can be resolved deliberately, and every operator action is recorded in a tamper-evident receipt chain. Whether you are running a business-critical agent that acts on financial data or a personal assistant that carries context across sessions, these surfaces give you full control over the belief state your agents operate from.

​
What governance covers

AtomicMemory governance spans four concerns:
  • Inspection — reading the content, provenance, and verification state of any memory
  • Correction — fixing inaccurate claims, reclassifying memories, or permanently removing sensitive content
  • Conflict resolution — adjudicating when the system holds two contradictory claims about the same subject
  • Auditing — a tamper-evident record of every operator action so you can answer “who changed what, and when”

​
The governance GUI

The governance interface ships as a standalone web application. Each route covers a distinct governance surface.
RouteSurfaceWhat it does
/memoryMemory ExplorerTable view with VERIFICATION and ACTION STATE columns, filter chips, and lineage hints
/memory/[memoryId]Memory InspectorDetail card + analyst correction panel (verify, supersede, confidence, reason)
/conflictsConflict QueueSide-by-side trusted-vs-claim view with four resolution actions
/quarantineQuarantine QueueWrite-time policy-gate queue — review, approve, reject, or escalate
/auditAdmin Audit LogTamper-evident receipt chain with chain_valid banner and observability stats
/eventsWorkflow EventsTyped event feed + delivery-subscription card for webhook integration
/chatsConversational assistantGoverned belief-state answer cards with current, superseded, conflict, and action-gate states
The governance GUI runs on the same AtomicMemory Core backend as your agents. Mutation operations (correct, redact, hard delete) require the CORE_ADMIN_API_KEY — a separate credential from the regular CORE_API_KEY used by agent workloads. Keep these keys distinct.

​
The Langflow plugin (enterprise)

If you are building governance workflows inside Langflow, four components are available as part of the enterprise plugin:
  • Memory Inspector — surface individual memory detail and verification state in a flow
  • Operator Action — execute correction, redaction, reclassification, revert, or delete operations
  • Audit Reader — read the operator action log; sources its admin key from the ATOMICMEMORY_LANGFLOW_ADMIN_API_KEY environment variable — never from a flow input
  • Search Diagnostics — inspect retrieval scoring and ranking for a given query

​
API key requirements

Governance and mutation operations use a separate admin credential from regular agent API calls.
KeyUsed forWhere to set it
CORE_API_KEYStandard agent reads and writesSDK, MCP server, framework adapters
CORE_ADMIN_API_KEYOperator actions — correct, redact, reclassify, revert, hard deleteGovernance GUI, Langflow Operator Action component, direct API calls
Never expose CORE_ADMIN_API_KEY in client-side code, browser environments, or log output. Operator actions are irreversible for some mutation types and are attributed to the authenticated session user in the audit log.

​
Where to go next

Inspect & Correct

View individual memories, correct inaccurate claims, resolve conflicts, and manage the quarantine queue through the UI or API.

Audit Log

Understand the tamper-evident receipt chain, how audit actors are attributed, and how to integrate with webhook event delivery.