# Unit panels on View

> The stack of cards a Process unit is operated through, as it appears on the View page: how it gets there, what each card shows and lets you do, and the Process permissions it obeys.

A **unit panel** is a Process surface standing on the [View](home) page: the cards a model
arranged for operating its units, drawn for one unit. It is not a dashboard. Nothing about
it is composed on a grid, no editor opens on it, and every unit of the model operates
through the same cards, so a bench of four identical stations is arranged once. The
arrangement is made on the model's **Panels** row in the Process workspace
([Panels](process-panels)); this page covers the panel as View shows it.

## How a panel gets onto View {#how-a-panel-gets-onto-view}

Each panel of a model carries a **Show on View** switch on its row's bar in the Process
workspace (it needs the **Manage process** permission). Turned on, the panel puts one entry
per unit of the model in the Visualization column, named `Model · Unit · Panel` and
wearing the icon picked on the panel, or the fixed mark of a panel when none was picked.
The entries stand under the **Unit panels** heading after your folders and screens until
you file one into a folder from its row's menu, exactly like a screen of your own; a model
that has no unit puts nothing there. A model's **screen** shown on View the same way is a
different thing: it runs on the canvas, resolved for its unit, and is covered at the end of
this page.

The stage bar names the entry with its full name and offers **Edit in Process** for a
role that may manage models, which opens the panel's own row on the Process page. **Copy**
and **Edit** are not drawn: there is no layout to take. **Expand** and **Full screen** work
as on any screen, and the status bar stays on.

## Permissions {#permissions}

Seeing a unit panel needs **Look at models**; the visibility checklist of your own
dashboards does not apply. Everything that commands the unit needs **Run procedures**, and
a role without it reads the notice at the top of the stack: "You can watch this unit's run
state here, but starting or steering it needs the “Run procedures” permission." The
run card then draws neither the procedure choice nor the lifecycle buttons, the single
commands card is not drawn at all, the Metadata entries are disabled, and a command
component inside a card wears the lock mark with "Run procedures permission required." in
its tooltip. The **Operate dashboards** permission plays no part here.

Two more refusals come from the station rather than the role, and both are said on the
card that fired the command: why the station as a whole is not accepting run operations
(the runtime stopped: "Runtime stopped"), and why this unit in particular is not (an
execution barrier such as a tripped interlock). Who pressed is recorded at every press: the
user signed in on this connection, or the station when nobody is.

## The stack {#the-stack}

The entry opens as a scrolling column of cards, in the order the panel arranges them.
Every card opens with the same head: its name on the left and, on the right, the one thing
qualifying it right now. A card the station gives nothing to show is left out rather than
standing empty: Single commands with no datalog and no instant recipe to fire, Channels on
a model with no readable channel, Metadata while the staged procedure prompts no field, a
screen card whose screen is gone or still empty. A panel that draws no card at all says:
"This panel draws no card. Choose its cards on the model's Panels row, under
Visualization."

Above the cards, and never arranged away, stands the **interlock banner** when the model's
stop interlock is enabled: nothing while the unit is normal; a critical banner while it is
**Tripped**, with the reason, the source, its value and its quality; a caution banner while
it is **Awaiting reset**, with a **Rearm** button that needs Run procedures. What the
interlock is and how it is configured is on [Automation](process-automation).

### Run {#run}

The procedure staged for the next start and the commands that steer the run.

| Element | What it shows or does |
|---|---|
| Head, right side | A lamp and a word: **Recording** while a run records, **Preparing** while the unit is reserved but not yet recording, **Not recording** otherwise. |
| Procedure | A picker of "(none)" and every procedure of the model. Choosing one stages it for the next Start; "(none)" stages nothing. Disabled without Run procedures or while the runtime is stopped. A staging the station refuses (an alias set that cannot be pinned, for example) snaps the picker back and says why on the card. |
| Start, Hold, Resume, Stop, Abort | The lifecycle commands, each greyed until the run can take it, with a tooltip saying what it does: "Start the staged procedure on this unit", "Freeze the temporal window; the datalog keeps recording", "Release the hold and carry the window on", "End the run cleanly and freeze it as history", "End the run as aborted; the finalization block still runs". Hold and Resume are drawn only while the staged procedure is a Temporal one, because only a temporal window can be frozen; with nothing staged the whole set is drawn. |
| Notes under the commands | The last command this unit refused, then the station-wide and the unit's own reasons for not accepting run operations, while they hold. |

What Start validates and what each command does to the run are on
[Runs and comments](process-runs).

### Metadata {#metadata}

One entry per metadata field the staged procedure prompts, under the line "What the next
run of “Procedure” is recorded under. A field marked * is prompted by every procedure." A
manual field is a text entry, disabled without Run procedures; a sequential field is never
an entry but a prediction of the identifier the counter will reserve at Start (or
"Reserved at start" while it cannot be predicted), with a tooltip saying a shared counter
may move before then. With nothing staged the card reads "Stage a procedure and the fields
it prompts appear here." What you type is station-wide staging: another connection sees it
at once.

### Run state {#run-state}

Three readouts: **State** (the run's state, or "Preparing" while the unit is reserved,
"Idle" otherwise), **Cycle** ("2 / 10", or "Not cycling"), drawn only while the staged
procedure is Temporal, since only a temporal window repeats, and **Verdict** (the verdict
of the evidence so far, "None" when there is none). Nothing here is tinted.

