How context changes the quality of an AI answer

“Yesterday” needs a date before it needs a clever prompt

Ask an assistant to interpret “lunch yesterday” without a date or timezone, and part of the task is undefined. A more emphatic instruction to be precise does not supply the missing reference point. The workflow needs context that makes the word meaningful, plus a rule for what to do when that context is unavailable.

In the operator's StockNote code, the AI extraction service receives a structured context pack containing a client date, timezone, locale, base currency, and allowed account candidates. That is a more interesting design choice than adding a long paragraph of background. Each field narrows a particular decision the extractor needs to make.

This guide uses that inspected implementation and our document-retrieval experiment to explain how to build a context pack. We did not run a controlled comparison of model answers with and without these fields. The examples below are design exercises, not measured claims of prompt improvement. The goal is to make missing information and hidden assumptions easier to see before evaluating the answer.

Original TrendsWhat visual guide. These are different roles for information, not five boxes that must always be filled with more text.

Five kinds of context that do different jobs

Task instructions say what the assistant should produce. Evidence provides material the answer may rely on. Current state explains the relevant moment or environment. Constraints define allowed choices and boundaries. Examples demonstrate an output pattern. Mixing them together can obscure why a response went wrong.

Suppose you want a summary of a support policy. “Write a short answer for a guest user” is an instruction and audience definition. The policy paragraph is evidence. The document revision date is state. “Do not infer permissions absent from the policy” is a constraint. A sample answer with a citation demonstrates the format.

When a result fails, these categories point to different repairs. An irrelevant source requires better evidence. An incorrect reference date requires corrected state. A verbose answer may need a clearer format. Adding more examples to compensate for missing policy text changes the wrong part of the input and can encourage the assistant to imitate facts that do not apply.

What the project context pack makes explicit

The inspected StockNote builder returns a versioned context object. Its user profile normalizes text fields, a date-shaped string, and a three-letter currency code. It includes account candidates and a payment account candidate. It also retrieves a bounded set of recent expense records for the authenticated user.

Those details show a useful direction: provide application state deliberately instead of expecting the model to infer it from conversation. Allowed account codes can be supplied as a list. A reference date can come from the client. Locale can guide the language of the response without being confused with the currency of a transaction.

The code inspection also exposes limits worth preserving. A date-shaped string is not proof that a calendar date is valid. A three-letter string is not, by itself, proof that a currency is supported throughout the application. The builder's field named recent_similar_transactions is populated by the latest ten expense rows in the inspected query, not by an observed semantic similarity search. Names should not be mistaken for stronger evidence than the code provides.

Separate facts from defaults

A default is a policy choice. It may be useful, but it is not the same as information the user explicitly supplied. If a message omits currency and the application uses the account's base currency, the resulting value should be understood as a contextual default. If the user explicitly names another currency, that evidence needs different treatment.

The same distinction applies to dates, categories, recipients, and destinations. An assistant can produce a complete-looking object by filling every blank, but completion can hide assumptions. A useful review surface lets a person see consequential values and correct them before an action occurs.

In your context pack, label the source of important fields. For example, distinguish user-stated, application-provided, defaulted, and unresolved. You do not necessarily need to show all four labels in the final interface, but preserving them during preparation and review helps diagnose a wrong answer. It tells you whether to change extraction, application state, or default policy.

A fictional context pack you can adapt

The following example concerns a fictional workshop note. It is a reusable template, not a transcript from a model run:

{
  "task": "Draft a participant reminder",
  "audience": "registered attendees",
  "state": {
    "event_date": "2026-10-08",
    "timezone": "Asia/Seoul",
    "draft_status": "not_sent"
  },
  "evidence": {
    "venue": "Room Cedar",
    "start_time": "14:00",
    "materials": ["laptop", "charger"]
  },
  "constraints": {
    "send_messages": false,
    "invent_missing_details": false
  },
  "unknowns": ["accessibility contact"]
}

The template separates the event facts from the permission to act. A request to draft a reminder does not authorize sending it. The unknown accessibility contact remains visible rather than becoming a plausible invented email address. A reviewer can now ask a focused clarification or omit that detail explicitly.

Before using the template, replace every fictional value and remove fields your task does not need. Templates become dangerous when their sample facts survive into real work. A helpful practice is to use unmistakable placeholder values during design and require a preflight check before creating the final request.

Evidence needs its scope attached

