An AI analyst cannot infer your business’s definition of revenue, approved join path, regional access rules, or decision format from a clever prompt. That information has to arrive before the question is answered.
Context engineering is the design of that input packet. It gives the system the minimum governed business, data, access, and decision context needed for one analytical task.
The point is not to stuff every document into a large context window. It is to select the right facts, with owners and versions, so the analyst can interpret the question and show its work.
The prompt is only the request
A user might ask, “Why did pipeline fall last month?” The prompt states an intent, but it leaves material choices unresolved:
- Which pipeline metric?
- Created, open, qualified, or weighted pipeline?
- Which month’s calendar and timezone?
- Compared with the prior month, plan, or last year?
- Which business units and currencies?
- What data may this user see?
- Which downstream decision will the answer support?
The analyst needs a governed way to resolve those questions. Some can come from a metric catalog or semantic model. Some depend on the user’s role. Some require a clarifying question.
Context engineering decides which information is retrieved automatically, which must be asked, and which requests should stop.
Build a four-part packet
1. Metric contract
The metric contract defines the business meaning:
- Name and plain-language definition
- Formula and aggregation
- Inclusions and exclusions
- Grain and supported dimensions
- Time and currency rules
- Effective date and version
- Owner and change process
A metric label without these fields invites plausible substitution. “Bookings” may have several legitimate definitions. The packet must select the one that applies or tell the analyst to ask.
2. Schema map
The schema map tells the analyst how that meaning reaches data:
- Approved tables, views, and fields
- Primary keys and relationships
- Valid join paths
- Grain of each source
- Data types and SQL dialect
- Known null, duplicate, or late-arrival behavior
- Freshness and last successful load
- Representative values only where safe and useful
Google Cloud’s text-to-SQL guidance identifies schema, data, business concepts, user intent, and SQL dialect as central context problems. It describes retrieval of relevant datasets, columns, examples, annotations, and business rules rather than passing an entire estate indiscriminately. Google Cloud’s engineering article supports this selective approach.
3. Role and access envelope
The access envelope states who is asking and what that identity may use:
- User and role
- Allowed business units, rows, and fields
- Restricted metrics or source systems
- Purpose or session constraints
- Whether derived data can reveal protected values
- Required approval or refusal behavior
Access is part of analytical meaning. If the user asks for global revenue but is restricted to one region, the system should not silently present the regional number as global.
4. Decision brief
The decision brief tells the analyst what useful output looks like:
- Decision to be made
- Audience
- Comparison baseline
- Required cuts or segments
- Materiality threshold
- Output format
- Evidence and trace requirements
- Deadline or freshness need
- Owner for follow-up
This prevents the system from returning ten pages of exploration when the user needs a two-line exception summary, or a single number when the decision requires a breakdown.
Keep authoritative context separate from hints
Not every retrieved item has equal status. Label the packet so the analyst can distinguish:
| Context class | Example | How it should be used |
|---|---|---|
| Governing rule | Approved metric contract | Must apply unless the request is clarified or refused |
| Data fact | Schema and freshness metadata | Constrains query construction and interpretation |
| Worked example | Prior approved query | Helps, but does not override current rules |
| User preference | Preferred chart or summary length | Shapes presentation, not analytical truth |
| Unverified note | Analyst comment or old document | May prompt investigation; cannot settle the answer |
Without status, a convenient example can override a current metric definition or an old note can become a business rule.
Retrieve context by need, not proximity
Large context windows do not remove selection work. Irrelevant tables, stale definitions, and near-duplicate examples can increase confusion.
Use the request to retrieve candidate context, then filter it through governance:
- Identify likely metric and intent.
- Retrieve the current metric contract.
- Select only approved schema paths for that metric.
- Apply the user’s access envelope.
- Add examples matched to the current dialect and business rule.
- Ask for any decision-critical information still missing.
Microsoft’s current AI-ready analytics learning path connects gold-layer data, semantic models, metadata, linguistic context, and ontologies. It is product-specific training, but it shows why business vocabulary and relationships need explicit representation. Microsoft’s learning path is a useful reference.
Version the packet as a first-class artifact
An answer should retain the versions of the metric, schema map, access policy, and decision brief it used. Otherwise, a later reviewer may compare the result with rules that did not exist when it ran.
A compact packet header can include:
packet_id
question_id
metric_contract_version
schema_map_version
access_policy_version
data_freshness_at
decision_brief_version
assembled_atThe trace should also record which portions were retrieved, which were supplied by the user, and which remained unresolved.
Versioning is not paperwork for its own sake. It lets the team reproduce an answer, explain a change, and rerun affected questions after a definition or schema update.
Test the packet before testing the prose
Evaluation should ask whether the packet caused the system to:
- Select the approved metric
- Use valid source and join paths
- Respect the user’s access
- Ask for missing scope
- Detect stale or unavailable data
- Produce the requested decision format
- Cite the relevant sources and definitions
- Preserve enough trace to review the result
Vary one context element at a time. Change the user’s role, metric version, data freshness, or comparison period and confirm that behavior changes appropriately. This is how the team learns whether the context is actually controlling the analysis.
Treat the packet as a design boundary
Context engineering happens before answer generation. It does not diagnose a disputed number after the fact, and it does not prove that an analytics platform is accurate enough for every use case. Those are separate jobs.
Brainiac can help data and business teams define the packet, assign its owners, and test how it governs one recurring decision. The practical outcome is a smaller, more explicit input contract that gives the AI analyst less room to invent business meaning.