Context Construction
Our context-construction layer assembles the evidence, state, instructions, and constraints required for a specific inference task.
Selection, not volume
The objective is not to maximize token count. It is to provide the smallest sufficiently complete context for the decision being made.
A large context window does not remove the need for selection. Irrelevant or conflicting material can reduce model performance, increase latency and cost, and make source attribution harder.
Context components
A task-specific context can combine:
- Retrieved documents
- Structured facts
- Canonical entity state
- Historical state
- Relationships
- Source authority
- Time windows
- Prior decisions
- Tool outputs
- Permissions
- Task instructions
These inputs do not necessarily enter the model in the same representation. Structured values can remain structured. Evidence can retain source references. Permissions and execution constraints can remain outside the natural-language prompt and be enforced deterministically.
- Task
- Entity + time resolution
- Retrieval / structured query
- Source authority + permissions
- Candidate evidence
- Selection / compression
- Model context
Selection before compression
We prefer to remove irrelevant information before asking a model to summarize it. Compression can be useful when the evidence set is large, but summarization introduces another transformation layer and can discard detail. Where exact language, amounts, dates, or commitments matter, the original evidence may need to remain available alongside any compressed representation.
Context construction also needs to preserve contradictions. Two sources that disagree should not be blended into a single synthetic fact merely to produce a cleaner prompt.
Runtime implications
Context size affects more than inference cost. It can affect latency, attention allocation, retrieval quality, source traceability, and the probability that a model follows the wrong piece of evidence. For that reason, context construction is evaluated as part of the task pipeline rather than treated as a formatting step.
Our goal is task-specific evidence assembly: the right records, from the right period, for the right entities, under the right permissions, with enough provenance to verify the result.
Failure modes
Context can fail even when retrieval succeeds. A correct record can be attached to the wrong entity, evidence from the wrong time period can enter the prompt, or a low-authority record can crowd out the system of record. Long context can also create contradictory instructions or duplicate evidence that changes model behavior without adding new information.
For important workloads, we therefore treat context assembly as an evaluable component. Test cases can verify not only whether the final answer is correct, but whether the expected evidence was selected and whether prohibited or irrelevant information was excluded.
What the model sees constrains what the model can know and how reliably it can reason.