Release baselines

A baseline is a named, timestamped snapshot of every compliance artefact in a project at a point in time. A baseline moves through its own controlled lifecycle before it becomes the record used for regulatory submission.

Baseline lifecycle

created → release_gate_running → passed → approved → released → obsolete
                                    ↓          ↓
                                  failed     stale
                                    ↑          ↑
                                    └─── re-evaluate ───┘

• created — snapshot captured; not yet evaluated
• release_gate_running — an async gate evaluation is executing
• passed / failed — the latest evaluation result
• approved — a Project Lead or Admin has approved the passed baseline
• released — a Quality Engineer or Admin has released the approved baseline (immutable)
• stale — an earlier passed result is no longer current because a new blocking-relevant event landed after the evaluation cut-off

released is the only terminal state; a released baseline can never re-enter evaluation.

What the release gate checks

The gate runs every rule with execution_mode = release_gate plus a set of structural checks:

Severity-based blocking

Not every validation issue blocks the gate. Whether an issue blocks depends on its severity and on the active profile.

The ASIL D profile treats both critical and major severity issues as blocking at the release gate. critical issues always block, regardless of profile configuration.

The end-to-end flow

The typical workflow, and the role that performs each step:

Baseline creation acquires a project-scoped update lock. While the lock is held, artefact and relationship writes for the project return 423 Locked. Reads are not affected.

Running the gate check

curl -X POST http://localhost/api/v1/projects/<project-id>/release-gate/run \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <your-token>" \
  -d '{"baseline_id": "<baseline-id>"}'

Fetch the latest result:

curl http://localhost/api/v1/projects/<project-id>/baselines/<baseline-id>/release-gate/results/latest \
  -H "Authorization: Bearer <your-token>"

Example response:

{
  "release_gate_result_id": "RGR_014",
  "status": "failed",
  "result": "fail",
  "evaluated_rules_count": 42,
  "passed_rules_count": 40,
  "blocking_issues": [
    {
      "issue_id": "ISS_233",
      "rule_id": "AAC-RULE-054",
      "severity": "critical",
      "artefact_id": "TC_042",
      "summary": "Test case has no associated TestResult"
    }
  ],
  "open_suspect_states": []
}

Fix the blocking issues, then re-run the gate. Each run creates a new immutable ReleaseGateResult; the newest completed result is the one that counts, provided nothing blocking-relevant has happened since.

Stale gates and approval invalidation

A passed gate result stays current only as long as nothing changes that could alter the outcome. A blocking-relevant event during the window between gate pass and release makes the baseline stale.

Blocking-relevant events include:

• A new issue whose severity blocks under the active profile
• A new open suspect state affecting an in-scope artefact
• A newly discovered mandatory-artefact or traceability gap
• A newly failed test result
• A change to the governing profile, rule catalog, or tailoring decisions

When the baseline goes stale:

• If it was already approved, the approval is invalidated and retained in audit history; the baseline returns to created
• Re-evaluation is required before it can be approved and released again

The release operation re-checks gate currency in the same transaction as the transition to released, so a stale baseline cannot slip through.

Approving and releasing

After a passed gate result that is still current:

curl -X POST http://localhost/api/v1/projects/<project-id>/baselines/<baseline-id>/approve \
  -H "Authorization: Bearer <your-token>"

curl -X POST http://localhost/api/v1/projects/<project-id>/baselines/<baseline-id>/release \
  -H "Authorization: Bearer <your-token>"

A released baseline records the exact artefact revisions, relationship revisions, validation state, suspect state, release-gate result, and any active repository connector commits at the moment of release.

What a released baseline contains

• Baseline ID and evaluation number — the identifier used as an anchor for UNECE R156 (RXSWIN) records
• Approved-by and released-by — recorded from the audit trail
• Timestamps — creation, gate evaluation, approval, and release
• Artefact manifest — every artefact ID and revision included in the baseline
• Relationship manifest — every relationship revision at the snapshot cut-off
• Release-gate result — the passing evaluation, including counts of evaluated and passed rules
• Repository commits — the exact source-code commit SHA for every active repository connector

Related

• Managing artifacts — the artefacts that feed into the baseline
• Suspect propagation — why suspects block release, and how to clear them
• Authorization — the roles that can create, approve, and release