Skip to main content
Once memories are flowing into a namespace, you’ll need to inspect them, retire stale ones, and trace what your application is actually doing. This page covers the read-side and lifecycle operations that complement remember and recall.

​
Forget a memory

Removing a memory removes the document and everything derived from it — chunks, entity mentions sourced from this document, and relationships sourced from this document. Entities mentioned by other memories survive; only the link to this document is severed. 
await deyta.memory.forget({
  namespace_id: ns.id,
  document_id: "doc_…",
});
forget is destructive and irreversible. There is no soft-delete and no undo. Use it deliberately, and consider taking a backup if you might want the content later.
The document_id you need is what remember returned. If you’ve lost it, you can find documents through the console namespace detail view or by listing recent activity.

​
Updating a memory

There is no in-place update operation. To change a memory’s content, forget the existing document and remember the new content as a fresh document. The new memory gets a new document_id. If your application maintains its own source-of-truth IDs, store the mapping yourself so you can find the right document_id to forget when content changes.

​
Inspect a namespace

The console namespace detail page shows you what’s in a namespace at a glance. Open Namespaces → click any row. You’ll see:
SectionWhat’s there
StatsDocument count, chunk count, entities, relationships, last activity timestamp
Recent activityThe last several remember / recall / forget events
DocumentsBrowsable list of memories with title, source, ingestion time
Ingestion jobsSync runs from connected data sources
PermissionsWhich users and API keys have access
For programmatic stats, the SDK exposes: 
const stats = await deyta.namespaces.get(ns.id);
// stats.stats.documents
// stats.stats.chunks
// stats.stats.entities
// stats.stats.relationships
// stats.stats.last_activity_at

​
Audit log

Every state-changing action — at the API and from the console — writes an entry to the audit log. Open Admin → Audit log to filter by:
  • Time range
  • Actor (user email or API key name)
  • Action (memory.remembered, memory.recalled, memory.forgotten, namespace.created, data_source_connection.connected, …)
  • Entity type / ID
Use the audit log to:
  • Trace which API key wrote a specific document
  • Investigate suspicious deletions
  • Build internal compliance reports
  • Debug ingestion timing issues
The log is read-only and append-only. There’s no way to redact entries from the console.

​
Tool calls

Beyond the audit log, every remember, recall, forget, and ask is captured as a tool call record — full input, output, duration, and any error. See Tool calls for the full reference, including filtering and common debugging workflows.

​
Costs

If your plan tracks usage, Admin → Costs breaks down LLM and retrieval cost by namespace, by API key, and over time. Costs are aggregated daily.

​
Re-indexing

There is no manual re-index button. If you change extraction settings (ontology, expertise config) or upgrade to a model with different embedding semantics, the existing memories keep their old chunks and embeddings — only new memories pick up the new behavior. To refresh existing content, forget and re-remember it. For data-source-driven memories, deleting the connection record and recreating it triggers a fresh sync of the source content.

​
Retention

Memories live in a namespace until you forget them or delete the namespace. There is no automatic expiry — Deyta Platform doesn’t garbage-collect old content on its own. If you need TTL behavior, either:
  • Filter at the application level using from / until on recall and ask
  • Drive retention from your application: track ingestion timestamps yourself and call forget on documents older than your policy
  • Build a small worker that walks the namespace periodically and prunes by age or count

​
What’s next

Concepts: memories

What’s inside a memory after ingestion.

Console: admin

Audit log, ontologies, and other org-wide controls.