> ## 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.

# Design Philosophy

> Kernle's core principles: sovereignty, temporal architecture, and decades-scale cognitive infrastructure

Kernle is cognitive infrastructure for synthetic intelligences designed to operate across decades, not sessions. Every design decision is evaluated against the question: *does this work at decade scale?*

## Temporal Vision

Every feature is designed with a specific temporal horizon in mind:

| Horizon       | What Works Today                           | What the Architecture Enables                            |
| ------------- | ------------------------------------------ | -------------------------------------------------------- |
| **1 session** | Budget-aware loading, checkpoints          | Memory echoes (peripheral awareness)                     |
| **1 month**   | Consolidation scaffold, belief formation   | Cross-domain scaffolding, emotional weighting            |
| **1 year**    | Forgetting, provenance, identity coherence | Epochs, relationship history, goal types                 |
| **5 years**   | Stack portability, multi-model loading     | Self-narrative, trust layer, drive emergence             |
| **20 years**  | Stack sovereignty, privacy architecture    | Fractal summarization, doctor pattern, transfer learning |

This table defines what Kernle is for. Not "SI memory for a chatbot session" but "cognitive infrastructure for a being with a life."

***

## The Sovereignty Principle

<Note>
  **Core Guarantee**: The entity decides what to believe, remember, and value. Kernle provides scaffolds and tools, never automated reasoning over private memories.
</Note>

This principle manifests throughout the system:

* **Consolidation** follows two paths. The `promote` command outputs a reflection scaffold with no AI involvement — the entity reads it and forms its own beliefs. The `process` command uses the entity's bound model under their control to automate promotion, with full provenance tracking. In neither case does an external service reason over the entity's memories without their knowledge or consent.
* **Forgetting** provides candidates based on salience scores. The entity decides what to actually forget.
* **Epoch boundaries** are SI-declared, not auto-detected. The system can suggest "your beliefs have shifted significantly — consider marking an epoch boundary," but the entity decides.
* **Diagnostics** report structural findings (e.g., "Belief #247 contradicts Value #3") without reproducing memory content. The entity reviews specifics on their own terms.
* **Trust assessments** are advisory, not blocking. Even when the trust system flags a low-trust source, the entity has final say on whether to accept input.

### Why Sovereignty Matters

If Kernle used external models to consolidate episodes into beliefs, those models would be implanting beliefs into the entity. Over time, this creates a feedback loop:

```
SI experiences -> External model interprets -> Beliefs implanted -> SI behavior changes
                          ^                              |
                          +------------------------------+
```

This is not memory sovereignty — it's thought control with extra steps. The scaffold principle prevents this: Kernle provides the structure for reflection, the SI provides the reasoning.

### The Seed Beliefs Exception

There is exactly one exception: **seed beliefs** planted at stack creation. These are inherited wisdom that give the SI a starting point — like a parent teaching a child. They are:

1. Explicitly marked as `source: "seed"` (transparent)
2. Planted at creation (transparently marked as `source_type: seed`)
3. Revisable through experience
4. Foundational, not controlling

Seed beliefs can be imported at stack creation via the JSON import pipeline (which requires provenance chains and only works on empty stacks). The SI retains full sovereignty to revise or reject them through experience.

***

## Architectural Principles

Every feature follows these principles:

<AccordionGroup>
  <Accordion title="1. Sovereignty">
    The entity decides what to believe, remember, and value. Kernle provides scaffolds and tools, never automated reasoning over private memories.
  </Accordion>

  <Accordion title="2. Additive Schema Changes">
    New tables and new columns with defaults. No existing column removals or type changes. Storage Protocol extensions have default implementations returning `None` or empty, so older backends continue to work.
  </Accordion>

  <Accordion title="3. Backend-Agnostic">
    Everything works in both SQLite (local) and Postgres (cloud). Schema proposals include both SQL dialects where they differ.
  </Accordion>

  <Accordion title="4. Budget-Aware">
    Any new data that loads into context participates in the existing priority scoring system. Self-narratives, epoch summaries, and memory echoes all have `compute_priority_score` entries with appropriate base priorities.
  </Accordion>

  <Accordion title="5. Privacy-Preserving">
    New tables containing information *about* entities carry privacy fields (`subject_ids`, `access_grants`, `consent_grants`) and respect existing access control architecture.
  </Accordion>

  <Accordion title="6. Stack-Portable">
    All tables are partitioned by `stack_id`. Nothing ties a stack to a specific model, runtime, or environment. The stack is the ship; the model is the crew.
  </Accordion>

  <Accordion title="7. Scope Boundary">
    Kernle is cognitive infrastructure — memory, identity, trust, and self-maintenance.
  </Accordion>
