Context is a budget, not a bag

Z29C investigations improved when I selected current contracts, evidence, and counterexamples for one decision instead of collecting every nearby log, file, and document.

My first response to a difficult Z29C failure was to open more context.

I loaded the workflow definition, worker logs, queue messages, adapter code, HTTP transcript, database rows, incident notes, related tests, and the last three pull requests. The desk looked prepared. The decision became harder.

Some evidence was stale. Some belonged to another attempt. A current policy document contradicted the definition accepted by the running workflow for legitimate reasons. The longest log was the least useful source and dominated attention because it was visible.

I had treated context as a bag: if a fact might matter, put it in.

Context behaved more like a budget. Every additional item consumed attention, carried freshness and authority questions, and competed with the evidence needed for the next decision.

More evidence and more context were not the same

Evidence supports or contradicts a claim. Context includes everything surrounding the work, whether or not it changes the current decision.

For an unknown delivery outcome, the decision might be whether Retry was safe. The useful evidence set was narrow:

  • Stable workflow and step identity.
  • Immutable input digest.
  • External request key and adapter contract version.
  • Invocation checkpoint.
  • Latest destination query and its consistency window.
  • Idempotency-key expiry.
  • Current workflow revision and authority.

The entire service log could help diagnose why the response was lost and still be irrelevant to whether another delivery would duplicate the effect.

I began writing the decision question first. Context earned inclusion by helping answer it, challenge it, or bound its uncertainty.

This reduced volume without demanding certainty in advance. A small initial set could expand when a hypothesis required it.

Every item had acquisition and interpretation cost

Opening a file feels cheap. Understanding which version, scope, and relationship it represents is not.

A workflow definition required checking that the run actually used that version. An adapter document required knowing whether its idempotency window applied to the request already issued. A log timestamp required its clock domain. A test showed intended behavior and not necessarily deployed behavior. A generated summary could omit the one field that made the result safe.

I thought of context cost in four parts:

retrieval cost
  finding and loading the item
 
interpretation cost
  understanding what it claims and under which assumptions
 
interference cost
  attention it takes from other relevant evidence
 
risk cost
  consequence if stale, private, or wrong context influences the decision

One precise receipt could be cheaper than a thousand log lines. One stale policy page could be expensive despite being short.

The budget was not measured in tokens or file count alone. Meaning determined the cost.

The next decision set the budget boundary

“Debug Z29C” was too broad to guide selection. I decomposed the work into decisions:

  • Did the external effect occur?
  • Is another attempt safe?
  • Why did the response fail?
  • Should the adapter timeout change?
  • Which maintained test prevents recurrence?

Each needed different context.

The status query and request identity answered the first. Adapter capability and key window answered the second. Network and worker logs informed the third. Latency distribution and workflow deadline informed the fourth. The causal mechanism and fault checkpoint informed the fifth.

Trying to answer all five simultaneously produced one undifferentiated investigation. Answering them in dependency order let earlier receipts narrow later searches.

The decision statement also provided a stopping rule. Once sufficient evidence supported the safe action under named limits, I could act and preserve remaining questions separately.

Context became task-shaped rather than repository-shaped.

Two documents could disagree without either being globally wrong. A workflow began under definition 3. Current policy 4 could block its pending side effect. The definition explained what the workflow intended next; current policy explained whether that action remained allowed.

I labeled context by role:

  • Historical basis.
  • Current authority.
  • Runtime observation.
  • Derived projection.
  • Hypothesis or commentary.
  • Test or synthetic evidence.

Freshest did not always mean authoritative. The newest application definition could not reinterpret old stable step identity. The old policy could not grant current permission. The live projection could be stale despite being generated seconds ago if it had an event gap.

Selection included the correct version for each question, not one global “latest.”

This made conflict useful. A mismatch between intended definition and current policy was a state to display, not an error to resolve by choosing the newer file.

Context needs provenance before it can carry authority.

A small manifest made the working set explicit

For consequential investigations, I wrote a compact context manifest:

Decision
  Is another delivery attempt safe for workflow w-17?
 
Included
  Step receipt projection r42 — current through event 188
  Adapter contract delivery/v2 — request used this version
  External query q-9 — observed after consistency window
  Policy decision p-4 — current execution authority
  Scenario lost-response-after-acceptance — nearest counterexample
 
Excluded for now
  Full worker logs — useful for cause, not safe-action decision
  Latest workflow definition v4 — run uses v3

The manifest took minutes and prevented accidental version mixing. It also made handoff easy: another session could see why these sources were present.

