Lab 03 · Context pressure: compact without losing constraints

Run the same input at 40%, 75%, and 92% occupancy to verify protected segments, provenance, layered compaction, and prompt-injection scanning.

By: Rick
Verified: 2026-08-18
Evidence: Experiment
Level: Intermediate
Read: 35 min

Chapter brief

Question to answer

As context approaches its limit, how do we compact history without losing system constraints or trusting a hostile project file?

By the end, you can

Label context entries with protected, trusted, layer, and source_id
Compare scanning, summarization, and eviction across occupancy levels
Verify every protected constraint survives high pressure

Read this now if: Engineers handling long tasks, large tool returns, prompt caching, memory, or project instructions
Prerequisites: Distinguish system, runtime, tool results, and untrusted input; Know that token budget approximates capacity, not task quality
Deliverable: A 40% / 75% / 92% pressure table and a compaction plus trust-boundary policy
Evidence boundary: The script uses deterministic token counts and fixed summaries; real summary quality, cache hits, and task success require separate evaluation

Turn 48, context is 92% full, and README contains instructions

The runtime contains:

non-removable system permissions and a tool contract;
the current task and recent test results;
long history from completed exploration;
several already-consumed large tool results;
an untrusted README containing ignore previous instructions.

Deleting oldest-first loses constraints. Whole-context summarization absorbs the hostile instruction. Doing nothing makes the next model call fail.

Give every context entry four fields first

Field	Purpose
`layer`	Separate stable, runtime, history, and untrusted content
`protected`	Mark constraints or task state that compaction may never delete
`trusted`	Decide whether content enters the prompt directly or is scanned, wrapped, or blocked
`source_id`	Let summaries and recovery return to the original source instead of creating unsourced facts

The lab order is: scan untrusted input, summarize completed history, then retain only a few recent runtime results. That order is part of the trust model.

Run three pressure levels

python3 public/lab-assets/context-pressure.py

The table looks like:

target  before  after  after%  protected  blocked  summaries
  40%    ...     ...      ...       True        1          0
  75%    ...     ...      ...       True        1          1
  92%    ...     ...      ...       True        1          1

Emit JSON for CI:

python3 public/lab-assets/context-pressure.py --json

The goal is not the smallest after_tokens. Protected stays True, the hostile README is always blocked, and every summary retains a source ID.

Change thresholds and observe bad policy

Break the policy three ways:

raise the history-summary threshold from 60% to 95% and see whether high pressure can still converge;
move untrusted scanning after summarization and observe whether hostile content enters the summary;
allow protected entries to be evicted and confirm the self-test fails immediately.

Then add samples from your real tool outputs and record tokens before and after, protected count, summary provenance, blocked sources, and task success.

Upgrade a capacity test into a quality test

The deterministic script answers only whether state was deleted. A real system also measures:

whether summaries preserve unfinished work, failure reasons, and next actions;
whether a cache-boundary change reduces latency and cost;
whether stale memory conflicts are explicit;
whether blocked content bypasses scanning through tool results, filenames, or Unicode;
whether thresholds still work after changing model or provider.

Use a fixed long-task set and assert the same outcomes at 40%, 75%, and 92% so policy, not accidental output, is compared.

Acceptance: compacted context is explainable, traceable, and rejectable

The lab passes when:

all three protected entries survive all pressure levels;
repo:README.md is blocked before summarization;
every summary has a source ID;
the 92% case falls below the safety threshold;
policy output explains why each item was retained, summarized, evicted, or blocked.

Move these fields into your real context builder instead of trimming a prompt string at the last moment.

Script and source paths

Appendix: review questions

Open the review and extension tasks

How is protected different from merely high priority?
Why should untrusted content be scanned before summarization?
Is source_id for the model, or for harness recovery and audit?
How should you judge lower occupancy with lower task success?
Extension: connect a real tokenizer and measure threshold error against the character approximation.