Context — What Must It Have In Front Of It?

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.