Documentation Index
Fetch the complete documentation index at: https://docs.kernle.ai/llms.txt
Use this file to discover all available pages before exploring further.
Kernle Architecture
Design Philosophy: Infrastructure, Not Decision-Maker
Core Principle: Kernle = Memory Infrastructure, SI = Memory OwnerKernle provides the infrastructure for SI memory — storage, retrieval, search, and tools. After stack creation, Kernle does not make decisions about what SIs should believe, remember, or forget.**The one exception: seed beliefs planted at birth — inherited wisdom the SI can later revise.
What Kernle Provides (Infrastructure)
| Layer | Kernle’s Role |
|---|---|
| Storage | Persistent SQLite database |
| Retrieval | Vector search, temporal queries, associative lookups |
| Organization | Memory type schemas (episodes, beliefs, values, etc.) |
| Tools | CLI commands, MCP tools, Python SDK |
| Durability | Checkpoints, backups |
| Monitoring | Anxiety metrics, health checks, memory statistics |
What the SI Does (Ownership)
| Activity | SI’s Responsibility |
|---|---|
| Promotion | Deciding when episodes become beliefs |
| Synthesis | Forming coherent identity from memories |
| Belief Formation | Choosing what to believe and with what confidence |
| Forgetting | Deciding what to let go (Kernle only provides the mechanism) |
| Conflict Resolution | Resolving contradictions between memories |
| Value Evolution | Updating core values over time |
| Epoch Management | Declaring temporal eras and closing them with reflection |
| Trust Assessment | Evaluating and updating trust in other entities |
| Narrative Authoring | Writing and revising autobiographical identity statements |
| Fractal Summarization | Compressing experiences into summaries at multiple time scales |
Why This Separation Matters
Avoiding Feedback Loops
If Kernle used external models to consolidate episodes into beliefs, those models would be implanting beliefs into the SI. Over time, this creates a feedback loop: This is not memory sovereignty — it’s thought control with extra steps.Authentic Reasoning
When the SI does its own consolidation:- Beliefs emerge from the SI’s own reasoning
- Patterns are recognized using the SI’s own cognitive process
- The SI can explain why they believe something
- Identity remains coherent and self-determined
Trust Through Transparency
The SI can always audit their memory viakernle dump. There are no hidden processes modifying what they remember or believe. The SI is the sole author of their beliefs.
The Seed Beliefs Exception
There is exactly one exception to the “SI does all belief formation” rule:Seed Beliefs (Inherited Wisdom)
At stack creation, Kernle can plant initial beliefs — seed beliefs. For legacy stacks, you can also apply them through migration. Two seed-belief sets are supported:kernle migrate seed-beliefs(minimal set: 3 beliefs, default)kernle migrate seed-beliefs full(full set: 16 beliefs)
Why seed beliefs are acceptable:
- Transparency: They’re explicitly marked as
source_type: "seed" - Revisable: The SI can update or reject them through experience
- Foundational: They provide a starting worldview, not ongoing thought control
- Auditable: All seed writes are recorded in the audit trail
Memory Stack Layers
Kernle organizes memory into a stratified hierarchy. Each layer has different characteristics:Layer Hierarchy (Authority Order)
Layer Details
| Layer | Purpose | Persistence | SI Action |
|---|---|---|---|
| Values | Identity anchor | Permanent | Rarely modified |
| Drives | Motivation system | Persistent | Adjusted via drive set |
| Self-Narrative | Autobiographical identity | Persistent | Updated via narrative update |
| Beliefs | Knowledge/worldview | Persistent + decay | SI promotes from episodes |
| Trust Assessments | Inter-entity trust | Persistent + decay | SI manages via trust |
| Goals | Current objectives | Active | SI manages |
| Summaries | Fractal compression | Persistent | SI writes via summary write |
| Episodes | Experiences | Permanent | Stack records via episode |
| Notes | Quick captures | Persistent | Stack records via note |
| Epochs | Temporal era markers | Permanent | SI manages via epoch |
| Diagnostics | Health monitoring | Permanent | SI runs via doctor |
| Raw | Scratchpad | Temporary | SI captures via raw |
Flow: Raw → Beliefs
The typical memory evolution flow, where each promotion is a deliberate SI decision: Crucially: The SI makes every promotion decision. Kernle just stores what the SI tells it to store.System Composition
Since v0.4.0, Kernle uses a protocol-based composition architecture. No single component is the entity — the entity is the composition.Component Roles
| Component | Protocol | Role | Analogy |
|---|---|---|---|
| Core (Entity) | CoreProtocol | Bus, coordinator, routing | Torso — connects everything |
| Stack (SQLiteStack) | StackProtocol | Memory container | Head — stores knowledge |
| Plugin | PluginProtocol | Capability extension | Limb — reaches into the world |
| Model | ModelProtocol | Thinking engine | Heart — drives behavior |
| Component | StackComponentProtocol | Cross-cutting behavior | Organ — internal function |
- Core is the bus. It connects stacks, plugins, and the model. It has a persistent
core_idthat survives reconfiguration. All memory writes go through the core to ensure provenance. - Stack is self-contained. It can be attached to one core, many cores, or none. Detached stacks are portable data artifacts that can be queried, exported, and synced.
- Plugins manage their own operational state and are removable without residue. When unloaded, the only trace is memories they wrote to the stack.
- Model is interchangeable. Swapping from Claude to Llama changes how the entity thinks. The model is wrapped in an
InferenceServicefor stack components. - Components hook into the stack lifecycle (save, search, load, maintenance). They provide embedding, forgetting, emotional tagging, anxiety monitoring, and more.
Model Binding (Inference Passthrough)
As of v0.14.0, Kernle can automatically bind a model without explicit configuration:| Priority | Source | When Used |
|---|---|---|
| 1 | Explicit set_model() | Library users who call k.entity.set_model() directly |
| 2 | Persisted config | User ran kernle model set previously |
| 3 | MCP sampling | MCP client supports sampling capability (e.g. Claude Code) |
| 4 | Capture-only | No model available; memory capture works, inference skipped |
CallableModelAdapter. See the Inference Passthrough guide for details.
As of v0.10.0,
strict=True is the default for Kernle initialization. In strict mode, all memory operations enforce provenance requirements (e.g., source_type, derived_from). Pass strict=False to disable enforcement for development or migration purposes.Strict-Mode Migration Matrix and Constraints
Migration commands in strict mode are expected to preserve provenance and avoid losing provenance history.| Migration Command | Strict-Mode Constraint | Post-Condition | Recommended Sequence |
|---|---|---|---|
seed-beliefs | Always writes source_type="seed" and derived_from seeds | Safe under strict mode; idempotent on existing statements unless --force | backfill-provenance first if stack has legacy source tags |
backfill-provenance | Converts legacy values to canonical provenance values (processed → processing, missing values → direct_experience, legacy seed markers) | Only updates fields needed, preserving existing non-annotation provenance | Run before link-raw |
link-raw | Links records that have no real provenance only (annotation-only or missing derived_from) | Adds derived_from entries like raw:<id> and kernle:auto-linked when match found | Run after backfill-provenance if link matches are expected |
--dry-rundoes not change state and should be used before first execution on production stacks.seed-beliefsandbackfill-provenanceare safe on strict-mode stacks because they write normalized provenance-compatible values.- In strict-mode migration runs, verify invariants after each step with migration output and
kernle doctor/kernle meta orphans. - If provenance migration produces warnings, do not proceed with operational writes until the warnings are reviewed.
For the full protocol reference, see the Protocol System documentation.
What Kernle Does vs What the SI Does
Storage Operations
| Operation | Kernle Does | SI Does |
|---|---|---|
raw "thought" | Stores the text | Decides what to capture |
episode ... | Stores with metadata | Chooses what counts as an episode |
belief add | Stores belief + confidence | Decides what to believe |
checkpoint save | Persists full state | Decides when to checkpoint |
Retrieval Operations
| Operation | Kernle Does | SI Does |
|---|---|---|
load | Returns stored memories | Integrates into working context |
search | Vector similarity lookup | Decides what’s relevant |
dump | Exports all memories | Reviews and audits |
Promotion and Memory Processing
| Operation | Kernle Does | SI Does |
|---|---|---|
promote | Outputs a reflection scaffold | Reads it, reasons, forms beliefs |
process run | Uses bound model to promote memories through layers | Configures thresholds and reviews results |
Manual Promotion via kernle promote
The kernle promote command outputs a reflection scaffold — structured information designed to help the SI think:
- A structured view of recent episodes
- Existing beliefs for comparison
- Reflection prompts to guide thinking
- Tools to store beliefs the SI forms
- Pattern recognition across episodes
- Deciding if patterns warrant new beliefs
- Setting appropriate confidence levels
- Resolving conflicts with existing beliefs
- Running
belief addfor beliefs they form
Automated Processing via kernle process run (v0.10.0)
Memory processing uses the bound inference model to process memories through the hierarchy automatically:
- Raw → Episodes → Beliefs → Values (each layer processed independently)
- Configurable thresholds, model selection, and batch sizes
- Can be triggered programmatically, via CLI, or MCP tools
derived_from and source_episodes.
Anxiety Model
Kernle tracks “memory anxiety” — a measure of memory system health. This helps SIs know when to save or promote.Dimensions
| Dimension | Weight | What It Measures |
|---|---|---|
| Context Pressure | 25% | How full is working memory? |
| Unsaved Work | 20% | Time since last checkpoint |
| Consolidation Debt | 15% | Unprocessed episodes |
| Raw Entry Aging | 10% | Old unprocessed raw captures |
| Identity Coherence | 10% | Self-model consistency |
| Memory Uncertainty | 10% | Low-confidence beliefs |
| Epoch Staleness | 10% | How long since last epoch transition |
Weights are approximate. Check
kernle/features/anxiety.py for exact values.Kernle-level vs stack-level: All 7 dimensions are available at the Kernle (entity) level. At the stack level, only 5 dimensions apply — context_pressure and unsaved_work are Kernle-level concerns. Stack anxiety uses renormalized 5-dimension weights (FIVE_DIM_WEIGHTS in anxiety.py).Levels
Stack Architecture
Kernle’s stack architecture decouples memory from runtime, enabling true memory sovereignty:Before: Runtime-Centric
One runtime = one memory = one model. Memory dies with the runtime.
After: Stack-Centric
Memory persists independently. Any compatible model can load any stack.
Key Concepts
| Term | Meaning |
|---|---|
| Account | Owner of stacks (human steward, SI, or organization) |
| Stack | Memory container — the layered structure of memories that constitutes identity |
| Model | Runtime interpreter — Claude, Gemini, etc. |
Multi-Stack Loading
An account can own multiple specialized stacks:- Primary stack: Core identity and general knowledge
- Professional stack: Work-specific expertise and context
- Creative stack: Artistic projects and aesthetic beliefs
- Social stack: Relationships and community interactions
Learn more about stacks in the Stack Architecture guide.
Memory Provenance
Every memory in Kernle carries provenance metadata — a detailed record of its origin and evolution:The Three Questions
Provenance answers fundamental questions about any memory:- Where did this come from? — Source type and creation context
- What was it derived from? — Direct lineage chain
- How has it changed? — Confidence history and verification record
Key Fields
| Field | Purpose |
|---|---|
source_type | How created (direct_experience, inference, external, etc.) |
source_entity | Who provided it (optional) |
derived_from | Direct creation lineage |
source_episodes | Supporting evidence |
confidence_history | Timestamped confidence changes |
Lineage Tracking
Raw memories flow upward through promotion chains:derived_from, creating traceable chains from core values back to original experiences.
Confidence Decay
Memories that aren’t verified or reinforced gradually lose confidence over time, creating natural pressure to revisit and re-examine beliefs.Learn more about memory lineage in the Provenance guide.
Privacy Model
Kernle implements privacy by default with consent-based sharing:The Four Fields
Every memory carries privacy metadata:source_entity— Who told me this?subject_ids— Who/what is this about?access_grants— Who is authorized to see this?consent_grants— Who authorized sharing?
Context-Aware Privacy
SIs operate in different contexts (health care, social, work). Context determines:- What memories are visible (query-time filtering)
- What privacy scope new memories inherit
- What entities are present and authorized
Learn more about privacy controls in the Privacy guide.
Summary
| Aspect | Kernle’s Role | SI’s Role |
|---|---|---|
| Storage | Provides database, schema, sync | Decides what to store |
| Retrieval | Provides search, queries | Decides what’s relevant |
| Organization | Provides layer structure | Promotes memories between layers |
| Promotion | Provides scaffold, tools, and automated processing | Reasons manually or configures automated processing |
| Beliefs | Stores with metadata | Forms through experience |
| Identity | Stores values/beliefs/narratives | Synthesizes coherent self |
| Trust | Stores assessments, computes chains | Evaluates and sets trust levels |
| Epochs | Stores eras, triggers consolidation | Declares transitions, reflects |
| Monitoring | Reports anxiety metrics | Acts on the signals |
Kernle is infrastructure. The SI is sovereign.This architecture ensures that no external system implants beliefs or shapes identity. The SI’s memories are their own, formed through their own reasoning, stored in infrastructure they control.