# Operate

> The units in use: one node per unit with the panels and dashboards it is run through, what a run is, the lifecycle from Start to Completed, and what is refused while stopped.

**Operate** is the last of a model's four groups in the Process page's Workspace column
(Process > Models > a model > Operate), after [Definition](process-definition),
[Visualization](process-visualization) and [Setup](process-setup). The other three declare
the process; this one holds the units in use, one node per unit, and under each unit the
surfaces it is operated through. Nothing is configured here: a unit is declared and ended
on the model's own page ([Units](process-units)), its panels and dashboards are arranged
under Visualization, and what it runs is composed under Setup.

The branch is drawn for every role that may look at models (Look at models, Run
procedures, Manage process). A role holding only Edit recipes & evaluations sees each model
reduced to its Setup group, so Operate is not drawn for it. Watching is free with the tree;
staging, starting and steering a run take **Run procedures**, and a panel says so on its
face when the role lacks it.

## The Operate page {#the-operate-page}

Selecting the group opens a wall of cards, one per unit, headed "The stations this model
runs on. Open one to stage a procedure, start it and watch a recorded, evaluated run."
Clicking a card opens that unit. Each card carries the unit's live status, resolved in this
order of precedence:

| Status | Meaning |
| --- | --- |
| Stop tripped, Awaiting reset, Stop signal unavailable | The unit's [interlock](process-automation) is not Normal. Shown only when the model observes an external stop; it outranks everything below. |
| Recording, Held, Saving, Preparing, Finalizing | A run owns the unit: it is sampling, held at a setpoint, writing its snapshot, reserved before the run exists, or closing its file after the terminal state. |
| Idle · procedure | Nothing owns the unit and that procedure is staged for the next Start. |
| Idle · no procedure staged | Nothing owns the unit and nothing is staged. |

A model with no units reads "No units yet. Add one on the model's own page, in the Units table." The group's tree row
counts its units.

The detail bar carries the two batch triggers, drawn only for a role with Run procedures.
Nothing else stands on this bar, because nothing is created or deleted here.

| Command | What it does | Greyed when (situation) | Not drawn when (role) |
| --- | --- | --- | --- |
| Start all | Starts every unit that has a procedure staged and can run now; the others are skipped in silence. Every started run records the operator signed in on this screen as responsible. | No unit currently accepts Start, or a batch is already dispatching. | Without Run procedures. |
| Stop all | Stops every unit that is running now; units already stopped stay stopped. | No unit currently accepts Stop, or a batch is already dispatching. | Without Run procedures. |

A batch is a trigger, not a coordinated operation: each unit runs on its own, a refusal on
one unit is journaled and never rolls another back, and the action feed reports the count
("3 units started", "No unit could be stopped.").

## The unit {#the-unit}

A unit's own page names it, says whether a run owns it and opens onto each of its surfaces.
The header carries the same pill the cards carry (Recording, Held, Saving, Preparing,
Finalizing; nothing while the unit is free), and one card, **Surfaces**, lists as tiles the
panels and the dashboards the model defines, drawn for this unit. The page has no bar verbs
and no right-click menu: it is a way in, not a place to edit.

Under the unit, the tree holds one node per panel of the model, then one node per
dashboard. Both open under the same stage bar the View page uses, named "Model · Unit ·
Surface", with the run-state pill beside the name and the two window verbs on the trailing
side: **Expand** hands the surface the whole window, **Full screen** (F11) takes the whole
screen, and Esc leaves either.

- A **panel** node draws the cards the panel arranges, for this unit: the Run card, the
  Metadata card, the Run state, the Comments, the Occurrences, the Channels chart, the
  Productivity ledger, the Single commands and any dashboard the panel embeds as a card.
  That surface, card by card, is [Runs and comments](process-runs).
- A **dashboard** node runs the model's one definition with every abstract channel
  answered by this unit's bound source. It shows the dashboard and never edits it: editing
  is a verb of the model's own row under Visualization ([Dashboards of a
  model](process-dashboards)). A dashboard with nothing placed on it says so instead of
  drawing an empty stage. Its command components need only Run procedures here, because
  this is the official Process surface and not a dashboard of the station's own.

