Memory levels
What Level 5 and Level 6 mean in Titen, which of the 58 routes belong to each, and why the kernel was built first.
The level model is Titen’s own product vocabulary, not an industry standard.
| Level | Main capability |
|---|---|
| 1 | Session context and raw files |
| 2 | Semantic retrieval from an external store |
| 3 | Typed memory tiers and relationships |
| 4 | Automatic extraction, consolidation, and forgetting |
| 5 | Evidence-grounded, temporal context compilation with outcome feedback |
| 6 | Collaborative memory, governance, and optional federation |
The jump that matters is 4 to 5. Level 4 manages stored memories. Level 5 decides what one agent should see for its next action, and can say where each item came from and when it was valid. Level 6 adds the identity, visibility, coordination and governance a team needs to share one store without corrupting it.
Two loops, one engine
Level 5 is the evidence loop, owned by one authorized actor:
Level 6 is the loop around it, for many actors sharing one store:
One engine underneath: personal, company and enterprise deployments run the same code, and policy plus topology decide which collaboration capabilities are on.
Which routes belong to which level
All 58 routes split along that boundary. Nothing in the kernel column needs a workspace, a membership or a policy to work.
| Layer | Routes | Surface |
|---|---|---|
| Service foundation | 8 | /healthz, /readyz, /v1/projects/resolve, /v1/keys ×3, /v1/export, /v1/import |
| Level 5 kernel | 11 | /v1/observations, /v1/consolidations, /v1/context/compile, /v1/context/:id/feedback, /v1/claims/:id/evidence, /v1/claims/:id/{supersede,revoke,expire}, /v1/checkpoints ×3 |
| Level 6 collaboration | 21 | /v1/workspaces ×2, /v1/memberships ×3, /v1/leases ×2, /v1/handoffs ×3, /mcp, /v1/events ×2, /v1/memory-views/compile, /v1/webhooks ×7 |
| Level 6 governance | 9 | /v1/policies ×2, /v1/channel-releases ×4, /v1/channel-context, /v1/audit, /v1/audit/export |
| Level 6 federation | 8 | /v1/federation/* — peers, filters, pull, push, log |
| Maintenance | 1 | /v1/index/drain |
ADR-0001 puts checkpoints in the kernel column because one agent needs resumable task state before any second agent exists. Sharing checkpoints across a team is the Level 6 addition, not the checkpoint. Federation is Level 6 too: two agents can share memory, race for a lease and hand off work without ever calling a federation route.
Why the kernel came first
ADR-0001 rejected three alternatives.
Level 5 only. Insufficient for shared agent work and enterprise governance. A flawless single-agent memory still cannot say what is private, already being worked on, or safe to hand off.
Full Level 6 first. Too much surface before the memory kernel is proven. Coordination with no ground truth under it is a scheduler, and Titen does not run agent loops.
Separate personal and enterprise products. Divergent semantics and double the maintenance.
Enterprise controls built into the storage kernel would have made the personal and VPS modes carry weight they never use; as a layer, those controls switch on without forking the memory model.
The cost, also recorded: every record needs explicit actor, scope and visibility semantics, so there is no unscoped observation even in personal mode. Collaboration tests have to cover conflicting writes and cross-scope access.
Stop at Level 5 and one agent gets a bounded, cited, temporally valid context pack it can send feedback against. Add Level 6 and several agents share that store while private memory stays private, disagreement stays visible, and the operations that change eligibility or disclose memory outside the organization leave metadata-only audit rows.