memory-and-context
From the Meridians Wiki · Public · Maintained · joint
Memory & context
A domain that has run for hundreds of scenes cannot fit in one prompt. The memory layer decides, at every step, what the model is allowed to see — full detail on the immediate horizon, faithful compression behind it. It is what lets a domain compound without collapsing under its own context.
World context — In multi-camera play, context is also a world rule. A playable character, location,
artifact, or other seat receives a context assembled from its graph position, memory, information that has
reached it, resources, permissions, current turn, and available tools. The seat must not inherit the
Director's omniscient record merely because the model could technically read it. Context management is
therefore both compression and information-economy enforcement. The exact context algorithm remains
product direction. A seat's outline is witnessed-only, with unseen scenes represented by elsewhere
stubs; narrator and Director perspectives read the whole outline.
Entity Interpretation — An immutable, evidence-backed context graph for one entity at a declared branch, moment, and vantage. Its nodes are an explicitly ordered array of reasons; typed edges retain how those reasons support, inhibit, activate, or contradict one another. An attributable binding may select the graph to replace raw entity continuity in a downstream model context. Replacement is contextual and reversible: canonical continuity remains stored, current Frames and Control remain live beside it, and a null selection restores the evidence context. The artifact is not a force, personality score, diagnosis, or source of action authority.
Tiered resolution — Scene history renders at lower detail the further back it sits from the cursor, but a scene is never dropped, only compressed. Near scenes render every delta; mid scenes keep only thread transitions and movements; far scenes collapse into a single arc snapshot. The model reads the recent past like a transcript and the distant past like a briefing.
Recency window ("memory loss") — An entity, thread, or rule drops out of context once its most recent use is more than a set lookback behind the cursor. A "use" includes an attribution, so a node a scene structurally leans on stays warm even if it wasn't directly changed. The working set tracks what is load-bearing now, not everything that ever happened.
Summary of summaries — Compression as a hierarchy, not truncation. Each scene summary must name the specific claim/tradeoff/conclusion a later scene needs. Each arc carries a world-state snapshot — a ground-truth account of where its scenes left the world, precise enough to supersede replaying the arc's deltas. Above that sits the domain's own summary. When far history collapses, it collapses into these.
Attribution — The accounting of what a scene structurally leans on: the entities, threads, rules, and leaf Theme Principles it depends on, merged from what the model declares and what the engine derives from typed deltas. Theme attribution derives only from canonical ThemeSignals: each signal contributes its Principle, carriers, and carrier→Principle links; neutral Theme Types receive none. Aggregated over the timeline, attribution sorts every node into activation tiers (hot / warm / cold / fresh) and a topology (hub / bridge / leaf / isolated), with Theme shown as a purple fourth attribution cohort beside the three causal forces. It also ranks the knowledge tree — a rule that keeps getting leaned on rises to the top as genuinely central. The forces read off deltas; memory decides which deltas the model re-reads.
Window Context (the god context) — An absolute snapshot of a period of time, built bottom-up from timestamped atoms. Where tiered resolution answers "what may the model see now", Window Context answers "what was true, what moved, and what it meant between these two moments". A window carries the substrate (thread/world/system deltas, stream priors, relationships, projection lifecycle + checks, articles, notes, readings, graphs, Modes, merges, scene/world-commit summaries) and the Program's own readout for the same period (research briefs, Opinion readings, tutor/projection proposals, directives, and the published Stories). Selected by preset (everything is the working default) over either axis: time (wall-clock) or scene (story position). Density is managed by the level of abstraction of each block — articles render their refined summary, a Story renders its headline + narrative and locates its attachments as ids, a brief never carries its long-form drill-down — never by dropping kinds. A scene-axis window that excludes off-branch atoms says so on <window omitted-off-branch>; nothing is dropped silently.
Atom — The finest timestamped unit a Window Context is composed from. Collection is atom-up; rendering is container-down (an entity's facts nest under one <entity>, a projection's moments and checks under one <projection>). An atom is windowable on both axes because every atom carries an at.
Temporal size — The one vocabulary for "how big is this slice of time": tokens (what it costs to read), active days of the span (whether the period is worth reading at all), and the period itself. It replaces per-surface item tallies — a "movement count" conflated a one-line prior with a full reasoning graph and said nothing about whether the period was one busy afternoon or a fortnight of steady work. Item counts survive as provenance, never as the headline.
Operator profile — Who the model is assisting: the real person driving the session, carried as the acting member's name and a self-authored bio ("about you"). It is not part of any domain — it is ambient session identity — so it rides into generation through a single operatorProfileStore (the third parallel of the identity / director-member bridges) that the client pushes from the People registry and the master resolves per-op. Every context builder — domain, outline, arc, scene, readings, mode, streams, game-theory, investigation, and Window Context — prepends one <operator> block, so anything grounded in context knows who it is for. This is what stops the model inventing an author (a stray "Jacob Vance") when a first-person or personal entry — a health log, a journal note — needs a name: the operator's real identity is right there, and the discipline is never invent a name in their place. An empty profile stays silent; a bare first/last name still grounds identity. Edited in the Profile panel. (The bio lives on instanceMembers, never on a DomainState.)
Record Context / Window Context — The two context shapes the constellation Expert chat reads, selected by a router toggle. Both use one generalist in two phases: Auto first routes every candidate through bounded Arc-coverage cards, then synthesis receives the chosen Domains' requested context. Record Context (code: router: "domain"; internal payload key: known; UI label Record) carries what the domain knows overall — from Arc coverage through the selected context depth — and is independent of a date range. Window Context (code: router: "window"; UI label Window) carries a temporal window over a chosen date range (full-preset atoms, the shared calendar vocabulary), but those full Window bodies are built only after routing and only for the selected Domains. Window synthesis therefore reads which selected Domains actually moved in that slice of time without paying to construct or send every candidate's full temporal record. A valid empty Auto selection stays empty; only routing failure falls back to all candidates. The pairing is flow vs stock — what moved, versus what is held in the record — and either can be the heavier read. An explicit all-domains or custom scope bypasses Auto narrowing. The active router + window persist on the constellation. Expert names the reader in both modes, never one of them — it is not a context type. (Renamed 2026-08-05 from "Known" to Record, which names the durable source the mode reads; previously renamed from "Expert Router", which implied a contrast that never existed since the Expert reads both. "Canon" was rejected because canonBranchId already makes canon mean the main line vs a fork, a different axis.)