Phase 2E — Q5 Tenant Config Storage: Native Edge Graph Extension

Context

Sub of Phase 2 Epic #11626 (meta-Epic #11624). Graduated from Discussion #11623 Q5.

Resolves Q5 — where tenant ingestion config is canonically stored. Required for KnowledgeBaseIngestionService (Phase 2A) to fetch tenant source/parser config at ingestion time.

The Problem

Phase 0/1B introduced data-driven source/parser registry shape, but DEFAULT registry (useDefaultSources: true) is in aiConfig. Per-tenant CUSTOM registry needs a storage substrate that:

• Supports tenant-scoped reads (getTenantConfig({tenantId}))
• Supports versioning (config changes shouldn't invalidate existing ingested chunks silently)
• Integrates with #10011 Native Edge Graph identity substrate
• Survives KB server restarts (durable, not in-memory)

The Fix

Lean (from Discussion §4 Q5): tenant-config-as-graph-node in Native Edge Graph (#10011 substrate), with optional kb-config.yaml file-bootstrap for first-deploy.

1. New graph node type: KnowledgeBaseTenantConfig with edges to AgentIdentity (tenant owner) and SourceRegistration / ParserRegistration (config entries)
2. KnowledgeBaseIngestionService.getTenantConfig({tenantId}) method — fetches from graph, falls back to kb-config.yaml if graph empty, falls back to default registry if both empty
3. Versioning: config-version edge increments on each mutation; chunk metadata carries tenantConfigVersion for retroactive invalidation if needed
4. kb-config.yaml bootstrap format documented at learn/agentos/cloud-deployment/Configuration.md (Phase 3 deliverable) — initial-deploy convenience; canonical state still in graph

Acceptance Criteria

• KnowledgeBaseTenantConfig graph node type defined; integrated with Native Edge Graph schema (#10011 substrate)
• getTenantConfig({tenantId}) resolves config from graph → kb-config.yaml → default registry (3-tier fallback)
• Config-version field tracked; mutation increments version
• kb-config.yaml bootstrap format documented inline (Phase 3 guide cross-link)
• AgentIdentity-scoped writes (tenant can mutate own config only; cross-tenant mutation rejected via #10011 RLS)
• Unit tests: 3-tier fallback, version increment, RLS rejection
• Integration test: tenant config persists across service restart

Out of Scope

• UI for tenant config editing (operator/tenant uses graph mutations or yaml file directly for V1)
• Multi-version config rollback (config-version field tracked; rollback is future ticket if needed)
• Config schema validation engine (basic JSON Schema validation OK for V1; rich validator is future ticket)

Backup-Bundle Compatibility

Substrate-correct V-B-A calibration 2026-05-19: per #10129 atomic-bundle architecture, buildScripts/ai/backup.mjs produces bundle-meta.json with shared_topology: true invariant. buildScripts/ai/restore.mjs rejects bundles marked chromaUnified: false unless --force-topology-mismatch. Tenant config storage MUST coexist with this layer:

• Per-tenant config nodes in Native Edge Graph live in .neo-ai-data/sqlite/memory-core-graph.sqlite, which IS bundled by backup.mjs under the graph/ subdir.
• Restore merge-mode (INSERT OR IGNORE per #11141) preserves live tenant config when restoring from older backups.
• kb-config.yaml bootstrap (if shipped per Q5 hybrid lean) is flat-file at deployment root; NOT in the canonical bundle (deployment-specific, not tenant-specific).

Related

• Parent: #11626
• Identity substrate: #10011 (Native Edge Graph RLS)
• Discussion source: #11623 §4 Q5
• Backup-bundle substrate: #10129 atomic-bundle; #11141 graph preserve-live

Origin Session ID

7360e917-1733-4cdd-a6f3-5ac51c34b838

Handoff Retrieval Hints

• Memory Core graph layer at ai/services/memory-core/ is the sibling-pattern reference for graph-node-shaped config
• ask_knowledge_base({query: 'Native Edge Graph RLS tenant', type: 'src'}) for #10011 substrate details