> ## Documentation Index
> Fetch the complete documentation index at: https://docs.internal.nscale.com/llms.txt
> Use this file to discover all available pages before exploring further.

# DC Standup Pipeline

> How Operational Racks places devices, interprets Job history, and exposes the next action.

The **Operational Racks** view is the primary progress board for DC standup. It shows where each
[device](../start-here/glossary#node) is, what happened there, and which action is currently available.

The full pipeline is:

```text theme={null}
enrolment → quarantine (Move to Test Cluster) → single-node test → multi-node test → release
```

Some device types skip stages. A column means the stage a device is **at or waiting to start**,
not the last stage it completed. After a stage succeeds, the device normally moves to the next
column as `not_started`.

## The placement rule

**Current customer [handover](../start-here/glossary#handover) state comes first.** If Fleet Manager reports a device as
`available` or `in_use`, the board places it at the end of its pipeline with `succeeded`:
`release` for customer hosts, or `enrolment` for hypervisors whose pipeline ends there. Job
history does not move a currently customer-ready device back to an earlier column.

```text theme={null}
Is operational_status available or in_use?
├─ yes → terminal column / succeeded
│        Keep the latest Job link and acceptance-gate history for inspection
└─ no  → place from Job history
         ├─ choose the newest non-interrupted attempt
         ├─ advance after success when required gates pass
         └─ clamp back to the first stage that has not succeeded
```

For devices that are not currently `available` or `in_use`, placement follows the newest attempt
that was not cancelled, terminated, or superseded:

| Latest relevant outcome | What the board does |
| - | - |
| Pending or running | Shows the device at the active stage |
| Completed | Clears the stage and normally moves to the next one |
| Failed or timed out | Keeps or moves the device to the failed stage |
| Cancelled, terminated, or superseded | Ignores the interruption for placement but keeps it in Job history |

A device cannot skip an earlier stage that never completed successfully. This is the
**prefix clamp**: for example, a later single-node attempt cannot place a device past a failed
enrolment. The clamp does not apply while current `operational_status` already proves the device
is `available` or `in_use`.

```text theme={null}
completed → cancelled = stays cleared
failed → cancelled    = stays failed
cancelled only        = remains incomplete
completed → timed out = becomes failed
```

The latest Job link can therefore open a cancelled or failed attempt while the cell reflects an
earlier result—or current customer-ready state. This is expected: the column answers where the
device is now; the Job link and gate details preserve how it got there and any evidence gaps.
When that latest Job is pending or running, the cell keeps the
`concurrent_workflow_running` suppression reason alongside `no_next_stage`, even though current
customer-ready state keeps its placement green.

The board is recalculated on every refresh; there is no stored pipeline column to backfill. Use it
for orientation, not as the only proof for a diagnosis or as an unchecked bulk-action list.

For raw Job states, see [Status Reference](./status-reference). For exact device-specific
pipelines, placement ordering, acceptance-gate rules, customer-ready overrides, and the prefix
clamp, see [Device State Machines](../developer-guide/device-state-machines).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.