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

The categories in the Context Debt Map describe which specific layer is malfunctioning. They do not form a separate or parallel taxonomy. This structure allows for the future creation of a failure-pattern library. Each identified failure represents a specific and recurring method by which one of these seven layers breaks, rather than being a collection of isolated anecdotes.

The implications of this change

The demos remain the same. The change is in what they demonstrate. The transition from partial to full support in the demo is caused by the addition of History and Boundaries rather than a general increase in context. The legal and financial demos show how the Verdict shape functions in practice. When viewed this way, the seven demos and eight case studies are no longer repetitive examples of one general point. Instead, they serve as seven distinct proofs of seven specific and identifiable concepts.