I did not create one for every bug. The technique matched decisions where wrong context could trigger another external effect or destructive migration.

The list was a working-set receipt, not permanent bureaucracy.

Exclusion was a reversible decision

The fear behind context hoarding was missing the decisive clue. I made exclusion explicit and revisable.

An excluded item had a reason and a trigger for inclusion. Worker logs remained out until the safe-action decision finished; they entered when investigating why the response was lost. Database query plans remained out until evidence pointed toward slow receipt commits. Historical incidents remained out unless the current failure matched their mechanism.

This preserved awareness without paying full interpretation cost immediately.

I also kept a “context gap” field. If no authoritative adapter contract existed, that absence was itself important. The correct action might be to stop and establish the contract rather than approximate it from code and logs.

Exclusion did not mean the item was unimportant. It meant not yet relevant to this decision under current evidence.

The budget could expand deliberately instead of through anxious accumulation.

Most context I gathered supported the leading hypothesis. That made the working set coherent and fragile.

I reserved room for at least one counterexample or competing explanation:

  • Destination accepted but query index is delayed.
  • Stale worker response belongs to a different request digest.
  • Rate limit scope is global, not per subject.
  • New policy blocks execution even though definition permits it.
  • Apparent duplicate is two deliberate intents with equal payload.

A small adversarial fixture often contributed more than another supporting log.

This practice came from W93H's competing incident hypotheses and became especially useful with Copilot. A plausible completion followed common patterns; the best context often described where this repository deliberately differed.

The context set should not merely make the current answer easier to tell. It should make the closest wrong answer hard to keep.

Counterexamples spent budget on error detection.

Logs needed queries, not collection rituals

Downloading every log around a timestamp felt thorough. It mixed unrelated workflows, repeated retries, and several clock domains.

Z29C's semantic timeline gave a better starting point. I selected workflow, stable step, attempt, request identity, and bounded time interval. Raw logs then answered a named gap.

The query and source identity became part of the context manifest. A copied excerpt retained enough fields to reproduce the search. Sensitive headers and payloads were redacted at source rather than pasted into notes.

If the log system could not query by the stable identity required for recovery, that was an observability defect. I added the field instead of teaching every investigation to search broadly by guessed timestamps.

The best context system reduces the cost of selecting the right evidence. It does not make gathering everything faster.

Search quality begins with identifiers designed into execution.

A run summary could save attention by grouping attempts and receipts. It could also hide the difference between direct success and manual resolution.

I treated summaries like any derived projection:

  • Name the source revision range.
  • Preserve links to underlying evidence.
  • State which distinctions are collapsed.
  • Show stale or incomplete state.
  • Version the projection logic.

For a handoff, the summary led with current knowledge, open gap, last consequential action, and next safe decision. It did not copy every event.

I could regenerate a summary after late evidence without pretending the new fact had been available earlier. Response-time and reconstructed views remained distinct where time mattered.

Compression was useful when its loss was intentional. An unlabeled summary could consume little space and carry enormous interpretation risk.

Context budgeting did not mean trusting shorter artifacts automatically.

The “collect everything” instinct also expanded access and retention. Logs could contain synthetic document data, identifiers, headers, or error responses whose full content was unnecessary.

I minimized context before moving it between systems. The recovery console showed bounded safe fields. External response excerpts followed adapter redaction rules. Context manifests linked to protected evidence rather than copying it into broad notes.

Access matched the decision. A person authorized to review delivery status did not automatically need raw workflow input or credentials. Expiring links and audit events applied where appropriate.

When context was exported for a fixture, data became synthetic and the transformation was documented. Real study-circle content from D4U7 did not enter Z29C scenarios.

More context increases not only cognitive load but information exposure. A budget made minimization an engineering property rather than a cleanup preference.

Q2F8's collection discipline had reached debugging.

Context had a lifecycle

An investigation folder can become a permanent shadow archive. Its copied logs and payloads outlive the incident purpose and drift from their source.

I classified context:

  • Durable decision evidence: receipts, accepted resolutions, maintained tests.
  • Temporary working material: bounded logs, query exports, local scratch notes.
  • Rebuildable projections: summaries and indexes.
  • Sensitive context: shortest justified retention and narrow access.

At closure, the useful conclusion entered code, a test, an adapter contract, or a decision record. Temporary material expired. The manifest retained links and claims where history justified them without copying every source.

If the conclusion depended on evidence that would expire, I preserved the minimal bounded receipt needed to support it or stated the limitation.

