Governance and Approvals

    ByteOr enforces policy-gated governance for production deployments and replay execution. This page explains the governance model, how approvals work, and what the platform verifies.

    Governance Model

    Governance in ByteOr is environment-scoped. Each environment defines its posture:

    • Which actions require approval
    • What capabilities must be covered
    • Whether dry-run replay is allowed without approval
    • Whether execute-mode replay requires elevated coverage

    The governance model is not a single global policy. It is a per-environment decision that the platform enforces consistently.

    Approval Credentials

    Approvals are cryptographic credentials that bind:

    • A spec hash — the exact pipeline version being approved
    • An environment — the target deployment or replay environment
    • A scope — the set of capabilities being authorized
    • An expiry — time-limited validity
    • A signing key — verified against known key sets

    Verification Rules

    The platform rejects approval credentials when:

    • 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

    These verification paths are release-blocking test coverage.

    Deployment Approvals

    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 Approvals

    Execute-mode replay reuses deployment-style approval 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 be used for investigation without execute privileges.

    Audit Trails

    Every approval-sensitive action creates audit records answering:

    • Who initiated the action
    • What environment and project were affected
    • Whether approval was required
    • Which approval was provided
    • Which capabilities were required

    Audit records are immutable once written. Missing audit trails for approval-sensitive actions are treated as product defects.

    Operational Guidance

    • Prefer short-lived approvals over broad standing coverage
    • Use dry-run replay first when investigating incidents
    • Verify the spec hash and environment before requesting approval
    • 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.
    Source-of-truth modelRepo docs index