Context Engineering for Analysts: The Project Pack That Makes AI Accurate

Context engineering is deciding what a model sees before it answers. For analysts that means one reusable project pack, built once per programme: the glossary, the interface contracts, the data dictionary, the business rules register, the decision log, and two worked examples. A mediocre prompt over the right pack beats a brilliant prompt over nothing, every time.

In part one the grounding was whatever you happened to paste. That works for an email. It falls apart the moment the task is real, because the real tasks need the contract and the data dictionary and the rule somebody agreed in March, and you are not going to hunt those down forty times a week.

So you build the pack once. This is part two of The AI Analyst, and it is the least glamorous article in the series and the one with the highest return. Everything after it, reading a codebase, connecting Jira and Confluence, generating a test plan, depends on the model having a stable, correct picture of your programme. Without that, every later step just produces wrong answers faster and through more channels.

Why does context beat prompting?

Because a model cannot reason about facts it has never seen, and it will not tell you it has not seen them. It will produce the most plausible substitute.

Ask an ungrounded model what the rejection reason code is for a closed beneficiary account and it will say AC04. That happens to be right in ISO 20022, because that is public standard knowledge. Now ask it what your bank’s internal mapping turns AC04 into on the customer statement, and it will invent something entirely reasonable and entirely wrong, in exactly the same confident tone. You cannot tell the two answers apart by reading them. Only the grounding tells you which is which.

This is why prompt collections disappoint. The wording is not what separates a useful answer from a fabricated one. What separates them is whether the fact was in the window. Once you internalise that, your effort moves from phrasing to curation, which is analyst work you already know how to do. A context pack is a data dictionary, a glossary, and a rules register: the same artifacts that make a programme legible to a new joiner make it legible to a model.

What goes in a project context pack?

Six artifacts. Keep them in one folder, in Markdown or plain text, and keep them short enough that a person would actually read them.

1. The glossary. Every domain term, one line each, plus the ones your organization uses inconsistently. The inconsistent ones matter most: if “settlement date” means the value date to operations and the posting date to finance, write both and say who means which. This is the artifact that stops the model producing text that is technically fine and organizationally meaningless. If you do not have one, the data dictionary article covers how to build the adjacent artifact properly.

2. The interface contracts. Your OpenAPI files, your ISO 20022 usage guidelines, your Kafka or Avro event schemas, your file layouts. These are the highest-value items in the pack because they are exact, machine-written, and unambiguous, which is precisely what a model is good at using. See reading an API contract and reading an ISO 20022 usage guideline for what to extract if the full files are too large.

3. The data dictionary. Field name, type, length, allowed values, nullability, and the system of record. Exact strings, not descriptions. paymentStatus with an enumeration of PENDING, SETTLED, RETURNED, REJECTED is worth more to a model than three paragraphs explaining payment lifecycle, because it can copy the strings instead of guessing them.

4. The business rules register. Numbered, dated, one rule per line, written as a condition and a consequence. “BR-014 (2026-03-02): if the debtor account currency differs from the instructed currency, the payment is routed to FX pricing before validation.” Numbering matters because it gives you traceability: the model can cite BR-014 and you can check BR-014.

5. The decision log. What was decided, on what date, by whom, and the reason. This is the artifact nobody keeps and everybody needs. It is what lets the model answer “why does the cut-off exist” instead of inventing a rationale, and it is what saves you in month nine when a new programme manager asks why.

6. Two worked examples of your output. One straightforward, one edge case. If you want test cases in your house format, paste two real ones. Examples transfer format far more reliably than any description of format, and the edge case teaches the model what you do with awkward input, which is where generated artifacts usually go wrong.

Total size: usually 15 to 40 pages. That fits comfortably in a modern long-context window and in most project knowledge features.

How do you assemble it without spending a week?

You already have most of it, scattered. The work is collection and dating, not authoring.

A practical order that gets you to something usable in an afternoon:

1. Export the contracts and schemas. They exist already; put copies in the folder. Zero authoring.
2. Write the glossary from the last three specifications you produced. Pull every term you had to explain in a meeting. Forty lines is plenty to start.
3. Extract the data dictionary from the actual database or the actual schema, not from a document. SELECT column_name, data_type, is_nullable FROM information_schema.columns WHERE table_name = 'payment' gives you the truth in one query. The document lies; the schema does not. If SQL is not yet in your toolkit, SQL for analysts is the fastest route.
4. Mine the rules register out of your existing specifications. Every “the system shall” sentence is a candidate. Number them, date them, and put the source document in brackets.
5. Start the decision log from today forward, and backfill only the decisions you can evidence. A decision log with six real entries beats one with forty reconstructed guesses.
6. Pick two examples you are proud of.

Date everything. Put the as-of date at the top of each file. This single habit prevents the most common late-stage failure, which is the model citing a rule that changed two releases ago in an authoritative tone.

How do you actually feed the pack to a model?

Three mechanisms, in increasing order of effort. Use the lowest one that works.

Paste, with headers. For a single task, paste the two or three relevant artifacts with clear headers and dates. Crude, effective, and it keeps you honest about what the model actually saw.