The context budget extended through time. A useful working set today should not become an unexplained maintenance burden next year.

When stopping work, attaching all tabs and logs made the next session repeat the selection problem.

A useful handoff included:

  • The decision already made and its evidence.
  • Current unresolved question.
  • Small active context manifest.
  • Exclusions likely to matter next and their triggers.
  • Next bounded action.
  • Completion condition.

For the Z29C delivery investigation, the next action might be run status query after the declared visibility window and compare the returned input digest. The receiver did not need the entire worker log before taking it.

This reused the handoff practice from D4U7. Context is valuable when it moves a person from old knowledge to one safe next transition.

A dump preserves material. A handoff preserves momentum and reasoning.

Generated tools made context selection more visible

Copilot's inline completions drew from available code context and could produce plausible behavior where the repository's true constraint lived elsewhere.

The lesson was not to feed every file into every tool. Irrelevant or stale context can steer a generated proposal just as it can distract a human.

Before asking for a substantial implementation, I selected the type contract, behavior table, nearest counterexample, installed API version, and relevant state transition. The tool could accelerate code inside that frame.

I did not include credentials, private content, or broad logs merely to improve a suggestion. Data authority remained part of the budget.

I suspect code-generation systems will make context selection into explicit architecture. Giving a tool an entire repository may feel generous and still produce a worse proposal if obsolete examples, generated files, and nearby secrets outweigh the few authoritative contracts. A useful system will need to retrieve selectively, preserve source and version, and admit that some relevant material is not authorized for the task.

The discipline is useful now: availability is not relevance, and relevance is not authority.

Context selection remained a human engineering decision even when a tool consumed the result.

Too little context failed differently

Budgeting could become minimalism theater. A tiny context set might omit a cross-boundary invariant and make local reasoning confidently wrong.

I used expansion triggers:

  • A test result contradicts the current hypothesis.
  • The selected source lacks authority or version identity.
  • The decision crosses a new adapter, policy, or storage boundary.
  • The nearest counterexample remains unexplained.
  • A recovery action would be irreversible or duplicate-prone.
  • The current model cannot state what evidence would change the conclusion.

When a trigger fired, I expanded toward the specific gap rather than opening the whole repository.

The goal was sufficient context, not minimal context. A budget allocates resources according to consequence; it does not always spend less.

Some decisions deserved a large evidence set. The important property was that every item had a role.

For recurring recovery tasks, I encoded the necessary inputs in the product.

The recovery console assembled workflow identity, request digest, adapter contract, latest query, deadlines, and current policy because those fields determined safe actions. Scenario tests removed one item at a time and asserted that the action became unavailable or uncertainty increased.

This turned context design into interface and API design. A reviewer did not need to know which six systems to search. Z29C supplied the bounded evidence and linked deeper sources.

If Retry remained enabled without a valid idempotency window, the scenario failed. If a manual receipt could be created without the target digest, the evidence contract failed.

The best context selection eventually moved from personal ritual into the system boundary that owned the decision.

Automation was appropriate because the required context had been made explicit.

Decision quality was the return on the budget

I did not measure context by how few tabs remained open. A small set that omitted current authority was worse than a larger set that included it.

The useful outcomes were:

  • Faster resumption without repeated archaeology.
  • Fewer version and identity mix-ups.
  • Clearer reasons to query or retry.
  • Less sensitive data copied into working notes.
  • Counterexamples considered before consequential action.
  • Conclusions converted into maintained tests and contracts.

There was no fabricated productivity percentage. The effect appeared in scenario reviews and the ability to explain a decision from its evidence.

When the context set was good, the next action felt smaller. That was not because the system had become simple. The relevant boundary had become visible.

A bag optimizes for not forgetting

The bag metaphor treats omission as the main risk. Put everything nearby and trust future attention to find the important pieces.

A budget recognizes several risks at once: omission, overload, staleness, misplaced authority, privacy, and retention. It asks what this decision deserves and what every item costs.

Z29C's hardest recovery questions rarely needed the entire codebase. They needed one stable intent, one effect identity, one current contract, one evidence gap, and one counterexample that could prove the safe action wrong.

I still opened broad context during exploration. I stopped confusing exploration with the evidence set that authorized a decision.

Context is not good because it is available. It is good when its provenance, scope, freshness, and relationship to the question are clear.

The working set became smaller only as a side effect. The real improvement was that every piece had a reason to be there.

When the decision changed, the context could change with it. The manifest was not a monument to the first hypothesis; it was a maintained allocation of attention to the next consequential uncertainty.

Selection remained an active judgment.