A process can stay locally healthy after its viable future has already collapsed. Your solver can keep running, your schedule can keep building, and your model can keep generating after the route to a correct outcome is already gone. Reachability Labs measures where that loss happens — resolved first in random 3-SAT, transferred to graph coloring, and now being extended through scheduling and LLM reasoning adapter lanes.
Prefer the plain-language version? Read The Builder's View or listen (~20 min).
The core object is not whether a valid endpoint exists somewhere. It is what future remains reachable from the exact state a process has already committed to.
αCAT(1000)=1.5352 · 194/194 bridged jams residual UNSAT
The canonical calibration site: a forward process loses reachable satisfying futures far below the existence threshold, with oracle-verified trap analysis and late visible failure.
See flagship evidence →Second oracle-backed CSP · different surface morphology
A second combinatorial domain shows process-side collapse inside a still-alive landscape. The timing differs from K-SAT; the deeper process-vs-landscape split remains.
See transfer lane →Latent schedule death · same-instance mixture · late failure
Forward scheduling is a literal committed-construction process. Current internal runs show that feasible schedules can remain globally possible after a committed schedule prefix has lost the route.
Discuss a scheduling adapter →V, H, Δ · three tiers · observability gap · collapse band
The LLM lane treats reasoning traces as committed prefixes and measures policy-conditional reachable future under rollout. It is an active measurement framework, not yet a completed empirical result.
Discuss the LLM lane →G(s), W, opacity, dead / fragile-live / robust-live
The methodology layer turns the measurements into reusable objects: gap profiles, walking-dead intervals, latent/observable mismatch, and adapter-specific viability structure.
See claim stack →Different visitors need different entry points. Start with the lane that matches what you are trying to evaluate.
Classical maps tell you where valid outcomes exist. They do not tell you when a real process has already committed itself out of every workable route. By the time that failure is obvious, teams have already paid in rework, scrap, wasted compute, or schedule slip.
A route can close long before the goal disappears. That loss has its own geometry, hidden states, warning signs, and costs. The diagnostics are built to find it.
The papers matter because they establish that the diagnostics are not guesswork. The current stack includes a flagship benchmark, a first validation lane, a process ladder, a parallel theorem program, and a second adapter showing that the core measurement logic transfers.
A sharp process-indexed boundary in a canonical benchmark, with late visible failure, exact-prefix deadness, trap depth, and strong within-instance path dependence.
See evidence ↓New validation runs keep the constructive boundary in the same narrow band, strengthening the case that the flagship signal is not just a pool artifact.
See validation ↓A stronger forward rung stays alive far beyond the baseline window, showing that added structure can move the accessibility boundary rather than merely smooth the curve.
Why the ladder matters ↓A second combinatorial domain now shows the same deeper process-vs-landscape split with a different surface morphology, strengthening the adapter-first program.
See domains ↓Parallel theorem program: a formal theorem line continues in parallel on hidden structural state, delayed manifestation, and the distinction between landscape-side existence and process-side reachability. See the benchmark view in Evidence.
The research-facing benchmark view. This is the benchmark projection of the same goal–process split used elsewhere on the site. The orange curve is measured A0 constructive success. The teal curve is the existence-side reference. The shaded band is the existence–accessibility gap. Toggle system size to see how the boundary sharpens. Drag to measure the separation at any matched success rate.
Nine system sizes through n = 1,000 anchor the flagship result. Oracle-verified trap analysis, bounded rewind, trajectory-space diagnostics, a confirmed scaling prediction, and a second combinatorial domain all support the same deeper claim: the goal can remain valid after the process has lost the route.
The artifact ledger, SHA-256 verification tool, and the public reference stack now live on the Evidence page so the homepage stays readable.
If you have a solver, scheduler, planner, optimizer, or reasoning workflow that keeps moving while outcomes collapse, diagnostics apply the same reachability instrumentation to your process: where the route closes, what kind of trap dominates, and what a realistic upgrade is likely to buy.
Bring a solver, planner, search pipeline, optimizer, or comparable constructive process. Reachability Labs instruments the run, analyzes where and how the path closes, and returns a decision-grade report.
A structured technical report, supporting plots and summaries, and a clear explanation of what is failing, what is merely noisy, and where process changes are most likely to matter.
The long-term product is a software platform for measuring constructive accessibility directly: boundary detection, trajectory diagnostics, trap analysis, variant comparison, and adapter-based transfer in one instrumented workflow.
Early adopters and pilot partners can start through diagnostic studies first. That path grounds the roadmap in real process failures, real reports, and validated instrumentation rather than speculative product claims. Public software releases should be tagged on GitHub and reflected back into this site through the artifact ledger.
Planned path: service-led development now, documented software release later, with publication-grade validation and a formal release track including JOSS.
The adapter logic is strongest where construction is forward, commitment is costly to reverse, local metrics compress global structure, and some external oracle or proxy can evaluate whether viable future remains.
Register allocation, routing, proof search, and related workflows are all sequential constrained processes that can lose reachable futures before their surface diagnostics reveal why.
Why it matters: These are real engineering domains where hidden process failure has direct cost.
Forward planners and schedulers commit to actions and resource allocations under accumulating constraints. They often fail for reasons that are visible only very late in the run.
Why it matters: The diagnostics translate naturally to process-side bottlenecks in planning systems.
Conflict-constrained assignment domains, including graph-coloring-like formulations in communications, fit the same instrument logic well.
Why it matters: The existence of valid assignments and the reachability of them by a process are often very different things.
Structured decoding, planning-like inference, and sequential reasoning systems are natural future domains because they also accumulate commitments while local metrics remain incomplete.
Why it matters: The long-term product opportunity is likely larger than SAT itself.
Use this after the program map if the language is new. The field guide explains the distinction between route, landscape, latent future, opacity, trap depth, and adapters.
Start here if the language is new. The goal is to make the problem legible in plain terms first and technical terms second.
In the figures, the goal is the valid endpoint, the process is the method, and reachability is the live relation between them. The gap and benchmark figures are viability-space views. The atlas is a local-state view of the same deeper object.
Opacity is symmetric. A doomed path is dead but cannot tell — it keeps moving, locally healthy, while its prefix has no satisfying completion. A surviving path is alive but cannot tell — it occupies a local state where most of its neighbors are already dead. Toggle between them: same instance, same local view, opposite truths. Three diagnostics measure what is happening: forfeiture (how much available future commitment has spent), the lost-route window (the “walking-dead” interval in the technical lineage) or the surviving corridor (steps spent dead but still moving, or steps survived through terrain where most paths are already dead), and opacity (the information gap between local view and actual fate).
From single path to population. The diagnostic figure above shows one trajectory at a time. The atlas below shows fifty at once — on the same instance. Press play and watch: they stay bundled for most of construction, then diverge violently in the final steps. Toggle "Reveal doomed paths" to see which ones were already dead before they knew it. Toggle "Structure view" to see beyond pass/fail — what each trajectory actually built.
A maze can still have exits even after the route you are on can no longer reach any of them. The map can stay alive while the route dies.
A goal can remain valid after the current process has lost the route to it. Reachability asks whether this process can still get from here to a valid completion.
A process can keep moving after its viable future is already gone. Local signals may look healthy even when the route is already dead.
The opposite can happen too: a route can look doomed while a narrow pass still exists. Some failures are shallow mistakes; others are deep structural traps.
Stronger processes get more sight, more inference, more correction, more reversibility, or some combination. The ladder asks what each added capability actually buys.
K-SAT and graph coloring are calibrated domains, not the whole story. The point is to measure the same deeper object across different terrains.
Each committed step realizes structure while narrowing the futures that remain reachable. That is why path history matters, why local health can mislead, and why going backward is rarely free.
A process that does not reach its stated goal has still built structure — and that structure may answer a question the original goal was too narrow to ask.
The classical view treats existence as the starting point — solutions sit in the landscape, and processes come afterward to find them. The constructive view inverts this: every real process in the physical world builds forward under irreversible commitment, with limited information, where each step shapes what can come next.
The aerial view of all existing solutions is what construction looks like in the limit of infinite capability. Reachability is the ground truth. Existence is the idealization.
See where a process loses the route. The concepts above are not abstractions. They are measurements. Drag through the demo to watch forfeiture rise and a late-loss morphology appear — or upload your own process trace and see where commitment concentrates difficulty.
Reachability Labs grew out of a process engineering background and a research program that kept arriving at the same question: why do well-instrumented processes still fail in ways their own metrics cannot explain?
The answer turned out to be structural. A process can lose access to viable futures long before any local signal reveals the loss. Behind that result is a broader thesis: each committed step realizes structure while narrowing the futures that remain reachable. The diagnostics, the research, and the software direction all follow from that finding — measured first in random 3-SAT with oracle-verified trap analysis, then extended to graph coloring, and now being built into a general-purpose diagnostic methodology.
The work spans computational combinatorics, constraint satisfaction, process diagnostics, and the emerging theory of constructive accessibility. At the core is a simple claim: success and failure are coarse labels on a deeper event — committed transformation and the futures it leaves behind. A process that fails its stated goal has still built structure, and that structure may be a complete answer to a question the goal was too narrow to ask. The classical landscape — the set of all valid solutions, studied from above — is the God's-eye limit of what this framework measures from the ground. Existence is what reachability looks like when you remove the constraint of actually having to build. The lab is currently a focused research-and-services operation. The intention is to grow it as the methodology and software mature.
The lab remains founder-led and is open to selected research, domain, and technical collaborations. If you want to propose working together, the collaboration lane below is the right place to start.
If your process keeps moving but outcomes still collapse, the cleanest path is the diagnostics page. If you want to propose research collaboration, a new domain application, or a technical contribution, use the collaboration lane below. If you are interested in the coming software, ask about early access or pilot work.
Fastest path: use diagnostics for live process failures; use the collaboration lane below for serious proposals that are not diagnostics work.
Do not start with a perfect story. Start with the process you already have and the failure you are already seeing.
The software direction is real and under active development. Reach out if you want early access, a pilot relationship, or to discuss what deployment would need to look like for your domain.
If you want to work with Reachability Labs on a serious line of work rather than commission a diagnostic, start here. The useful proposals usually attach to one of the program lanes above: theorem work, adapter transfer, scheduling, LLM reasoning, instrumentation, or release infrastructure.
Send a short note describing what you want to work on, why the fit is real, and what kind of first conversation would be useful.