The Context Architecture

Part II: The Context Architecture

The Operating Context System organizes context into a deliberate architecture. Not everything belongs at the same level or serves the same purpose. Understanding these layers is essential to building something that actually works.

These terms describe the major layers of context an organization needs to make its operating model legible and useful:

Anchor Artifacts: Minimum Viable Context

Anchor artifacts are the core objects of the operating model. They are the "minimum viable context" required to transform front-line work into something usable for planning and decision-making.

Not everything is meaningful. The purpose of an anchor artifact is precisely to filter: to establish which things are important enough to be explicitly modeled and maintained, and which things don't need to be.

Anchor artifacts are meant to function as self-driving context hubs. They don't just sit there waiting to be updated. They are designed and architected to continuously pull context from the tools where work is actually happening. An initiative automatically draws in the tickets aligned to it. A strategic pillar connects to the research relevant to it. A customer account pulls in the signals from support and sales activity.

This is where significant design attention must be paid: the definitions of anchor artifacts determine their accuracy as magnets for context. A vaguely defined initiative will attract vaguely related work. A precisely defined initiative with thoughtful definition, clear ownership, and explicit success criteria will attract the right signals with much higher fidelity. Humans must invest in making these definitions good. Better definitions make context agents more accurate, which reduces the manual work required to maintain them, which frees up time for better definitions.

Context Contracts

Anchor artifacts are also the site of what can be called a context contract: the explicit agreement between operators and front-line teams about what needs to be connected and what activities need to happen for the system to have enough relevant information for planning and decision-making.

Context contracts have a specific failure mode: they become extractive.

When a context contract feels like it's only asking for information, adding governance overhead without returning value, teams stop complying. The system accumulates stale data. Leaders lose trust in it. The whole system collapses under the weight of its own maintenance burden.

A well-designed context contract is built around reciprocity. The question isn't only "what do we need from this team?" It's also "what does this team get in return for keeping their context current?"

The path of least resistance must be the path of good context. When contributing context requires more effort than it saves, the system will never reach critical mass.

Dimensional Artifacts

Dimensional artifacts are the things you roll up to, cut by, and plan around. They provide the analytical dimension of the operating context.

Where anchor artifacts represent what the organization is doing, dimensional artifacts represent what the organization is about. Examples: Customer segments, Value streams, Strategic pillars, Products, Markets, Capabilities.

Dimensional artifacts enable the questions that matter most for strategic decision-making. "How is our investment distributed across value streams?" "What work is in-flight for customers in this segment?" "Which capabilities are under-resourced relative to our strategic bets?"

Without explicit dimensional artifacts, these questions require someone to manually pull data from multiple systems and stitch it together. With them, the answers exist continuously in the graph.

Though it may not always be the case, you can often distinguish dimensional artifacts from anchor artifacts by whether they're ephemeral or enduring. Though a 'Product' may have a lifecycle, it's an enduring artifact relative to an 'Initiative' or 'Bet'. When we ask questions about a Product, we're really asking questions about the sum activities of its parts. The context for an enduring dimensional artifact may be more akin to an evolving vision vs ephemeral artifacts might look more like scope.

Org Topology

The Operating Context System must explicitly model the organizational structure: how teams are formed, how they relate to each other, what they own, and how ownership is assigned to initiatives and outcomes.

Ron Howard, a pioneer in applied decision science, said "A decision is an irrevocable allocation of resources." Some of the most profound visibility into organizational decision making comes from understanding where the focus of resources is going and why.

Org topology is not just an org chart. It's the living model of focus and resources. Teams form, dissolve, and reorganize. Responsibilities shift. An Operating Context System that doesn't track these changes becomes unreliable quickly.

Org topology connects everything else: anchor artifacts are owned by teams, outcomes are attributed to teams, work is done by teams. Without effective team modeling, there's no connection between organizational focus and activity; and without that connection, it's difficult to really understand what explicit decisions are made and why.

Measures

Metrics need to be first-class citizens of the operating context, not an afterthought. The measures themselves are often sourced from many systems, but metrics relevant to the operating model need to come together in a unified repository for explicit and semantic relations to other artifacts. Not all measures are artifacts, just like not everything measured in a car or an aircraft is included in the dashboard or cockpit.

A metric is modeled in the operating context if it is queryable, relatable to other things in the system, has properties, and retains history on those properties. If it's an output displayed on a dashboard or pasted in a slide every month, it's not modeled.

There's a specific design principle here: operationally meaningful measures should be explicitly modeled in the graph and automated wherever possible. The goal is to plug the system into the organization's data infrastructure (BI tools, data lakes, engineering metrics, product analytics) so that the operating context has live, connected measurement rather than manually reported numbers.

Manually reported metrics are a maintenance burden that most organizations simply can't sustain. They go stale. They get cherry-picked. They're not trusted. They create the illusion of measurement without the reality of insight.

The right model: define the metrics that matter (a human design decision), establish automated connections to the sources of truth for those metrics (a technical investment), and let the system keep them current.

Metrics should also be explicitly connected to the anchor and dimensional artifacts they measure. An objective without its associated metrics is a statement of intent with no feedback loop. Connecting them closes the loop between what the organization is trying to do and whether it's working.

That said, when we get the time dimension explicitly modeled, we have more ways to connect actions to outcomes indirectly.

Time: The Underestimated Keystone

Time is the most underestimated component of an Operating Context System. Almost every organization builds time in as an afterthought, a date field here, a quarter label there, and lives with the consequences.

If time isn't modeled explicitly as a first-class dimension, the system can't effectively answer questions about what happened when. "What was in-flight in Q2?" becomes a question of inference rather than fact. "Did this initiative land in this fiscal year or the next?" depends on which system you're looking at, what timezone the date was stored in, and how "Q2" was defined by the person who entered the data.

Complex organizations typically have complex cycles across the business, finance, and delivery. When timeframes are important to the answer or activity, we can't rely on inference across server timestamps at runtime.

These problems compound catastrophically when you try to roll anything up. Aggregating delivery performance across an organization when date fields are populated inconsistently across tools is not just difficult. It's unreliable in ways that aren't obvious until someone makes a decision based on a bad number.

Time in an Operating Context System means more than dates. It means:

• Coordinated organizational cycles: fiscal quarters, planning periods, sprint cadences that define what's referenced in any given period. All reconcilable with each other.
• State over time: knowing not just what is true now but what was true when, so trend analysis and retrospectives are grounded in fact rather than memory. State nodes need to be deeply tied to time (beyond timestamps).
• Queryable time: time as a first-class dimension the system can answer against irrefutably, not a timestamp or 'Q4 2026' in plain text that someone has to reconstruct after the fact.

Resolving dates across different formats, timezones, and organizational definitions is an absolute nightmare at scale. Getting time right early is far cheaper than fixing it later.