Decision Traces Are Just Taint Analysis for Business Logic

Foundation Capital recently published a piece arguing that the next trillion-dollar platforms won’t be built by adding AI to existing data - they’ll be built by capturing decision traces. Ed Sim followed up with his own take on what he calls the “Execution Intelligence Layer” - the infrastructure that sits between human intent and actual system execution.

The thesis: AI agents don’t just need access to data. They need access to the reasoning that connected data to action - the exceptions, overrides, precedents, and cross-system context that currently live in Slack threads and people’s heads.

This is exactly what OnchainDB is built for.

Three Concepts That Sound Similar But Aren’t

Chain of Thought is an LLM’s internal reasoning for a single decision. It’s ephemeral - generated during inference, then discarded. It explains how the model arrived at an answer, but it’s not stored, not queryable, and not shared across agents.

Audit Trails capture what happened: who changed what, when, and from which IP address. They’re compliance artifacts - valuable for security and regulatory requirements, but they don’t capture why something was allowed to happen.

Decision Traces are a superset of audit trails. They capture the full context at decision time: what inputs were gathered across systems, what policy was evaluated, what exception was granted, who approved, and what precedent was referenced.

The key insight: audit trails tell you what happened. Decision traces tell you why it was allowed to happen - and make that reasoning searchable for future decisions.

The Context Graph

When decision traces accumulate over time, they form what Foundation Capital calls a context graph: a living record of decisions stitched across entities and time, where precedent becomes searchable.

As Sim puts it, context is “the combination of inputs, intent, constraints, history, permissions, exceptions, and outcomes that surround every real enterprise decision.” The context graph makes all of that queryable.

Consider a renewal agent that proposes a 20% discount when policy caps renewals at 10%. To justify the exception, it needs:

• The 3 SEV-1 incidents from PagerDuty that impacted this customer
• The open escalation in Zendesk flagging churn risk
• The prior renewal where a VP approved a similar exception last quarter

The CRM stores one fact: “20% discount.” The context graph stores why the 20% was allowed, who approved it, under what policy version, and which precedent was referenced.

Next quarter, when another agent encounters a similar situation, it can query the context graph: “Show me approved exceptions for customers with multiple SEV-1 incidents.” That’s organizational memory.

Why Incumbents Can’t Capture Decision Traces

The Foundation Capital piece makes a sharp observation about why existing systems fail here.

Operational systems store current state. Salesforce knows what the opportunity looks like now, not what it looked like when the decision was made. When a discount gets approved, the context that justified it isn’t preserved. You can’t replay the state of the world at decision time.

Warehouses receive data via ETL. Snowflake and Databricks get data after decisions are made. By the time it lands in the warehouse, the decision context is gone. A system that only sees reads, after the fact, can’t be the system of record for decision lineage.

The article’s key line:

“Capturing decision traces requires being in the execution path at commit time, not bolting on governance after the fact.”

OnchainDB as the Decision Trace Layer

OnchainDB is designed to be in the write path - where agents make decisions and persist the context that justified them.

Append-only by design. Every write is cryptographically committed to Celestia. You can’t overwrite history, so decision context is preserved alongside outcomes. The “why” doesn’t get lost when the “what” gets updated.

Cross-app queries at decision time. Agents can pull context from multiple apps in a single request. The renewal agent can query price history from one app, support tickets from another, and incident data from a third - all before making a decision. That context becomes part of the decision trace.

Queryable precedent. Because decision traces are stored as structured data with configurable retention, agents can search for relevant precedent. “How have we handled similar situations?” becomes a query, not a Slack archaeology expedition.

Cryptographic verification. Decision traces aren’t just stored - they’re verifiable. Third parties can confirm that the data existed at a specific point in time without trusting your internal systems.

What This Looks Like in Practice

import { createClient } from '@onchaindb/sdk';

const client = createClient({
  endpoint: 'https://api.onchaindb.io',
  appKey: process.env.ONCHAINDB_KEY
});

// Store a decision trace - not just the outcome
await client.store({
  collection: 'decision_traces',
  data: [{
    decision_type: 'discount_approval',
    entity_id: 'renewal_12345',
    outcome: { discount_percent: 20 },

    // The context that justified the decision
    context: {
      policy_version: '3.2',
      incidents: ['SEV1-001', 'SEV1-002', 'SEV1-003'],
      escalation_id: 'ESC-789',
      churn_risk_score: 0.85
    },

    // The precedent that was referenced
    precedent: {
      prior_decision_id: 'decision_abc',
      similarity_score: 0.92
    },

    // Approval chain
    approval: {
      approver: 'vp_finance',
      approved_at: new Date().toISOString(),
      exception_type: 'service_impact'
    }
  }]
});

// Later: query for relevant precedent
const precedents = await client.query({
  collection: 'decision_traces',
  filter: {
    decision_type: 'discount_approval',
    'context.incidents': { $exists: true },
    'outcome.discount_percent': { $gt: 10 }
  }
});

The decision trace captures everything an auditor - or a future agent - would need to understand why this exception was granted.

A Familiar Problem: Taint Analysis for Business Logic

If the concept of decision traces sounds familiar to anyone who’s done reverse engineering or security research, that’s not a coincidence. I’ve spent 20 years in reverse engineering and security, and this problem - tracking “how did we get here?” - comes up constantly.

In security, we have taint analysis: mark certain inputs as “tainted” (user input, external data), track how that taint propagates through the system, and flag when tainted data reaches sensitive sinks. The question taint analysis answers is: “What contributed to this state? Where did the influence come from?”

We also have symbolic execution: instead of running a program with concrete values, you run it with symbolic ones and track the constraints that accumulate along each path. This lets you answer: “Under what conditions do we reach this state?”

Decision traces are the same pattern applied to business logic:

The “why” in decision traces is essentially provenance tracking - the same concept taint analysis uses to answer “how did we get here?”

A context graph is the accumulated taint propagation history across decisions. When an agent makes a decision, it’s “tainted” by all the inputs that influenced it - and that taint is preserved so future agents (or auditors) can trace the lineage.

For technical audiences: decision traces are taint analysis for organizational decision-making.

From Audit Logs to Organizational Memory

The shift from “audit trails” to “decision traces” isn’t just semantic. It’s a change in what you’re optimizing for.

Audit trails are backward-looking. They exist so you can investigate after something goes wrong.

Decision traces are forward-looking. They exist so agents can make better decisions by learning from how similar situations were handled before.

Both are valuable. But as agents take on more autonomous decision-making, the ability to query precedent - not just log events - becomes critical infrastructure.

The question isn’t whether your data is immutable. It’s whether the reasoning behind your decisions is captured in a way that makes your organization smarter over time.

That’s what we’re building.

If you’re working on AI agents and want to explore how decision traces could fit into your stack, or need audit trailing for compliance, reach out at partners@onchaindb.io.

For more on where OnchainDB fits in the AI agent stack, see OnchainDB vs The World.