Why We Index Decisions, Not Just Code

The search that never works

I've been there. When I was CTO at Bemmbo, a customer reported unexpected behavior via Intercom. Manu, our support lead, asked why a certain ERP integration worked differently for customer A than for customer B. Hashira, the on-call engineer, started digging through the code across multiple repositories.

Eventually, he found it. He could see what the code did.

But he still couldn't understand why they had chosen that configuration over a generic one.

The commit message said "Add custom config for customer A." The PR title said "ERP sync adjustments." But the actual decision—why this customer needed special handling, what edge case led to this exception, what the original requirements were—lived somewhere else. Maybe in a Slack thread from the sales handoff, now archived. Maybe in the head of the engineer who onboarded them and no longer works here.

The three most senior people at Bemmbo probably had some clue. But they were all in meetings, or deep in their own work, or simply didn't have time to dig through their memory for a decision made eighteen months ago.

---

Code tells half the story

Every line of code is the answer to a question someone asked. But we only index the answer.

Back to Bemmbo: that custom ERP configuration existed for a reason. The code was clean, tested, working. But the code didn't tell Hashira:

• That customer A's ERP had a non-standard API that required special handling
• That the sales team had promised a specific behavior during the deal
• That we'd tried the generic approach first and it failed silently for three weeks
• That the original engineer had documented the workaround in a Slack thread, not in the code

This context existed. It was scattered across Linear tickets, Slack threads, sales handoff notes, and one engineer's memory. But when Hashira needed it, he couldn't find it.

So he interrupted three people. And the customer waited.

---

The Decision Graph

This is what I wished existed at Bemmbo. Not another search tool—a map of every decision we'd made, connected to the code that implemented it.

At Emisso, we build what we call a Decision Graph—a connected representation of not just what shipped, but who decided, why they decided it, and what was considered.

Here's what that Bemmbo PR would look like in our system:

PR #847: Custom ERP config for Customer A
    │
    ├── WHY: Customer A's ERP uses non-standard API responses
    │
    ├── WHO DECIDED: @sircrab (author), @cdotte (approved)
    │
    ├── WHAT WAS DISCUSSED:
    │   ├── Linear ENG-234: "Customer A onboarding issues"
    │   └── Slack #integrations: "Generic approach failing silently"
    │
    ├── ALTERNATIVES CONSIDERED:
    │   ├── Generic config (rejected: failed for 3 weeks, silent errors)
    │   └── Ask customer to change their ERP (rejected: sales promised compatibility)
    │
    └── IMPACT: Customer A only, no effect on other integrations

If Hashira had access to this, he wouldn't have needed to interrupt anyone. The answer—why customer A was different—would have been one search away.

---

Why this matters for AI

Here's the thing about AI-powered support: it's only as good as the context it has access to.

Traditional approaches train AI on documentation. But documentation is a filtered, static snapshot of what someone thought was important to write down. It's always incomplete. It's often outdated.

Code search finds syntax. It answers "where is this function defined?"

Documentation search finds prose. It answers "what did someone write about this?"

Decision search finds context. It answers "why does this work this way?"

When your AI support agent has access to the Decision Graph, it doesn't just parrot documentation. It explains the reasoning. It cites the actual decisions. It provides the context that makes answers useful.

---

The technical moat

Anyone can index code. GitHub does it. Sourcegraph does it. Grep does it.

Anyone can index documentation. Notion does it. Confluence does it. Every RAG implementation does it.

But indexing decisions requires understanding the relationships between artifacts:

• Temporal proximity: A Slack message sent 10 minutes before a PR was created is likely related
• Entity extraction: "@cdotte" in a comment maps to the same person as the PR author
• Semantic linking: "auth refactor" in Linear connects to "OAuth implementation" in GitHub
• Decision signals: "After discussion, we decided..." patterns indicate rationale

This is what we're building. Not just search, but understanding.

---

What this looks like in practice

Let me replay that Bemmbo scenario—but with Emisso.

What actually happened:

Customer A: "Why does my ERP sync work differently than other customers?"

Manu (support): "Let me check with the team."

[4 hours later, after three interruptions and digging through old Slack threads]

Manu: "It's a custom configuration. I'm told it was necessary for your setup."

What could have happened with Emisso:

Customer A: "Why does my ERP sync work differently than other customers?"

Manu asks to @emisso, and replies: "Your account uses a custom ERP configuration added in PR #847 on March 2024. Your ERP returns non-standard API responses that weren't compatible with our generic sync. The team tried the standard approach first, but it failed silently for three weeks. The custom config was approved by @cdotte after confirming with sales that compatibility had been promised during your onboarding. See the full discussion in Linear ENG-234."

The difference isn't just speed. It's depth. It's the why. And Hashira never gets interrupted.

---

What we're not (and what we also do)

We're not replacing documentation. Good documentation still matters—and when you know what decisions were made, writing docs becomes much easier. (Some teams are already using Emisso to draft release notes and internal guides automatically.)

We're not replacing code search. You still need to find functions and files.

We're not replacing your knowledge base. Your written guides still have value—Emisso makes them more discoverable by connecting them to the code and decisions they describe.

We're connecting all of it. Making the implicit explicit. Turning tribal knowledge into searchable context.

---

The goal

Every product decision your team makes should be queryable—by your support team, by new engineers, by AI agents, by future you.

Not because someone took the time to document it.

But because it was captured automatically, as it happened, in the systems where decisions are actually made.

That's what we're building.

---

Building Emisso — Product knowledge platform for software teams. Learn more