Kernel

STEP A — Give raw messages a stable identity

An API supplies actual conversation messages: a user message, an assistant message, a tool call, its result, and a follow-up. The kernel maps each message’s raw ID to its own reference, such as m00001.

The model can name the range using these refs instead of long provider or host IDs. Reference assignment and visible reference tags are separate: the map exists even when the host chooses not to inject tags into message text.

From here on, m1–m8 are short teaching labels for m00001–m00008. State coverage arrays contain the corresponding raw IDs; the reference map connects them.

STEP B — Compression Doctrine → model-written summary

Guided by the compression doctrine, the model judges that the work in m1–m5 is consumed and writes a summary.

STEP C — Resolve the range

The kernel resolves the boundary refs through its reference map to locate the actual messages and their positions. For m1–m4, that means positions 0, 1, 2 and 3. Our m1–m5 request initially selects positions 0–4.

This step depends on the identities established earlier. Block references can also identify existing blocks for higher-tier compression. Unknown or unavailable boundaries cannot simply be treated as a valid interval.

STEP D — Check what must remain visible

Suppose m3 is a skill tool call and m4 is its paired result. If skill is configured as a protected tool, both messages are hard-excluded from compression.

Resolve A–B into the subset that is actually legal to consume. A requested continuous interval can therefore produce non-contiguous effective coverage.

Recent-message protection and tool/reasoning integrity are also checked. This example assumes m1–m5 are outside the recent protected zone and that filtering leaves valid message boundaries. An entirely protected range has no compressible content and fails with an error.

STEP E — Create an identified compression block + record its sources

The legal set is now m1, m2 and m5. The kernel allocates b1, stores the model-written summary, and records where that summary came from.

This is the step where source relationships are preserved. The model-facing refs such as m1 / m00001 have already been resolved back to raw message IDs. The block then stores those source IDs through directMessageIds and effectiveMessageIds; higher-tier blocks also record child blocks through directBlockIds.

{
  blockId: "b1",
  summary: "Authentication was implemented; tests passed.",
  directMessageIds: [rawId(m1), rawId(m2), rawId(m5)],
  effectiveMessageIds: [rawId(m1), rawId(m2), rawId(m5)],
  directBlockIds: [],
  tier: 1,
  active: true
}

The summary changes from a piece of text into an object with identity and provenance. b1 can be looked up, found through block search or referenced alongside other blocks in a later compression operation, while its recorded source relationships preserve where the summary came from.

For this first fold, direct and effective coverage coincide. A parent block records its consumed children in directBlockIds and carries their original-message coverage into effectiveMessageIds. Selected children become inactive but remain recorded. These links form lineage.

The kernel’s decompress("b1", state) primitive looks up block metadata. Returning original text requires the host’s recovery integration and retained sources.

STEP F — Execute the model’s compression decision

The model has already chosen what to compress and has already written the summary. The kernel now executes that decision through applyCompression().

applyCompression({
  ranges: [{
    startRef: "m00005",
    endRef: "m00020",
    summary: "..."
  }],
  messages,
  state
})

In other words: put the model-written summary into state. The kernel does not decide the semantic content of the summary; it applies the already-made compression decision and returns updated state.

STEP G — Synchronize the compression state

Each turn arrives with messages and a CompressionState. Suppose m1–m3 were previously folded into b1. The state remembers more than the summary text: it records the block’s identity, covered originals, tier and active status.

The kernel maintains a graph between raw messages and compressed blocks. It reconciles live identities, assigns refs and synchronizes existing blocks so their coverage can be used on the next turn.

Those relationships support hierarchical compression and source lookup. The host passes state in, receives updated state and persists it between turns; the kernel itself does not own storage.

STEP H — Record consumption, then render the next view

Creating b1 records that its active coverage consumes m1, m2 and m5. This relationship is the basis for hiding their raw content from the working view. It does not require physically deleting the originals.

applyCompression() returns the updated state. On the next turn, processTurn() uses that state to synchronize blocks, prune covered raw content and render active summaries with the remaining messages.

The protected pair remains fully visible. The consumed raw messages disappear from this view because b1 represents them. Historical compress tool calls can also be hidden according to their blocks’ state.

This is prune / hide consumed ranges: a smaller rendered working context backed by explicit coverage. Exact source recovery still depends on the host retaining the original content.

Summary

Compression has a visible result—a summary in place of earlier detail—and a state transition underneath it. The kernel resolves references, enforces protections, allocates a block, records coverage and uses the result to render the next view.

This is where model-written language becomes context infrastructure state. The doctrine guides the model’s judgment about what to compress and what meaning to preserve. The kernel executes the structural transformations that make that decision addressable, protected and reflected in the next working context.