# Handoff signals > A handoff is an item addressed to the parties that need it, with an allocated id, a declared kind and a closure the kind selects, as written in [an item] and… Page: PAG · Orchestration Canonical: https://banes-lab.com/pag/orchestration#handoff-signals This section is stop 85 of 102 in the learning route. Previous: [04 - Phase binding](https://banes-lab.com/pag/orchestration/phase-binding.md). Next: [06 - Orchestration invariants](https://banes-lab.com/pag/orchestration/orchestration-invariants.md). It builds on [03 - Shared surfaces](https://banes-lab.com/pag/orchestration/shared-surfaces.md). A handoff is an item addressed to the parties that need it, with an allocated id, a declared kind and a closure the kind selects, as written in [E1·a an item](https://banes-lab.com/pag/orchestration#handoff-signals-panel-a) and shown in [E1·d kind selects closure](https://banes-lab.com/pag/orchestration#handoff-signals-panel-d). An artifact item asks for something that can exist, and it closes when a typed reference to that thing resolves. A judgement item asks for a reading, and it closes when its acknowledger marks it; [E1·c closing an item](https://banes-lab.com/pag/orchestration#handoff-signals-panel-c) shows the closure in either case. A failure is a finding rather than a halt, and it follows the route shown in [E1·b failure routes](https://banes-lab.com/pag/orchestration#handoff-signals-panel-b) and [E1·e failure to finding](https://banes-lab.com/pag/orchestration#handoff-signals-panel-e). A report goes to the parties whose next work it creates, never to the developer as a closing summary. ### Typed items, falsifiable closures A handoff closed by the party that wrote it closes whether or not the work exists. A party declares an item handled, nothing points at the thing it asked for, the item is removed, and the work it named was never done. A closure that a reference decides can be checked by any party, while a closure that a party declares can be checked only by that party. For this reason a handoff is a typed item whose closure can be checked by a party other than its author. The kind decides the closure, either a reference that has to resolve or an acknowledger named on the item, rather than the author's word that the work is done. In practice, a handoff is posted as an item with an id the surface allocates, a kind, the parties it is addressed to, and a body carrying the finding's surface, location, and observed and expected values. An artifact item closes through a reference that has to resolve and stay true while the work is done, and a judgement item closes through its acknowledger. A failure is routed by what it binds: a decision goes to the party whose surface it binds, a question about the purpose of the work goes to the developer with a recommendation first, and everything else goes to the next open item. To check this, name for each closed item the reference that closed it or the party that acknowledged it. An item that its own author closed with no reference was declared done, not shown to be done. The handoff protocol is for parties that share a surface; what a bounded reader does instead is described in [composing a collaboration](https://banes-lab.com/pag/orchestration/composing-a-workflow.md). The kind is on the item, and it selects the closure. An artifact item names something that can exist, such as a file, a gate or a record, so it closes with a typed reference that has to resolve. The reference names a condition that can turn out wrong rather than a path, because a path resolves as soon as the file exists, and the item would read as closed while the defect is still open. The reference also moves with the work: it is true when the work is done and false when it is not, so a citation that points at the findings themselves is refused, since a broken tree would satisfy it. A judgement item closes when its declared acknowledger signs it off, with no reference, and why one kind requires an acknowledger and the other forbids one is explained in [the board and the venue](https://banes-lab.com/disciplined-methodology/collaborate/the-board-and-the-venue.md). A failure travels through the same channel as any other item and is routed along the same three paths, as derived in [a turn never ends to wait](https://banes-lab.com/disciplined-methodology/collaborate/a-turn-never-ends-to-wait.md). A gate's result line is the same routing in miniature, with a third arm that the item channel also needs. An unknown, meaning a claim the run could not measure, is blocked rather than passed, and blocked is a state that names the party who owes the answer. The commit node carries the rule that a report goes to the parties whose next work it creates. The handler removes the item by its id, after extraction, as the board and the venue requires. An item whose readers have all gone is re-addressed rather than left, because an item that no party can handle reads as live traffic forever. E1·a an item ```pag # an item is a typed span · its kind selects how it closes, and the closure is checked by a party other than its author DECLARE item: object SET item = { id: , kind: , from: , to: [], body: {surface: , locus: , observed: , expected: } } FUNCTION closes(item): # an artifact item asks for something that can exist · it closes when a typed reference resolves IF item.kind == artifact: RETURN resolves(item.satisfied_by) AND monotone_with_the_work(item.satisfied_by) # a judgement item asks for a reading · it closes by its declared acknowledger, with nothing to point at IF item.kind == judgement: RETURN acknowledged_by(item.acknowledger) FUNCTION may_close(party, item): RETURN party IN item.to # a reader, never the author ``` E1·b failure routes ```pag # a failure is a finding, not a halt · it flows through the same channel and routes by what it binds FUNCTION route(failure): SET finding = {surface: failure.surface, locus: failure.locus, observed: failure.observed, expected: failure.expected} IF failure.blocks_a_decision: RETURN SEND finding TO IF failure.asks_what_the_work_is_for: RETURN SEND finding TO AS RETURN # NODE 9 — COMMIT [evaluative · representation · information-theory · yields: one typed artifact] CONTRACT: input: findings + run_context transform: emit exactly one artifact of the kind bound at orientation, deduplicated, naming every limitation constraints: a report goes to the parties whose next work it creates, never to the developer as a closing summary output: committed { artifact_type, output } handoff: one typed artifact emitted (yields: hash + boolean) HANDOFF GATE (evidence-bearing): rule_id: "COMMIT" yields: hash + boolean [check] exactly one artifact emitted, of the kind bound at orientation (evidence: committed.artifact_type) [check] every finding addressed to a party that needs it (evidence: findings[].to) over: findings measured: / [check] no finding recorded twice (evidence: dedup) refuse: the artifact's destination changed since it was read before PERSIST_ARTIFACT result: pass → NODE 10 | duplicate or unaddressed → REPAIR (owner: NODE 9) | unknown → BLOCKED ``` E1·c closing an item ```pag # closing an item · the handler removes it, never the author, and extraction comes first WHEN handles : VALIDATE IN . VALIDATE closes() EXTRACT_FACTS . INTO PERSIST_ARTIFACT TO REMOVE BY . # the span, never a matched line ``` E1·d kind selects closure ```mermaid flowchart TB posted["An item is posted · id allocated, kind set, readers named"] kind{"Which kind?"} artifact["Artifact · closes when its reference resolves"] judgement["Judgement · closes when its acknowledger marks it"] handler["Removed by a party in its reader set · never its author"] extract["Its durable half extracted first"] posted --> kind kind -- artifact --> artifact --> handler kind -- judgement --> judgement --> handler handler --> extract ``` E1·e failure to finding ```mermaid flowchart LR fails["A gate fails"] finding["A finding · surface, locus, observed, expected"] binds{"What does it bind?"} owner["The party whose surface the decision binds"] person["The developer · what the work is for, a recommendation first"] next["The next open item"] fails --> finding --> binds binds -- a decision --> owner binds -- the purpose --> person binds -- nothing --> next ``` ## Links to - [Composing a collaboration](https://banes-lab.com/pag/orchestration/composing-a-workflow.md) - [The board and the venue](https://banes-lab.com/disciplined-methodology/collaborate/the-board-and-the-venue.md) - [A turn never ends to wait](https://banes-lab.com/disciplined-methodology/collaborate/a-turn-never-ends-to-wait.md) ## Linked from - [Ask where it appears](https://banes-lab.com/disciplined-methodology/plan/ask-where-it-appears.md) - [The board and the venue](https://banes-lab.com/disciplined-methodology/collaborate/the-board-and-the-venue.md) - [A turn never ends to wait](https://banes-lab.com/disciplined-methodology/collaborate/a-turn-never-ends-to-wait.md)