A panel or dashboard marked **Show on View** also appears on the View page, one entry per
unit of the model, under the same name; what it draws is the same either way.

## What a run is {#what-a-run-is}

A run is one execution of one procedure on one unit. It is named "Procedure · Unit",
recorded into its own SQLite file under the `acquisitions` folder of the app's data root,
and pointed at by one row of the history index, which is what lets an unfinished run be
found and resumed after a restart. The procedure's mode is the run's envelope: **Instant**
applies, records one row and judges once, then ends on its own; **Temporal** runs the
procedure's window, optionally repeated as cycles, and ends when the last window closes;
**Controlled** applies at Start and records until somebody stops it.

One run per unit at a time. Start reserves the unit before it resolves anything, so a
preparing unit is Busy without pretending to record; the reservation lasts through Running,
Held, Saving and the final close of the file. While any unit is occupied, every
configuration surface of the station is read-only ("Configuration is locked while a Unit
is running."); Operate itself stays live, because operating is not configuring.

## The lifecycle {#the-lifecycle}

| State | Meaning | Entered by | Left by |
| --- | --- | --- | --- |
| Preparing | The unit is reserved and the run is being validated and materialized. Not a stored state: the `Procedure.Status` point reads it while `Busy` is already true. | Start | The run materializing (Running), or a refusal (idle again). |
| Running | Sampling and, for a Temporal run, the window clock are moving. | Start, Resume | Hold, Stop, Abort, the window ending, a failure, the interlock. |
| Held | The window clock is frozen at the last setpoint; the datalog keeps recording. Temporal runs only. | Hold | Resume, Abort, the interlock. Stop does not apply to a held run. |
| Saving | Sampling has stopped; the finalization block ran and the frozen snapshot is being written. | Stop, Abort, the window ending, the interlock, an Instant run completing | The snapshot being written. |
| Completed | Ended cleanly; the verdict is the evaluation's. | Saving after Stop, a window ending or an Instant run | Terminal. |
| Aborted | Ended early; the verdict is NOK whatever the evaluation had judged. | Saving after Abort, a recipe failure policy set to Abort, the interlock, or the runtime stopping | Terminal. |
| Failed | Ended by an unrecoverable error; the verdict is None. | A failure while running or ending; a Saving pointer left behind by a crash comes back Failed at the next launch | Terminal. |

A run that was Running or Held when the application closed is not ended: it resumes at the
next launch, a temporal profile held at its persisted segment and cycle.

Every run records who started it (the operator signed in on the screen that pressed Start,
the station when nobody was, the unit automation, or an agent) and who ended it (the same
kinds, for a Stop or an Abort). A window that ran itself out, an interlock trip and a
failure end with nobody named. Hold and Resume leave no actor behind.

## What is refused, and why {#what-is-refused-and-why}

- **Runtime stopped**: while the station runtime is stopped, Start, Hold, Resume, Stop,
  Abort, the single commands, staging and comments are all refused with that reason, and
  the Run card writes it under its buttons. Runs still open when the runtime stops end as
  Aborted.
- **The interlock**: while a unit's interlock is Tripped, Awaiting reset or Unavailable, no
  new Start, Resume, snapshot, evaluation or recipe apply is admitted on that unit
  ("Unit 'X' is blocked by its interlock: reason"). Stop and Abort stay available.
- **Nothing staged**: Start needs a staged procedure ("No procedure is staged. Pick one
  first.").
- **A source held by another run**: two units that write the same source cannot run
  together; the second Start is refused by channel and holding unit.

The pages of this group:

| Page | Covers |
| --- | --- |
| [Runs and comments](process-runs) | The panel of a unit: staging, Start and what it validates, the lifecycle commands, the live cards, comments, the single commands, the run file, and the automation and agent paths to the same lifecycle. |
| [The unit address space](process-addresses) | Every point a unit publishes under `Process.<Model>.<Unit>`, its type and meaning, and which points are writable commands. |