Join us at Breakbulk AmericasSept 22โ€“23, 2026Houston, TX ยท Booth M01
Back to Documentation

Route Readiness โ€” One Answer per Route Option

How RoadScope turns the constraint verdicts of a route option into one status per declared load, how a human decision sits next to it, and why every channel quotes the same rows.

7 min read

One Status per Route Option and Load

A map can hold several route options (a route or a chain of declared legs). For every option and every declared load, RoadScope aggregates the constraint verdicts of the POIs on that option into a single readiness status. No new rule is applied at this level โ€” the status is a roll-up of the same PASS / MARGINAL / FAIL / NOT EVALUATED verdicts described in *Constraint Verdicts in Reports*.

  • Clear โ€” every evaluated constraint passes with margin; nothing is missing
  • Needs work โ€” usable only after the listed work: movable obstacles (wires, trees, signs) or precise positioning at a marginal fixed structure
  • Blocked โ€” at least one fixed structure fails on height, width or weight for this load
  • Incomplete โ€” a load dimension or a required constraint measurement is missing; RoadScope never assumes a pass, so the option cannot be called usable yet
  • Each row also names the governing constraint per dimension (the worst evaluated height, width and weight margin with its POI), counts the work required, and lists the top reasons in plain language.

    Computed Status vs Human Decision

    The status is computed and never edited by hand. Separately, a person can record a decision on the option โ€” Recommended, Under review or Rejected โ€” with a note. The decision stores the computed status at the moment it was taken. Both are always shown side by side, and when they disagree (for example *Recommended* on a *Blocked* option, or a decision taken when the status was different) a mismatch warning is printed next to the row. The decision is provenance and accountability; it does not change the computed status.

    The Same Answer Everywhere

    The readiness rows are computed once on the server and quoted, never re-derived, by every channel:

  • Map โ€” the Route readiness panel
  • Reports โ€” a *Route Options Summary* table opens the Route Survey, Clearance Profile and Envelope reports; the narrative conclusion of a route is driven by its readiness status, and the pre-publish gate refuses issuance when a conclusion contradicts the current status
  • One-page Route Options Summary โ€” a printable, shareable report type (Reports Hub โ†’ Route Options Summary) with the load, the options table, the top 3 reasons per option, the human decision and the date of survey
  • Public API โ€” GET /api/surveys/{surveyId}/route-readiness returns the rows with the same status values (clear, needs_work, blocked, incomplete) and margins; decisions are read and recorded under /route-readiness/decisions
  • Max โ€” the assistant reads the same endpoint (read-only) to answer "which option can I use?" or "why is Option 04 blocked?", and the route briefing carries the status line
  • Freshness

    Rows are recomputed from the current measurements when a report is generated and are cached briefly for the map and Max; each surface shows when the readiness was computed. Changing a POI measurement, the declared load or a route changes the answer everywhere at once.