#Policy and Approvals

byteor-policy is the enterprise guardrail layer. It keeps the decision process explicit: given an environment, a replay posture, a dry-run flag, and an action capability, the runtime can explain whether execution is allowed.

#Safe defaults

The workspace default posture is intentionally conservative:

• dev: side effects may be allowed for iteration.
• staging and prod: side-effecting actions are expected to require approval.
• replay defaults toward dry-run safety rather than silent live execution.

#Decision model

The policy engine distinguishes between:

• replay policy: disabled, dry-run only, or allowed,
• side-effect policy: deny all, allow all, or require approval,
• action capability: side-effecting or non-side-effecting.

That yields an explicit decision such as Allow, DryRunOnly, RequireApproval, or Deny.

#Practical approval flow

For operator purposes, the flow is:

1. validate the target spec and environment,
2. acquire an approval credential scoped to that spec and environment,
3. verify the credential before runtime execution,
4. pass the verified approval into the runtime surface,
5. capture policy audit artifacts alongside execution artifacts.

The credential shape itself is documented in ../spec/approval-credentials-v1.md.

#What to treat as authoritative now

• Environment names and path conventions come from byteor-core.
• Decision semantics come from byteor-policy.
• Runtime artifacts such as policy audit records come from byteor-runtime and byteor-replay.

If a historical SaaS document says something broader than the code-backed contracts above, the current runtime behavior wins.