# Emitting labels and reports

> What a run emits at Start and at Completion, in which order, through which queue, what is frozen into the run file, and how every delivery is recorded.

A run emits its paperwork through the **actions** of its model: named groups of commands,
each command emitting a label or a report at the run's Start or at its Completion,
declared under Setup > [Actions](process-actions) and selected by the
[procedure](process-procedures) as whole groups. The templates the commands render with
are the two libraries of this root: the layout of a report command comes from
[Reports](process-reports), the file of a label command from [Labels](process-labels).
This page is what happens once a run reaches a boundary.

## The two boundaries {#the-two-boundaries}

At a boundary the commands fire in the model list's order across the selected groups and
in each group's own order within it, the labels before the reports. Every command is
isolated: a missing template, a composition that throws or a queue that refuses is
journaled, changes nothing about the run and never stops the commands behind it.

| Boundary | When | What is available | What is emitted |
| --- | --- | --- | --- |
| Start | As the run materializes, after the sequential counters are reserved and the metadata is written; the run is already recording while the documents compose, through the run's own open file. | The run's identity, the metadata, the start instant and the state Running. | Every label command with the trigger Start; every report command with the trigger Start and a layout: a travel sheet on which the sections with no evidence yet are left out and the Recipe row prints the planned recipe. |
| Completion | After the run's terminal state and snapshot are sealed and the unit is released; the labels first, the reports in the background right after. | Everything at Start plus the finish instant, the duration, the terminal state, the verdict, the termination reason and the judged criteria. | Every label and report command with the trigger Completion whose verdict filter admits the run's verdict. |

The verdict filter (OK, NOK, Indeterminate, No verdict) is read only at Completion; at
Start there is no verdict yet. A run that ended Failed has no terminal snapshot: its
completion labels record a failed artifact and no completion report is published. A report
command whose layout was deleted, and a report command with no layout, publish nothing.
Restarting the application never repeats Start documents: a run resumed after a restart
carries the artifacts it already emitted.

## Reports {#reports}

A report command with a layout publishes its PDF at its boundary whatever else it asked
for. The file is named after the run's export base plus the group's name
(`<base> - <group>.pdf`), so the travel sheet and the closing report of one run stand side
by side; two groups whose names would land on the same file are told apart by the
command's identity. A later render of the same command replaces that command's document
and nothing else. The two options of the command decide what happens to the document:

| Option | Effect |
| --- | --- |
| Print automatically | The published PDF is also submitted to the report queue in force for the unit for that boundary. A unit with no queue in that slot records the attempt as failed ("No printer queue is configured for this action on the Unit."). |
| Keep a copy inside the run | The finished PDF is stored in the run file, so a later resend submits those exact bytes even after the layout is edited or deleted, or the published file was replaced by a later render. The run then carries the document's size. |

A command that asked for either one registers the document on the run (the registration
Histories lists under **Report**); a command that asked for neither publishes the file and
registers nothing, because generation is an export of the run file and never a write to
it.

## Labels {#labels}

A label command renders its template with one source per marker. At Start only the
sources committed at accepted Start resolve: the metadata, the model name and revision, the
unit name and code, the procedure name and code, the run identifier, the start instant and
the run state; a marker mapped to anything else refuses the Start label ("Marker
'{{RESULT}}' is not available when a run starts."). At Completion the whole catalogue
resolves, a criterion result by its stable identity and an explicit cycle (a missing cycle
never means "latest").

Every generation first appends an immutable **artifact** to the run file: the final
command bytes, the template's name, source file and content hash, the group's name, the
trigger, the resolved values with their sources, or the reason no commands could be
generated. Then the bytes go to the label queue in force for the unit for that boundary as
a RAW document named `Ganter Lab · <group>`. A unit with no queue in that slot records a
failed attempt ("No printer queue is configured for this label on the Unit."); a template
that is gone records "The configured label template is missing.". Every delivery attempt
is appended to the artifact: **Sending** before the spooler is called, then **Sent to
queue** or **Failed**; an attempt the app stopped in the middle of stays **Send
uncertain** and is never retried automatically, because the printer may already have
produced the label. "Sent to queue" confirms that Windows accepted the payload, not that
paper came out.

## Printers {#printers}

Which queue a document lands in is decided on Definition > [Printers](process-printers):
the model declares four default slots, one per combination of what is emitted and when
(label or report, at Start or at Completion), and each unit follows the model's four or
keeps four of its own. A command resolves its destination by its own kind and trigger,
through the model for a following unit and through the unit's slots for a detached one, so
a group two procedures share prints through one destination picked once. Queues are the
Windows printer queues installed for the user the station runs as; a label goes out as RAW
bytes, a report is rasterized and drawn onto the device, so an ordinary document printer
serves the reports and a label printer the labels.

## Afterwards {#afterwards}

Everything a run emitted is read on its record in Histories ([Labels and
reports](histories-documents)): the artifacts, the registrations and every attempt with its
status. There the pair of gestures is the same for both media: a **new** document from the
run's frozen evidence (a new label with a configured command or a template mapped by hand,
a new PDF with any layout), and the **reissue** of a recorded one (a reprint of an
artifact's frozen bytes, a resend of the registered PDF), which resolves nothing again.

## What emission does not do {#what-emission-does-not-do}

It never reads a live value: a label resolves only what the run file froze, and a report
renders only from the file. It never changes a run: a document failure leaves the verdict,
the state and the file exactly as they were. It never confirms printing. And it never
emits for a snapshot or an evaluate-now run, which carry no procedure and no actions.