The CDK Trust Graph Specification

Abstract

This document defines the Trust Graph, a data model for representing software delivery events as a chain of cryptographically verifiable nodes. Each node corresponds to a discrete event — an approval, a build, a deployment — and carries a signed attestation of what occurred, who was responsible, and how it was verified. The model is designed to be implementable independently of CDK, using existing open standards for signing and verification.

1. Terminology

Four terms recur throughout this specification.

Node

A single verifiable event in the delivery lifecycle.

Edge

A directed relationship between two nodes, representing causality or sequence.

Attestation

A signed statement of fact attached to a node.

Graph

The complete set of nodes and edges for a given artifact or release.

2. Node Model

Every node conforms to a single, versioned shape regardless of its type. The type field determines how metadata is interpreted; the status field is derived, never set directly.

interface TrustNode {
  id: string;
  type: "identity" | "commit" | "approval"
      | "policy" | "artifact" | "deployment";
  status: "verified" | "pending" | "failed";
  metadata: {
    actor?: string;
    timestamp?: string; // RFC 3339
    signature?: string;
  };
}

3. Edge Model

An edge connects exactly two nodes and is directional: source → target. Edges carry no independent trust claim of their own — they inherit verification status from their endpoints. A graph is considered fully verified only when every node and every edge on the path from origin to release resolves to verified. A single failed node breaks the chain at that point, regardless of what precedes or follows it.

4. Verification

Verification is independent of CDK by design. Given a node's attestation and its signer's public key material, any party can recompute the signature and confirm it matches — using standard tooling such as Sigstore's verification flow or an equivalent in-toto verifier. CDK does not act as a trusted intermediary. It is one of potentially many systems capable of producing and checking evidence in this format, and a Trust Graph should remain verifiable even if CDK itself is unavailable.

5. Serialization

Nodes are serialized as canonical JSON prior to signing, per RFC 8785, so that two implementations produce byte-identical output for the same logical record.

{
  "id": "node_8f92ab",
  "type": "approval",
  "status": "verified",
  "metadata": {
    "actor": "[email protected]",
    "timestamp": "2026-07-28T09:41:00Z",
    "signature": "sha256:8f92ab…"
  }
}

References