About Reachability Labs
Reachability Labs grew out of a process-engineering question: why do well-instrumented processes still fail in ways their own metrics cannot explain?
The current posture is simple: diagnostics now, software later, with the research and instrumentation continuing in parallel.
The lab measures route loss, not just endpoint failure.
The core claim is that a process can lose access to viable futures long before any local signal reveals the loss. That result became measurable first in random 3-SAT, then extended into transfer-calibration lanes and service diagnostics.
The work spans computational combinatorics, process diagnostics, constraint satisfaction, and the broader theory of constructive accessibility. The practical thread is always the same: identify where a committed process lost the route, what kind of trap it entered, and what stronger variants actually buy.
Current posture
Services are available now. Software is in development. The research and the service line are being built to reinforce each other rather than drift apart.
Michael Richard Nothem
Process engineer, researcher, and founder of Reachability Labs.
The lab grew out of repeated encounters with the same pattern: processes that remained locally active or locally healthy while the real route to a valid outcome had already narrowed or vanished. That observation led to the current research program and the diagnostics line.
Behind the benchmark results is a broader thesis: each committed step realizes structure while narrowing the futures that remain reachable. Success and failure are coarse labels on a deeper event — committed transformation and the futures it leaves behind.
What the work is for
The goal is not to produce another generic benchmark score. It is to make route loss measurable, diagnose it in real systems, and turn that measurement into software and decision-grade reports.
Diagnostics now
If you already have a process that keeps moving while outcomes still collapse, start with the diagnostics page and the intake form.
Open diagnosticsResearch first
If you need to understand the object before the service, use the research hub and the concept pages.
Open research hubEvidence first
If you need the benchmark, supporting materials, and public references, use the evidence hub.
Open evidence