Skip to main content

Shipping a knowledge base

AtomicMemorySDK can load a knowledge base — a bundled set of memories shipped with your application — into the active provider on first init. Useful when your product ships with seed content (onboarding hints, product docs, reference snippets) that you want searchable from the moment the user opens it.

The method​

await sdk.loadKnowledgeBase('production');
// or
await sdk.loadKnowledgeBase('development');
await sdk.loadKnowledgeBase('test');

The type parameter selects which bundle to load — production, development, or test. Each is defined under src/knowledge-base/ in the SDK source.

When to call it​

Load once, early in your app's lifecycle, after initialize has completed. Typical pattern:

const sdk = new AtomicMemorySDK({ /* config */ });
await sdk.initialize();

if (!(await hasSeedContent(sdk))) {
  await sdk.loadKnowledgeBase('production');
}

Where hasSeedContent is your own idempotency check — the simplest version is a list with a known scope tag like { namespace: 'seed' } and a count check.

What gets loaded​

The bundled knowledge bases are plain memory records: content, scope, provenance. They go through ingest like any other memory, which means:

  • They pass through the capture gate (so platform: 'knowledge-base' must not be blocked in the user's preferences, or you need to use a provider-direct path)
  • They get embedded, AUDN-checked, and stored the same way user memories are
  • They appear in list and search results

Scoping seed content​

The convention is to give seed memories a dedicated namespace like 'seed' or 'knowledge-base' so they're easy to identify and prune later:

// Inside your seed data (bundled in SDK or your app)
{
  content: '...',
  scope: { user: 'system', namespace: 'seed' },
  provenance: { source: 'knowledge-base' },
}

Apps can then search against { namespace: 'seed' } when they want seed-only hits, or the user's own scope when they want personal memory.

Eviction and updates​

loadKnowledgeBase does not automatically reconcile against previous loads. If your seed content changes between versions, plan for that:

  • Additive updates — add new records, let old ones stay. Simplest.
  • Replacement — delete by namespace first, then reload. Requires keeping stable identifiers for the scope.
  • Versioning — namespace each load (seed-v1, seed-v2), and configure your app to prefer the latest. Most robust, most code.

Next​