The Context Gap - Part 1

Here's a metaphor that crystallizes what's broken in enterprise systems:

Every system has a state clock - what's true right now - and an event clock - what happened, in what order, with what reasoning.

We've built trillion-dollar infrastructure for the state clock. The event clock barely exists.

The examples are everywhere:

We've built elaborate systems for recording what's true now. Almost nothing for why it became true.

The event clock - the reasoning connecting observations to actions - was never treated as data. It lived in heads, chat threads, meetings that weren't recorded. When a VP approves a 20% discount despite a 10% policy cap, the CRM records "20% discount." The context - customer escalation history, churn risk signals, the prior exception that set precedent, the approval chain - all of it vanishes.

This isn't a data problem. It's a decision trace problem. And according to Foundation Capital, solving it represents a trillion-dollar opportunity.

Building the event clock requires understanding that organizational knowledge exists in three distinct layers:

Content is the state clock - immutable source documents, the evidence trail. Emails, meeting transcripts, contracts, chat messages. Content is never edited or merged. It's the canonical record of what was captured.

Entities are what content mentions - people, organizations, places, products, events. This is where identity resolution happens. "Sarah Chen" in an email, "S. Chen" in a meeting transcript, and "@sarah" in the chat application are the same person. Without entity resolution, you can't reason about actors.

Facts are what content asserts - temporal claims about the world. This is the event clock. Not just "the patient takes Drug A" but "the patient started Drug A on March 15, 2024" and "the patient stopped Drug A on August 3, 2024 when insurance coverage ended."

Each layer is progressively more structured. Content is raw evidence. Entities add identity. Facts add temporality and assertion.

Most enterprises have decent content storage. Entity resolution is partial at best. Facts as queryable data? Almost non-existent.

To build the event clock - to capture decision traces - enterprises need to solve four foundational problems.

The core issue: The same entity appears fragmented across systems, and nobody connects the dots.

In business terms: Is "Sarah Chen" in the email thread the same Sarah from the chat application channel and the meeting transcript? When a renewal lead synthesizes customer context, they're mentally resolving identities across five systems. That synthesis happens in their head and disappears.

In security terms: This problem is acute and dangerous.

Consider a single employee's digital footprint:

Same person? Your SIEM doesn't know. Your IAM platform sees six different entities. Your EDR has four separate profiles.

When John leaves:

Three months later, someone asks: "Show me everything John Smith had access to."

You can't answer. Without entity resolution, you're protecting fragments instead of understanding complete identities. And every unresolved identity is a potential persistence mechanism for an attacker - or an audit finding waiting to happen.

The core issue: Assets and entities exist without clear ownership, dependencies, or business context.

In business terms: When a support lead decides to escalate a customer issue, they synthesize information across systems - customer tier from CRM, SLA terms from billing, recent outages from the operations dashboard, churn risk signals from a Slack thread. That synthesis exists momentarily in their head. Then it's gone.

In security terms: This is the foundational principle - "you can't protect what you don't know" - but it goes deeper than simple inventory.

What your systems typically record:

What you actually need to make risk decisions:

Without relationship context, your asset inventory becomes ceremonial security - performing the ritual of knowing your assets without actually being able to answer fundamental risk questions.

The orphaned service account is the perfect illustration. Created in 2019 by a developer who left in 2020. Inherited by an operations team who never asked questions. Still running with domain admin privileges. Powers some critical business process. Nobody knows exactly what it does. Everybody's afraid to touch it.

The decision trace that would explain what this account does and why it needs those privileges? It never existed.

The core issue: Every exception to policy is a decision that should leave a trace. Almost none of them do.

In business terms: When that VP approved the discount exception, there was reasoning - customer history, competitive pressure, revenue at risk, prior precedent. None of that reasoning was captured as data. Six months later, when a similar situation arises, there's no way to query "how did we handle this before?"

