Skip to content

Fallback-Mode Router

Dispatch process — instantiates Computability Boundary Mapping

Dispatches each query to the strongest method that fits where it falls relative to the computability boundary — exact, sound-approximate, bounded, or escalated — under an explicit fallback contract.

Fallback-Mode Router is the dispatcher that sits in front of a boundary-mapped problem and sends each incoming query to the strongest method that legitimately applies to it. Some queries fall in a decidable, cheap region and get an exact answer; others fall past the boundary and must be handled by a weaker mode — a sound over-approximation, a bounded search, a semi-decision that may return UNKNOWN, or escalation to a human. The router's defining job is not to solve anything itself but to choose the mode and enforce its contract: it reads where a query sits relative to the boundary, selects the matching fallback, labels the answer with the guarantee that mode actually provides — never a stronger one — and records why. It is the machinery that makes "publish an honest weaker fallback" operational, one query at a time.

Example

A verification-as-a-service platform checks user-submitted programs for a safety property. For programs written in the platform's decidable fragment, it runs the exact decision procedure and returns a definitive verdict. For programs using the full language, exact checking is undecidable, so the router dispatches down a ladder: first a sound static over-approximation that answers "safe" or "cannot prove safe" and never a false "safe"; if that cannot prove safety, a bounded model-check up to a depth budget; if that too is inconclusive, the query is escalated to a human-review queue. Every response is stamped with the mode that produced it and the guarantee that mode carries — "exact," "sound-approx: unproven," "bounded to depth k" — so no downstream consumer mistakes a bounded pass for a proof. The hard yes/no of "can we verify this?" becomes a graceful, labelled degradation.

How it works

  • Classify the query against the boundary map: decidable-and-cheap, decidable-but-costly, or past the boundary.
  • Select the mode whose guarantee is the strongest that legitimately applies.
  • Run it under its fallback contract, then label the output with that guarantee and no stronger one.
  • Record the routing decision and its reason.
  • Re-route on a trigger when the query's inputs or the surrounding assumptions change.

It owns dispatch and labelling; the internal mathematics of any mode lives in that mode, not in the router.

Tuning parameters

  • Mode ladder — which fallback modes exist and in what order (exact → sound-approx → bounded → human); more rungs cover more queries but complicate the contract.
  • Classification threshold — where a query is judged past the boundary and demoted; conservative thresholds demote early for safer, weaker answers, aggressive ones attempt exactness longer.
  • Budget per mode — the resource ceiling before falling to the next rung; larger budgets resolve more at each level but raise latency.
  • Escalation policy — when to hand off to a human versus return UNKNOWN, driven by the cost of a wrong-labelled answer.
  • Re-route trigger sensitivity — what change forces reclassification; too sensitive and it thrashes, too coarse and it serves stale routes.

When it helps, and when it misleads

Its strength is that it turns a hard "can we solve this at all?" into per-query graceful degradation, and its guarantee-labelling is what stops a weaker mode's answer from being read as a strong one.

Its failure mode is that a router is only as honest as its labels. If a fallback's guarantee is overstated — a bounded search reported as a proof — the router launders unsound answers behind an official-looking stamp, which is worse than having no router at all.[1] The classic misuse is bolting on a "best-effort" mode that returns a bare answer with no guarantee and then letting consumers treat it as authoritative. The discipline is that every mode carries an explicit, honest contract and that the label travels with the answer wherever it goes.

How it implements the components

Fallback-Mode Router fills the dispatch-and-contract side of the archetype — the components a router produces without solving anything itself:

  • fallback_solution_contract — for each mode it publishes and enforces the contract: what guarantee that weaker mode provides and what it explicitly does not, so a degraded answer is never oversold.
  • decision_record — it records, per query, which mode was chosen and why, leaving an auditable trail of how each answer was produced and under which guarantee.
  • recheck_trigger — it carries a trigger that re-routes a query when its inputs or the surrounding assumptions change, so a stale classification does not silently persist.

It implements no single mode's internals — the sound over-approximation is Abstract Interpretation or Model Checking, the honest-UNKNOWN recognizer is Semi-Decision with Explicit Unknown, the bounded pass is Bounded-Domain Exhaustive Search; the router only selects among them and enforces their contracts.

Notes

The router is the one mechanism in the set that consumes several others as interchangeable modes, so its entire value rides on correct classification and honest labelling — it should own no solving logic of its own. The moment it starts "just handling" an edge case inline rather than routing it to a mode with a stated contract, its guarantee discipline quietly erodes and the labels stop meaning what they say.

References

[1] A method is sound if every answer it asserts is correct, and complete if it asserts an answer whenever one holds. Past the computability boundary you generally cannot have both; the fallback modes a router dispatches to keep soundness and give up completeness, returning "unproven" or UNKNOWN rather than a false positive. ↩