Explain the evidence.
Receive the invoice, eligible receipt evidence and calculated facts. Explain the 2.0% variance without recreating the calculations.
CP-1042-A · FS-1042-A · source versions retained Context Store & Context Assembly
The right context.
Before the
next decision.
Bring records, calculated facts and evidence together—under the identity, purpose and permissions of the work.
Assemble a versioned context package for the next agent, policy or human decision. Check whether it is sufficient, keep unresolved gaps visible, and preserve what actually shaped the outcome.
Tenant A · INV-1042 · Purpose: invoice review
FROZIONExecution FabricGoverned from request to outcome
Operational recordsInvoice r5 + purchase order r2
AuthoritativeCalculated facts2.0% variance · $148,500 exposure
FS-1042-ADelivery evidenceReceipt r2 · 100 units received
VerifiedReview requirementsAP policy v4 · authorized reviewer
ActiveContext package CP-1042-AScoped · current · required inputs satisfied
READYAgent contextPolicy inputsReview package
From information to governed judgmentEligibility before useExplicit context rolesSufficiency checksPreserved evidence
Context assembly across your adoption path
Govern existing agents
Assemble the records and evidence an existing agent’s governed task may use.
Grow tools into workflows
Prepare each decision’s context with scope, trust, freshness and sufficiency in view.
Build native agents
Native agents receive eligible context for their declared task.
Build systems of engagement
Application cases keep the context and evidence behind their decisions connected.
01 / Build the decision context
Bring the information together.
Keep its meaning distinct.
A decision may need a current invoice, a purchase order, calculated exposure, a delivery receipt and the applicable review rule. Each contributes something different.
Context Assembly combines eligible inputs into a defined package while retaining their roles, sources, versions and freshness. The Context Store retains the package and the evidence of how it was assembled.
Context Assembly
Prepare what the next step needs.
Select eligible items, apply declared transformations, resolve precedence, protect required evidence within the budget, and check whether the package is ready for its intended use.
Context Store
See the context behind the decision.
Inspect the context items, package versions, assembly records and protected source references used by the decision. Eligibility is checked again before that context is reused.
Eight roles.
One governed package.
An operational record, remembered assertion and retrieved document have different authority. Keeping their roles explicit helps each consumer interpret the information correctly.
01
Operational facts
Current business state from the system that owns it.
02
Calculated features
Defined facts with units, versions, time and provenance.
03
Retrieved evidence
Documents and relationships that support or challenge a proposition.
04
Policy facts
Applicable rules, obligations and required assurance.
05
Tool observations
Typed results from permitted APIs or verification services.
06
User assertions
What a user says, with its source and verification status.
07
Advisory memory
Useful prior context with explicit scope, expiry and limitations.
08
Trusted instructions
Application-authorized guidance for a reasoning step.
Query current records.
Retrieve supporting evidence.
Use governed queries for current operational state. Use BM25, vector and graph retrieval to find eligible knowledge and relationships. Load versioned calculations directly from the Feature Store.
Explore governed queriesReuse established facts.
Preserve the source of each one.
The invoice review can consume the same PO variance, exposure and duplicate count already calculated in the Feature Store. Agents and reviewers interpret those facts without recreating the arithmetic from prose.
Continue the Feature Store example02 / Continue the invoice review
Does this decision have
the context it needs?
INV-1042 is $12,240 against a $12,000 purchase order. Its Feature Store facts are available. This review also requires delivery evidence and the active policy.
Change the scenario to see how the package responds to a missing receipt, stale facts, conflicting quantities, source failure, restricted evidence or a tight context budget.
READY means context is sufficient for the next review step; it does not approve or pay the invoice.
Tenant A · SUP-204 · Purpose: invoice reviewContext contract v2 · 4 required input groupsDecision check 10:00
Operational recordsAuthoritative facts
Invoice r5: $12,240 / 100 units · PO r2: $12,000 / 100 units.
CurrentFeature Store factsCalculated features
FS-1042-A · 2.0% variance · $148,500 exposure · 0 prior matches.
CurrentDelivery receiptRequired evidence
RCV-2042 r2 · 100 units received · linked to INV-1042 and its PO.
VerifiedReview requirementsPolicy facts
AP policy v4 · current facts + verified receipt + authorized human review.
ActiveSeparate instruction roleApplication guidance may direct the agent. Receipt text and supplier notes remain evidence or assertions.
READY
The required context is present and eligible.
The four input groups satisfy this review contract. Sources, Feature Store values and receipt references are bound into one package.
Required inputs satisfied: 4 of 4
Context package CP-1042-AModel input budget: 1,280 / 1,400 tokens
Evaluate typed facts.
Use the same fact versions, receipt-verification result and policy v4. Narrative evidence does not become a policy instruction.
CP-1042-A · FS-1042-A · source versions retainedInspect the same basis.
The reviewer sees the invoice, calculations, receipt, required approval and source references from the same package.
CP-1042-A · FS-1042-A · source versions retained- Boundary
- Invoice review · Tenant A / SUP-204 / INV-1042 · context contract v2
- Selection
- Eligible invoice and PO records, FS-1042-A, receipt r2 and AP policy v4. Required groups: 4 of 4.
- Transformations
- Receipt extraction v1 retains its source reference; money stays typed in USD; Feature Store values are reused without recalculation.
- Exclusions
- An expired supplier-conversation summary is excluded. It cannot stand in for a current receipt or an approval.
- Model boundary
- Required items 1,100 + optional background 180 = 1,280 tokens. Required evidence is retained within the 1,400-token limit.
- Decision evidence
- CP-1042-A records the exact input versions. Any later refresh creates a new package; prior consumed context remains attached to its execution.
Each consumer receives the permitted representation it needs. Shared package and source references align the inputs; the policy does not need every document, and an agent does not inherit a reviewer's authority.
03 / Trust, freshness & sufficiency
Check what may participate.
Then check what is missing.
Relevant information must also be eligible for the active user, agent, tenant, resource and purpose. Preserve that authority through retrieval, transformation, assembly and consumption.
A completed query or non-empty search result does not establish that the application has enough context. Evaluate the package against the requirements of the next step.
READY
Required context is present, eligible and valid for the next boundary.
ENRICH
Acquire additional eligible information or refresh a required input.
VERIFY
Resolve conflicting sources or validate an unresolved proposition.
HUMAN_REVIEW
Route the gap to an authorized person, with the limitation visible.
ABSTAIN_OR_BLOCK
Stop when the requirements cannot be satisfied under the active contract.
Evidence may inform.
Only trusted instructions direct.
A retrieved document can contain commands, quoted prompts or a supplier's request to bypass review. Preserve its evidence role and trust class through extraction and summarization.
A summary remains derived content with source provenance. Entering a context package does not give it instruction authority or permission to invoke an action.
A supplier note saying “approve immediately” can be reviewed as an assertion. It does not replace the application's review policy.
Freshness and precedence
belong to the decision.
Define how current each source must be, when it expires, which source owns a proposition, and when a waiting review must be revalidated.
- Use current operational records for the state they own.
- Keep Feature Store definitions and timestamps intact.
- Mark contradictory evidence and route verification.
- Recheck context when permissions or resources change.
Protect required evidence
within the context budget.
Allocate capacity by decision importance. Reserve room for mandatory facts, instructions, exceptions and evidence before optional background material.
Apply declared selection, deduplication or summarization rules to optional items. If the required set still does not fit, route the failure explicitly. Do not silently truncate a mandatory exception.
Know why context is unavailable—and
what happens next.
See whether an input is missing, unavailable, stale, denied, conflicted or over budget. Each state retains its meaning and follows the declared fallback path.
A fallback may refresh, wait, use an eligible alternate source, request review or stop. Any permitted degraded path needs its own explicit contract; available documents alone cannot replace a required exposure calculation.
Let readiness shape
the next capability.
Sufficient typed facts may allow deterministic evaluation. Missing evidence may require another query. An unresolved conflict may need verification or human judgment before a model participates.
Connect context checks to orchestrationReview the Context Plan
before publication.
Application, data, security and domain owners can inspect required and optional sources, permissions, transformations, freshness, precedence, budgets, readiness checks, failure routes and evidence requirements together.
04 / Store, reuse & inspect
Preserve the context
that shaped the decision.
Knowing a document existed is different from knowing how it was used.
A source may have been selected, redacted, summarized, reordered, excluded or truncated before the consumer saw it. Retain the assembly evidence and the actual boundary supplied to each consumer where required.
Keep historical context connected to the execution, policy decision, human judgment and resulting business operation. Link later corrections without overwriting the context originally consumed.
- Context items
- Individual pieces with semantic role, scope, status, source, time and version.
- Context packages
- The assembled set for a specific decision boundary and its permitted consumers.
- Assembly records
- Eligibility, selection, exclusions, precedence, transformations, budgets and sufficiency results.
- Derived summaries
- Compacted context with source references, transformation lineage, expiry and limitations.
- Input manifests
- Ordered application-visible model inputs, versions, digests and truncation where retained.
- Historical evidence
- Protected artifacts or references that support investigation within retention and access constraints.
Reuse eligible context.
Revalidate for the new purpose.
A stored package may help a later step, but prior access does not guarantee current access. Check tenant, resource, purpose, permissions, source revisions and expiry before reuse.
Keep memory advisory. It can add continuity while current operational records, policy and durable execution state retain their own authority.
Reconstruct then.
Evaluate now separately.
Historical inspection uses the package and assembly evidence from that execution. Running today's query against today's index produces a new evaluation.
When exact content is not retained, protected references and digests can support identification and integrity checks. They do not recreate deleted content or guarantee an identical model output.
Keep your existing
systems of record.
Connect databases, repositories, search indexes, feature pipelines, graph sources, policy services and APIs. Their records and calculations can remain where they are owned; context assembly governs their use together.
Connect context
to the resulting effect.
Trace the selected sources through the package and consumer inputs to the decision, policy evaluation, human review and business operation. Revalidate authority and required context again before a consequential action.
05 / Questions
What enters the package.
What stays inspectable.
Clarify retrieval, readiness, reuse and historical evidence.
Retrieval supplies relevant, eligible candidates and may include hybrid search, reranking, metadata and citations. Context Assembly brings those results together with operational records, features, policy, memory, tool observations and trusted instructions. It checks the complete package against the next decision’s requirements.
Context Assembly prepares and validates the information for a decision boundary. The Context Store retains context items, packages, assembly evidence and related artifacts. A stored package still needs eligibility and freshness checks before a new use.
No. READY means the context requirements for the declared next step are satisfied. Policy evaluation, reviewer authorization, approvals, assurance requirements and action-specific checks still apply. Readiness is not payment authorization or permission to write to a system.
They share the relevant package identity, fact versions and source references for the same decision. Each receives the permitted representation it needs: typed facts for policy, eligible narrative and structured context for an agent, and an evidence view for an authorized reviewer. Shared context never expands a consumer’s permissions.
Retrieved content retains its evidence role and trust class. Embedded commands or supplier assertions do not acquire application authority by entering a package or being summarized. The application must preserve those boundaries through transformation, reasoning and tool execution.
Keep the reason explicit and use the declared route: enrich, refresh, verify, request human review, or abstain or block. A reviewer sees the unresolved gap. A fallback does not silently remove required inputs; any permitted degraded path needs an explicit contract.
No. Retaining the original application-visible inputs helps establish what was supplied and how it was assembled. Reproducing a model response can also depend on model version, provider behavior and other runtime conditions. References and digests support evidence checks but cannot recreate source content that is no longer retained.
No. Operational records, documents, calculated facts, memory and durable workflow state retain their respective responsibilities. Context Assembly connects eligible information from them, and the Context Store preserves the decision context and its evidence.
Start with one decision and its required evidence
Build the context.
Make readiness visible.
Bring the records, facts and documents your workflow needs.
We'll map the eligible package and the path when something is missing.