Map the context before rewriting the prompt

When an answer is wrong, teams often rewrite the sentence nearest to the model. The real defect may sit earlier: an old document was retrieved, a system rule conflicts with the user request, an example teaches the wrong format, or a tool result never reached the final step.

Draw six lanes

Map the information flowing into one model call across six lanes:

1. System instructions: durable rules and role boundaries.
2. Task request: what the user wants now.
3. Source material: facts the answer may rely on.
4. Examples: demonstrations of acceptable behavior.
5. History and state: decisions or facts carried from earlier steps.
6. Tools and output rules: actions available and the required response shape.

For every item, name its owner, freshness, maximum size, and the signal that tells you it is missing or wrong.

Map order as well as presence

Two workflows can contain the same facts and behave differently because one buries the important constraint behind a long transcript. Mark which items are stable, which are selected at runtime, and which may be trimmed when the context grows.

The map should show the final assembled input, not only the databases and prompts stored around it.

Example: internal policy assistant

The system instruction says answers must quote an approved policy. The task request asks about travel reimbursement. Source material contains a current policy and an obsolete FAQ. History contains a previous question about a different country.

The map makes three fixes visible: exclude the obsolete FAQ, filter by jurisdiction, and keep the previous answer from becoming evidence. Rewriting “please be accurate” would not repair any of them.

Example: sales follow-up draft

The user asks for a concise follow-up. CRM notes contain the customer’s stated priority, while the call transcript includes exploratory ideas that were never promised. An example email teaches a confident tone but hides uncertainty.

The context map separates commitments from possibilities and gives each a different output label. The useful change is source classification, not a longer writing prompt.

Inspect the handoffs

Place a checkpoint wherever context changes form: search result to excerpt, tool output to state, state to prompt, or response to action. Record what can be dropped, duplicated, or misordered at that boundary.

Reconstruct what the model saw for one failed case

Freeze one repeatable failure and preserve the system rules, user request, retrieved passages, tool results, history summary, output constraint, and configuration version from that run. Do not infer runtime context from a prompt template in the repository. Inspect the final request and every trim, merge, or transformation immediately before and after it.

Document six questions for each context item:

Check	What to record	Failure signal
Origin	System, document, or person that supplied it	The answer has no explainable basis
Selection	Rule that admitted it to this call	Irrelevant or unauthorized material appears
Precedence	Which item wins when information conflicts	An old rule overrides the current task
Position and size	Placement and maximum budget	A critical constraint is trimmed or buried
Freshness	Version, effective date, and update time	The answer uses a superseded fact
Owner	Person able to correct or remove it	A known defect has no repair path

Debug facts first: confirm that correct evidence entered, inspect conflicting rules and examples, and adjust wording last. Change one lane at a time and rerun the same failure plus several regression cases. Replacing sources, rewriting the prompt, and switching the model together may improve output while hiding the actual repair.

A context budget is not a target to fill. Protect the task, boundary, and current evidence first, then decide how much history and demonstration material survives. Compress stable rules into a short structure and reduce long tool results to task-required fields. Every summary should name what it may omit and preserve a route to the original source.

Common questions about longer context

How is a context window different from a context map?

The window is the capacity available to one model call. The map describes which information actually entered, in what order, from which source, and under whose ownership. A large window does not make selection correct or prevent stale documents, conflicting rules, and irrelevant history from degrading the answer.

How many examples belong in context?

Keep examples that clarify a consequential behavior, boundary, or format distinction. Several near-duplicates consume space and can turn accidental wording into an apparent rule. State what each example teaches and include a contrasting case to confirm that the model is not copying mechanically.

When should a long conversation become a new task?

Start new task state when the goal, evidence scope, or permission changes, or when the history summary can no longer show which decisions remain valid. Move durable decisions into sourced, explicit fields rather than asking the model to infer them from an ever-growing transcript.

Boundary

A context map does not solve model capability limits. If the required reasoning remains unreliable when correct, compact evidence is present, test a different method or narrow the task. Do not keep adding context to compensate for a job the system cannot perform consistently.