Manifests and tickets

Work in a Works has two sizes. A piece of work large enough to be worth planning is a manifest — an initiative, with an outcome and a shape. The tasks underneath it are tickets, and a ticket is the unit an agent is actually handed.

The split exists so that a plan can be reviewed once, at the size where review is cheap, and then executed many times without a human re-approving each step.

The states

A ticket moves through four states, and it cannot skip one:

open → latched → complete → landed

An initiative moves through four of its own:

draft → active → landed → reckoned

Every transition is validated before it is written. An initiative with open tickets under it cannot land. A ticket cannot be assigned to a seat that is not on the roster. The rules are enforced where the state lives rather than in whatever surface asked for the change, so the desktop and the command line cannot disagree about what is allowed.

Latching

Between open and someone is doing it there is a queue. Assigning a ticket to a specific seat puts it in that seat's queue — hm calls this latching — and the ticket stays latched until the work is complete or the assignment is released.

Latching is deliberately a separate step from executing. It is the moment a piece of work acquires an owner, and it is a moment worth being able to point at: the record shows when a task acquired an owner, which is a different question from when the work started.

Why a ticket ends twice

Complete and landed are not the same event. Complete means the worker says the task is done. Landed means the finished work has been integrated and the record has closed over it.

Keeping the two apart is what stops a self-reported completion from being the last word. An agent can mark its own work complete; it cannot land it.