Context Graphs and the Missing Memory of Global Trade

The team at Foundation Capital recently articulated the idea of context graphs — systems that capture the reasoning connecting data to action. Their work resonated deeply with what we see every day in global trade operations.

Why was this rate approved?

Why was this HS code used instead of another?

Why did this shipment require an exception when the last one didn’t?

In global trade operations, these questions come up constantly. And the answers almost never live in your systems.

They live in inboxes, spreadsheets, Teams threads, and people’s heads — and once the action is taken, they disappear.

For decades, enterprise software has focused on one thing: state.

Systems of record tell us what’s true right now — the final rate, the booked shipment, the cleared entry, the paid invoice. They’re very good at that.

But in global trade, what breaks operations isn’t missing state.

It’s missing context.

At Wove, we believe this missing layer is the biggest unsolved problem in global trade software. It’s what led us to think deeply about context graphs.

The problem isn’t automation — it’s memory

Most trade operations today look like this:

• An email arrives with a rate request, document, or exception

• A human interprets it, applies judgment, and makes a call

• The final outcome gets written into a system

• The reasoning behind that outcome is lost

Multiply this by millions of shipments and years of operations, and you get an industry that constantly re-learns the same lessons.

This is why automation alone doesn’t compound in trade.

If every edge case resets the system back to human judgment, with no memory of how similar cases were handled, progress stalls.

State vs. context: the two clocks of trade operations

One way to think about this is that every organization runs on two clocks:

• A state clock: what’s true right now

• An event clock: what happened, in what order, and why

Global trade systems are excellent at the first. They are almost blind to the second.

A TMS shows that a shipment was booked. It doesn’t show the tradeoffs that led to that booking.

A customs system shows an HS code. It doesn’t show the ambiguity that was resolved to select it.

A pricing system shows a rate. It doesn’t show the exception, approval, or precedent behind it.

That second clock — the event clock — is where real operational intelligence lives.

What a context graph actually is (and isn’t)

A context graph is often described as “a graph of decisions,” but that framing can be misleading.

It’s not a static knowledge graph.

It’s not a document index.

It’s not a memory bolted onto an agent.

A context graph is the accumulation of execution-time traces — records of how real trade actions were carried out, with context preserved.

Each trace captures things like:

• What inputs were considered (documents, emails, prior shipments)

• What rules or policies applied

• What exceptions were triggered

• Who approved what, and why

• What outcome was ultimately committed

Here’s a concrete example: when a forwarder approves a non-standard rate for a perishable shipment due to holiday capacity constraints, the trace doesn’t just record the rate. It captures the capacity constraint, the precedent check against similar routes, the approval chain, and the customer communication. Six months later, when the same scenario surfaces, that context is retrievable.

Individually, these traces are useful.

Over time, they compound into something far more powerful: institutional memory.

Why execution matters more than intelligence

The hardest part about building context graphs isn’t models or storage.

It’s positioning.

You can’t reconstruct context after the fact.

Data warehouses see outcomes too late.

Dashboards see signals but don’t act.

Standalone AI tools observe, but don’t commit.

To capture context, a system has to sit in the execution path — at the moment judgment is applied and state is written.

That’s why context graphs emerge from doing real work:

• Ingesting messy inputs

• Orchestrating workflows

• Routing exceptions

• Recording approvals

• Writing back to systems of record

The context graph isn’t built as a separate project.

It’s the exhaust of executing trade operations at scale.

Why global trade is uniquely suited for this

Global trade is one of the most context-heavy domains in the world:

• Rules change by country, commodity, and time

• Exceptions are common, not rare

• Precedent matters

• Errors are costly and auditable years later

This makes trade a poor fit for brittle automation but an ideal fit for systems that *learn* from execution.

Every shipment handled with context preserved makes the next one easier. Every resolved exception becomes precedent. Every approval becomes a reusable signal.

That’s how intelligence compounds safely.

From automation to institutional memory

At Wove, we started by automating execution:

• Turning unstructured trade communication into structured, system-ready data

• Reducing manual effort across pricing, operations, and compliance

• Writing outcomes directly back into systems of record

But over time, we realized the deeper value wasn’t just automation.

It was what automation allowed us to capture.

By sitting in the execution path — as outcomes are determined and data is committed — we preserve the context behind those outcomes as first-class data, not as an afterthought.

That’s what we mean by a context graph.

The long view

The future of global trade software won’t be defined by better dashboards or bigger models.

It will be defined by systems that:

• Preserve reasoning, not just results

• Learn from execution, not just ingestion

• Turn judgment into durable, auditable memory

Context graphs are the infrastructure that make that possible.

And global trade — with all its complexity, exceptions, and edge cases — is where they matter most.