RESEARCH / SPECIFICATION

The Software Delivery Assurance Model

Version 1.0 Published 2026-07-30 Authors CDK Core Team DRAFT

Abstract

This document defines the Software Delivery Assurance Model: the conceptual layer connecting CDK's technical specifications to compliance outcomes. It describes how raw delivery events accumulate into assurance, and how that same assurance is then read differently by different frameworks. Where the other specifications define mechanisms, this one defines what the mechanisms are for.

1. The Assurance Pyramid

Six properties build on one another. Each is defined precisely by a technical specification; together, they constitute assurance.

Identity
Who initiated or approved an action, cryptographically verified.
Security Architecture §1
Policy
The rules that were supposed to apply, expressed as executable logic.
Platform: Policy Engine
Provenance
Where an artifact came from, and every step it passed through.
Trust Graph §2–3
Integrity
Confirmation that nothing was altered between steps.
Evidence Model §2
Verification
Independent confirmation that a signature and its claims are valid.
Security Architecture §2–3
Assurance
The cumulative confidence that results from all five, continuously.
This document

2. Event to Assurance

Assurance is not a single measurement — it's an accumulation.

01

Event occurs

Captured per the Evidence Model.

02

Signed

The event becomes an attestation.

03

Linked

The attestation becomes a node in the Trust Graph.

04

Accumulated

Many verified nodes form a complete delivery history.

05

Assured

The accumulated, continuously-verified history is assurance.

3. Assurance to Compliance

Assurance is framework-agnostic by design. A single attestation about a change-management event doesn't know or care that SOC 2 calls it CC8.1 and ISO 27001 calls it A.12.1.2 — see the Solutions overview for the full mapping. Compliance frameworks are consumers of assurance, not producers of it. This is why CDK generates evidence once and lets frameworks read it differently, rather than generating separate evidence per framework.

4. Non-Goals

This model does not claim to:

  • Replace human judgment in complex or ambiguous approval decisions
  • Guarantee the correctness, quality, or security of the code itself — only that the required procedural steps occurred
  • Eliminate the need for an organization to define sound policies in the first place. CDK enforces and evidences policy; it does not author it.

References

The CDK Trust Graph Specificationv1.0
The CDK Evidence Model Specificationv1.0
The CDK Security Architecturev1.0
The CDK Threat Modelv1.0