Cognitive Context

There’s a gap between the code you write and the system it becomes.

You write a function. You know what it does in isolation. But do you know what happens when it runs alongside everything else? What services it depends on? What fails when it fails? What safeguards exist upstream?

This is what we mean by cognitive context: the awareness of how your code behaves as part of a running system, available while you’re still writing it.

The Problem

When you’re deep in a function, your mental model is local. You’re thinking about the logic at hand, the variables in scope, the immediate task. That’s normal. That’s how we work.

But production systems don’t run in isolation. A function that looks fine on its own might:

Call an external service without a timeout, creating cascading failures
Swallow an exception that should propagate, hiding real problems
Depend on a database connection that has no retry logic
Live in a route with no rate limiting, exposed to abuse

These aren’t bugs in the traditional sense. The code does what it says. The issue is that the code doesn’t say enough about how it behaves under stress, at scale, over time.

Most of the time, you don’t discover this until production tells you. And by then, you’re debugging at 2am with incomplete information and mounting pressure.

What Traditional Tools Miss

Linters check syntax and style. Type checkers verify contracts. Test suites confirm behavior under controlled conditions. These are valuable, but they don’t tell you:

Where this function fits in the call graph
What external dependencies it transitively relies on
Whether error paths are handled or silently dropped
How the framework wires this handler to incoming requests

Static analysis tools can find some of this, but they typically operate in batch mode. You run them in CI, get a report, and context-switch back to fix things. The insight arrives too late, disconnected from the moment of writing.

Cognitive Context in Practice

Unfault takes a different approach. Instead of generating reports, it provides context where you work:

In your editor, when you hover over a function, you might see:

“Called by 3 routes, 2 with authentication middleware”
“Makes HTTP calls to payment-service, no circuit breaker”
“Error path logs but doesn’t propagate”

In your terminal, when you run a review:

Findings grouped by what matters (stability, performance, security)
Each finding explains why it matters, not just what it is
Suggested fixes when the path forward is clear

In CI, as a gate:

Catch patterns that tend to cause production issues
Exit codes that integrate with your deployment flow
Output formats for your existing tools

The goal isn’t to generate more alerts. It’s to give you the information you’d want if you could hold the entire system in your head.

Why This Matters

Code review catches a lot. Testing catches a lot. But some things slip through because they require thinking about the system as a whole, and that’s hard to do when you’re reviewing a diff or writing a unit test.

Consider a simple change: you add a call to fetch user preferences from a new service. The code is correct. The tests pass. The reviewer approves.

But nobody noticed:

The new service has p99 latency of 800ms
The call has no timeout
It’s in the critical path for page load
There’s no fallback if the service is down

Six months later, that service has a bad deploy, and your unrelated feature is suddenly the cause of a site-wide slowdown.

This isn’t a failure of process. It’s a failure of context. The information existed, but it wasn’t available at the moment of decision.

Not a Gatekeeper

Unfault doesn’t block your commits or fail your builds by default. It doesn’t tell you what to do. It surfaces information and lets you decide.

Sometimes a missing timeout is fine. Maybe the call is to a local cache with sub-millisecond latency. Maybe you’re in a batch job where latency doesn’t matter. You know your system better than any tool.

What Unfault does is make sure you’re making that decision consciously, with the relevant context visible, rather than accidentally.

The Feeling We’re After

You know that feeling when you’re working with someone who really knows the codebase? They glance at your PR and say, “Oh, be careful here, this function gets called from the payment flow and that service is flaky on Mondays.”

That’s the experience we’re building toward. Not a judge. Not an enforcer. Just a knowledgeable colleague who helps you see what you might have missed.