Approval Gates

Approval gates are human-in-the-loop checkpoints that suspend workflow execution until qualified reviewers make a decision. The gate bridge connects the BFSI compliance pipeline to the workflow executor's gate node system, enabling regulatory-grade approval workflows with audit-complete decision trails.

Gate lifecycle

A gate transitions through the following states:

pending → approved | rejected | escalated | timed_out

Gates start as pending when created. Once the required number of approved decisions is collected from actors with the required roles, the gate moves to approved. A single rejected decision immediately moves the gate to rejected. If no decision is reached within timeoutHours, the gate transitions based on the onTimeout configuration (escalate or deny).

Creating a gate

Gates are created by the workflow gate bridge when a stage transition occurs. You can also create gates via the API:

curl -X POST https://rensei.ai/api/approval-gates \
  -H "Authorization: Bearer rsk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "issueId": "issue_...",
    "name": "Deploy Approval",
    "requiredRoles": ["tech-lead", "devops-lead"],
    "requiredCount": 1,
    "timeoutHours": 4,
    "onTimeout": "deny"
  }'

Submitting a decision

Reviewers submit decisions via the approval UI at /approvals or the API:

curl -X POST https://rensei.ai/api/approval-gates/<gateId>/decision \
  -H "Authorization: Bearer rsk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "actorId": "user_alice",
    "actorType": "human",
    "actorRole": "tech-lead",
    "decision": "approved",
    "reason": "Risk assessment reviewed, approved for production deployment"
  }'

Valid decision values: approved, rejected, escalated.

The API validates that actorRole is in the gate's requiredRoles list. A decision from an unqualified role is rejected with 403.

Escalation

When a gate times out with onTimeout: 'escalate', an approval.gate_escalated event is emitted and the gate status becomes escalated. The escalation service routes the gate to the configured escalation path (typically a Slack notification to a senior approver or CAB chair).

Agent signals

The gate bridge translates gate resolution status into four workflow executor signals:

These signals are consumed by the workflow gate node executor. See Workflow Gates for how gate nodes handle these signals and resume suspended instances.

Gate status check

Check the current resolution status of all gates for a stage:

curl "https://rensei.ai/api/approval-gates?issueId=issue_...&stage=deploy" \
  -H "Authorization: Bearer rsk_live_..."
# Returns:
# {
#   "signal": "waiting",
#   "pendingGates": ["gate_xyz"],
#   "resolvedGates": [{ "id": "gate_abc", "status": "approved" }]
# }

Stage bridge: connecting to workflow executor

When an agent transitions to a new BFSI pipeline stage, the gate bridge looks up the stage definition in the standard or emergency pipeline configuration, creates all required gates for that stage, and emits a factory.bfsi.stage_transition event. If gates are created, the workflow instance is suspended with a gate.waiting signal until all gates resolve.

Audit trail

Every gate lifecycle event is appended to the audit chain:

All events include the gate ID, issue ID, actor ID and role, decision, and a timestamp. These records satisfy audit requirements for SOX change-management documentation.

Viewing pending approvals

Platform members with the approvals:read permission can view all pending gates for their org at /approvals. The approval inbox shows:

• Gate name and type
• Required roles and approval count remaining
• Time remaining before timeout
• Linked issue or workflow instance
• Approve / Reject / Escalate actions (gated by role membership)

Related pages

• BFSI Compliance - risk scoring, pipeline definitions, tenant tier
• Workflow Gates - gate node suspension and signal handling in the executor
• Cedar Policies - Cedar policy checks on gate decisions
• Audit Trail - hash-chain records for every gate event