Checkpoints

What a checkpoint is

A checkpoint is a mandatory control-plane re-evaluation boundary requiring renewed approval, revalidation, or both (governed_execution_spec.md §7).

It is not a UI construct. The control plane enforces the boundary. The TUI renders checkpoint_pending and forwards operator decisions.

Spec citation: governed_execution_spec.md GP-006, operator_interface_spec.md OI-002.

When checkpoints fire

Policy-triggered categories

governed_execution_spec.md §7.1 defines these mandatory checkpoint triggers:

capability transition to higher-risk class
path scope expansion
delegation requiring separate trust treatment
provider class change
policy boundary change
high-risk operation defined by policy

Trust-state categories

governed_execution_spec.md §7.2 adds trust-driven triggers:

first trust violation on any boundary resets that boundary to untrusted
trust-state conditions may force envelope invalidation, per-step approval, or execution halt

Checkpoint presentation

Before approval is recorded, operators must be shown canonical form, authorization scope, and reversibility class (operator_interface_spec.md INV-OI-001).

checkpoint_pending payload fields (operator_interface_spec.md §18.7):

checkpoint_type
trigger_description
canonical_request_summary
scope_delta
risk_classification
side_effect_class
policy_basis
authorization_statement
trust_state

The TUI does not derive these fields. It renders control-plane payload directly (operator_interface_spec.md INV-OI-010).

Operator responses

Key	Action	Control-plane effect
`y`	Approve	Sends `ApprovalDecisionMutation(decision: ALLOW)`; records `approval_decision`; may issue permit
`n`	Deny	Sends `ApprovalDecisionMutation(decision: DENY)`; denies continuation
`d`	Expand detail	Renders full canonical form, scope delta, trust snapshot
`i`	Inspect context	Opens context inspector
`?`	Help	Renders key-binding overlay

Irreversible actions require a second confirmation step. A single y is insufficient (operator_interface_spec.md INV-OI-009).

Multiple pending checkpoints are queued and resolved sequentially (operator_interface_spec.md INV-OI-008).

Checkpoint outcomes

Checkpoint resolution outcomes (governed_execution_spec.md §7.3):

continue under existing envelope
continue under modified envelope with renewed approval
shift to per-step approval
deny further execution
halt workflow and require operator action

Checkpoint frequency modes

syndicate run --checkpoint modes (cli_command_reference.md §6):

Mode	Behavior
`always`	Checkpoint before every tool invocation
`policy`	Policy-defined checkpoint boundaries (default)
`never`	No checkpoints for this run; policy may reject this override

--checkpoint never is a policy override and can require elevated trust tier authorization.

Headless checkpoint behavior

In --no-tui mode, mandatory human-approval checkpoints are denied. Command exits with code 2 and includes structured denial output (operator_interface_spec.md OI-008, INV-OI-006; cli_command_reference.md §6.1).

No silent bypass is permitted.

syndicate run <workflow-name> --no-tui --objective "<text>"
echo $?  # 2 means denied by policy/checkpoint

syndicate run <workflow-name> --no-tui --output json --objective "<text>" | jq '.denial'

Approval binding

Approval binds to executable canonical target, not a loosely similar request.

Core binding principles (canonicalization_binding_and_approval_spec.md §3):

CB-001: one stable meaning
CB-002: no hidden widening
CB-003: approval is valid only when execution remains within approved canonical target

A decision for one canonical form is not reusable outside that bound scope.