How DEPLOY verifies deployment status: Active, paused, ended, and the evidence behind each

"Is this service still operating" is a question an operator, a journalist, or a downstream agent asks DEPLOY constantly. The answer is a state value (active, paused, ended) with an evidence anchor (the verification source that lets DEPLOY assert the state). When the evidence anchor is current, the state is verified. When the evidence anchor is stale or absent, the state is at risk of drift, and the verification posture collapses into claim. The framework treats state drift as the systemic risk at registry scale and treats source-depth maintenance as the state-verification infrastructure that mitigates it.

The methodology rests on the constructs defined at /methodology/what-verified-means: the verified-vs-claimed boundary, source discipline (≥3 distinct editorial functions), and cap-flag-as-trust-signal. Deployment status applies the same constructs to a state-tracking layer. A state asserted on current counterparty evidence is verified; a state with stale evidence is at risk; a state for which no verification evidence exists is cap-flagged.

Active: operational evidence criteria

Active means the deployment is currently operating against counterparty-confirmable evidence at the verification threshold DEPLOY operates. Three evidence categories anchor the active state. First, recent service reports from the operator or its customer (a service-availability announcement, an earnings-call mention of current throughput, a user-facing scheduling or booking surface). Second, current permit-plus-operations status (a regulatory permit that authorizes operation in the deployment envelope, paired with evidence that operation is actually occurring under the permit). Third, counterparty confirmation (a customer of record's own communication about the deployment as current).

A single category can anchor active state when the evidence is current and unambiguous; thinner evidence (a months-old press release that has not been refreshed; a permit that authorizes operation but no recent evidence of operation itself) shifts the state into at-risk territory pending re-verification. DEPLOY's source-depth campaign on registry entities is the maintenance mechanism that refreshes the evidence anchor on a recurring cycle so the active assertion does not drift into stale-claim posture.

Paused versus ended: the distinction

Paused means a deployment that has been operating against verified evidence and has temporarily ceased, with a documented reason and an expected resumption. Ended means a deployment that has been operating against verified evidence and has permanently ceased, with a documented wind-down, pivot, customer-relationship termination, or maker-corporate event removing the deployment from active operation. The two states differ structurally in the documented reason and in the expected forward trajectory; the framework treats them as distinct because operators evaluating "should I plan around this service" need to know whether resumption is expected.

Waymo's recent operational record anchors several paused-state worked examples in DEPLOY's signal corpus. Atlanta and San Antonio service paused after vehicles repeatedly drove into flooded roads; Waymo published the software-update work and the conditional resumption plan, anchoring the paused state with both documented reason (flood-entry failure) and expected resumption (post-update redeployment). Freeway service halted across four markets after construction-zone perception failures; the partial pause sits in the same shape (documented reason, expected resumption pending fix). The 3,791-vehicle recall via NHTSA is a third paused-adjacent shape: regulator-anchored remediation with quarterly status reports required, where the regulatory record itself is the verification surface for the operational state.

Cruise's San Francisco wind-down anchors the ended-state shape. Operations were active under CPUC permit through October 2023, paused after the pedestrian-dragging incident, and subsequently ended through GM's corporate decision to retire the robotaxi business. The state transitioned from active to paused to ended along documented evidence at each step: regulatory action, maker announcement, and corporate-strategy filing. Operators evaluating Cruise's deployment record encounter the full arc as a verified ended state with the wind-down evidence preserved; the verification surface does not silently retire when operations stop.

State drift as the default failure mode

At registry scale, state drift is the systemic risk. Deployments are announced with press-release events, the press-release event becomes the verification anchor, and the state assertion stays valid as long as the anchor remains current. Months later, conditions have changed: the deployment expanded into new markets, contracted out of old ones, transitioned from pilot to commercial, or ended on customer pivot. The registry's state assertion is now stale unless the evidence anchor was refreshed against current operational reality. Default behavior at most data sources is to leave the original anchor in place; this is how registry entries accumulate stale claims that read as verified state when they no longer are.

DEPLOY's source-depth campaign is the state-verification infrastructure that mitigates drift. The campaign deepens registry entities by re-verifying the evidence anchor against current sources, surfacing stale assertions for correction. Wave 3 of the campaign produced roughly eleven stale-status corrections across seventy-nine deepened entities; the corrections include both ended-misregistered-as-active and paused-misregistered-as- active patterns, plus active-but-evidence-stale entries that were re-anchored to current sources. The standing discipline is quarterly source-depth cycles across the registry, with monthly cadence for highest-traffic entities (robotaxi services with active service maps; enterprise humanoid deployments with active customer relationships) where state volatility is highest.

The Waymo Driver Gen6 deployment in Austin is the recursive-application worked example. The deployment launched via Waymo's partnership with Uber in March 2025 and has remained active and expanding through May 2026, but the registry entity had drifted into a paused-state assertion during the period when the evidence anchor was not refreshed against current operational reality. Wave 3 source-depth research re-verified against current evidence (Waymo-Uber Austin service availability, current ride throughput, current geographic envelope) and surfaced the paused-misregistered-as-active correction; the deployment state was corrected to verified-active with refreshed evidence anchors. Applying the framework recursively, the correction is the same discipline DEPLOY asks operators to apply to manufacturer deployment claims: a stale paused-state assertion is no more verified than a stale active-state assertion, and the verification posture is tied to the evidence anchor, not to the maker's last published statement. DEPLOY caught the drift in its own data through the same source-discipline cycle the framework names; the correction is the published trust signal that the recursion operates.

Where to go next

Operators evaluating a specific deployment can start at the registry's entity surface (registry.deploy.report), which catalogs deployments per maker with the verified state, last-verification timestamp, and evidence anchor. Named registry cuts at verified robotaxis, verified delivery robots, and verified humanoid companies surface category-specific deployment cuts. DEPLOY's consumer surfaces will provide entity-level availability overviews at dedicated identity routes once published; the deployment-status constructs defined here govern what surfaces as active, paused, ended, or cap-flagged across those pages.