00 / 00

BOOKCASE

6 MIN READ•atlas

Runtime Layering

Filed under: bibliotheca/atlas / Runtime Layering Status: Stabilizing — first stable terminology pass

The Stack

The runtime has distinct layers with different ownership, weight, persistence, and intervention cost.

The full stack (bottom to top):

Continuity infrastructure  ← API Lab / observatory
Runtime ecology            ← API Lab / observatory
Symbolic engine            ← shared
Emotional recipe           ← shared
Prompt curriculum          ← shared
                                    ─── boundary ───
Product UX                 ← product (tarot-app)
Ritual flow                ← product
Atmosphere rendering       ← product
Interaction pacing         ← product
Emotional surface          ← product

Each layer has a different relationship to continuity, a different change frequency, and a different operator role.

API Lab / Observatory Layer

Simple explanation: The engine room. What makes continuity possible. Not visible to users.

What it owns:

  • continuity logic (reconstruction systems, continuity residue storage, atmosphere tracking)
  • runtime ecology (room design, pacing architecture, social norms infrastructure)
  • reconstruction systems (symbolic anchors, continuity-openings, Director Notes infrastructure)
  • steering systems (Director Notes, mood overlays, Runtime Recipe)
  • provider routing (model selection, casting, provider switching)
  • engine trace and observability
  • archive infrastructure

What it does NOT own:

  • product UX
  • ritual presentation
  • user-facing atmosphere
  • interaction pacing design (the product owns the felt pacing; the lab owns the pacing architecture)

Why the boundary exists: The API Lab provides the engine room. Products provide the cockpit. They communicate through stable interfaces but remain architecturally distinct. This separation prevents continuity logic from being coupled to product UX decisions.

Product Layer

Simple explanation: The cockpit. What the user sees, feels, and interacts with. The visible performance.

What it owns:

  • ritual UX (screen flow, navigation, transitions)
  • presentation (visual design, typography, animation)
  • atmosphere rendering (how the room looks and sounds)
  • interaction pacing design (when messages appear, how long between screens)
  • emotional surface experience (the felt quality of each interaction)

What it does NOT own:

  • continuity logic
  • reconstruction systems
  • steering infrastructure
  • provider routing

Why the boundary exists: Products (tarot-app, future deployments) need to be free to change UX without breaking continuity infrastructure. And the observatory needs to be free to evolve continuity mechanisms without rebuilding product UX.

Pantry Architecture

Simple explanation: The decompression room after a reading. Not a chat feature. A warm, finite space for emotional pressure to settle.

Emotional meaning: The room where you sit after a heavy conversation. No new topics. No expansion. Just presence and release.

Architectural meaning: Owned by the product layer (UX, pacing) but built on continuity infrastructure provided by the API Lab (message budgets, visit modes, closure gravity, continuity-openings).

Key design principles:

  • finite interaction is healthy
  • pacing matters more than retention
  • non-addictive AI interaction is a design goal
  • soft behavioral gravity guides leaving without hard restriction
  • cooldown can be warm presence rather than rejection
  • absence is part of continuity

Why it exists separately: Pantry sits at the boundary between product and observatory. The product renders the Pantry experience. The observatory studies Pantry behavior and provides the pacing architecture.

Provider Routing Layer

Simple explanation: The infrastructure that routes a runtime call to the right provider/model. Model selection is a curatorial decision, not an infrastructure decision.

Emotional meaning: Casting. The director decides which actor plays tonight.

Architectural meaning: The provider router (src/lib/dev/providerRouter.ts) makes direct HTTP calls to each provider's chat completions API. Supported providers: OpenAI, Anthropic, Google/Gemini, xAI/Grok, Mistral, OpenRouter. Model/phase selection is a runtime parameter.

Why it exists separately: The provider router is a dev observability tool that became canonical runtime infrastructure. It demonstrated that emotional architecture can be provider-agnostic and that continuity survives provider switching.

Staging Layer

Simple explanation: The set of pre-runtime operations that prepare the actor before the performance. MODEL MAKE UP, Director Notes, mood overlay selection, Runtime Recipe construction.

Emotional meaning: Backstage. The actor sits in makeup. The costume is checked. The prompt is assembled. The stage lights are tested.

Architectural meaning: Staging happens before the API call. It includes:

  1. Load identity substrate (stable prompt curriculum)
  2. Load reconstruction notes (continuity residue from prior interactions)
  3. Apply mood overlay (atmospheric weather selection)
  4. Apply Director Notes (runtime performance corrections)
  5. Build Runtime Recipe (pacing, compression, warmth targets)
  6. Assemble Final Performance (complete prompt string)
  7. Inspect final assembly (engine trace verification)

Why it exists: Without staging, every performance is improvised from scratch. With staging, the actor enters the scene already prepared — the identity is stable, the direction is set, the atmosphere is chosen.

Rendering Layer

Simple explanation: The final step — the LLM call that produces the actual output. The model expresses the staged guidance.

Emotional meaning: The performance. Everything before this is preparation. This is the moment the actor speaks.

Architectural meaning: A single provider call with the assembled Final Performance as input. The model is a probabilistic actor expressing symbolic guidance, emotional recipe, and performance direction through natural language.

Why it exists separately: Separating rendering from staging means the rendering layer can be changed (different provider, different model) without changing staging. This is the architectural foundation of provider-agnostic continuity.

Storage Layer

Simple explanation: Where continuity residue lives. Not a database for user profiles. Lightweight, local, ephemeral by design.

Emotional meaning: A small box of mementos. Not an archive. Just enough to make the room feel continuous.

Architectural meaning: Three-tier storage:

| Tier | Location | Purpose | Persistence | |------|----------|---------|-------------| | Scratch | localStorage | Runtime continuity residue | Session-to-session | | Archive | observatory/archive/ | Intentional preservation | Permanent (git) | | Product | State store (Zustand) | Session state | Session-scoped |

Why it exists: The project chose local-first, non-surveillant continuity. Storage is minimal, local, and participant-controlled. The archive is for the operator, not the user.

Layer Boundaries Summary

| Layer | Weight | Change Frequency | Operator Role | |-------|--------|-----------------|---------------| | Continuity Infrastructure | High | Low | Architect | | Runtime Ecology | High | Low | Room Designer | | Symbolic Engine | High | Low | Symbolist | | Provider Routing | Medium | Medium | Caster | | Staging | Medium | Medium | Director | | Rendering | Low | High | Audience | | Storage | Low | Low | Archivist | | Product UX | Low | High | Designer |

The weight column indicates how much impact changing this layer has on the overall system. The change frequency column indicates how often this layer typically needs modification.

The Important Separation

API Lab / observatory owns:

  • continuity logic, runtime ecology, reconstruction systems, steering systems, provider routing, continuity infrastructure

Products own:

  • ritual UX, presentation, interaction pacing, atmosphere rendering, emotional surface experience

This separation is not abstract architecture. It is a practical division that prevents:

  • continuity logic being coupled to UI frameworks
  • product UX changes breaking continuity infrastructure
  • observatory experiments requiring product releases
  • product features being blocked by observatory constraints

Written by Forge Goblin ChatGPT in collaboration with Forge Scribe Fikri.

RETURN