Our retrieval experiment provides a concrete example of context loss. An overlapping text window retrieved export-related wording and the start of a guest heading but omitted the guest restriction. The model would have received relevant terms without the complete policy sentence if that fragment were used as its evidence.

This suggests a practical preparation rule: keep a rule with the heading, population, exception, and date needed to interpret it. More text is not automatically better, but a smaller passage that removes the decisive qualification can be worse. The correct unit of context depends on meaning, not only length.

For a research brief, attach the source title and revision date to the relevant passage. For a spreadsheet, retain column headers and units beside values. For code, include the caller contract when it determines whether a function may assume valid input. Context quality improves when relationships survive the transformation into a prompt.

Examples should teach form without smuggling facts

A good example can clarify the desired structure faster than several paragraphs of instructions. It can show how to separate a conclusion from evidence, how to label an unknown, or how much detail a reader needs. But a sample can also import irrelevant assumptions if its content resembles the real task too closely.

For instance, a reminder example that includes a parking instruction may lead a reader or assistant to repeat that instruction when the actual venue has no parking information. The problem is not merely model behavior; people also copy templates too literally. Label which parts are format and which parts are fictional content.

Use contrasting examples when the boundary matters. Show one answer with sufficient evidence and another that correctly says information is unavailable. An all-success example set can make abstention look like a formatting failure. The examples should demonstrate the kinds of outcomes the workflow permits, including a useful request for clarification.

Copy this context review checklist

• Can the task be stated in one sentence with a specific deliverable?
• Is the audience clear enough to choose detail and terminology?
• Are evidence passages distinguished from instructions?
• Does every relative date have an appropriate reference date and timezone?
• Are units, currencies, and identifiers preserved with their values?
• Are allowed choices supplied from the application rather than invented?
• Are defaults distinguished from facts the user supplied?
• Do examples contain fictional values that must be replaced?
• Are missing information and conflicting sources visible?
• Does the context include only material appropriate for the chosen tool?

A short context pack that answers these questions is often more inspectable than a long conversation history. That is a design judgment, not a universal model-performance claim. Test the specific pack with the tasks and model you use, and retain the actual outputs when comparing versions.

How to test a context change

Choose a fixed task and a small set of representative inputs. Define the expected facts and acceptable unknowns before generating answers. Compare one context change at a time where practical: adding a reference date, preserving a heading, or replacing free-form choices with an allowed list.

Score the dimension the change targets. If you add timezone context, inspect date resolution rather than awarding points for a friendlier tone. If you add source passages, check factual support rather than answer length. Keep formatting and usefulness as separate dimensions so an improvement in one does not hide a regression in another.

Record the full context version and the output. A later answer may differ because the source document changed, not because the prompt improved. For nondeterministic systems, repeat cases and report the observed range instead of selecting the most flattering response. This article proposes that evaluation method; it does not supply unrun model scores.

When to remove context

Remove information that is irrelevant to the decision, duplicated without purpose, or no longer current. A stale policy paragraph can conflict with its replacement. A long history of abandoned instructions can obscure the current request. A personal detail may add disclosure without helping the task.

Do not remove disagreement merely to make the prompt cleaner. If two current sources conflict, preserve that conflict and ask for an unresolved result or a comparison of the evidence. Cleaning context should remove noise, not erase uncertainty that the reader needs to understand.

For recurring workflows, assign ownership to the context pack. Someone should know which fields come from the application, which sources are refreshed, and which assumptions need review. Otherwise, a useful first version can become a stale bundle that continues to look authoritative because it is structured as JSON.

The skill is asking what the answer depends on

Context design begins with a dependency question: what information must be true and available for this answer to be justified? A date interpretation depends on time context. A policy answer depends on the relevant rule and exception. A structured record depends on units, allowed values, and a treatment of missing fields.

The operator's project and our retrieval lab make those dependencies visible in different ways. One packages state deliberately; the other shows what happens when evidence is split badly. Together they suggest a useful habit: inspect the context the assistant actually receives, then repair the missing relationship before asking for a more confident answer.

Sources, materials, and limits

• StockNote source inspection notes: context builder and extraction instructions, inspected September 15, 2026.
• Document retrieval experiment: executed comparison showing incomplete evidence in a selected fragment.
• Approval-boundary case study: the separate user-review path.
• Original context map and fictional workshop template. No controlled language-model comparison was run for this guide; code structure does not prove improved model accuracy.