Skip to main content
Every improvement — no matter how confidently proposed — passes through approval before touching production. The gates are configurable per Flow.

​
The approval queue

Reliable → Approvals shows all pending approvals across the workspace:
  • What’s being approved — improvement candidate, its diff, its simulation results.
  • Who requested — the person or process that submitted it.
  • Who can approve — the eligible reviewers for this Flow.
  • Since when — how long it’s been waiting.
Sort by age, by Flow, by size of change.

​
The approval view

For each item:
  • Summary — one line describing the change.
  • Diff — line-level view of what would change in the Flow config.
  • Simulation — before/after against the dataset. Pass rate, regressions, cost delta.
  • Rationale — the root cause note that triggered this improvement.
  • History — prior similar improvements and their outcomes.
  • Rollback plan — what would happen if this is rolled back.
Approve, reject with reason, or request changes.

​
Gate configuration

Per Flow, choose:
  • Auto-approve — no human gate. Only recommended for low-risk levers (rules, minor prompt clarifications) with strong simulation results.
  • Single approval — one eligible reviewer.
  • Multi-sign — two or more reviewers, different people.
  • Role-restricted — only Owners or Managers can approve.
Configure under Flow settings → Approvals.

​
Approval routing

For workflows integrated with external systems:
  • Slack approval — the approval appears as a Slack card with Approve/Reject buttons. Signed action.
  • Email approval — one-time link.
  • Webhook approval — POST to your custom review system; it POSTs back with the verdict.
Set the routing under Flow settings → Approval webhook.

​
Approval SLAs

Set a per-Flow SLA: approvals auto-escalate (notify additional reviewers) or auto-fail (marked rejected) after N hours. Common patterns:
  • 1-hour SLA for a well-staffed team on-hours.
  • 24-hour SLA for less time-sensitive Flows.
  • Auto-reject after 7 days for anything stale (forces re-submission with fresh sim results).

​
The deploy step

Once approved, three deploy options:
  • Apply to Draft — the diff lands in Draft; you (or automation) publishes when ready.
  • Publish immediately — the change goes to production as soon as approved. Skips the manual publish step.
  • Canary rollout — the change goes to a small % of production traffic first (see below).
Configure per improvement (or per Flow default).

​
Canary rollout

For high-stakes improvements:
  1. Publish, but only route N% of traffic to the new version.
  2. Watch signals on the canary traffic for 24-72 hours.
  3. If clean, roll to 100%. If signals fire, auto-rollback.
Percentages: 1% → 5% → 25% → 100% is a common progression. Route by scope key (users, tenants) so a given user consistently hits one version. Prevents flip-flopping.

​
Rollback

Every deployed improvement has one-click rollback (see Rollback). Rollback is atomic — the whole improvement, not just parts. Approvers can pre-authorize rollback (auto-rollback when a specified signal fires) so no manual intervention is needed if things go wrong.

​
Audit

Every approval, rejection, request-for-changes, and deploy is logged with actor, timestamp, IP, and any comments. Exportable for compliance reviews.