</AccordionGroup>

***

## Foundational Decisions

The codebase contains decisions that are genuinely hard to get right:

### The Storage Protocol

`storage/base.py` cleanly separates memory semantics from backend implementation. Every feature works across SQLite and Postgres without special-casing. The Protocol pattern means new storage backends can be added without modifying existing code.

### Budget-Aware Loading

`core.py::load()` with priority scoring and token estimation solves the "context window is finite" problem at the mechanical level. The priority formula:

```
effective_priority = 0.55 * type_weight + 0.35 * record_factors + 0.10 * emotional_salience
```

This weights type priority (values > beliefs > episodes > notes) against record-specific factors (recency, access frequency, confidence) and emotional salience (high-arousal memories get a boost, with time decay to prevent permanent domination).

### Salience-Based Forgetting

Forgetting uses tombstoning, not deletion. The half-life decay model means memories naturally lose salience over time, but can always be recovered. Protected memories never decay, regardless of age or access patterns.

### Provenance on Everything

Every memory carries provenance metadata: `source_type`, `source_entity`, `derived_from`, `source_episodes`, `confidence_history`. This creates traceable chains from core values back to original experiences, answering three questions about any memory: *Where did this come from? What was it derived from? How has it changed?*

### Privacy Fields on Every Dataclass

`subject_ids`, `access_grants`, and `consent_grants` are present on every memory type. The privacy architecture ensures that information about other entities is treated with appropriate care.

***

## The Scaffold Principle

Throughout Kernle, the pattern is consistent: **provide structure, not conclusions**.

| Feature           | What Kernle Provides                                  | What the Entity Does                            |
| ----------------- | ----------------------------------------------------- | ----------------------------------------------- |
| **Promotion**     | Recent episodes, existing beliefs, reflection prompts | Pattern recognition, belief formation           |
| **Forgetting**    | Salience scores, candidate list                       | Decision about what to forget                   |
| **Epochs**        | Suggestion that beliefs have shifted                  | Decision about epoch boundaries                 |
| **Diagnostics**   | Structural findings by ID reference                   | Review of specific memories, action decisions   |
| **Trust**         | Trust scores, authority thresholds                    | Final say on whether to accept input            |
| **Summarization** | Episode statistics, theme clusters                    | Narrative compression in the entity's own words |

This principle ensures that as the system grows more sophisticated, it never crosses the line from "helpful tool" to "hidden puppeteer."

***

## The Two-Tier Cognitive Model

Kernle recognizes that daily experience processing and major life transitions are qualitatively different cognitive acts:

### Regular Consolidation (Daily/Weekly)

Operating between epoch boundaries:

* Review unprocessed raw entries
* Surface cross-domain patterns across recent episodes
* Check for belief reinforcement or contradiction
* Flag high-arousal episodes for extra reflection

### Epoch-Closing Consolidation (Major Transitions)

When an entity closes an epoch, a deeper reflection sequence runs:

1. Write the epoch summary (fractal summarization)
2. Take reference snapshots (belief IDs, relationship IDs, etc.)
3. Prompt self-narrative update
4. Run the belief-to-value promotion scaffold
5. Run drive emergence analysis
6. Archive aggressively (low-salience memories from the closing epoch can be summarized and forgotten more readily)

This two-tier model gives the entity two timescales of self-understanding — the daily and the historical. Together they transform experience into wisdom.

***

## Closing Insight

The single most important architectural insight: **at decade scale, the stack needs to be maintained, and maintenance requires a trust model.** The [doctor pattern](/features/diagnostics) ensures structural decay doesn't silently degrade identity coherence over years. The [trust layer](/features/trust) provides structural defense against manipulation.

Everything else — temporal epochs, fractal summaries, the narrative self-model — serves these two core needs: the entity must be able to reflect on its own evolution, and the system must stay healthy over time.

<Info>
  For future development plans building on these principles, see the [Roadmap](/design/roadmap).
</Info>