Route Scoring

Route scoring is implemented by the RouteScorer class in @arc-route/scoring. It reduces each candidate Route to a single score in the range zero to one, where one is the best possible, so the RoutingEngine can rank candidates and select one. The score is a weighted combination of four normalized signals: cost, speed, reliability, and liquidity. Lower-is-better signals — total cost and total latency — are inverted during normalization, so a higher score always means a better route.

Normalization is performed across a candidate set, not in isolation. The scoreBatch method normalizes cost and latency relative to the other routes in the batch, because absolute cost numbers are only meaningful against the alternatives; rank returns the same routes sorted by score. Per-dimension subscores are exposed on each ScoredRoute for transparency and debugging, so the reason a route won (or lost) is inspectable rather than opaque.

Cost and speed are the dimensions users intuit, but reliability and liquidity are what make a route survive real conditions. Reliability reflects how consistently a route's constituent bridges settle as expected; it is carried per hop by the HopEstimate and aggregated onto the Route. Liquidity reflects how robust the path is to the transfer consuming a large share of available depth, and degrades as utilization rises.

The weights are caller-supplied through the ScoringWeights type and default to a balanced profile. Because the function combines all four dimensions, a marginally cheaper route built on less reliable or thinner components does not displace a slightly costlier but more trustworthy one — a property best described as reliability dominance. This is how the scorer encodes a preference for routes that actually complete, not merely routes that look optimal on paper.