Delivery Pipelines: CI/CD for Business Rules in DecisionManager

## Why rules need their own pipeline model

Software CI/CD pipelines run tests and deploy code. Business rule pipelines need to do the same for governed artifacts: run test suites against a specific ruleset version, assert analysis results, and promote to the Decision Server — all subject to the governance lifecycle.

Standard CI/CD tools don't understand governance states. A generic pipeline runner can call APIs, but it can't express "this step should only run if the ruleset version is in `approved` state". DecisionManager's Pipelines feature provides a rule-aware pipeline model.

Pipeline anatomy

A pipeline in DecisionManager is a sequence of steps scoped to one ruleset. Steps are:

| Step type | What it does | |:--|:--| | `suite_run` | Runs a test suite against a specified version; fails on any failing case | | `analysis_check` | Runs structural analysis; fails on any overlap or gap | | `deploy` | Promotes to a Decision Server environment; requires `approved` state | | `scenario_run` | Runs a scenario set batch; fails if coverage drops below threshold | | `notify` | Posts a webhook event to a configured endpoint |

Steps are ordered and the pipeline halts on failure — subsequent steps do not run.

Deep-linkable run URLs

Every pipeline run produces a permanent URL:

/pipelines?pipeline=<pipelineId>&run=<runId>

This URL is the entry point from CI. The `dm` CLI prints it at the end of `dm pipeline run`. Your CI system (GitHub Actions, GitLab CI, Jenkins) can post it as a PR comment or deployment annotation so the team has a direct link from the CI build to the rule pipeline run.

dm CLI integration

bash
# Trigger a pipeline run (waits by default; exit code is the stage verdict)
dm pipeline run --pipeline <pipeline-uuid> --environment staging --wait \
  --version <versionId>

# Check the status of a run dm pipeline status --run <runId>

# List pipeline definitions on a ruleset (not "runs") dm pipeline list --ruleset <ruleset-uuid>

# Pull JUnit / SARIF / report for a finished run dm pipeline artifacts --run <runId> --out-dir artifacts/run ```

A typical GitHub Actions step:

yaml
- name: Run release pipeline
  run: |
    dm pipeline run \\
      --pipeline ${{ vars.PIPELINE_ID }} \\
      --version ${{ steps.publish.outputs.version_id }} \\
      --environment staging \\
      --wait
  env:
    DM_API_KEY: ${{ secrets.DM_API_KEY }}
    DM_MANAGER_URL: ${{ vars.DM_MANAGER_URL }}

Governance-aware deployment step

The `deploy` step enforces governance: it calls the Decision Server's hot-deploy endpoint, which requires the ruleset version to be in `approved` state. If it is not, the step fails with a governance error — no live traffic is affected. This is the safety layer: a pipeline cannot accidentally deploy a draft to production.

The deploy step also accepts a slot for blue/green via the runtime deploy APIs (`dm deploy --ruleset … --environment … --slot green` when the CLI stage is used). Shifting live traffic remains a Decision Server console / runtime routing action — there is no `dm traffic shift` subcommand.

Example: full release pipeline

A complete pipeline for a credit underwriting ruleset:

yaml
pipeline: loan-eligibility-release
ruleset: loan-eligibility
steps:
  - type: analysis_check
    fail_on: [overlap, gap, unreachable]

- type: suite_run suite: loan-elig-regression fail_on: any_failure

- type: scenario_run set: quarterly-corpus fail_if_coverage_below: 95 fail_if_verdict_drift_exceeds: 0.5 # percent points

- type: deploy environment: production slot: green strategy: blue_green

- type: notify webhook: release-channel message: "loan-eligibility {version} deployed to green slot" ```