Why “Service Active” Does Not Mean “System Healthy”

While building and using Sovereign Local MCP, one reliability lesson kept becoming clearer:

A running service is not the same thing as a working system.

A process can be alive. A service manager can report active. A health request can succeed. And the capability the user actually needs can still be broken.

Process health is only one layer

Imagine a browser automation service. The daemon is running, the browser process is running, and the connection service is running. Everything looks healthy from the operating system’s point of view.

Then you try the operation that actually matters:

• discover browser tabs;
• take a snapshot;
• select a target;
• execute a bounded browser action;
• recover after a reconnect.

And it fails.

From the service manager’s perspective, nothing is wrong. From the user’s perspective, the system is broken. Both observations can be technically correct because they are measuring different things.

Health should follow the capability

A useful health model should move through layers:

1. Is the process alive?

Necessary, but weak evidence.

2. Can the component respond?

Stronger, but still not proof that downstream capabilities work.

3. Is the expected runtime actually loaded?

Source code, installed binaries, configuration, services, and browser bridges can drift apart. The source tree can contain a fix while an older runtime is still executing.

4. Can the real operation succeed?

If the system exists to discover browser tabs, tab discovery itself is meaningful evidence. If it exists to read a page, a real bounded snapshot proves more than checking whether the bridge process exists.

The health check should get as close as safely possible to the capability that matters.

“Healthy” should not hide partial failure

A system may have transport available, runtime reachable, browser connected, one tool working, another failing, and session state preserved.

Calling the whole system simply “healthy” loses useful diagnostic information.

A better result looks like this:

transport reachable → runtime verified → browser reachable → tab discovery failed

That tells us exactly where investigation should begin.

Recovery is part of reliability

Local automation contains state: browser profiles, authenticated sessions, tabs, runtime configuration, and operation identity.

A restart that restores the process but destroys useful state is not a complete recovery.

The system should be able to reconnect, rediscover the current environment instead of trusting stale references, preserve the user session where possible, and determine what can safely be retried.

Runtime verification should be explicit

After an important fix, I now prefer a sequence closer to:

change → build → install/deploy → identify runtime → reproduce the original failure → verify corrected behavior

Skipping runtime identity creates a dangerous debugging gap. Tests can pass against one version while the real environment executes another.

A green status is evidence, not proof

Every health signal proves only what it actually measured.

A running process proves the process is running. A successful health request proves the health request succeeded. A verified runtime proves something stronger. A successful real operation proves more again.

Reliability comes from composing those pieces of evidence instead of treating one green indicator as proof of the whole system.

This is one of the ideas shaping Sovereign Local MCP as it evolves: failures should identify their boundary clearly, recovery should preserve useful state, and health checks should verify real capabilities rather than only confirming that processes exist.

Because in operational systems, “active” and “working” are not synonyms.