The Context Stack

Where this came from

Every demo on this site curates context. None of them, until now, said what "context" was actually made of. This page is that answer, built by reading back through the demos, the case studies and the Thinking section for what recurs, rather than starting from a blank page and reaching for a framework.

One thing worth knowing before the seven layers: the Context Debt Map already has an informal taxonomy of its own. Its six debt categories, Missing, Contradictory, Outdated, Unowned, Difficult to retrieve, Unsafe to automate, describe how context breaks. That's a failure taxonomy. The Context Stack below is the anatomy: what context is made of when it's working. The two connect directly, and that mapping is below.

The seven layers

1. Facts

The concrete, verifiable specifics of the situation: order numbers, dates, amounts, names, thresholds. Every demo's key-facts panel is this layer made explicit, Dana Ellery's order #48213, the renewal in 45 days, the £42,450 total split across three invoices. Facts are necessary but not sufficient. The uncurated version of the support context demo has every fact correct and still offers a customer the exact replacement that's already failed twice. Facts alone don't make a decision usable.

2. History

What has already happened, specifically what has already been tried, promised, or repeated. This is the layer that is compressed first, and most subtly. The context drift demo is built entirely around this: the uncurated run's intake stage does not get anything factually wrong, but it downgrades a second, connected claim on the same line eleven months later into a previous, unrelated plumbing issue that was resolved informally. Nothing is fabricated. The exception simply did not survive the handoff. How context gets designed names this as the first of its four generalisable moves: describe the history of the situation, not only the current request.

3. Rules

The documented standard that's supposed to govern the decision, the refund policy excerpt, the liability-floor playbook, the reporting standard requiring a stated root-cause status. Rules are usually the layer that's already written down somewhere, which is exactly why people assume it's the whole of "context." It isn't. On its own it produces the partially-curated support reply: policy-correct, and still tone-deaf to a third contact.

4. Precedence

Which source wins when two of them disagree. The Context Debt Map already surfaces this without naming it: two of its twelve fragments are flagged specifically because they conflict with no stated authority between them. A model doesn't stall on a contradiction the way a person does. It picks one, confidently, with no way to tell afterward which one it picked or why. Rules can be complete and still fail if nothing states which rule governs when two disagree.

5. Exceptions

The tribal knowledge and precedent that never made it into the Rules layer at all, the thing Context Debt is actually about. A paralegal flagging a two-year-old dispute, a junior analyst flagging a fourteen-month-old case that looked the same on the surface: neither is written policy. Both are actively shaping the judgement call in front of them. This is the layer that lives in people rather than documents, and the one AI exposes rather than works around. It doesn't pause to ask. It fills the gap with something plausible and moves on.

6. Boundaries

What to explicitly leave out, and what tone or behaviour is required, stated as actions rather than adjectives. How context gets designed names both halves of this directly: an instruction to ignore an unrelated question unless the customer raises it again, and an instruction to own two missed follow-ups without naming the previous agents, rather than simply asking a model to "be warm." Boundaries are the layer most often skipped because leaving something out feels like it goes without saying. It doesn't, to a model.

7. Verdict shape

The form the judgement is required to take, stated in advance. Both the legal and financial demos build this in explicitly: an anomaly brief must state Confirmed, Probable or Unconfirmed and close with Close, Monitor or Escalate; a clause review must close with Accept, Negotiate or Escalate. This layer isn't information about the situation at all. It's a constraint on the shape of the output, and it's what stops a fluent answer from never actually committing to a call.

How the layers fail

So the Context Debt Map's categories aren't a separate taxonomy. Each one names the layer that's failing. That's what makes a failure-pattern library possible later: every failure becomes a specific, recurring way one of seven layers breaks, not another isolated anecdote.

The implications of this change

The demos haven't changed. What they show has. The jump from partial to full in the support demo comes from adding History and Boundaries, not from adding more context in general. The legal and financial demos show Verdict shape doing its job. Read this way, the demos and case studies stop being repeated examples of one general point. Each one shows a specific layer doing specific work.

(See how these seven layers hold up once they have to survive a handoff between agents, not just a single call: The Context Stack under agents.)