In security terms: Exception management is where decision traces matter most - and where they're most consistently absent.

Vulnerability management example:

A scanner finds 500 systems with a critical CVE. Three weeks later, 200 remain unpatched. The CMDB shows "not patched."

What the board asks: "Why do we still have 200 critical vulnerabilities?"

What you can't answer:

Every vulnerability exception is a decision trace that disappears. You're left reconstructing the "why" during audits - hunting through email threads and chat conversations, asking people who may have left the company.

The exception spiral:

Exceptions don't just create point-in-time risk. They compound: Exception → change configuration → weaken existing control → implement new control → increase complexity.

Without decision traces, you can't even see this pattern emerging.

Access management example:

Someone requests elevated access. The approver types "approve" - or worse, "business need" - and clicks submit. The context that justified the decision is gone.

PAM systems generate queues of privileged access requests. Approvers click through 50 requests per day because there's no context about why access is needed, no way to verify legitimacy, no visibility into precedent. Clicking "approve" is faster than investigating.

What gets recorded: "Approved by Jane Smith at 14:32"

What should exist: Why does this person need production database access right now? Is this related to an active incident? Is there precedent for this access? What's the blast radius if misused?

The decision happens in the approver's head based on limited context and time pressure. Then it evaporates. Approval becomes ceremonial. The control exists to satisfy compliance, not to reduce risk.

The core issue: Systems show current state, but decisions require understanding how things evolved.

This is the event clock problem at its core. As Kirk Marple frames it: "The config file says timeout=30s. It used to say timeout=5s. Someone tripled it. Why? The git blame shows who. The reasoning is gone."

In security terms: Security is fundamentally about change - configuration drift, privilege escalation, unusual behavior. But most tools show only snapshots.

What you need to know:

What your tools show:

The forensic cost:

When investigating an incident, you need to reconstruct: Who made configuration changes and why? What policy exceptions were active at the time? Who approved those exceptions? What was the organizational state when decisions were made?

Without temporal decision traces, this reconstruction takes weeks or months. With them, investigation time goes from weeks to hours because you're not reconstructing context - you're querying it.

Here's the key insight from those building this infrastructure: facts need to be first-class entities, not just derived metadata.

A properly structured fact has:

This structure captures temporal validity natively. When you query "What's Paula's current employer?", you don't search for recent documents and hope the LLM figures it out. You query facts where invalidAt is null.

When you query "Where did Paula work in 2022?", you filter facts where validAt <= 2022 and invalidAt > 2022.

The event clock becomes queryable data, not reconstructed reasoning.

For security, this transforms fundamental questions:

Three shifts have converged to make this urgent:

AI agents are exposing the gap. When you tell an agent to "calculate ARR by segment," which ARR does it use? Sales has one number. Finance has another. Accounting has a third. Humans resolve these ambiguities through judgment and conversation. Agents can't. They need explicit rules about which definition wins - and they need the decision traces that explain why.

The cost of missing context is measurable. Every breach investigation that takes six months instead of six weeks is a context problem. Every audit finding about "unable to explain exception rationale" is a missing decision trace. Every quarterly access review where managers blindly re-certify everything is ceremonial security - performing rituals instead of reducing risk.

The event clock is now buildable. This isn't a research problem anymore. The infrastructure patterns exist. Content ingestion, entity extraction, fact modeling with temporal validity, relationship graphs - the pieces are available. The question is whether enterprises will build this infrastructure deliberately or continue operating with the event clock missing.

Most enterprises have none of this infrastructure:

This isn't because organizations are negligent. It's because this infrastructure layer - what Foundation Capital calls "context graphs" - simply doesn't exist as a category yet. The tools weren't built for it. The processes weren't designed for it.

The state clock has trillion-dollar infrastructure. The event clock is still being invented.

In Part 2, we'll explore why security can't build this alone - and what it means for security leaders who want to move from ceremonial security to actual risk reduction.

Sources: