Governance & Approvals

Transitions over raw strings

The safety model evaluates transitions such as run admission, stage advancement, lane retry, rebind, compensation entry, blocked-to-resumed, and final disposition. A shell command string may be one input, but it is never the whole decision.

Why this is better: the same command can be low-risk in one context and dangerous in another depending on concurrency, target scope, sandbox posture, retries, and provenance continuity.

Risk and blast radius

Risk is structural rather than cosmetic. tamux considers dimensions such as:

destructiveness
scope
reversibility
privilege
externality
concurrency

Blast radius is compositional: lane-local, stage-wide, and run-wide.

Structured verdicts

Verdict class	Meaning
`allow`	Proceed normally
`allow_with_constraints`	Proceed, but only under declared limits
`require_approval`	Operator approval is required
`defer`	Execution cannot proceed yet
`deny`	Execution must not proceed
`halt_and_isolate`	Stop and isolate the work
`allow_only_with_compensation_plan`	Proceed only with explicit mitigation obligations

Binary allow/deny is too weak for real orchestration.

Approval semantics

Approvals are bound to actual execution conditions rather than treated as permanent permission slips. A valid approval is expected to bind to:

run or transition scope
target scope
risk rationale
attached constraints
freshness/expiry semantics
policy fingerprint

If the target set, privilege posture, command family, or environment facts materially change, prior approval should be considered stale.

Provenance as a dependency

The safety model explicitly treats provenance quality as a blocking dependency for side-effecting work. If the system cannot prove enough about who initiated the action, what policy inputs were evaluated, what verdict was returned, what approval authorized it, and what actually ran, governance should block advancement.

Critique before action

tamux includes an adversarial self-critique subsystem with advocate, critic, and arbiter roles. This lets the runtime challenge risky plans before execution, rewrite them into safer variants, or require explicit operator confirmation when risk remains high.

This is not just prompt style: critique has explicit runtime behavior and retrievable session state.

Containment and compensation

tamux safety is designed to express honest outcomes such as blocked, compensated, partially compensated, or isolated. This is important because autonomy often fails in partial, recoverable, or risky ways that should not be flattened into one generic error state.

Why this matters in multi-agent work

It keeps multiple agents from silently escalating one another’s scope.
It binds approvals to real execution posture rather than vague intent.
It makes risky work reviewable and auditable.
It supports operator trust by showing the reasons behind blocked or constrained transitions.
It prevents “autonomy” from becoming invisible recklessness.

Operator expectation

Operators should expect safety to show up as structured friction at the right moments: approval gates, critique retrieval, risk labels, provenance-aware explanations, and honest blocking behavior. In tamux, that friction is part of the product, not an accidental obstacle.