Context — What Must It Have In Front Of It?

1. What must it have in front of it?

Context is what the system has in front of it, not how much it can hold.

Scope said what may be touched. Context says what the system needs to know before touching it. They are different documents and must stay different documents — that was Module 1's central warning. This module builds the one that guides.

Context — the standing material an AI-augmented workflow loads on every operational cycle so that its output fits the organization it serves.

"On every operational cycle" is the load-bearing phrase. Context supplied once, at the start of a relationship, is onboarding. Context reloaded every time is infrastructure.

Why this is hard — and it is not a tooling problem

Michael Polanyi's observation, in The Tacit Dimension (1966), was that we can know more than we can tell. Much competent practice cannot be fully articulated by the person performing it, because it was never in propositional form to begin with.

That explains a misdiagnosis you will meet often. When AI produces work that is technically correct and obviously wrong to a practitioner, the missing ingredient is usually tacit knowledge nobody wrote down because nobody knew it needed writing.

Nonaka and Takeuchi call the conversion of tacit knowledge into explicit form externalization, and treat it as the hard, valuable step. A context package is externalization made operational — not documentation for colleagues who already share your background, but articulation for a competent stranger who shares none of it and will act on whatever is written, confidently, at speed.

2. A bigger window is not more context

The most common error in the field, and it is expensive because the remedy looks like progress.

A larger context window is capacity. Context design is selection and articulation. Loading more material into a bigger window raises the quantity of information present without improving what the system actually needs — and often makes it worse, because the signal thins.

Ask what is missing, not how much fits.

3. Objectives are not directives

A strategic objective is not actionable. Hand one to a capable system and you get confident work aimed at the wrong target.

The translation is the operator's work — it is not something to delegate to the system that will execute it.

This is where the Four Questions from Module 1 re-enter: intended outcome, constraints, what success looks like, how results are validated. A directive that cannot answer all four is an objective wearing a directive's clothes.

4. Context as loaded infrastructure

These examples come from an operation where every worker boots with no memory of any previous session. Whatever is not in the context package does not exist. That makes the layer unusually visible.

The standing context file

One file is read at the start of every session by every worker. It carries conventions, standing rulings, escalation tiers, and a tool inventory. Its first substantive section is titled with the rule that has caused the most rework:

Verify against the live document. Never against this conversation, and never against memory.

What follows is four dated instances where that rule was broken, and what each one cost.

Note the form. The rule is stated, then evidenced. A rule carrying its own failure history is followed more reliably than one asserted alone — the reader can see the cost rather than take it on faith.

Prior decisions, recorded so they stay decided

A separate file holds settled rulings. One is annotated:

"Raised in error three times — do not raise it again."

That annotation does precise work. It does not merely record the decision; it records that the decision keeps being re-opened — which tells a reader the question is more tempting than it is open.

Context that failed by omission

A standard for rebuilt work said only "match the depth of the baseline." Seven items were produced against it. All seven were rejected.

The context was present and insufficient. The fix was not more context — it was converting a tacit standard into a checkable one, a twenty-four row component list. Externalization, done under pressure, after the failure.

Context has a shelf life

The same file carrying those rules also carried a tool inventory stale by more than a dozen entries — capabilities that existed, were not listed, and so were believed unavailable. Workers built elaborate workarounds for things that already worked.

A context package is not written once. It decays, silently, exactly like any other record. That is the handoff to Module 4.

5. What good context looks like

A test, rather than a template:

Could a competent stranger load this and act correctly, without asking you anything?

If the honest answer is "they would need to check with me on a few things" — those few things are the context package's real content. Everything else is already obvious enough not to need writing.

Three properties distinguish a working package from a document nobody reads:

• Reloaded, not remembered. Present at the start of every cycle, not handed over once.
• Evidenced, not asserted. Rules that carry their reason are followed; rules that arrive as commands are worked around.
• Dated. Anything that can go stale says when it was last checked.

A caution before you build one

The examples in this module come from an operation where context must be total, because the workers have no memory at all. A human team is never in that position. Colleagues carry undocumented shared understanding that does real work, and writing all of it down would be waste.

So the question worth holding as you build: which parts of your package would be unnecessary for a human colleague — and what does that tell you about where the boundary actually sits?

The test: could a competent stranger load this and act correctly, without asking you anything?