oz0 replay

Usage and flags for oz0 replay.

For: Operators and developers looking up a command.

A replay decides the tenant's recently finished jobs again under one candidate change: a tool-policy document, shadow rules to promote, a preset (a shipped one, or a proposed level change as rules), or budget and tree limits. Every model response and every tool result comes from the job's recorded history: no model and no tool is called, and nothing is spent.

What runs live is the governance: the tool policy with its conditions, shadow rules and presets, the taint-default rule, origin and sequence rules, grants, and budgets recomputed from the recorded usage.

For each job the report gives the first decision the candidate changes. Everything after it is unknown, since the agent would have acted differently from there, and counts neither as changed nor as unchanged. Each job is first replayed under the policy it ran with; a job whose record that does not reproduce is listed as 'replay disagrees' and left out of every count.

The coverage line always says what was read and what was not: jobs of an erased data subject, past the history retention, unreadable, not replayable, and sessions whose own tools never reach the workflow.

The edge, which holds the tenant's payload keys, opens the histories in memory; the report holds counts, job and call IDs, function names, rule IDs and verdicts, never an argument or a result. Starting a replay needs governance.write and the content permission; reading one needs governance.read.

Usage

oz0 replay [command]

Subcommands

Inherited flags

FlagTypeDefaultDescription
--contextstring$OZ0_CONTEXT or <config dir>/orchestrator-zero/context.jsonCLI context file written by server init
--log-levelstringinfolog level: debug, info, warn or error

See all oz0 commands and the global flags.

Copyright © 2026