Developers live in code. Observability lives in signals.
Between them, there is a gap nobody owns.

A developer opens a method and asks: "Is this still used? who calls it? does it run on the path that customers actually hit?"
The codebase cannot answer. The IDE cannot answer. Static analysis cannot answer.

So the developer switches tabs. They open a tracing tool, build a query, scroll through logs, eyeball a dashboard, and try to back-translate the result into the file they were just reading.

Code shows what the system was written to do. Observability shows what the running system emitted. Neither shows what the system actually does.

Two layers, one missing

Look at how engineering tooling has evolved.

The code layer is mature. IDEs, code search, refactoring tools, static analyzers, linters, AI copilots. All of it sharpens what happens when an engineer is reading or writing code.

The observability layer is also mature. Logs, metrics, traces, dashboards, alerts. All of it sharpens what happens when something is wrong in production.

Both layers are necessary. Both have improved enormously over the last decade.

But neither was built to answer the question that sits between them: "How does this code actually behave when it runs?"

That question is asked every day. Before a refactor. During a code review. While planning a migration. When deciding whether an API can be deprecated. When an AI agent is about to change a method it has never seen run.

It usually gets answered by hand, with assumptions.

The shape of the missing layer

The missing layer is not another dashboard, and it is not another log search. It is a connection. It connects code — methods, classes, blocks, APIs — to runtime reality: which paths run in production, how often, who calls them, what they touch downstream, what is dormant, what is hot, what is risky.

The signals already exist. The code already exists. What is missing is the wiring between them.

Once that wiring is in place, a lot of work changes shape. Reading code becomes reading code with usage. Reviewing a change becomes reviewing a change with blast radius. Drawing the architecture becomes seeing the architecture, the way it actually runs.

The shift

This is not a competing tool to observability. Observability stays where it is, doing what it does well.
The shift is recognising that there is a third layer — production-aware code and system understanding — and that engineering teams have been improvising it for years.

The system graph that KarmaDomain builds, and the in-IDE view that KarmaLens surfaces, are both pointed at this layer. Not at the signals. Not at the source. At the connection between them.

Observability shows what the system emitted. Engineering needs to know what the system did.