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 pipeline to the workflow executor's gate node system and emits audit records from the implemented gate lifecycle paths. Those records are tamper-evident when checked as a supplied segment; they are not a capture-completeness or regulatory-compliance guarantee.

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:

Signal	Meaning
`proceed`	All gates approved - workflow execution may continue
`halt`	At least one gate rejected - workflow is aborted
`rework`	Rejection requires rework before resubmission
`waiting`	Gates are still pending - workflow remains suspended

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

The implemented gate lifecycle paths emit the following audit event types:

Event	Trigger
`approval.gate_created`	`createGate()`
`approval.decision_submitted`	`submitDecision()`
`approval.gate_resolved`	Gate reaches terminal state
`approval.gate_escalated`	Timeout with `onTimeout: 'escalate'`

The emitted records include gate, issue, actor, role, decision, and timestamp context where supplied by the path. They can contribute to change-management evidence, but their presence alone does not prove that every lifecycle action was captured or that a SOX control is satisfied.

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)

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 emitted by gate paths, explicit verification, and proof limits

On this page