Project knowledge. Most assistants now have a persistent per-project file store: Claude Projects, ChatGPT project files, Copilot with a SharePoint or OneDrive scope, Gemini with a Drive folder. Upload the pack once, and every conversation in that project starts grounded. This is where most analysts should live. It costs an afternoon and pays back weekly.

Retrieval (RAG). Retrieval-augmented generation chunks your documents, embeds them, and pulls the pieces that look relevant to each question. It is the right answer above roughly fifty documents, or when the corpus changes faster than you can curate it.

Be honest about the tradeoff, because retrieval is over-recommended. Retrieval gives the model three or five chunks that scored well on similarity. A curated pack gives it everything. For analyst work, where the answer often depends on a rule in one document interacting with a field definition in another, seeing everything wins. I have watched a retrieval setup confidently answer from a superseded specification because that document used the question’s vocabulary more closely than the current one did. The curated pack does not have that failure mode, because you removed the superseded document yourself.

Start with project knowledge. Move to retrieval when you can name the specific documents you keep failing to find.

Where does the instruction go?

After the documents. This is the structural detail most people get wrong.

You are a senior technical business analyst on a payments programme.

=== CONTEXT PACK (as of 2026-09-14) ===
--- GLOSSARY ---
[...]
--- DATA DICTIONARY: payment table ---
[...]
--- BUSINESS RULES (BR-001 to BR-042) ---
[...]
--- EXAMPLE OUTPUT: test case, simple ---
[...]
--- EXAMPLE OUTPUT: test case, edge case ---
[...]
=== END CONTEXT PACK ===

TASK
Derive the negative test cases for the partial refund endpoint.

RULES
- Use only field names and enumerated values from the data dictionary.
- Cite the BR number for every rule-based case.
- If a case depends on something not in the pack, list it under
  UNGROUNDED and do not invent the detail.
- Match the format of the two examples exactly.

Two things are doing work here. The task sits at the end, where attention is most reliable and where it is not diluted by thirty pages of contract. And the UNGROUNDED section forces the model to separate what it derived from your material from what it would have to guess, which turns an unverifiable wall of output into two lists: one you spot-check, one you investigate.

Add one more standing rule to the pack itself: if two sources conflict, name both and say which is more recent. Programmes are full of contradictions, and a model that silently picks one is more dangerous than one that surfaces the clash. Surfacing contradictions is genuinely useful analyst output.

The full treatment of how retrieval, the Model Context Protocol, and agents fit together, including how to evaluate them as a delivery analyst, is in AI at Work: MCP, RAG, and AI Agents.

How do you keep the pack from rotting?

Context rot is the failure mode that catches teams in month four. The pack was accurate in June, three rules changed in July, and now every generated artifact is subtly wrong in a way nobody notices because the output still looks right.

Four habits stop it:

• Refresh at every release. Put it on the release checklist next to the runbook update. Ten minutes.
• Supersede, never delete. When BR-014 changes, keep it and mark it SUPERSEDED 2026-07-11, replaced by BR-039. Now the model can tell you the rule changed. Deleting it just makes the old behavior invisible.
• One owner. The pack belongs to one analyst. Shared ownership means no ownership and a folder full of three competing glossaries.
• Version it in git. Plain text files in a repository give you history, diffs, and review. Git for analysts covers the twelve commands you need, and it is the same skill you will use in part four when the model starts reading your codebase.

What does a good pack change, measurably?

Three things move, and they are worth tracking because they are the argument you will need when someone asks whether any of this is real.

Signal	Without a pack	With a pack
Invented field names in a generated draft	Several per page	Near zero, and flagged as UNGROUNDED
Time from task to usable draft	Ten minutes of hunting for documents, then a prompt	Straight to the prompt
Review comments on issued specs	Unchanged or worse, because errors arrive faster	Falls, because vocabulary is consistent
Onboarding a new analyst	Weeks of tribal knowledge	They read the pack

That last row is the one that surprises people. The pack is a genuinely good onboarding document, because the things a model needs to be correct about your programme are exactly the things a new joiner needs. I have started handing the pack to new team members before their first meeting and it has cut a fortnight of orientation to about two days. The AI use case paid for itself, and then the human use case paid for it again.

The takeaway

Context engineering is the analyst’s real AI skill. Build one project pack per programme: glossary, interface contracts, data dictionary, numbered and dated business rules, decision log, and two worked examples. Load it into project knowledge, put your instruction after the documents, force an UNGROUNDED section, and refresh it every release.

Do that and every later part of this series works. Skip it and you will spend the next year getting fluent, confident, wrong answers with better tooling around them.

Next: part three, the guardrails, which is what you read before any of this touches real data or a real system. Then part four, where the pack stops being documents and starts being the codebase itself. The whole path is on The AI Analyst.

If you want the artifacts themselves rather than building each one from a blank page, Real-World BA Deliverables gives you twenty templates that make perfectly good pack contents on day one.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Business Analysis, Artificial Intelligence, Requirements, Documentation, Data