Approval Workflow Guide

ByteOr Cloud uses approval coverage to gate risky deployment and replay actions.

When approvals matter

Approvals are required when the target environment posture or action type demands governed execution.

Typical cases include:

  • production deployments
  • execute-mode replay against governed environments
  • actions that require named capabilities or policy coverage

Core operator flow

  1. Prepare the pipeline version and config bundle.
  2. Start the deployment or replay action.
  3. Review the environment, spec hash, and required capabilities.
  4. Select an eligible approval or obtain one from an authorized reviewer.
  5. Submit the action with the approval attached.
  6. Confirm the audit trail records the actor, scope, and decision.

What the platform validates

Approval verification rejects requests when any of the following are true:

  • the signing key is unknown
  • the signature is invalid
  • the approval does not match the spec hash
  • the approval targets the wrong environment
  • the credential has expired
  • the capabilities are insufficient for the requested action

These rejection paths are covered in backend test suites and should remain release blockers for future approval changes.

Deployment guidance

Before approving a deployment, verify:

  • the pipeline version is the expected canonical build
  • the config bundle matches the intended environment
  • the deployment target environment is correct
  • the approval scope covers the deployment action

Replay guidance

Execute-mode replay reuses deployment-style approval coverage checks. Reviewers should confirm:

  • the source artifact came from the expected environment
  • the resolved pipeline version matches the incident spec hash
  • the approval scope is valid for replay execution

Dry-run replay can still be used for investigation without granting execute privileges.

Audit expectations

Approval-sensitive flows should create audit records that make it possible to answer:

  • who initiated the action
  • what environment and project were affected
  • whether approval was required
  • which approval was provided
  • which capabilities were required

Operator checklist

  • verify environment and project before requesting approval
  • verify the spec hash or version being approved
  • prefer short-lived approvals over broad standing coverage
  • use dry-run replay first when investigating incidents
  • review audit records after high-risk actions
Provenance
Need the canonical source?
Use the public hub to orient yourself, then jump to repo-owned docs or rustdoc when you need contract-level detail.