Variant Templates

Beyond the default SDLC template, Rensei ships three additional SDLC templates for teams with different pipeline shapes or compliance requirements. All variants share the same subscription model as the default - subscribe a project, publish, and the template fires on matching events.

Template comparison

Template	Slug	Best for	Tracker	Gate-protected
SDLC v2 (default)	`sdlc-v2`	General-purpose engineering teams	Linear + GitHub Issues	No (optional via canvas)
SDLC Loop	`sdlc-loop`	Single-tracker orgs, linear pipelines	Linear or GitHub	No
SDLC BFSI	`sdlc-bfsi`	Financial services, regulated orgs	Any	Yes - segregation of duties
BFSI Model Risk	`sdlc-bfsi-model-risk`	Orgs needing model-invocation risk controls	Any	Yes - model risk tiering

SDLC Loop (`sdlc-loop`)

The Loop template models the pipeline as a linear sequence: trigger → guard block → research → develop → code review → approval gate → QA → deploy → close. It is simpler than the v2 default and does not support dual-tracker routing or per-role capability fan-in.

When to use

Teams running a single issue tracker who want a straightforward sequential pipeline without the v2 routing complexity.
Projects where every issue follows the same path with no branching on workType.
Proof-of-concept deployments where the full v2 template's node count is more than needed.

Pipeline stages

Issue Assigned - the issue.assigned webhook (Linear or GitHub) fires the trigger.

Guard Block - four condition nodes run in sequence:

agent.session.status - blocks if a session for this issue is already active
agent.session.failure_backoff - blocks if the issue has recent failure history
Dispatch-count cap guard - blocks if the org has hit its concurrent dispatch limit
Circuit breaker - blocks if the issue has exceeded the max-retry threshold

Research and Plan - dispatches a research agent that reads the codebase and writes an implementation plan.

Develop - dispatches a development agent that implements the plan, creates a branch, and opens a PR.

Code Review - dispatches a code-review agent that reviews the open PR for correctness and style.

Approval Gate - a gate.human_query node pauses the workflow pending human approval. Default timeout: configurable (no auto-approve in this template by default).

QA Validation - dispatches a QA agent that validates the implementation against the acceptance criteria.

Escalation (branch) - if QA fails, routes to a human-escalation annotation node.

Deploy - dispatches a deploy agent (GitHub push or provider-specific deploy action).

Close Issue - closes the Linear issue or applies the sdlc/accepted GitHub label.

GitHub variant

A separate sdlc-loop-github YAML ships alongside sdlc-loop for teams using GitHub natively (GitHub Issues trigger instead of Linear). The two variants are functionally equivalent; the GitHub variant replaces the Linear issue.assigned trigger with github_issues.issue.assigned and uses GitHub labels for state transitions.

Installing

Variant templates are installed by an operator from a platform checkout via the marketplace install engine (there is no self-serve install UI or rensei CLI command yet):

pnpm tsx scripts/install-template.ts sdlc-loop@<version> --org <org-id> --project <project-id>

Or via the API: POST /api/templates/sdlc-loop/install/{version} with a { "projectId": "..." } body.

SDLC BFSI (`sdlc-bfsi`)

The BFSI template adds segregation-of-duties (SoD) gates before every regulated dispatch verb. It is designed for teams operating under financial-services regulatory frameworks (SR 11-7, SOC 2, ISO 27001) that require independent review of each pipeline stage.

The BFSI template requires the bfsi provider to be configured for the org. See BFSI Compliance Overview for the full setup guide.

Gate structure

Every regulated stage (Development, Security Validation, QA, Acceptance, Deploy) is preceded by a gate node whose predicate is bfsi.segregation.evaluate:

- id: bfsi_dev_gate
  type: gate
  name: SoD Gate - Development
  config:
    predicate: bfsi.segregation.evaluate
    verbId: bfsi.development.dispatch
    proposedStage: Development
    actorId: "{{ trigger.data.actorId }}"
  gateConfig:
    gateType: signal
    signalEventType: bfsi.gate.decision
    timeoutMs: 3600000
    onTimeout: escalate
  branches:
    allow: bfsi_dev_dispatch
    deny: bfsi_dev_rework

The gate predicate reads the proposed stage assignment, consults the accumulated upstream assignments for this pipeline run, and routes to:

allow - the dispatch verb executes normally.
deny - the workflow routes to a bfsi_*_rework terminal annotation node. The run ends; a human must re-queue the issue with a different actor assignment.

