ASPICE · SPL.2 · Product Release

ASPICE SPL.2 Product Release

Controlling the release to the customer — defined content, a release built from configured items, release notes, approval against criteria, and a recorded delivery.

In short

ASPICE SPL.2 Product Release controls the release of a product to the intended customer: defining the release content and classification/numbering, building the release from configured items, producing release notes, approving the release against defined criteria, and delivering it to the customer with the delivery recorded.

SPL.2 is the last mile — and it depends entirely on SUP.8: you can only release a controlled product if it's built from baselined configuration items. It's the point where the CM data model pays off.

Purpose & process outcomes

Purpose (per the ASPICE PAM): control the release of a product to the intended customer.

The process is achieved when these outcomes hold:

Base practices

SPL.2.BP1

Define the functional content of releases

Determine what is in each release.

SPL.2.BP2

Define release products

Identify the products/artifacts to release.

SPL.2.BP3

Establish a release classification and numbering scheme

Versioning of releases.

SPL.2.BP4

Define build activities and build environment

Reproducible build from CIs.

SPL.2.BP5

Build the release from configured items

Assemble from baselined items (SUP.8).

SPL.2.BP6

Communicate support level and duration

Service level for the release.

SPL.2.BP7

Define media type / packaging and produce release notes

Delivery media, packaging, release notes.

SPL.2.BP8

Ensure product release approval before delivery

Approve against criteria.

SPL.2.BP9

Deliver the release to the intended customer

Deliver and record the delivery.

Work products

The output work products SPL.2 asks for (named per the standard):

Map it to your tools

This is where the standard meets reality. Each work product and outcome has a concrete home — an issue type, work-item type, or model element — in the tools you already run. Types are configurable, so treat this as the typical ASPICE setup:

Work product / outcomeJiraPolarionCodebeamerDOORS NextEnterprise ArchitectConfluence
WP: release plan / contentVersion / Release + scope (fix-version)Release plan + BaselineRelease baseline + planrelease plan page
WP: release built from configured itemsrelease tied to a build + tagged commitrelease from a Baselinerelease from a Baseline
WP: release notesauto release notes from fix-version issuesrelease-notes LiveDocrelease-notes docrelease-notes page
WP: release approval recordrelease workflow approval / gateapproval workflow + e-sigapproval workflowrelease sign-off page
WP: delivery recorddelivery issue + timestampdelivery record itemdelivery itemdelivery log

The trap isn't the tools — it's that the links between them are maintained by hand and decay the moment a requirement changes. (See best ASPICE tools.)

It only matures on one configuration-management data model

Here is the part almost everyone misses. SPL.2 can never reach a mature capability level (CL2+) on its own — it can only be as mature as the configuration-management data model underneath it. SUP.8 Configuration Management is the secret enabling layer: the shared data model of items, versions, baselines and links that is the basis on which every other process group becomes provable. Scatter that data model across a Jira project, a Polarion space, a DOORS module, an EA model and a Confluence tree, and the model is fragmented by construction — the traceability that SPL.2 depends on decays the moment anything changes, and no amount of process ceremony fixes it.

What actually unlocks maturity is a headless ALM — an API-first, tool-agnostic configuration-management data model that is the single source of truth for every work product and every link, readable and writable by both humans and agents — plus an agent/human workflow definition, coordination and traceability platform on top of it, so every change is planned, assigned (to a human or an agent), executed and traced against that one model. That is the layer that lets SPL.2 be mature instead of theatrical.

Where teams fail SPL.2

This is part of The Blueprint — our free template QMS

ASPICE deliberately gives you no blueprint. So we wrote one. This SPL.2 guide is part of The Blueprint — our free, open template QMS for ASPICE: every VDA-scope process area, its outcomes and work products, mapped to concrete artifacts in your tools and grounded in one configuration-management data model. Take it, use it, no cost.

Agents assemble the release notes and the release record from the baselined configuration items and the change set, and check the release against its approval criteria — so what shipped is always provably tied to a baseline. And we offer to implement The Blueprint for you: our agentic solutions (Vera generates SPL.2's work products and traceability as a byproduct of the build, each with a confidence score and audit trail) running on a partner headless ALM — the API-first configuration-management data model that makes the whole thing provable.

Frequently asked questions

What is SPL.2 in ASPICE?

SPL.2 Product Release controls the release of a product to the customer — defining release content and numbering, building the release from configured items, producing release notes, approving against criteria, and delivering with a recorded delivery.

What are the SPL.2 work products?

A release plan, release notes, the release itself (built from configured items), a release approval record, and a delivery record.

Why does SPL.2 depend on SUP.8?

Because a controlled release must be built from baselined configuration items. Without SUP.8's baselines you cannot say exactly what shipped — which is why SPL.2 is where the configuration-management data model pays off.

How do you map SPL.2 to the toolchain?

A Version/Release with its scope (Jira fix-version, Polarion/Codebeamer Baseline), release notes auto-derived from the change set, an approval workflow gate before delivery, and a recorded delivery — all tied to a tagged, reproducible build.

Part of the ASPICE explainer series

Grounded in the standard, honest about the theater: All VDA-scope process areas · SUP.8 CM · ACQ.4 Supplier Monitoring · SWE.6 SW Qualification

Get The Blueprint. Have us implement it.

The Blueprint is our free template QMS for ASPICE. We implement it with our agentic solutions on a partner headless ALM — SPL.2's work products and traceability generated in your tools, with a confidence score and audit trail on every artifact.or book a compliance teardown →

See Vera →