Handbook
Approval Model
Approval is not chat memory. Approval is a record in the Forge Run Spine, visible in Lenses.
Updated
Approval modes
readonly
inspect state only.
proposal
generate plans, artifacts, handoff packs, and evidence drafts.
operator
submit approved Fleet template jobs and create Lenses records.
sandboxed_implementation
perform bounded implementation work in a controlled workspace.
Approval lifecycle
Approval request lifecycle
How a bounded action moves from request through human review to execution, evidence, and a traceable decision—or a terminal alternative.
- requestedAn operator or agent submits a bounded action for human review.
- approvedA human with the required role accepts the proposed action.
- executedThe approved action runs within its stated constraints.
- evidence_readyExecution artifacts and evidence refs are captured for review.
- decisionThe run closes with a traceable outcome recorded on the spine.
- rejectedA reviewer declines the request; the action does not run.
- deferredReview pauses until more context or a later time window.
- expiredThe request times out under expiration or revocation rules.
requested -> approved -> executed -> evidence_ready -> decision
requested -> rejected
requested -> deferred
requested -> expiredApprovalRequest must include
approval_id,forge_run_id,- requested action,
- risk level,
- required role,
- constraints,
- evidence refs,
- expiration or revocation rules when applicable.
Rule
Approval is not chat memory. Approval is a record in the Forge Run Spine, visible in Lenses.
For Self-Host Alpha, scripts/selfhost_runner.py requires an on-disk forge.approval_request.v1 in approved state whose action field gates the allowlisted action_id (for example local_runner:check_foundation). Chat transcripts are never sufficient approval for execution.