Regulated stages

Stage	Gate ID	Governed verb
Development	`bfsi_dev_gate`	`bfsi.development.dispatch`
Security Validation	`bfsi_secval_gate`	`bfsi.security_validation.dispatch`
QA	`bfsi_qa_gate`	`bfsi.qa.dispatch`
Acceptance	`bfsi_accept_gate`	`bfsi.acceptance.dispatch`
Deploy	`bfsi_deploy_gate`	`bfsi.deploy.dispatch`

Timeout behavior

All BFSI gates default to a 1-hour (3600000 ms) signal timeout with onTimeout: escalate. When a gate times out without receiving a bfsi.gate.decision signal, the workflow routes to the escalation ladder rather than auto-approving or auto-denying. This ensures no regulated stage executes unreviewed.

Installing

The BFSI template is not installed by default. An operator must explicitly install it:

pnpm tsx scripts/install-template.ts sdlc-bfsi@<version> --org <org-id> --project <project-id>

Ensure the bfsi provider is configured first - attempting to install without it will surface a PROVIDER_NOT_CONFIGURED validation error at subscription time.

Stacking with the default template

A common pattern for BFSI teams is to disable the default sdlc-v2 template and install sdlc-bfsi as the sole SDLC template for regulated projects. Non-regulated projects in the same org can retain sdlc-v2.

For the regulated project: toggle sdlc-v2 to Unpublished in the Workflows → System Templates panel (or PATCH /api/projects/{projectId}/workflow-subscriptions - see Template Subscriptions), then install the BFSI template:

pnpm tsx scripts/install-template.ts sdlc-bfsi@<version> --org <org-id> --project <project-id>

Non-regulated projects need no change.

BFSI Model Risk Tiering (`sdlc-bfsi-model-risk`)

The Model Risk template is a sibling to sdlc-bfsi. Where sdlc-bfsi governs who may perform each stage (segregation of duties), sdlc-bfsi-model-risk governs which models may be invoked in each stage (model risk tiering per SR 11-7).

This template is a partial implementation. The gate predicate (bfsi.model_risk.evaluate) and the Cedar policy (bfsi-model-risk-tiering) are complete; the full catalog-registration UI for individual model entries is not yet shipped. Track progress in the BFSI compliance section.

Gate structure

Every model-invoking node is preceded by a bfsi.model_risk.evaluate gate:

- id: model_risk_gate
  type: gate
  config:
    predicate: bfsi.model_risk.evaluate
    resolvedProfileId: "{{ nodes.resolve_profile.output.profileId }}"
  gateConfig:
    gateType: signal
    signalEventType: bfsi.gate.decision
    timeoutMs: 3600000
    onTimeout: escalate
  branches:
    pass: invoke_model
    fail: model_risk_rework
    escalate: model_risk_human_approval

The Cedar policy evaluates the resolved model catalog row against:

Whether the model is registered and active.
Whether the model's risk tier is permitted for the current pipeline stage.
Whether the model's data classification ceiling covers the issue's classification.

Stacking the two BFSI templates

In a production regulated deployment, both gates can be stacked upstream of a regulated dispatch in a custom workflow:

segregation gate → model-risk gate → dispatch verb

The canonical pattern is to compose both into a single custom workflow using sub-workflow groups rather than installing both templates independently.

Installing

pnpm tsx scripts/install-template.ts sdlc-bfsi-model-risk@<version> --org <org-id> --project <project-id>

Choosing a template

Creating a custom variant

Any of these templates can be forked as a starting point for a custom workflow:

Open the workflow canvas for the template you want to extend: Workflows → [template name].

Click Clone in the workflow controls panel. Give the clone a unique name.

Edit the canvas, adjusting nodes, capability sets, gate thresholds, or routing logic.

Publish the cloned workflow - publishing activates its trigger subscriptions for the project directly. Clones are project-scoped workflows, not template installs: they are not linked to a project_template_subscriptions row and do not appear in the System Templates panel.

Cloned workflows are independent of the official template - they do not receive automatic updates when Rensei ships template improvements. Pin the clone's version deliberately and review upstream changes against your customizations periodically.

For advanced composition patterns - sharing nodes across multiple template variants via workflow groups - see Groups and Sub-workflows.

I run a standard engineering team

I want a simpler single-tracker pipeline

We have regulatory requirements (SR 11-7, SOC 2)

We need to gate which AI models can be used per stage

On this page