### Comments {#comments}

The comment timeline of the unit's active run, headed by the line the timeline writes
about itself (which run, or that there is none). Each comment shows its time, its phase and
its text, with **Edit** (rewrite in place; Enter saves, Escape cancels) and **Delete** (the
first press arms the row with "Delete this comment? This cannot be undone." and the second
removes it). The **Add a comment…** box and its **Add** button append one to the active
run. All of them need Run procedures; a locked timeline stays readable and says the reason
on the gesture. The command answers on its own feedback line under the box.

### Occurrences {#occurrences}

The unit's active and recent occurrence episodes, headed by the list's own line. Each row
carries the occurrence's name, its status, how long it has been **Active**, a **Signal
loss** or **Signal unavailable** clock where the source dropped out, and its message. An
empty list says so. The episodes come from the model's [Occurrences](process-occurrences).

### Channels {#channels}

The unit's readable channels on one live chart, each series named the way the channel is
called on this unit (an alias shows live) and drawn in the colour and on the bands the
channel declares in [Channels](process-channels). The chart carries the standard row of
buttons a chart on a screen opens with (zoom into an area, reset the zoom, save and copy a
PNG, show or hide series, the tooltip and full screen) and a note under the drawing when
the retention it asked for could not be granted whole; what every button does is on
[Charts](view-charts).

### Productivity {#productivity}

Produced quantities, rates and the outcome ledger of the unit, under the line "Production
activity in today." or "Production activity in the last N hours." (or days). The head's
right side is the period: **Today** (since local midnight) or **Last N h** / **Last N d**,
the rolling window the model declares (or the unit overrides) in
[Productivity](process-productivity). The body is three readouts (**Productivity**,
**Yield**, **Typical elapsed**, each saying what it still misses instead of drawing a
placeholder: "No reference", "Not classified", "Not measured"), the **Output ledger** (one
row per output: name, quantity with its unit, and the rate per elapsed hour or "No elapsed
time"), the **Completion outcomes** tally (Finalized, OK, NOK, Inconclusive, Not evaluated,
Aborted, Failed) and a **By Procedure** disclosure with the same figures per procedure. A
model where no procedure contributes production says: "No Procedure contributes production
yet. Enable “Production output” on a Procedure to start these indicators."; a period with
nothing recorded says "No production recorded in today." (or in the window).

### Single commands {#single-commands}

"Fire one isolated command on this unit, outside a procedure." Each row is drawn only where
the model declares the library it fires from:

| Row | Controls | What it does | Greyed when |
|---|---|---|---|
| Snapshot | A datalog picker and **Capture** | "Record one datalog row now as a finished run in Histories": one row of the picked datalog becomes a born-finished run. | No Run procedures, the unit is busy (preparing, running, held or saving), the unit or the station refuses run operations, or a snapshot is already in progress. |
| Evaluate now | A datalog picker, an evaluation picker and **Evaluate** | "Snapshot one row and judge it against the evaluation now"; the verdict is recorded in Histories. Drawn only where the model has both a datalog and an evaluation. | The same as Snapshot. |
| Apply recipe | An instant recipe picker and **Apply** | "Write the recipe's setpoints once through the funnel (no run recorded)"; the journal is the record. Only Instant recipes are offered. | No Run procedures, the unit or the station refuses run operations, or an apply is in progress. It stays available while the unit is busy. |

While the unit is busy the card explains: "Snapshot and Evaluate are unavailable while this
unit is preparing, running, held or saving. Apply recipe stays available through a run, but
not while the interlock is holding the unit: a tripped chain, one waiting to be rearmed and
one whose reading is unavailable all refuse it." The outcome of each command lands in the
status bar's action feed ("Snapshot recorded. See Histories.", "Evaluated. The verdict is
recorded in Histories.", "Recipe applied.", or the refusal). The pickers start on the first
item of each library and keep your choice while the entry stays open.

### A screen as a card {#a-screen-as-a-card}

A panel may also carry one of the model's screens as a card, at the height chosen on the
panel (120 to 1200 px, 320 by default), headed by the screen's name. The card runs the
model's one screen definition resolved for this unit: every abstract channel answered with
the unit's own bound source. It scales to fill the card and never scrolls; the page does.
Its commands follow the Process rule above (Run procedures only), and a screen with
nothing on it is left out.

## A unit's screen on View {#a-units-screen-on-view}

A model's screen marked **Show on View** on its Dashboards row puts one entry per unit in
the same list, named `Model · Unit · Screen`. It is not a stack of cards: the stage runs it
on the canvas like any dashboard, resolved for its unit, with the status bar preference
and the icon chosen on the model's screen. Its commands need Run procedures only, seeing
it needs Look at models, and it is edited on the model's Dashboards row
([Dashboards of a model](process-dashboards)), where the same editor opens with the model's
abstract channels leading every address list.

## What a unit panel does not do {#what-a-unit-panel-does-not-do}

It is never edited, copied or reordered on View, never filed by the model (only by you,
one unit entry at a time), and never carries the Visible to checklist. It records nothing
on its own: a snapshot, an evaluation or a run is recorded through the Process services and
read back in [Histories](histories). And it never draws a card the station has nothing
for, so a card missing from the stack is a card with nothing to show, not a card turned
off.