# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "published", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-09-03T01:44:07Z", "synthesisSha256": "2a7f1e488ad105c90e4453b222b08def51d2e12c48caec32e667cbfbc6811eb0", "providerMode": "single-provider-waiver", "providers": [ "Claude" ], "waivedProviders": [ "Grok" ] }, "metaModel": { "id": "WM-SFT-008", "registryId": "vr.wm-sft-008", "name": "Build / Release", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "aggregate", "family": "World Models", "category": "Information and virtual systems", "industry": [ "Cross-industry" ], "domain": [ "INF.SFT.REL" ], "tags": [ "build", "release", "inf.sft.rel" ], "status": "published" }, "canonicalUrl": "https://ver.cy/models/wm-sft-008-build-release/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-sft-008", "model": { "registry_id": "vr.wm-sft-008", "model_id": "WM-SFT-008", "name": "Build / Release", "entry_kind": "aggregate", "purpose": "Provide the context an agent needs to understand, create, inspect and operate a software release aggregate: its identity and version designation, the build runs and provenance that produced its artifacts, the integrity and attestation evidence bound to those artifacts, the release lifecycle and authority, and its publication, archival and external evidence references.", "scope_statement": "Covers a Release as an aggregate that binds (a) release and artifact identity, (b) build definition, build platform and build run provenance, (c) integrity, attestation and producer-declared verification expectations, (d) lifecycle state, authority, change communication and support declaration, (e) publication coordinates, archival and retention metadata, and (f) typed references to SBOM, test evidence and regulatory documentation. It stops at the point where a release becomes obtainable; installing, rolling out or running it is not modelled here. It records declarations, references and evidence pointers, never the execution of verification, enforcement or audit-trail keeping.", "in_scope": [ "Release identity, version designation, release type and distribution channel classification", "Artifact descriptors: digests, media types, sizes, download locations, platform variants and artifact roles", "Build definition (buildType, external and internal parameters) and resolved build-time dependency descriptors", "Build platform identity, declared build assurance level and build run execution record (invocation, start, finish, byproducts)", "Reproducibility declaration, recorded build environment and independent rebuild comparison outcomes", "Attestation statement binding, signature and trust-anchor references, and producer-published verification expectations", "Release lifecycle states, supersession and withdrawal, release authority and approval references", "Change content, release notes, security-fix references and support-period / end-of-support declarations", "Publication targets, package coordinates, provenance co-distribution, release archival and retention metadata", "Typed references to SBOM documents, test evidence records and regulatory documentation" ], "out_of_scope": [ "SBOM content: component inventory, dependency graph, licence facts, VEX statements and SBOM lifecycle — owned by WM-SFT-012", "Test design, test execution, result schemas, coverage and defect semantics — owned by WM-SFT-015", "Deployment, installation, environment promotion, rollout strategy, runtime configuration and runtime rollback — owned by WM-SFT-009", "Source-control repository, branch, merge and change-request models; only the resolved revision reference is carried here", "Cryptographic key generation, custody, rotation, revocation and PKI/HSM operation", "Execution of signature verification, policy evaluation, admission enforcement, and operation of transparency logs or audit trails", "Vulnerability discovery, CVE/advisory record structure and incident reporting workflows", "Package registry and mirror service operation, hosting capacity and access-control implementation", "Licence compliance obligations and export-control determination", "Product-level roadmap, pricing, commercial packaging and customer entitlement" ], "boundary_notes": [ { "neighbor": "WM-SFT-012 (SBOM)", "distinction": "This model carries only the SBOM reference: document URI, digest, declared format, generation stage and binding to the release. SLSA resolvedDependencies is a best-effort build-time fetch record and is explicitly not an SBOM; component inventory semantics and SBOM lifecycle remain with WM-SFT-012.", "source_refs": [ "SRC-001", "SRC-007", "SRC-013" ] }, { "neighbor": "WM-SFT-015 (Test evidence)", "distinction": "This model records which evidence records a release gate referenced and the outcome pointer. Test design, execution, result interpretation and evidence lifecycle stay in WM-SFT-015.", "source_refs": [ "SRC-007" ] }, { "neighbor": "WM-SFT-009 (Deployment)", "distinction": "WM-SFT-009 consumes release identity and artifact digests published here. Installation, rollout, environment promotion and runtime rollback are owned there. SWID primary and patch tags describe installed state and therefore sit on the deployment side; only pre-installation (corpus-level) identity is in scope here.", "source_refs": [ "SRC-015" ] }, { "neighbor": "Signing key management and transparency-log services", "distinction": "Signature, signer-identity and trust-anchor values are carried as references so a release record is self-describing. Key custody, signing execution, verification execution and transparency-log entry semantics are owned elsewhere; a reference here grants no ownership of evaluation or audit-trail semantics.", "source_refs": [ "SRC-003", "SRC-004", "SRC-012" ] }, { "neighbor": "Source control / change management", "distinction": "Only the resolved source repository URI, revision digest and subpath are bound to a build. Branch policy, review and change-request state belong to the source model.", "source_refs": [ "SRC-001", "SRC-003" ] }, { "neighbor": "Vulnerability and advisory management", "distinction": "A security release may reference fixed-vulnerability identifiers and advisories, but advisory authoring, severity assessment and disclosure workflow are not modelled here.", "source_refs": [ "SRC-013", "SRC-007" ] } ] }, "sources": [ { "id": "SRC-001", "title": "SLSA Build Provenance (predicate specification)", "organization": "OpenSSF / SLSA community specification", "url": "https://slsa.dev/spec/v1.2/build-provenance", "version_or_date": "v1.2, status Approved", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T10:00:00Z", "relevance": "Normative schema for buildDefinition (buildType, externalParameters, internalParameters, resolvedDependencies) and runDetails (builder, metadata invocationId/startedOn/finishedOn, byproducts)." }, { "id": "SRC-002", "title": "SLSA Build track requirements (Producing artifacts)", "organization": "OpenSSF / SLSA community specification", "url": "https://slsa.dev/spec/v1.2/build-requirements", "version_or_date": "v1.2, status Approved", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T10:02:00Z", "relevance": "Producer and build-platform requirements per Build L1-L3: consistent build process, provenance existence/authenticity/unforgeability, hosted, isolated and ephemeral environment." }, { "id": "SRC-003", "title": "SLSA: Verifying build artifacts", "organization": "OpenSSF / SLSA community specification", "url": "https://slsa.dev/spec/v1.2/verifying-artifacts", "version_or_date": "v1.2, status Approved", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T10:04:00Z", "relevance": "Defines expectations (expected builder identity, canonical source repository, buildType, externalParameters) and how they are formed; used here only to model producer-published declarations, not verification execution." }, { "id": "SRC-004", "title": "SLSA: Distributing provenance", "organization": "OpenSSF / SLSA community specification", "url": "https://slsa.dev/spec/v1.2/distributing-provenance", "version_or_date": "v1.2, status Approved", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T10:06:00Z", "relevance": "Co-distribution of attestations with artifacts, sidecar filename convention (.intoto.jsonl), and publication venues (source releases, package registries, transparency logs)." }, { "id": "SRC-005", "title": "in-toto Attestation Framework: Statement layer (v1)", "organization": "in-toto project (CNCF)", "url": "https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md", "version_or_date": "v1 (https://in-toto.io/Statement/v1), accessed 2026-09-03", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T10:08:00Z", "relevance": "Statement fields _type, subject, predicateType, predicate; subject matching is by digest alone and subjects are assumed immutable." }, { "id": "SRC-006", "title": "in-toto Attestation Framework: ResourceDescriptor (v1)", "organization": "in-toto project (CNCF)", "url": "https://github.com/in-toto/attestation/blob/main/spec/v1/resource_descriptor.md", "version_or_date": "v1, accessed 2026-09-03", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T10:10:00Z", "relevance": "Descriptor fields name, uri, digest, content, downloadLocation, mediaType, annotations; at least one of uri, digest or content is required." }, { "id": "SRC-007", "title": "NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1", "organization": "National Institute of Standards and Technology (NIST)", "url": "https://csrc.nist.gov/pubs/sp/800/218/final", "version_or_date": "Version 1.1, February 2022", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:12:00Z", "relevance": "PS.2 verifying software release integrity, PS.3 archive and protect each software release (PS.3.1 archive files and supporting data including integrity verification and provenance data; PS.3.2 provenance data for components), PW.6 build/compiler configuration." }, { "id": "SRC-008", "title": "Semantic Versioning 2.0.0", "organization": "Semantic Versioning (semver.org)", "url": "https://semver.org/", "version_or_date": "2.0.0", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T10:14:00Z", "relevance": "MAJOR.MINOR.PATCH format, pre-release and build-metadata identifiers, precedence rules, and the normative immutability rule that released version contents MUST NOT be modified." }, { "id": "SRC-009", "title": "ECMA-427: Package-URL (PURL) Specification", "organization": "Ecma International (TC54)", "url": "https://ecma-international.org/publications-and-standards/standards/ecma-427/", "version_or_date": "1st edition, December 2025", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:16:00Z", "relevance": "Standardised cross-ecosystem package identifier syntax pkg:type/namespace/name@version?qualifiers#subpath used as a governed global identifier for release coordinates." }, { "id": "SRC-010", "title": "OCI Image Format Specification: Annotations", "organization": "Open Container Initiative (OCI)", "url": "https://github.com/opencontainers/image-spec/blob/main/annotations.md", "version_or_date": "main branch, accessed 2026-09-03", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T10:18:00Z", "relevance": "Pre-defined keys org.opencontainers.image.created (RFC 3339), version, revision, source, vendor, licenses, base.digest, base.name — a concrete projection of release metadata onto packaged artifacts." }, { "id": "SRC-011", "title": "OCI Image Format Specification", "organization": "Open Container Initiative (OCI)", "url": "https://github.com/opencontainers/image-spec/blob/main/spec.md", "version_or_date": "main branch, accessed 2026-09-03", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T10:20:00Z", "relevance": "Content-addressable descriptors (mediaType, digest, size), image manifest and image index for multi-platform artifact variant grouping." }, { "id": "SRC-012", "title": "Reproducible Builds: Definition", "organization": "Reproducible Builds project", "url": "https://reproducible-builds.org/docs/definition/", "version_or_date": "Living document, accessed 2026-09-03", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 3, "accessed_at": "2026-09-03T10:22:00Z", "relevance": "Conditions for reproducibility (same source, build environment and instructions yield bit-by-bit identical artifacts), the requirement to record build environment attributes, and verification by cryptographic hash comparison." }, { "id": "SRC-013", "title": "The Update Framework (TUF) Specification", "organization": "The Update Framework / Linux Foundation (CNCF)", "url": "https://theupdateframework.github.io/specification/latest/", "version_or_date": "Version 1.0.36, last modified 2026-08-05", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T10:24:00Z", "relevance": "Target file metadata (length, hashes, custom), metadata expiry and monotonic version numbers protecting against rollback, freeze and mix-and-match attacks; consistent-snapshot naming for release channel metadata." }, { "id": "SRC-014", "title": "Regulation (EU) 2024/2847 (Cyber Resilience Act)", "organization": "European Parliament and Council of the European Union", "url": "https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng", "version_or_date": "OJ L, 2024/2847, 20 November 2024 (regulation of 23 October 2024)", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:26:00Z", "relevance": "Article 13(8) support period of no less than five years unless product lifetime is shorter; Annex I Part II component documentation via SBOM and secure distribution of updates; Annex II end-of-support information to users; Annex VII technical documentation." }, { "id": "SRC-015", "title": "Using SWID Tags in the Software Lifecycle", "organization": "National Institute of Standards and Technology (NIST), Software Identification (SWID) project", "url": "https://csrc.nist.gov/Projects/Software-Identification-SWID/lifecycle", "version_or_date": "NIST SWID project page, accessed 2026-09-03", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:28:00Z", "relevance": "Corpus tags identify an installable product in its pre-installation state while primary and patch tags describe installed state — the boundary line between this model and WM-SFT-009." }, { "id": "SRC-016", "title": "NISTIR 8060: Guidelines for the Creation of Interoperable Software Identification (SWID) Tags", "organization": "National Institute of Standards and Technology (NIST)", "url": "https://csrc.nist.gov/pubs/ir/8060/final", "version_or_date": "April 2016", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:30:00Z", "relevance": "Guidance on software identification tags for asset and security management across the software lifecycle; supports software identity as a distinct concern from version strings." } ], "structure": { "bundles": [ { "id": "release-identity-and-designation", "name": "Release Identity and Designation", "description": "What a release is, how it is identified and versioned, and which concrete artifacts constitute it.", "rationale": "Every downstream concern — provenance, attestation, distribution, deployment — resolves against a stable release identity and digest-addressed artifact set. in-toto matches subjects purely by digest, so identity and digest binding must be settled before anything else.", "source_refs": [ "SRC-005", "SRC-006", "SRC-008", "SRC-009", "SRC-011" ], "layers": [ { "id": "release-designation", "name": "Release Designation", "description": "Identifiers, version designation and classification of a single release.", "source_refs": [ "SRC-008", "SRC-009", "SRC-015", "SRC-016" ], "findings": [ { "id": "release-identity", "name": "Release Identity and Identifier Scheme", "description": "How one release of a product or component is uniquely identified, independent of its human-readable version string and of the build run that produced it.", "source_refs": [ "SRC-005", "SRC-009", "SRC-016" ], "questions": [ { "id": "release-identity-q-master", "text": "Which system of record issues the authoritative identifier for this release?", "kind": "identity", "answer_data": [ "Issuing system URI or registered system code", "Release record key within that system" ] }, { "id": "release-identity-q-global", "text": "Which governed global identifiers designate this release and its package coordinates?", "kind": "interoperability", "answer_data": [ "Package URL (purl) string per ECMA-427", "OCI image reference including digest, or SWID tagId" ] }, { "id": "release-identity-q-vs-build", "text": "What distinguishes the release record from the build run or runs that produced its artifacts?", "kind": "definition", "answer_data": [ "Release identifier", "Set of build invocation identifiers bound to this release" ] }, { "id": "release-identity-q-granularity", "text": "Which product or component owns this release, and at what packaging granularity?", "kind": "composition", "answer_data": [ "Parent product or component reference (WM-SFT-007)", "Granularity code: product, component, module or package" ] } ], "data_elements": [ { "id": "release-identifier", "name": "Release identifier", "description": "Authoritative master-system identifier for the release.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "release-purl", "name": "Release package URL", "description": "purl coordinates identifying the released package.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "release-parent-ref", "name": "Parent component reference", "description": "Reference to the product or component being released.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-016" ] }, { "id": "release-identifier-scheme", "name": "Identifier scheme code", "description": "Scheme governing the primary identifier value.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-009" ] } ], "artifacts": [], "inline_only_rationale": "Release identity is pure reference data: a set of identifier values and the schemes that govern them. It has no document form of its own — it is the key that other artifacts (manifests, attestations, archives) cite. Materialising it as a file would create a second, competing source of truth for the identifier." }, { "id": "version-designation-and-classification", "name": "Version Designation, Precedence and Release Classification", "description": "The version string, its scheme and ordering semantics, and the classification of the release by change type and distribution channel.", "source_refs": [ "SRC-008", "SRC-010", "SRC-014" ], "questions": [ { "id": "version-q-scheme", "text": "Which version scheme governs this release, and how is precedence against sibling releases determined?", "kind": "classification", "answer_data": [ "Version scheme code (for example semver-2.0.0, calendar, ecosystem-specific)", "Precedence rule reference and computed ordering rank" ] }, { "id": "version-q-immutability", "text": "What guarantees that the contents published under this version will never be modified?", "kind": "constraint", "answer_data": [ "Immutability declaration and its enforcement point", "Digest set frozen at publication" ] }, { "id": "version-q-change-type", "text": "What class of change does this release carry, and does it break a published interface?", "kind": "decision", "answer_data": [ "Release type code: major, minor, patch, security, hotfix or rebuild", "Breaking-change indicator with affected interface references" ] }, { "id": "version-q-channel", "text": "Which distribution channel and maturity does this release target, and for which audience?", "kind": "classification", "answer_data": [ "Channel code (for example alpha, beta, release-candidate, stable, long-term-support)", "Audience or availability scope code" ] } ], "data_elements": [ { "id": "version-string", "name": "Version string", "description": "Human-readable version designation for the release.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-008" ] }, { "id": "version-scheme-code", "name": "Version scheme", "description": "Scheme that gives the version string meaning and ordering.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-008" ] }, { "id": "version-prerelease", "name": "Pre-release identifier", "description": "Dot-separated pre-release identifiers lowering precedence.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "version-build-metadata", "name": "Build metadata string", "description": "Build metadata ignored when determining precedence.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "release-type-code", "name": "Release type", "description": "Change class carried by this release.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-008", "SRC-014" ] }, { "id": "release-channel-code", "name": "Distribution channel", "description": "Channel and maturity the release is published into.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [], "inline_only_rationale": "Version designation and classification are scalar and coded values attached to the release record. Semantic Versioning defines rules rather than a document; rendering these values as a separate artifact would duplicate fields that consumers read directly from the release record and from package metadata." } ] }, { "id": "artifact-identity", "name": "Artifact Identity and Packaging", "description": "The concrete files, images and packages that constitute the release, and their variants and roles.", "source_refs": [ "SRC-006", "SRC-010", "SRC-011" ], "findings": [ { "id": "artifact-descriptor-set", "name": "Artifact Descriptor Set and Digests", "description": "The enumerated set of artifacts released, each addressed by cryptographic digest with media type, size and retrieval location.", "source_refs": [ "SRC-005", "SRC-006", "SRC-007", "SRC-011" ], "questions": [ { "id": "artifact-q-membership", "text": "Which artifacts constitute this release, and which of them are consumer-facing distributables?", "kind": "composition", "answer_data": [ "Ordered list of artifact descriptors", "Distributable indicator per descriptor" ] }, { "id": "artifact-q-digest", "text": "Which digest algorithms address each artifact, and which algorithm is authoritative for matching?", "kind": "identity", "answer_data": [ "DigestSet mapping algorithm name to hash value", "Authoritative algorithm code and its deprecation status" ] }, { "id": "artifact-q-integrity-publish", "text": "How can a consumer verify that a retrieved file is the artifact this release declares?", "kind": "validation", "answer_data": [ "Published checksum or manifest location", "Digest comparison procedure reference" ] }, { "id": "artifact-q-media", "text": "What media type and size does each artifact carry, and from where can it be retrieved?", "kind": "interoperability", "answer_data": [ "Media type string and size in bytes", "Primary URI and alternate download location" ] } ], "data_elements": [ { "id": "artifact-descriptor", "name": "Artifact descriptor", "description": "Descriptor with name, uri, digest, mediaType and downloadLocation.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-006" ] }, { "id": "artifact-digest-set", "name": "Artifact digest set", "description": "Algorithm-to-hash map addressing artifact content.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "artifact-size-bytes", "name": "Artifact size", "description": "Size of the artifact in bytes.", "value_kind": "quantity", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-013" ] }, { "id": "artifact-authoritative-algorithm", "name": "Authoritative digest algorithm", "description": "Algorithm consumers must use for subject matching.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "release-manifest", "name": "Release manifest", "description": "Signed or checksum-protected enumeration of every artifact in the release with its digests, media types and sizes; the mechanism SSDF PS.2 calls for to let consumers verify release integrity.", "media_or_form": [ "Release manifest document", "Checksum list file (for example SHA256SUMS)", "in-toto subject array", "OCI image manifest" ], "serial": false, "identity_strategy": "Digest of the manifest content, bound to the release identifier; the manifest is never identified by its filename or publication date.", "source_refs": [ "SRC-005", "SRC-006", "SRC-007", "SRC-011" ] } ], "inline_only_rationale": null }, { "id": "artifact-variants-and-roles", "name": "Artifact Variants and Roles", "description": "How platform, architecture, locale or edition variants are grouped under one release and what role each artifact plays.", "source_refs": [ "SRC-010", "SRC-011" ], "questions": [ { "id": "variant-q-axes", "text": "Along which axes does this release vary, and what is the full variant matrix?", "kind": "classification", "answer_data": [ "Variant axis codes (platform, architecture, locale, edition)", "Enumerated variant keys present in the release" ] }, { "id": "variant-q-role", "text": "What role does each artifact play within the release?", "kind": "composition", "answer_data": [ "Role code: primary distributable, debug symbols, source archive, installer, byproduct", "Role-to-descriptor mapping" ] }, { "id": "variant-q-selection", "text": "Which variant is canonical for a consumer that cannot express a platform preference?", "kind": "decision", "answer_data": [ "Default variant key", "Selection rule or index reference" ] }, { "id": "variant-q-grouping", "text": "What single reference lets a consumer resolve the whole variant group as one release?", "kind": "relationship", "answer_data": [ "Variant index or manifest-list reference with digest", "Grouping identifier shared by all variants" ] } ], "data_elements": [ { "id": "variant-key", "name": "Variant key", "description": "Composite key identifying one variant of the release.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "artifact-role-code", "name": "Artifact role", "description": "Function of an artifact within the release.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "platform-target", "name": "Platform target", "description": "Operating system, architecture and variant triple.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "variant-index-ref", "name": "Variant index reference", "description": "Digest reference to the index grouping all variants.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] } ], "artifacts": [ { "id": "variant-index", "name": "Variant index", "description": "Index grouping every platform or edition variant of the release under one addressable reference, with per-variant descriptors and selection metadata.", "media_or_form": [ "OCI image index or manifest list", "Platform-variant matrix table", "Multi-artifact release index document" ], "serial": false, "identity_strategy": "Content digest of the index, referenced from the release identifier; media type and platform fields carry selection semantics.", "source_refs": [ "SRC-010", "SRC-011" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "build-provenance", "name": "Build Provenance", "description": "What was built, from which inputs, on which platform, in which run, and whether it can be rebuilt to the same result.", "rationale": "SLSA defines provenance as documentation of what entity built an artifact, by what process and from what inputs. These are the load-bearing facts for reproducing, debugging and trusting a release, and they are distinct from the release's identity and distribution.", "source_refs": [ "SRC-001", "SRC-002", "SRC-012" ], "layers": [ { "id": "build-definition-and-inputs", "name": "Build Definition and Inputs", "description": "The declared build template, its parameters and the dependencies resolved during the build.", "source_refs": [ "SRC-001", "SRC-003" ], "findings": [ { "id": "build-definition-and-parameters", "name": "Build Type and Build Parameters", "description": "The build template identifier and the external and internal parameters that determined how the build ran.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ], "questions": [ { "id": "builddef-q-type", "text": "Which buildType template identifies how this build was performed, and where is that template documented?", "kind": "definition", "answer_data": [ "buildType TypeURI", "Resolvable documentation location for the template" ] }, { "id": "builddef-q-external", "text": "Which parameters were under external or tenant control for this build?", "kind": "provenance", "answer_data": [ "externalParameters object with the values actually passed", "Parameter names a verifier must recognise" ] }, { "id": "builddef-q-completeness", "text": "Is the external parameter set claimed to be complete, and on what basis?", "kind": "quality", "answer_data": [ "Completeness claim code and declared build level", "Statement of any influence channel not captured" ] }, { "id": "builddef-q-internal", "text": "Which platform-controlled internal parameters were recorded, and are they needed to reproduce the build?", "kind": "constraint", "answer_data": [ "internalParameters object", "Indicator of whether each is reproduction-relevant" ] } ], "data_elements": [ { "id": "build-type-uri", "name": "Build type URI", "description": "TypeURI naming the build template.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "external-parameters", "name": "External parameters", "description": "Externally controlled inputs to the build.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "internal-parameters", "name": "Internal parameters", "description": "Platform-controlled build inputs, optional and trusted.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "parameter-completeness-claim", "name": "Parameter completeness claim", "description": "Declared completeness of external parameters at a build level.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "build-definition-record", "name": "Build definition record", "description": "The captured definition of the build: template identifier plus the parameter values actually supplied, in a form a verifier can compare against expectations.", "media_or_form": [ "SLSA buildDefinition object", "Pipeline or workflow definition snapshot", "Build recipe or spec file" ], "serial": false, "identity_strategy": "Digest of the captured definition, referenced from the build run record; never identified by pipeline name alone.", "source_refs": [ "SRC-001", "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "source-revision-binding", "name": "Source Revision Binding", "description": "The exact source repository, revision and subpath the build consumed, and whether the tree was modified before building.", "source_refs": [ "SRC-001", "SRC-003", "SRC-012" ], "questions": [ { "id": "source-q-revision", "text": "Which repository and revision digest did this build consume?", "kind": "provenance", "answer_data": [ "Canonical source repository URI", "Revision digest (for example gitCommit) rather than a branch or tag name" ] }, { "id": "source-q-canonical", "text": "Is that repository the canonical source a verifier should expect for this release?", "kind": "authority", "answer_data": [ "Canonical source declaration", "Fork or mirror indicator" ] }, { "id": "source-q-modification", "text": "Was the source tree patched or modified between checkout and build, and how is that recorded?", "kind": "exception", "answer_data": [ "Modification indicator", "Descriptors for applied patches with digests" ] }, { "id": "source-q-boundary", "text": "Which model owns the change history and review state behind this revision?", "kind": "ownership", "answer_data": [ "Reference to the source-control or change-management model", "Statement that only the resolved revision is carried here" ] } ], "data_elements": [ { "id": "source-repository-uri", "name": "Source repository URI", "description": "Resource URI of the repository the build consumed.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "source-revision-digest", "name": "Source revision digest", "description": "Digest identifying the exact source revision.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-006" ] }, { "id": "source-subpath", "name": "Source subpath", "description": "Path within the repository that was built.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "source-modification-flag", "name": "Source modification indicator", "description": "Whether the checked-out tree was modified before building.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [], "inline_only_rationale": "The binding is a small set of identifier and digest values that must live inline in the provenance so that subject matching and expectation checking work without dereferencing anything. Repository content, commit history and review records are artifacts of the source-control model, not of this one; duplicating them here would create a stale second copy." }, { "id": "resolved-dependencies-record", "name": "Resolved Build-Time Dependencies", "description": "The artifacts fetched during build initialisation and execution, recorded as descriptors with digests on a best-effort basis.", "source_refs": [ "SRC-001", "SRC-006", "SRC-007" ], "questions": [ { "id": "resolveddeps-q-what", "text": "Which artifacts were fetched during build initialisation and execution?", "kind": "provenance", "answer_data": [ "Array of resolved dependency descriptors with uri and digest", "Fetch stage indicator per descriptor" ] }, { "id": "resolveddeps-q-completeness", "text": "On what basis is this dependency record considered complete, and what is knowingly absent?", "kind": "quality", "answer_data": [ "Completeness basis code (best-effort, lockfile-derived, network-captured)", "Enumerated known exclusions" ] }, { "id": "resolveddeps-q-not-sbom", "text": "Why must this record not be treated as the release's software bill of materials?", "kind": "interoperability", "answer_data": [ "Statement that build-time fetch scope differs from shipped component scope", "Reference to the SBOM document that does carry component inventory" ] }, { "id": "resolveddeps-q-pinning", "text": "How were dependency versions pinned so that the same set resolves on a rebuild?", "kind": "constraint", "answer_data": [ "Pinning mechanism code (lockfile, digest pin, vendored)", "Reference to the pinning artifact with its digest" ] } ], "data_elements": [ { "id": "resolved-dependency-descriptor", "name": "Resolved dependency descriptor", "description": "Descriptor for one artifact fetched during the build.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-006" ] }, { "id": "dependency-completeness-basis", "name": "Completeness basis", "description": "How the dependency record was assembled and bounded.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "dependency-pinning-mechanism", "name": "Pinning mechanism", "description": "Mechanism that fixes dependency versions for rebuilds.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "resolved-dependency-record", "name": "Resolved dependency record", "description": "Captured list of build-time fetched artifacts with digests, sufficient to re-resolve the same inputs; explicitly not an SBOM.", "media_or_form": [ "SLSA resolvedDependencies array", "Dependency lockfile snapshot", "Build-time fetch log with digests" ], "serial": false, "identity_strategy": "Digest of the captured record, referenced from the build run; scoped by build invocation identifier.", "source_refs": [ "SRC-001", "SRC-006", "SRC-007" ] } ], "inline_only_rationale": null } ] }, { "id": "build-execution", "name": "Build Platform and Execution", "description": "Which platform ran the build, at what declared assurance level, and what the individual run produced.", "source_refs": [ "SRC-001", "SRC-002" ], "findings": [ { "id": "build-platform-identity", "name": "Build Platform Identity and Declared Assurance", "description": "The identity of the trusted build platform and the assurance properties claimed for it.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ], "questions": [ { "id": "platform-q-id", "text": "Which builder identity represents the transitive closure of the trusted build platform for this release?", "kind": "identity", "answer_data": [ "builder.id TypeURI", "Component-to-version map for the platform" ] }, { "id": "platform-q-level", "text": "What build assurance level is claimed for this platform, and who asserts it?", "kind": "evidence", "answer_data": [ "Declared build level code", "Reference to the assessment or attestation asserting it" ] }, { "id": "platform-q-isolation", "text": "Which isolation properties are claimed: hosted, isolated between runs, and ephemeral per run?", "kind": "security", "answer_data": [ "Isolation property set with per-property claim", "Basis or evidence reference for each claim" ] }, { "id": "platform-q-enforcement", "text": "Which party operates and enforces those platform controls?", "kind": "ownership", "answer_data": [ "Operating organisation reference", "Statement that control operation and enforcement are outside this model" ] } ], "data_elements": [ { "id": "builder-id", "name": "Builder identity", "description": "URI identifying the trusted build platform closure.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "builder-version-map", "name": "Builder version map", "description": "Platform component names mapped to versions.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "build-assurance-level", "name": "Declared build level", "description": "Build track level claimed for the producing platform.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "isolation-property-set", "name": "Isolation properties", "description": "Claimed hosted, isolated and ephemeral properties.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "These are identifier and claim values that must sit inside the provenance for a verifier to compare against expectations. The platform's own assessment reports, control descriptions and operational evidence are produced and owned by the platform operator; this model records the identity and the claim, and references the assessment rather than restating it." }, { "id": "build-run-record", "name": "Build Run Execution Record", "description": "The specific invocation that produced the artifacts, its timing and its byproducts.", "source_refs": [ "SRC-001", "SRC-002", "SRC-007" ], "questions": [ { "id": "run-q-invocation", "text": "Which invocation identifier distinguishes this build run from every other run of the same definition?", "kind": "identity", "answer_data": [ "Globally unique, opaque, case-sensitive invocation identifier", "Issuing build platform reference" ] }, { "id": "run-q-timing", "text": "When did the build start and finish, and in which time reference were those values asserted?", "kind": "temporal", "answer_data": [ "startedOn and finishedOn as RFC 3339 values with seconds and explicit offset or Z", "Asserting party and normalisation note" ] }, { "id": "run-q-byproducts", "text": "Which byproducts and logs did the run emit, and which of them are retained as evidence?", "kind": "event", "answer_data": [ "Byproduct descriptors with digests", "Retention indicator per byproduct" ] }, { "id": "run-q-ingestion", "text": "When was this run record observed and ingested into the release record, as distinct from when the build ran?", "kind": "provenance", "answer_data": [ "Observation or ingestion timestamp", "Ingesting system reference" ] } ], "data_elements": [ { "id": "build-invocation-id", "name": "Build invocation identifier", "description": "Opaque unique identifier of the build run.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "build-started-on", "name": "Build start time", "description": "Event time at which the build run started.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "build-finished-on", "name": "Build finish time", "description": "Event time at which the build run finished.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "build-run-observed-at", "name": "Run record observation time", "description": "Ingestion time of the run record, distinct from event time.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "byproduct-descriptor", "name": "Byproduct descriptor", "description": "Descriptor for a log or side output of the run.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [ { "id": "build-run-record-artifact", "name": "Build run record", "description": "The runDetails capture for one invocation: builder, invocation identifier, start and finish times, and byproduct descriptors including build logs.", "media_or_form": [ "SLSA runDetails object", "Build execution log", "Byproduct descriptor set" ], "serial": true, "identity_strategy": "Platform-issued invocation identifier is authoritative; the record digest binds the captured content to that invocation.", "source_refs": [ "SRC-001", "SRC-007" ] } ], "inline_only_rationale": null } ] }, { "id": "reproducibility", "name": "Reproducibility", "description": "Whether and under what conditions the release artifacts can be recreated bit-for-bit, and what independent rebuilds found.", "source_refs": [ "SRC-012", "SRC-001" ], "findings": [ { "id": "reproducibility-declaration", "name": "Reproducibility Declaration and Build Environment Record", "description": "The claim made about reproducibility together with the recorded build environment attributes needed to act on that claim.", "source_refs": [ "SRC-001", "SRC-007", "SRC-012" ], "questions": [ { "id": "repro-q-claim", "text": "Is this release declared reproducible, and under exactly which conditions does the claim hold?", "kind": "quality", "answer_data": [ "Reproducibility claim code", "Stated conditions: source revision, environment, instructions" ] }, { "id": "repro-q-environment", "text": "Which build environment attributes are recorded so a third party can recreate them?", "kind": "provenance", "answer_data": [ "Environment descriptor: toolchain, base image digest, locale, environment variables", "Compiler, linker and hardening flag set" ] }, { "id": "repro-q-timestamps", "text": "How are embedded timestamps and other varying inputs normalised during the build?", "kind": "constraint", "answer_data": [ "Normalisation mechanism, such as a fixed source date epoch value", "Enumerated inputs held constant" ] }, { "id": "repro-q-nondeterminism", "text": "Which sources of nondeterminism are known to remain, and what is their effect on comparison?", "kind": "exception", "answer_data": [ "Known nondeterminism notes with affected artifacts", "Comparison tolerance or normalisation step required" ] } ], "data_elements": [ { "id": "reproducibility-claim", "name": "Reproducibility claim", "description": "Declared reproducibility status of the build.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "build-environment-descriptor", "name": "Build environment descriptor", "description": "Recorded toolchain, base image and environment attributes.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "source-date-epoch", "name": "Normalised build date value", "description": "Fixed timestamp value used to remove build-time variance.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "hardening-flag-set", "name": "Build hardening flags", "description": "Compiler and linker settings applied to improve executable security.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "known-nondeterminism-note", "name": "Known nondeterminism", "description": "Documented residual variance between rebuilds.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "build-environment-specification", "name": "Build environment specification", "description": "Recorded declaration of the build environment and instructions sufficient for an independent party to attempt an identical rebuild.", "media_or_form": [ "Build environment record file", "Build container image reference with digest", "Toolchain and flag manifest" ], "serial": false, "identity_strategy": "Digest of the environment record, bound to the build invocation identifier and the release identifier.", "source_refs": [ "SRC-007", "SRC-012" ] } ], "inline_only_rationale": null }, { "id": "rebuild-verification-record", "name": "Independent Rebuild Verification", "description": "Outcomes of attempts by independent parties to recreate the release artifacts and compare them bit-for-bit.", "source_refs": [ "SRC-012", "SRC-005" ], "questions": [ { "id": "rebuild-q-who", "text": "Which independent party performed the rebuild, and what is their relationship to the original producer?", "kind": "provenance", "answer_data": [ "Rebuilder identity reference", "Independence classification" ] }, { "id": "rebuild-q-outcome", "text": "Did the rebuild produce bit-for-bit identical artifacts, and for which artifacts specifically?", "kind": "measurement", "answer_data": [ "Per-artifact outcome code and digest comparison result", "Count of matching and diverging artifacts" ] }, { "id": "rebuild-q-divergence", "text": "Where outputs diverged, what differed and was the cause identified?", "kind": "validation", "answer_data": [ "Divergence summary with affected byte ranges or sections", "Attributed cause code" ] }, { "id": "rebuild-q-when", "text": "When was the rebuild performed and observed, relative to the original build?", "kind": "temporal", "answer_data": [ "Rebuild event time and observation time as RFC 3339 values", "Elapsed interval since the original build" ] } ], "data_elements": [ { "id": "rebuilder-identity-ref", "name": "Rebuilder identity", "description": "Reference to the party performing the rebuild.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "rebuild-outcome-code", "name": "Rebuild outcome", "description": "Match, partial match or divergence result.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "rebuild-observed-at", "name": "Rebuild observation time", "description": "Time the rebuild result was recorded.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "rebuild-divergence-summary", "name": "Divergence summary", "description": "Description of differences found during comparison.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "rebuild-comparison-report", "name": "Rebuild comparison report", "description": "Report of a bit-by-bit comparison between the published artifacts and an independently rebuilt set, including any divergences.", "media_or_form": [ "Binary comparison or diff report", "Rebuild attestation", "Hash comparison table" ], "serial": true, "identity_strategy": "Digest of the report plus the rebuilder identity and the compared artifact digests; sequence assigned per release for successive rebuild attempts.", "source_refs": [ "SRC-005", "SRC-012" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "integrity-and-attestation", "name": "Integrity, Attestation and Declared Expectations", "description": "How evidence is cryptographically bound to the release artifacts, and what the producer declares a consumer should expect.", "rationale": "SLSA and in-toto separate the artifact from the signed statements about it, and separate producer declarations from verifier action. Modelling the binding and the declaration — without modelling evaluation — is what keeps this model inside its boundary while still being useful.", "source_refs": [ "SRC-003", "SRC-005", "SRC-006", "SRC-013" ], "layers": [ { "id": "attestation-binding", "name": "Attestation and Signature Binding", "description": "Which signed statements cover which artifacts, and which references establish signer and trust anchor.", "source_refs": [ "SRC-004", "SRC-005", "SRC-006" ], "findings": [ { "id": "attestation-statement-binding", "name": "Attestation Statement Binding", "description": "The attestation statements that apply to this release, how their subjects bind to artifact digests, and which predicate types and spec versions they carry.", "source_refs": [ "SRC-001", "SRC-004", "SRC-005" ], "questions": [ { "id": "attest-q-which", "text": "Which attestation statements apply to this release, and what does each assert?", "kind": "evidence", "answer_data": [ "Statement references with predicate type URIs", "Assertion summary per statement" ] }, { "id": "attest-q-subject", "text": "How does each statement bind to the release artifacts, and what happens if a digest does not match?", "kind": "validation", "answer_data": [ "Subject descriptors with digest sets", "Non-match handling declaration" ] }, { "id": "attest-q-version", "text": "Which specification version does each predicate conform to, given that the predicate type URI may be stable across versions?", "kind": "interoperability", "answer_data": [ "Predicate type URI", "Separately recorded specification version code" ] }, { "id": "attest-q-envelope", "text": "In which envelope and media type is each attestation carried?", "kind": "interoperability", "answer_data": [ "Envelope format and media type", "Bundle format when multiple statements travel together" ] } ], "data_elements": [ { "id": "attestation-statement-ref", "name": "Attestation statement reference", "description": "Reference to a statement covering this release.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "attestation-subject-digest", "name": "Attestation subject digest", "description": "Digest set by which a statement binds to an artifact.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "predicate-type-uri", "name": "Predicate type URI", "description": "TypeURI naming the predicate carried by a statement.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "predicate-spec-version", "name": "Predicate specification version", "description": "Version of the predicate specification actually used.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [ { "id": "attestation-statement", "name": "Attestation statement", "description": "A signed statement whose subject is one or more release artifacts, carrying a typed predicate such as build provenance.", "media_or_form": [ "in-toto Statement document", "Signed envelope", "Attestation bundle in line-delimited form" ], "serial": false, "identity_strategy": "Subject digest set is authoritative for binding; the statement itself is addressed by its own content digest and its predicate type URI plus recorded spec version.", "source_refs": [ "SRC-004", "SRC-005" ] } ], "inline_only_rationale": null }, { "id": "signature-and-trust-anchor-reference", "name": "Signature and Trust Anchor References", "description": "References to the signatures covering release artifacts and attestations, the asserted signer identity, and where the trust anchor is documented.", "source_refs": [ "SRC-003", "SRC-007", "SRC-013" ], "questions": [ { "id": "signature-q-coverage", "text": "Which signatures cover which artifacts and attestations of this release?", "kind": "evidence", "answer_data": [ "Signature references mapped to covered digests", "Detached or embedded indicator" ] }, { "id": "signature-q-signer", "text": "Which signer identity or key is asserted by each signature?", "kind": "identity", "answer_data": [ "Signer identity reference or key identifier", "Algorithm code" ] }, { "id": "signature-q-anchor", "text": "Where is the trust anchor for these signatures documented for consumers?", "kind": "access", "answer_data": [ "Trust anchor or root-of-trust document reference", "Publication location for key material fingerprints" ] }, { "id": "signature-q-ownership", "text": "Which party owns key custody, rotation and the execution of signature verification?", "kind": "ownership", "answer_data": [ "Key management owner reference", "Statement that signing and verification execution are outside this model" ] } ], "data_elements": [ { "id": "signature-ref", "name": "Signature reference", "description": "Reference to a signature covering release content.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "signer-identity-ref", "name": "Signer identity reference", "description": "Asserted identity or key associated with a signature.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "trust-anchor-ref", "name": "Trust anchor reference", "description": "Pointer to documented roots of trust for consumers.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "signature-algorithm-code", "name": "Signature algorithm", "description": "Algorithm identifier used for the signature.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [], "inline_only_rationale": "Only pointers belong here. The signature blobs, key material and trust-anchor documents are produced and governed by the signing and key-management function, and transparency-log entries are records of a separate service. Carrying references keeps a release record self-describing; carrying the objects themselves would claim ownership of key custody and verification execution, which this model explicitly disclaims." } ] }, { "id": "declared-expectations", "name": "Declared Verification Expectations", "description": "What the producer publishes for consumers to check against, and the freshness constraints of the channel.", "source_refs": [ "SRC-003", "SRC-013" ], "findings": [ { "id": "verification-expectations", "name": "Producer-Published Verification Expectations and Freshness Constraints", "description": "The expectation values a producer publishes so that a consumer can decide whether a release is the one it intended to obtain, plus declared anti-rollback and freshness constraints.", "source_refs": [ "SRC-003", "SRC-013" ], "questions": [ { "id": "expect-q-values", "text": "Which expectation values does the producer publish for this release?", "kind": "requirement", "answer_data": [ "Expected builder identity, canonical source URI and buildType", "Permitted external parameter names and values" ] }, { "id": "expect-q-authority", "text": "Who is authorised to set these expectations, and how is that declaration itself authenticated?", "kind": "authority", "answer_data": [ "Expectation authority reference", "Authentication mechanism for the declaration" ] }, { "id": "expect-q-reject", "text": "What conditions does the producer state should cause a consumer to reject this release?", "kind": "constraint", "answer_data": [ "Enumerated rejection conditions", "Handling rule for unrecognised external parameter fields" ] }, { "id": "expect-q-freshness", "text": "Which anti-rollback and freshness constraints apply to this release within its channel?", "kind": "temporal", "answer_data": [ "Minimum acceptable version or monotonic counter value", "Channel metadata expiry time as an RFC 3339 value" ] }, { "id": "expect-q-evaluator", "text": "Which party evaluates these expectations, and where is the outcome recorded?", "kind": "ownership", "answer_data": [ "Evaluating role: package ecosystem, consumer or monitor", "Statement that evaluation, enforcement and outcome records lie outside this model" ] } ], "data_elements": [ { "id": "expected-builder-id", "name": "Expected builder identity", "description": "Builder identity a consumer should require.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "expected-source-uri", "name": "Expected source repository", "description": "Canonical source repository a consumer should require.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "allowed-external-parameters", "name": "Permitted external parameters", "description": "External parameter names and values considered acceptable.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "channel-minimum-version", "name": "Minimum acceptable version", "description": "Monotonic floor protecting against rollback within a channel.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "channel-metadata-expiry", "name": "Channel metadata expiry", "description": "Time after which channel metadata is no longer fresh.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [ { "id": "published-verification-expectations", "name": "Published verification expectations", "description": "Producer-authored, authenticated declaration of what a consumer should expect of this release's provenance and channel position. It is a declaration only: no evaluation logic, decision outcome or enforcement record is held here.", "media_or_form": [ "Producer-published expectations document", "Source-defined expectations file in the canonical repository", "Channel metadata declaration" ], "serial": false, "identity_strategy": "Digest of the declaration bound to the release identifier and, where applicable, to the channel identifier; superseded declarations are retained by digest, never overwritten.", "source_refs": [ "SRC-003", "SRC-013" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "release-lifecycle-and-authority", "name": "Release Lifecycle and Authority", "description": "The states a release passes through, who authorises transitions, what users are told, and how long it is supported.", "rationale": "A release is not only a set of files: it has a governed lifecycle with approval, communication and support obligations. Semantic Versioning fixes content immutability while withdrawal and end-of-support change availability and obligations without changing content.", "source_refs": [ "SRC-007", "SRC-008", "SRC-013", "SRC-014" ], "layers": [ { "id": "lifecycle-states", "name": "Lifecycle States and Supersession", "description": "State model of a release and the semantics of superseding or withdrawing it.", "source_refs": [ "SRC-008", "SRC-013", "SRC-014" ], "findings": [ { "id": "release-state-model", "name": "Release State Model and Transitions", "description": "The states a release occupies, the evidence required to enter each, and when each transition occurred.", "source_refs": [ "SRC-002", "SRC-007", "SRC-008" ], "questions": [ { "id": "state-q-enumerate", "text": "Which states can a release occupy in this Dimension, and which are terminal?", "kind": "lifecycle", "answer_data": [ "Enumerated state codes with permitted transitions", "Terminal state indicator" ] }, { "id": "state-q-evidence", "text": "What evidence must exist before a release may enter its published state?", "kind": "requirement", "answer_data": [ "Required evidence references per transition", "Blocking condition list" ] }, { "id": "state-q-timing", "text": "When did each state transition occur, and when was it observed by the recording system?", "kind": "temporal", "answer_data": [ "Transition event time as an RFC 3339 value with offset", "Separate observation or ingestion time" ] }, { "id": "state-q-conflict", "text": "When two systems report different states for the same release, which record is authoritative?", "kind": "state", "answer_data": [ "Authoritative system reference", "Conflict resolution rule and precedence order" ] } ], "data_elements": [ { "id": "release-state-code", "name": "Release state", "description": "Current lifecycle state of the release record.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-008" ] }, { "id": "state-entered-at", "name": "State entry time", "description": "Event time at which the release entered this state.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "state-observed-at", "name": "State observation time", "description": "Time the state was recorded, distinct from entry time.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "state-transition-reason", "name": "Transition reason", "description": "Coded reason for entering the state.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [], "inline_only_rationale": "The state model is a controlled vocabulary plus timestamps on the release record itself. Transition approval records and any audit trail of who changed what are governance records owned by the adopting Dimension; this finding references them rather than reproducing them, so no document form is declared here." }, { "id": "supersession-and-withdrawal", "name": "Supersession and Withdrawal", "description": "How a release is replaced or withdrawn without violating the immutability of its published content.", "source_refs": [ "SRC-008", "SRC-013", "SRC-014" ], "questions": [ { "id": "withdraw-q-successor", "text": "Which release supersedes this one, and does the successor fully replace it?", "kind": "relationship", "answer_data": [ "Successor release reference", "Replacement scope: full, partial or security-only" ] }, { "id": "withdraw-q-reason", "text": "If this release is withdrawn, what is the coded reason and when did withdrawal take effect?", "kind": "event", "answer_data": [ "Withdrawal reason code with narrative", "Effective time as an RFC 3339 value with offset" ] }, { "id": "withdraw-q-immutability", "text": "How does withdrawal change availability without modifying the artifact content already published under this version?", "kind": "constraint", "answer_data": [ "Availability class after withdrawal", "Confirmation that digests and content are unchanged" ] }, { "id": "withdraw-q-retrievability", "text": "What remains retrievable after withdrawal so that historical builds can still be reproduced and audited?", "kind": "retention", "answer_data": [ "Retained artifact and evidence inventory", "Retrieval path and conditions" ] } ], "data_elements": [ { "id": "superseded-by-ref", "name": "Superseded-by reference", "description": "Reference to the release that replaces this one.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "withdrawal-reason-code", "name": "Withdrawal reason", "description": "Coded reason for withdrawing the release.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "withdrawal-effective-at", "name": "Withdrawal effective time", "description": "Time from which withdrawal applies.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "post-withdrawal-availability", "name": "Post-withdrawal availability", "description": "Availability class of artifacts after withdrawal.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "withdrawal-notice", "name": "Withdrawal or deprecation notice", "description": "Notice recording that a release has been withdrawn, deprecated or superseded, with reason, effective time and successor pointer.", "media_or_form": [ "Withdrawal or yank notice document", "Deprecation record in the distribution channel", "Advisory-linked notice reference" ], "serial": false, "identity_strategy": "Bound to the withdrawn release identifier; the notice is addressed by its own digest and never replaces or mutates the withdrawn release's artifacts.", "source_refs": [ "SRC-008", "SRC-013", "SRC-014" ] } ], "inline_only_rationale": null } ] }, { "id": "authority-and-communication", "name": "Authority, Change Content and Support", "description": "Who authorised the release, what changed, and what commitment is made to users.", "source_refs": [ "SRC-007", "SRC-014" ], "findings": [ { "id": "release-authority-and-approval", "name": "Release Authority and Approval References", "description": "Accountability for the release and references to the decisions that authorised its publication.", "source_refs": [ "SRC-002", "SRC-007", "SRC-014" ], "questions": [ { "id": "authority-q-owner", "text": "Which party is accountable for this release once published?", "kind": "ownership", "answer_data": [ "Accountable owner reference and role", "Organisational scope of accountability" ] }, { "id": "authority-q-approval", "text": "Who authorised publication, acting in which role, and against which criteria?", "kind": "authority", "answer_data": [ "Approver reference with role code", "Approval criteria or gate definition reference" ] }, { "id": "authority-q-evidence", "text": "Which decision records evidence the approval, and where are they held?", "kind": "evidence", "answer_data": [ "Approval decision record references", "Holding system reference" ] }, { "id": "authority-q-segregation", "text": "Was the release approved by a party distinct from the one that produced it?", "kind": "security", "answer_data": [ "Segregation-of-duties indicator", "Identities compared in making that determination" ] } ], "data_elements": [ { "id": "release-owner-ref", "name": "Accountable owner", "description": "Party accountable for the published release.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-014" ] }, { "id": "approval-decision-ref", "name": "Approval decision reference", "description": "Pointer to the decision record authorising publication.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "approver-role-code", "name": "Approver role", "description": "Role in which the approval was granted.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "segregation-of-duties-flag", "name": "Segregation of duties indicator", "description": "Whether producer and approver are distinct parties.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "This finding deliberately holds references only. Approval decision records, workflow history and the audit trail of who approved what are governance and audit artifacts owned by the adopting Dimension; materialising them here would give this model ownership of audit-trail semantics it explicitly disclaims. The release record carries the pointer and the accountable-owner value, nothing more." }, { "id": "change-content-and-release-notes", "name": "Change Content and Release Notes", "description": "What changed in this release, which changes are breaking or security-relevant, and what users must be told.", "source_refs": [ "SRC-008", "SRC-014" ], "questions": [ { "id": "notes-q-changes", "text": "What changed in this release relative to its predecessor?", "kind": "composition", "answer_data": [ "Change entries with type and affected component", "Predecessor release reference used for comparison" ] }, { "id": "notes-q-breaking", "text": "Which changes break a published interface or documented behaviour?", "kind": "classification", "answer_data": [ "Breaking-change descriptors with affected interfaces", "Migration guidance reference" ] }, { "id": "notes-q-security", "text": "Which security fixes does this release carry, and which advisories or vulnerability identifiers do they reference?", "kind": "relationship", "answer_data": [ "Security-fix references with external vulnerability identifiers", "Statement that advisory authoring is owned elsewhere" ] }, { "id": "notes-q-user-action", "text": "What action must a user take on adopting this release?", "kind": "requirement", "answer_data": [ "User-action-required indicator", "Instructions or documentation reference" ] } ], "data_elements": [ { "id": "change-entry", "name": "Change entry", "description": "One described change carried by the release.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "breaking-change-descriptor", "name": "Breaking change descriptor", "description": "Description of an interface-breaking change.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "security-fix-ref", "name": "Security fix reference", "description": "Reference to a vulnerability fixed in this release.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "user-action-required", "name": "User action required", "description": "Whether adopting the release requires user action.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] } ], "artifacts": [ { "id": "release-notes", "name": "Release notes", "description": "User-facing statement of what changed, which changes are breaking, which security issues are fixed, and what action adopters must take.", "media_or_form": [ "Release notes document", "Changelog entry", "User-facing update notice" ], "serial": false, "identity_strategy": "Bound to the release identifier and addressed by content digest so that the published text is itself verifiable and non-repudiable.", "source_refs": [ "SRC-008", "SRC-014" ] } ], "inline_only_rationale": null }, { "id": "support-period-declaration", "name": "Support Period and End-of-Support Declaration", "description": "The period for which this release will receive vulnerability handling and security updates, and how end of support is communicated.", "source_refs": [ "SRC-013", "SRC-014" ], "questions": [ { "id": "support-q-duration", "text": "For how long, and until which date, is this release supported with security updates?", "kind": "requirement", "answer_data": [ "Support start and support end dates", "Support class code, for example standard or long-term" ] }, { "id": "support-q-basis", "text": "On what basis was the support period determined?", "kind": "decision", "answer_data": [ "Determination basis: expected product lifetime, regulatory floor or contractual commitment", "Applicable regime reference" ] }, { "id": "support-q-notify", "text": "How and when are users informed that support for this release is ending?", "kind": "process", "answer_data": [ "Notification mechanism and lead time", "Notice reference and publication location" ] }, { "id": "support-q-inheritance", "text": "How does this release's support window relate to the product-level support commitment?", "kind": "relationship", "answer_data": [ "Product-level support reference", "Inheritance or override indicator" ] } ], "data_elements": [ { "id": "support-start-date", "name": "Support start", "description": "Date from which the release is supported.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "support-end-date", "name": "Support end", "description": "Date on which security update provision ends.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "support-class-code", "name": "Support class", "description": "Category of support commitment for the release.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "eol-notice-ref", "name": "End-of-support notice reference", "description": "Pointer to the notice informing users of support end.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] } ], "artifacts": [ { "id": "support-statement", "name": "Support period statement", "description": "Declaration of the support period and end-of-support date for the release, in the form made available to users alongside the product.", "media_or_form": [ "Support period statement", "End-of-support notice to users", "Product documentation section" ], "serial": false, "identity_strategy": "Bound to the release identifier and to the parent product; addressed by content digest with the declared support end date as an attribute, never as an identifier.", "source_refs": [ "SRC-014" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "distribution-and-retention", "name": "Distribution, Provenance Availability and Retention", "description": "Where a release is published and made obtainable, how its provenance travels with it, and how it is archived and eventually disposed of.", "rationale": "SSDF PS.3 requires each release to be archived with its integrity and provenance data, and SLSA requires provenance to reach consumers. Both are release-side obligations that end where installation begins.", "source_refs": [ "SRC-004", "SRC-007", "SRC-013" ], "layers": [ { "id": "publication", "name": "Publication and Provenance Availability", "description": "Where the release is obtainable and how its evidence is discovered alongside it.", "source_refs": [ "SRC-004", "SRC-009", "SRC-013" ], "findings": [ { "id": "distribution-target-and-coordinates", "name": "Distribution Targets and Coordinates", "description": "Where the release is published, the coordinates that identify it in each target, and its availability scope.", "source_refs": [ "SRC-004", "SRC-009", "SRC-013" ], "questions": [ { "id": "dist-q-targets", "text": "To which registries, repositories or download locations is this release published?", "kind": "spatial", "answer_data": [ "Target references with type code", "Publication time per target" ] }, { "id": "dist-q-coordinates", "text": "Which coordinates identify the release within each target?", "kind": "identity", "answer_data": [ "Per-target coordinate string, for example a purl or image reference", "Digest pin accompanying each coordinate" ] }, { "id": "dist-q-availability", "text": "Is the release publicly obtainable, restricted, or embargoed until a stated time?", "kind": "access", "answer_data": [ "Availability class code", "Embargo lift time as an RFC 3339 value where applicable" ] }, { "id": "dist-q-canonical", "text": "Which target is canonical when the same release appears in several places?", "kind": "authority", "answer_data": [ "Canonical target reference", "Mirror or replica designation for the others" ] } ], "data_elements": [ { "id": "distribution-target-ref", "name": "Distribution target", "description": "Registry, repository or location holding the release.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "distribution-coordinates", "name": "Target coordinates", "description": "Identifier locating the release within a target.", "value_kind": "identifier", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-009" ] }, { "id": "availability-class", "name": "Availability class", "description": "Public, restricted or embargoed obtainability.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-013" ] }, { "id": "canonical-target-flag", "name": "Canonical target indicator", "description": "Marks the authoritative publication target.", "value_kind": "boolean", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [], "inline_only_rationale": "Publication coordinates are reference values that belong on the release record so that any consumer can resolve the release without a separate document. Registry catalogue entries and channel metadata are produced and owned by the distribution service; treating them as artifacts of this model would drag registry operation inside the boundary." }, { "id": "provenance-co-distribution", "name": "Provenance Co-Distribution and Discovery", "description": "How attestations and provenance are made discoverable next to the artifacts they describe.", "source_refs": [ "SRC-004", "SRC-002" ], "questions": [ { "id": "prov-dist-q-where", "text": "Where is the provenance for this release published so that a consumer can find it?", "kind": "access", "answer_data": [ "Provenance publication location per artifact", "Discovery mechanism code" ] }, { "id": "prov-dist-q-naming", "text": "Which naming or attachment convention relates each provenance document to its artifact?", "kind": "interoperability", "answer_data": [ "Sidecar filename convention applied", "Registry attachment or referrer mechanism used" ] }, { "id": "prov-dist-q-who", "text": "Does the producer distribute provenance directly, or does the package ecosystem do so on their behalf?", "kind": "process", "answer_data": [ "Distributor role code", "Delegation agreement reference" ] }, { "id": "prov-dist-q-missing", "text": "What is the declared state when provenance is unavailable for a published artifact?", "kind": "exception", "answer_data": [ "Provenance availability state code", "Declared consumer guidance for that state" ] } ], "data_elements": [ { "id": "provenance-location-ref", "name": "Provenance location", "description": "Where provenance for an artifact is published.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "provenance-naming-convention", "name": "Provenance naming convention", "description": "Convention relating provenance files to artifacts.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "provenance-distributor-role", "name": "Provenance distributor role", "description": "Party responsible for distributing provenance.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "provenance-availability-state", "name": "Provenance availability state", "description": "Whether provenance is available for each artifact.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "attestation-bundle", "name": "Attestation bundle", "description": "The packaged set of attestations distributed alongside the release artifacts, named or attached so consumers can discover it from the artifact reference.", "media_or_form": [ "Line-delimited attestation bundle sidecar file", "Registry attachment or referrer object", "Source-repository release asset" ], "serial": false, "identity_strategy": "Content digest of the bundle, resolvable from the artifact descriptor via the declared naming or attachment convention.", "source_refs": [ "SRC-004" ] } ], "inline_only_rationale": null } ] }, { "id": "archival-and-retention", "name": "Archival and Retention", "description": "What is preserved for each release and for how long.", "source_refs": [ "SRC-007", "SRC-014" ], "findings": [ { "id": "release-archive-record", "name": "Release Archive Record", "description": "The archived set of files and supporting data preserved for a release, including integrity verification information and provenance data.", "source_refs": [ "SRC-007", "SRC-012" ], "questions": [ { "id": "archive-q-inventory", "text": "Which files and supporting data are archived for this release?", "kind": "composition", "answer_data": [ "Archive content inventory with digests", "Inclusion rule applied when assembling it" ] }, { "id": "archive-q-integrity", "text": "How is the archive protected against undetected alteration?", "kind": "validation", "answer_data": [ "Archive integrity digest and algorithm", "Integrity check schedule or trigger" ] }, { "id": "archive-q-location", "text": "Where is the archive held, and under whose custody?", "kind": "ownership", "answer_data": [ "Storage location reference", "Custodian party reference" ] }, { "id": "archive-q-retrieval", "text": "Who may retrieve the archive, and how long does retrieval take?", "kind": "access", "answer_data": [ "Authorised retriever roles", "Retrieval mechanism and expected latency" ] } ], "data_elements": [ { "id": "archive-location-ref", "name": "Archive location", "description": "Where the release archive is stored.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "archive-content-inventory", "name": "Archive inventory", "description": "Enumeration of archived files and supporting data.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "archive-integrity-digest", "name": "Archive integrity digest", "description": "Digest protecting the archived content.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "archive-created-at", "name": "Archive creation time", "description": "Time the archive was assembled.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "release-archive-bundle", "name": "Release archive bundle", "description": "The preserved bundle of release files and supporting data — integrity verification information, provenance and build inputs — retained so the release can be examined or reproduced later.", "media_or_form": [ "Archive bundle of release files and supporting data", "Cold-storage snapshot manifest", "Checksum-protected archive index" ], "serial": true, "identity_strategy": "Release identifier plus archive content digest; successive archive generations for the same release carry a zero-padded sequence, never a date, in their name.", "source_refs": [ "SRC-007", "SRC-012" ] } ], "inline_only_rationale": null }, { "id": "retention-disposition-and-tombstone", "name": "Retention, Disposition and Tombstone", "description": "How long release records and archives are kept, what disposition applies when retention lapses, and what remains as a tombstone.", "source_refs": [ "SRC-007", "SRC-014" ], "questions": [ { "id": "retention-q-class", "text": "Which retention class applies to this release record and its archive, and what sets that class?", "kind": "retention", "answer_data": [ "Retention class code and retention period", "Driving obligation reference, for example a support period or regulatory rule" ] }, { "id": "retention-q-due", "text": "When does disposition become due, and what triggers the clock to start?", "kind": "temporal", "answer_data": [ "Retention-until date", "Trigger event code, for example publication, withdrawal or end of support" ] }, { "id": "retention-q-remains", "text": "What remains discoverable after disposition, and in what form?", "kind": "exception", "answer_data": [ "Tombstone record fields retained", "Fields and payloads removed" ] }, { "id": "retention-q-executor", "text": "Which party executes disposition, and where is execution recorded?", "kind": "ownership", "answer_data": [ "Executing policy or system reference", "Statement that deletion execution and its audit record lie outside this model" ] } ], "data_elements": [ { "id": "retention-class-code", "name": "Retention class", "description": "Retention category applied to the release record.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "retention-until", "name": "Retention until", "description": "Date after which disposition may proceed.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "disposition-action-code", "name": "Disposition action", "description": "Action taken when retention lapses.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "tombstone-record", "name": "Tombstone record", "description": "Minimal surviving record of a disposed release.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [], "inline_only_rationale": "Retention is expressed as coded policy values and dates on the release record plus a minimal tombstone structure. The records-management policy, the deletion mechanism and the log of executed disposals belong to the adopting Dimension's storage and governance layers; declaring an artifact here would imply this model performs or evidences deletion, which it does not." } ] } ] }, { "id": "evidence-linkage-and-interoperability", "name": "External Evidence Linkage and Interoperability", "description": "Typed references from a release to evidence and documentation owned by other models, and the mapping of this record onto external schemas.", "rationale": "The relation ledger makes SBOM and test evidence external models. This bundle exists to hold the binding — reference, digest, purpose — without importing their content, and to make explicit which external schemas a release record projects onto.", "source_refs": [ "SRC-001", "SRC-007", "SRC-014" ], "layers": [ { "id": "external-evidence-references", "name": "External Evidence References", "description": "Bindings from a release to SBOM documents and test evidence records held in sibling models.", "source_refs": [ "SRC-007", "SRC-014" ], "findings": [ { "id": "sbom-reference-binding", "name": "SBOM Reference Binding", "description": "How a release points at the SBOM documents that describe it, without reproducing their content.", "source_refs": [ "SRC-001", "SRC-007", "SRC-014" ], "questions": [ { "id": "sbom-q-which", "text": "Which SBOM documents describe this release, and at which lifecycle stage was each generated?", "kind": "relationship", "answer_data": [ "SBOM document references with digests", "Generation stage code, for example source, build or analysed" ] }, { "id": "sbom-q-binding", "text": "How is each SBOM bound to this specific release rather than to the product generally?", "kind": "validation", "answer_data": [ "Binding subject digests shared with the release artifacts", "Binding mechanism, for example attestation subject or manifest entry" ] }, { "id": "sbom-q-authoritative", "text": "When several SBOMs exist for one release, which is authoritative for consumers?", "kind": "authority", "answer_data": [ "Authoritative SBOM reference", "Precedence rule and its declaring party" ] }, { "id": "sbom-q-boundary", "text": "Which facts about components does this model deliberately not record?", "kind": "ownership", "answer_data": [ "Statement that component inventory, licence facts, dependency graph and VEX belong to WM-SFT-012", "Reference to that model as the owner" ] } ], "data_elements": [ { "id": "sbom-document-ref", "name": "SBOM document reference", "description": "Pointer to an SBOM describing this release.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "sbom-binding-digest", "name": "SBOM binding digest", "description": "Digest binding an SBOM to release artifacts.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "sbom-format-declaration", "name": "Declared SBOM format", "description": "Format and version the referenced SBOM uses.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "sbom-generation-stage", "name": "SBOM generation stage", "description": "Lifecycle stage at which the SBOM was produced.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [], "inline_only_rationale": "The relation to WM-SFT-012 is an outgoing REFERENCE, so this model may carry the target reference, the binding and subject-specific parameters, but not the target's content or lifecycle. Declaring an SBOM artifact here would reproduce a document that WM-SFT-012 owns and would create two competing masters for component data." }, { "id": "test-evidence-reference-binding", "name": "Test Evidence Reference Binding", "description": "How a release points at the test evidence records that informed its release gates, without owning test semantics.", "source_refs": [ "SRC-002", "SRC-007" ], "questions": [ { "id": "test-q-which", "text": "Which test evidence records did this release reference, and for which gate?", "kind": "relationship", "answer_data": [ "Evidence record references", "Gate name or identifier per reference" ] }, { "id": "test-q-outcome", "text": "What outcome does each referenced evidence record report, as recorded at reference time?", "kind": "evidence", "answer_data": [ "Outcome pointer and summary code", "Time the outcome was observed, as an RFC 3339 value" ] }, { "id": "test-q-subject", "text": "Do the referenced records apply to the exact artifacts in this release?", "kind": "validation", "answer_data": [ "Artifact digests the evidence was produced against", "Match or divergence indicator against the released digests" ] }, { "id": "test-q-boundary", "text": "Which model interprets these results and owns their lifecycle?", "kind": "ownership", "answer_data": [ "Reference to WM-SFT-015 as owner of test design, execution and result semantics", "Statement that only the pointer and gate binding are held here" ] } ], "data_elements": [ { "id": "test-evidence-ref", "name": "Test evidence reference", "description": "Pointer to an evidence record informing a release gate.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "release-gate-name", "name": "Release gate", "description": "Named gate the evidence was referenced for.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "gate-outcome-ref", "name": "Gate outcome pointer", "description": "Pointer to the recorded outcome of the gate.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "evidence-observed-at", "name": "Evidence observation time", "description": "When the evidence outcome was observed by this record.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [], "inline_only_rationale": "The relation to WM-SFT-015 is an outgoing REFERENCE. Test reports, result structures and coverage measures are that model's artifacts; holding a copy here would duplicate its lifecycle. Only the pointer, the gate binding and the subject digests the evidence applies to are recorded inline." } ] }, { "id": "compliance-and-interoperability", "name": "Compliance Linkage and Interoperability", "description": "Regulatory documentation references and the projection of this record onto external schemas.", "source_refs": [ "SRC-010", "SRC-014", "SRC-015" ], "findings": [ { "id": "regulatory-documentation-linkage", "name": "Regulatory and Framework Documentation Linkage", "description": "Which regimes and practice frameworks apply to this release and where the supporting documentation is held.", "source_refs": [ "SRC-007", "SRC-014" ], "questions": [ { "id": "reg-q-regimes", "text": "Which regulatory regimes apply to this release, and on what basis?", "kind": "classification", "answer_data": [ "Applicable regime codes", "Basis of applicability, for example market placed on or product category" ] }, { "id": "reg-q-documentation", "text": "Which technical documentation must reference this release, and where is it held?", "kind": "provenance", "answer_data": [ "Documentation reference and holding system", "Documentation element covering this release" ] }, { "id": "reg-q-claim", "text": "Which secure-development practice framework does the producer claim to follow for this release?", "kind": "decision", "answer_data": [ "Framework and version claimed", "Scope of the claim" ] }, { "id": "reg-q-evidence", "text": "What evidence supports that claim, and what is explicitly not claimed?", "kind": "quality", "answer_data": [ "Supporting evidence references", "Explicit non-conformance or unassessed areas" ] } ], "data_elements": [ { "id": "applicable-regime-code", "name": "Applicable regime", "description": "Regulatory regime engaged by this release.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "regulatory-documentation-ref", "name": "Regulatory documentation reference", "description": "Pointer to technical documentation covering the release.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "practice-framework-claim", "name": "Practice framework claim", "description": "Secure-development framework claimed for this release.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "claim-evidence-ref", "name": "Claim evidence reference", "description": "Evidence supporting a framework or regime claim.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [], "inline_only_rationale": "Technical documentation, conformity assessment files and framework attestations are produced and maintained under the product-level compliance function and are subject to their own retention and disclosure rules. This model records which regimes engage a release and where the documents live; producing the documents here would misplace ownership and duplicate a regulated record set." }, { "id": "interoperability-profile", "name": "Interoperability Profile and Schema Projection", "description": "Which external schemas a release record projects onto, which fields map losslessly, and where conflicts require a decision.", "source_refs": [ "SRC-001", "SRC-005", "SRC-008", "SRC-009", "SRC-010", "SRC-015" ], "questions": [ { "id": "interop-q-targets", "text": "Which external schemas does this release record project onto?", "kind": "interoperability", "answer_data": [ "Target schema references with pinned versions", "Direction of projection per target" ] }, { "id": "interop-q-lossless", "text": "Which fields map losslessly, and which lose information in projection?", "kind": "measurement", "answer_data": [ "Field mapping entries with fidelity code", "Enumerated lossy mappings and what is lost" ] }, { "id": "interop-q-conflicts", "text": "Where do target schemas conflict with this model's rules, and how is each conflict resolved?", "kind": "constraint", "answer_data": [ "Conflict entries with resolution rule", "Field retained to preserve the original value" ] }, { "id": "interop-q-version-pin", "text": "How is the version of each target specification pinned, given that some type URIs remain stable across versions?", "kind": "validation", "answer_data": [ "Separately recorded specification version per target", "Rule forbidding inference of version from type URI alone" ] } ], "data_elements": [ { "id": "target-schema-ref", "name": "Target schema reference", "description": "External schema this record projects onto.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "mapping-entry", "name": "Field mapping entry", "description": "Mapping between a local element and a target field.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "mapping-fidelity-code", "name": "Mapping fidelity", "description": "Whether a mapping is lossless, lossy or unmapped.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "pinned-spec-version", "name": "Pinned specification version", "description": "Recorded version of the target specification used.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001" ] } ], "artifacts": [ { "id": "interoperability-profile-document", "name": "Interoperability profile", "description": "Mapping profile stating how release record elements project onto external schemas, with per-field fidelity and recorded conflicts.", "media_or_form": [ "Field mapping table", "Projection profile document", "Schema binding manifest" ], "serial": false, "identity_strategy": "Profile identifier plus the set of pinned target specification versions; addressed by content digest so a projection can be reproduced exactly.", "source_refs": [ "SRC-001", "SRC-005", "SRC-009", "SRC-010", "SRC-015" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "assign-release-identity", "name": "Assign release identity", "description": "Mint or resolve the authoritative identifier for a release and attach its governed global identifiers and version designation.", "inputs": [ "Parent product or component reference", "Version string and version scheme", "Available master-system identifier or minting request" ], "outputs": [ "Release record with an authoritative identifier", "Governed global identifiers such as purl coordinates" ], "preconditions": [ "A parent component reference resolves", "The version scheme is declared and its precedence rules are known" ], "effects": [ "A stable release identity exists that all later evidence can cite", "Version string alone is never used as the identifier" ], "source_refs": [ "SRC-008", "SRC-009", "SRC-016" ] }, { "id": "record-build-provenance", "name": "Record build provenance", "description": "Capture the build definition and run details for a build run and associate them with the release.", "inputs": [ "buildType and parameter values", "Builder identity and version map", "Invocation identifier and start and finish times" ], "outputs": [ "Build definition record", "Build run record with byproduct descriptors" ], "preconditions": [ "A build run has completed on an identified build platform", "Event times are available with seconds and an explicit offset or Z" ], "effects": [ "The release becomes traceable to a specific invocation and input set", "Observation time is stored separately from build event time" ], "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "bind-artifacts-to-release", "name": "Bind artifacts to release", "description": "Attach artifact descriptors with digests, media types and locations to the release and group platform variants.", "inputs": [ "Artifact files or references", "Digest sets and media types", "Variant and role assignments" ], "outputs": [ "Release manifest with per-artifact descriptors", "Variant index for multi-platform releases" ], "preconditions": [ "Digests have been computed with the declared authoritative algorithm", "Every descriptor carries at least a uri, digest or content value" ], "effects": [ "Artifacts become content-addressed members of the release", "Later attestations can match subjects by digest alone" ], "source_refs": [ "SRC-005", "SRC-006", "SRC-011" ] }, { "id": "register-attestation-reference", "name": "Register attestation reference", "description": "Record an attestation statement and any signature references that cover release artifacts, with their predicate type and recorded specification version.", "inputs": [ "Attestation statement reference and predicate type URI", "Subject digest sets", "Signature and signer identity references" ], "outputs": [ "Attestation binding entries on the release record", "Recorded predicate specification version" ], "preconditions": [ "Subject digests correspond to artifacts already bound to the release", "The specification version is known independently of the predicate type URI" ], "effects": [ "Evidence is discoverable from the release record", "No signature is created or verified by this function" ], "source_refs": [ "SRC-001", "SRC-004", "SRC-005" ] }, { "id": "declare-verification-expectations", "name": "Declare verification expectations", "description": "Publish the producer's expectation values and freshness constraints for a release.", "inputs": [ "Expected builder identity, source URI and buildType", "Permitted external parameter set", "Channel minimum version and metadata expiry" ], "outputs": [ "Published verification expectations declaration" ], "preconditions": [ "An authorised party for setting expectations is identified", "The declaration itself can be authenticated by consumers" ], "effects": [ "Consumers and ecosystems have an authenticated basis for their own checks", "Evaluation, enforcement and outcome recording remain outside this model" ], "source_refs": [ "SRC-003", "SRC-013" ] }, { "id": "record-reproducibility-outcome", "name": "Record reproducibility outcome", "description": "Record the reproducibility declaration, the build environment specification and the result of an independent rebuild comparison.", "inputs": [ "Build environment attributes and normalisation settings", "Rebuilder identity and rebuilt artifact digests" ], "outputs": [ "Build environment specification", "Rebuild comparison report with per-artifact outcomes" ], "preconditions": [ "The original artifact digests are recorded on the release", "The rebuild conditions are stated and comparable" ], "effects": [ "Reproducibility becomes a falsifiable, evidenced claim rather than an assertion", "Known residual nondeterminism is documented" ], "source_refs": [ "SRC-007", "SRC-012" ] }, { "id": "transition-release-state", "name": "Transition release state", "description": "Record a lifecycle state transition together with its reason, timing and authority reference.", "inputs": [ "Target state code and transition reason", "Approval decision reference", "Transition event time" ], "outputs": [ "Updated release state with transition history entry" ], "preconditions": [ "The transition is permitted by the declared state model", "Required evidence references for the target state resolve" ], "effects": [ "Release state history is append-only and time-stamped at event and observation time", "Approval decision records themselves remain in the governance system that owns them" ], "source_refs": [ "SRC-002", "SRC-007", "SRC-008" ] }, { "id": "publish-release-record", "name": "Publish release record", "description": "Record the publication of a release to one or more targets together with its coordinates and provenance co-distribution details.", "inputs": [ "Distribution target references", "Per-target coordinates and digest pins", "Provenance publication locations" ], "outputs": [ "Publication entries with availability class", "Attestation bundle location references" ], "preconditions": [ "The release is in a state that permits publication", "Provenance is available or its absence is explicitly declared" ], "effects": [ "The release becomes obtainable and its evidence discoverable alongside it", "Installation, rollout and runtime behaviour are not affected or described by this function" ], "source_refs": [ "SRC-002", "SRC-004" ] }, { "id": "link-external-evidence", "name": "Link external evidence", "description": "Attach typed references to SBOM documents, test evidence records and regulatory documentation for a release.", "inputs": [ "External document references with digests", "Binding subject digests", "Gate or purpose code per reference" ], "outputs": [ "Typed evidence reference entries on the release record" ], "preconditions": [ "The referenced record exists in its owning model", "The binding digests match artifacts bound to this release" ], "effects": [ "Assurance context is reachable from the release without copying it", "Content, interpretation and lifecycle stay with the owning models" ], "source_refs": [ "SRC-007", "SRC-014" ] }, { "id": "withdraw-or-supersede-release", "name": "Withdraw or supersede release", "description": "Record that a release has been superseded or withdrawn, with reason, effective time, successor pointer and post-withdrawal availability.", "inputs": [ "Withdrawal reason code and narrative", "Successor release reference", "Effective time" ], "outputs": [ "Withdrawal or deprecation notice", "Updated availability class on the release record" ], "preconditions": [ "The release is currently published", "Retention obligations for the release have been determined" ], "effects": [ "Availability changes while published artifact content and digests remain unaltered", "Removal of already-installed instances is not performed or described here" ], "source_refs": [ "SRC-008", "SRC-013", "SRC-014" ] }, { "id": "apply-retention-disposition", "name": "Apply retention disposition", "description": "Set the retention class and disposition schedule for a release record and its archive, and record the tombstone that survives disposition.", "inputs": [ "Retention class and driving obligation reference", "Trigger event and retention-until date" ], "outputs": [ "Retention schedule entry", "Tombstone record structure" ], "preconditions": [ "Support period and regulatory retention obligations are known", "The archive inventory has been recorded" ], "effects": [ "Disposition timing is explicit and auditable by the owning policy", "Execution of deletion is performed by the adopting Dimension's storage and records policy, not by this model" ], "source_refs": [ "SRC-007", "SRC-014" ] } ], "composition": [ { "target": "WM-SFT-007", "relation": "CHILD", "purpose": "This model is a child entry of its parent software model, from which it inherits product and component identity, ownership and the commercial or organisational context of a release. Product-level roadmap, entitlement and packaging remain in the parent.", "required": true, "source_refs": [ "SRC-016", "SRC-014" ] }, { "target": "WM-SFT-012", "relation": "REFERENCE", "purpose": "A build or release produces an SBOM. This model carries only the SBOM reference, binding digest, declared format and generation stage. Component inventory, dependency graph, licence facts, VEX and SBOM lifecycle belong to the target.", "required": false, "source_refs": [ "SRC-007", "SRC-014", "SRC-001" ] }, { "target": "WM-SFT-015", "relation": "REFERENCE", "purpose": "A build or release references test evidence for release assurance. This model carries the evidence pointer, the gate binding and the subject digests the evidence applies to. Test design, execution, result semantics and evidence lifecycle belong to the target.", "required": false, "source_refs": [ "SRC-002", "SRC-007" ] }, { "target": "WM-SFT-009", "relation": "REFERENCE", "purpose": "Inbound relation: deployment installs a release. This model exposes release identity, artifact descriptors, digests and support declarations for the target to consume. Installation, rollout, environment promotion, runtime configuration and runtime rollback are owned by the target, as are SWID primary and patch tag semantics that describe installed state.", "required": false, "source_refs": [ "SRC-015", "SRC-011" ] }, { "target": "SLSA Build Provenance v1.2 predicate", "relation": "ALIGN", "purpose": "Build definition, platform and run findings align to the buildDefinition and runDetails structures. Alignment only: conformance is not claimed without a verified attestation, and the predicate type URI does not by itself identify the specification version.", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] }, { "target": "in-toto Attestation Framework Statement v1 and ResourceDescriptor v1", "relation": "ALIGN", "purpose": "Artifact descriptors and attestation bindings align to ResourceDescriptor and Statement subject semantics, including digest-only subject matching and the requirement that a descriptor carry at least a uri, digest or content value.", "required": false, "source_refs": [ "SRC-005", "SRC-006" ] }, { "target": "Package URL (ECMA-427)", "relation": "ALIGN", "purpose": "Governed global identifier for release package coordinates. A purl carries no digest, so it is used together with a digest set and never as a sole artifact identity.", "required": false, "source_refs": [ "SRC-009" ] }, { "target": "Semantic Versioning 2.0.0", "relation": "ALIGN", "purpose": "Version designation, precedence and the immutability of published version content, where the adopting Dimension declares this scheme. Alternative schemes are permitted and must be declared explicitly.", "required": false, "source_refs": [ "SRC-008" ] }, { "target": "OCI Image Format Specification and annotations", "relation": "ALIGN", "purpose": "Projection of release metadata onto packaged container artifacts using pre-defined annotation keys, and use of the image index for variant grouping.", "required": false, "source_refs": [ "SRC-010", "SRC-011" ] }, { "target": "The Update Framework specification", "relation": "ALIGN", "purpose": "Source of the freshness, metadata expiry and monotonic version constraints recorded as channel declarations. Repository role operation, key delegation and client update workflow are not adopted.", "required": false, "source_refs": [ "SRC-013" ] }, { "target": "NIST SP 800-218 SSDF v1.1 practices PS.1, PS.2, PS.3 and PW.6", "relation": "ALIGN", "purpose": "Release integrity verification mechanism, archival of each release with integrity and provenance data, and build configuration practices. Practice adoption is a claim recorded with evidence, not an asserted conformance.", "required": false, "source_refs": [ "SRC-007" ] }, { "target": "Regulation (EU) 2024/2847 (Cyber Resilience Act)", "relation": "ALIGN", "purpose": "Support period declaration, end-of-support information to users, component documentation via SBOM and secure update distribution, where a product is within the regulation's scope. Conformity assessment and technical documentation remain product-level.", "required": false, "source_refs": [ "SRC-014" ] }, { "target": "Signing key and trust anchor management model", "relation": "REFERENCE", "purpose": "Candidate link not yet in the relations ledger: this model carries signature, signer identity and trust anchor references only. Key generation, custody, rotation, revocation and signing or verification execution are owned by the target and require registry review before adoption.", "required": false, "source_refs": [ "SRC-003", "SRC-007" ] }, { "target": "Source control and change management model", "relation": "REFERENCE", "purpose": "Candidate link not yet in the relations ledger: only the resolved repository URI, revision digest and subpath are bound to a build. Branch policy, review state and change-request lifecycle are owned by the target.", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] }, { "target": "Vulnerability and advisory management model", "relation": "REFERENCE", "purpose": "Candidate link not yet in the relations ledger: security releases reference fixed-vulnerability identifiers and advisories. Advisory authoring, severity assessment, disclosure workflow and incident reporting are owned by the target.", "required": false, "source_refs": [ "SRC-014", "SRC-007" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "The adopting Dimension must name a single accountable owner for the release record set and declare the authoritative master system that issues release identifiers, so that identity priority can be applied deterministically.", "The package must declare its version scheme, release state vocabulary, distribution channel vocabulary and artifact role vocabulary as governed code lists with stable codes, since none of these is fixed by an external standard.", "The package must declare, per product, which regulatory regimes and practice frameworks are claimed, which retention obligations follow from them, and which system executes disposition.", "The package must declare the authoritative digest algorithm for subject matching and a migration rule for algorithm deprecation, because in-toto subject matching depends entirely on digest agreement.", "The package must record, for every referenced sibling model, the target model identifier and the binding mechanism, and must not shadow target-owned fields locally." ], "namespace_guidance": "Use a reverse-DNS namespace owned by the release producer for local extension fields, and reserve external specification namespaces to their owners. Do not place local fields inside org.opencontainers.image, in-toto or SLSA namespaces; SLSA extension fields follow the vendor-prefixed field naming convention and must not alter the meaning of standard fields. Release identifiers are namespaced by the issuing master system; purl coordinates carry their own ecosystem namespace and must not be re-namespaced locally.", "registry_links": [ "Registry entry vr.wm-sft-008 in the world-model record plane, navigation path NAV.INF.SFT.REL", "Parent registry entry WM-SFT-007 for product and component identity", "Relations ledger planning/VERCY-MODEL-RELATIONS.csv for the REFERENCE links to WM-SFT-012, WM-SFT-015 and the inbound link from WM-SFT-009" ] }, "canon_and_patch": { "canonicalization_rules": [ "Serialise release records with lexicographically sorted object keys, no insignificant whitespace and UTF-8 encoding before computing any record digest, so the same logical record yields the same digest across storage projections.", "Normalise all time values to RFC 3339 with seconds and an explicit offset; where a source asserts a UTC-only timestamp, record the normalised value and retain the source's original string in a provenance field rather than discarding it.", "Normalise digest algorithm names to lower case and keep the full algorithm-to-hash map; never truncate a hash or reduce a digest set to a single algorithm during canonicalisation.", "Preserve unrecognised fields from external attestations verbatim in an extension container; consumers must ignore fields they do not recognise rather than dropping them." ], "patch_rules": [ "Published release content is append-only: artifact descriptors, digests, provenance and attestation bindings for a published release are never edited in place. Corrections are recorded as new evidence entries or a new release.", "Lifecycle state, availability class, retention schedule, evidence references and support declarations are mutable and are patched as append-only history entries carrying both the event time and the observation time.", "Every patch records the patching actor reference, the reason code and the prior value digest so that superseded values remain reconstructable.", "A patch that would change a digest, a version string or the release identifier is rejected; such a change requires a new release record." ], "compatibility_rules": [ "Additive changes — new optional elements, new code-list values, new evidence reference types — are compatible and do not require a new model version.", "Removing an element, narrowing cardinality, changing an element's value kind or removing a code-list value is breaking and requires a major model version with a documented migration.", "Pin the version of every external target specification separately from its type URI, because a stable predicate type URI may span multiple specification versions.", "Consumers must tolerate unknown fields and unknown code-list values, treating unknown values as unclassified rather than as errors." ] }, "artifact_rules": { "identity_priority": [ "Authoritative master-system identifier: the release record key issued by the declared system of record, or the build platform's invocation identifier for a build run record. This is the first-choice identity whenever it exists.", "Governed global identifier or IRI: a Package URL per ECMA-427, an OCI image reference including its digest, a SWID tagId, or the artifact's cryptographic digest set used as a content-addressed identifier.", "UUID or ULID assigned by the adopting Dimension, used only when neither of the above exists, and recorded together with the reason no governed identifier was available.", "A version string, tag name, build number, branch name, filename or any date or timestamp is never an identifier on its own; such values may only qualify an identifier already established by one of the three priorities above." ], "timestamp_rule": "All time values are recorded as RFC 3339 date-time strings that include seconds and an explicit UTC offset or the literal Z. Event time and observation or ingestion time are stored in separate fields and never conflated: build startedOn and finishedOn, state transition times, withdrawal effective time and embargo lift time are producer-asserted event times, while the time a record was observed or ingested into the release register is recorded independently by the receiving system. Where a source supplies a UTC-only value without an offset, the normalised value is stored alongside the original source string. Durations such as a support period are recorded as an explicit start and end, not as a bare interval.", "serial_naming_rule": "Artifacts that recur for one release — build run records, rebuild comparison reports and archive bundles — are named ----, where the sequence is a monotonically increasing counter scoped to the release and the artifact slug. The sequence must never encode a date, a version string or a timestamp, and gaps in the sequence are permitted but must be explained in the record. Non-serial artifacts such as the release manifest, release notes and interoperability profile carry no sequence and are distinguished by content digest.", "integrity_rule": "Every artifact declared by this model is addressed by a cryptographic digest set recorded with explicit algorithm names, and the release manifest binds those digests to the release identifier. Attestations bind to artifacts by digest alone, so an artifact whose digest does not match its declared descriptor is treated as a different artifact and must not be substituted. Archived release bundles carry their own integrity digest. This model records digests, signature references and integrity declarations; it does not perform hashing verification, signature verification or enforcement, which belong to the consuming or platform services." }, "policies": [ "Boundary policy: a release record may reference an SBOM, test evidence, a deployment, a signing key, a source revision or an advisory, but must never reproduce the referenced model's content, lifecycle or operational semantics. Any field that would duplicate a target-owned concept is moved to a composition link or recorded as out of scope.", "Declaration-not-evaluation policy: this model holds producer declarations, evidence pointers and recorded outcomes. It never holds evaluation logic, enforcement decisions, admission results or audit-trail entries; those are produced and owned by verification, policy and audit services outside the boundary.", "Immutability policy: once a release is published, its artifact content, digests and version designation are frozen. Availability, lifecycle state and support commitments may change; content may not. Withdrawal changes availability without altering published artifacts.", "Falsifiability policy: every assurance claim — build level, reproducibility, framework conformance — is recorded with the asserting party and an evidence reference, and is expressed as a claim rather than as an established fact where no verifying evidence exists.", "Identifier discipline policy: no date, version or filename may serve as a primary identifier, and identity priority is applied in order without substitution." ], "crud": { "read": [ "Reading a release record returns identity, version designation, artifact descriptors, lifecycle state and evidence references; artifact payloads themselves are dereferenced from their declared locations rather than embedded.", "Provenance, attestation and expectation records are readable together with the release so a consumer can assemble a complete evidence set in one traversal.", "Reads of embargoed or restricted releases return the availability class and withhold coordinates and artifact locations until the embargo lift time recorded on the record has passed.", "Reads must surface the recorded specification version for every external projection so a consumer never infers a version from a type URI." ], "create": [ "Creating a release requires a resolvable parent component reference, an authoritative identifier assigned under the identity priority, a declared version scheme and at least one artifact descriptor carrying a digest.", "Creating a build run record requires a builder identity and a platform-issued invocation identifier; event times, where present, must carry seconds and an explicit offset or Z.", "Creating an evidence reference requires the target model to own the referenced record and requires binding digests that match artifacts already bound to the release.", "Creation is rejected where a date, version string or filename is offered as the primary identifier." ], "update": [ "Published artifact descriptors, digests, version strings and release identifiers are immutable; update attempts against them are rejected and require a new release.", "Lifecycle state, availability class, evidence references, retention schedule, support declaration and withdrawal fields are updatable as append-only history entries recording actor, reason, event time and observation time.", "Adding later evidence — a rebuild report, an additional attestation, a superseding SBOM reference — is an update to the reference set, never an edit of prior evidence.", "Updates that would import a target model's owned content, such as SBOM component data or test results, are rejected at validation." ], "delete": [ "Release records are not hard-deleted while any retention obligation is open. Each record carries a retention class, a retention trigger event and a retention-until date derived from the declared support period and applicable regulatory obligations.", "When retention lapses, the declared disposition action is applied and a tombstone is retained containing the release identifier, version designation, artifact digest set, withdrawal or disposition reason, and the disposition time; the payload, archive contents and personal or contact data are removed.", "Execution of deletion is outside this model's boundary. The adopting Dimension's storage and records-management policy owns the deletion mechanism and its own audit record; this model owns only the retention class, schedule, disposition action and tombstone structure, and records the reference to the executing policy.", "Deletion of a release record never implies removal of artifacts already distributed, mirrored or installed. Removal from distribution targets is a withdrawal action recorded here; removal from running systems is owned by WM-SFT-009.", "Where a release is referenced by a deployment, an SBOM or a test evidence record, disposition must retain the tombstone so that those references do not dangle, and must not delete the referenced records themselves." ] }, "roles": [ { "name": "Release owner", "responsibilities": [ "Accountable for the release record and its published claims", "Declares version scheme, release type, channel and support commitment", "Approves withdrawal and supersession decisions" ] }, { "name": "Build provenance steward", "responsibilities": [ "Ensures build definition, platform identity and run records are captured for every release", "Maintains the reproducibility declaration and commissions independent rebuilds", "Records known nondeterminism and dependency completeness limits honestly" ] }, { "name": "Release authorising officer", "responsibilities": [ "Authorises transition of a release into a published state against declared gate criteria", "References the approval decision record held in the governance system", "Confirms segregation between producing and approving parties where required" ] }, { "name": "Distribution and archive custodian", "responsibilities": [ "Records publication targets, coordinates and provenance co-distribution locations", "Maintains the release archive with its integrity digest per SSDF PS.3", "Applies the retention schedule and records the tombstone on disposition" ] }, { "name": "Interoperability steward", "responsibilities": [ "Maintains the mapping profile onto external schemas and pins their specification versions", "Records conflicts between this model's rules and target schemas rather than silently resolving them", "Reviews additive and breaking changes against the compatibility rules" ] }, { "name": "Boundary reviewer", "responsibilities": [ "Compares every bundle, layer, finding and function against each relation rationale before release of the model", "Moves target-owned concepts to composition links, out_of_scope or boundary notes", "Blocks any addition that would grant this model evaluation, enforcement or audit-trail ownership" ] } ], "access": { "default_rule": "Release records are readable by any party entitled to obtain the release itself: for a publicly distributed release the identity, version designation, artifact digests, provenance, attestations and support declaration are public, because consumers cannot verify what they cannot read. Write access is restricted to the release owner and the roles named above, scoped to the fields each role is accountable for.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Embargoed security releases: coordinates, artifact locations and change content are withheld until the recorded embargo lift time, while the release identifier and state may remain visible.", "Restricted or customer-specific releases: artifact locations and distribution coordinates are visible only to entitled parties, but digests and support declarations remain available to entitled consumers for verification.", "Build platform internal parameters and byproducts may contain infrastructure detail; these may be restricted to the producing organisation while externalParameters remain readable, since verification depends on external parameters only.", "Contact and personnel data in approval references, signer identities and release notes may be restricted or pseudonymised under the adopting Dimension's privacy policy without restricting the technical evidence.", "Withdrawn releases remain readable for reproducibility and audit purposes even where they are no longer obtainable, unless a legal obligation requires otherwise." ], "audit_requirements": [ "Every write records the acting party reference, the reason code, the event time and the observation time; this model stores those fields on its own records but does not own or operate the wider audit trail.", "Access to restricted or embargoed release fields is logged by the storage or interface layer that enforces the restriction; the log itself is owned by that layer, not by this model.", "Disposition actions record the executing policy reference and the resulting tombstone; the evidential record of execution belongs to the adopting Dimension's records-management function.", "Changes to declared verification expectations are retained by digest so that superseded declarations remain reconstructable." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Owner", "Model version and status" ], "read_order": [ "AGENTS.md — establishes the model name, type, and the specification, storage, interface and process entry points before any record is read or written", "Specification URL — scope statement, in-scope and out-of-scope lists, and boundary notes, so an agent knows which concepts belong to sibling models before it acts", "Storage type URL — the concrete projection in use (document store, Git tree, object store or MCP-exposed resource) and the canonicalisation rules that make record digests stable across projections", "Interface URL — the read, create, update and delete surface, including which fields are immutable after publication", "Processes URL — the functions, role responsibilities and boundary review procedure, including the rule that referencing a target model never confers ownership of its lifecycle or operational semantics" ] } }, "coverage": { "claim": "Covers the software Release aggregate as bounded by the pack: release and artifact identity, build definition, platform and run provenance, reproducibility claims and rebuild outcomes, attestation and signature references, producer-published verification expectations, lifecycle, authority, change and support declarations, publication coordinates and provenance co-distribution, archival, retention and tombstone, and typed references to SBOM, test evidence and regulatory documentation, grounded in sixteen cited primary sources. Coverage is claimed only for producer-published software releases built on hosted build platforms and distributed through public registries or direct download, and only against the single EU regime examined. It is not complete for non-EU product-security regimes, export control or geo-restricted distribution, firmware and over-the-air updates, machine-learning artefacts, ecosystem-specific registry rules, monorepo release trains or downstream repackaging, and no cross-provider convergence evidence exists because the second provider is waived.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Identity priority places the authoritative master-system identifier first, then governed global identifiers (purl per ECMA-427, OCI reference with digest, SWID tagId, content digest), then Dimension-assigned UUID or ULID. Version strings, tags, build numbers and dates are explicitly excluded as identifiers. Grounded in SRC-005, SRC-006, SRC-008, SRC-009, SRC-016." }, { "dimension": "lifecycle", "status": "covered", "notes": "Release state model, transitions with reason and authority, supersession and withdrawal, and support period with end-of-support. Deployment and runtime lifecycle are excluded and assigned to WM-SFT-009. Grounded in SRC-007, SRC-008, SRC-013, SRC-014, SRC-015." }, { "dimension": "relationships", "status": "covered", "notes": "Typed references to SBOM (WM-SFT-012), test evidence (WM-SFT-015), inbound deployment (WM-SFT-009), parent product (WM-SFT-007), plus three candidate links flagged for registry review. Each link states what the target owns." }, { "dimension": "temporal", "status": "covered", "notes": "RFC 3339 with seconds and explicit offset or Z; build event time separated from observation and ingestion time; withdrawal effective time, embargo lift time, metadata expiry and retention-until dates modelled distinctly. Note the residual conflict with SLSA's UTC-only timestamp illustration." }, { "dimension": "provenance", "status": "covered", "notes": "Build definition, external and internal parameters, source revision binding, resolved dependencies, builder identity, run record and byproducts, plus reproducibility declaration and independent rebuild outcomes. Grounded in SRC-001, SRC-002, SRC-012." }, { "dimension": "ownership", "status": "covered", "notes": "Accountable release owner, approval authority with role, custody of archives, and six declared roles including a boundary reviewer. Approval decision records and audit trails are referenced, not owned." }, { "dimension": "validation", "status": "covered", "notes": "Manifest and digest verification mechanism per SSDF PS.2, attestation subject-digest binding, rebuild bit-for-bit comparison, and producer-published expectations. Execution of verification is deliberately excluded from the boundary." }, { "dimension": "access", "status": "covered", "notes": "Default is public readability for publicly distributed releases because verification requires readability; exceptions cover embargo, restricted distribution, internal build parameters and personal data. Scopes span bundle, layer, finding and artifact." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Retention class, trigger and retention-until derived from support period and regulatory obligation; disposition action and tombstone structure defined; execution explicitly delegated to the adopting Dimension's records-management policy, with dangling-reference protection for deployment, SBOM and evidence links." }, { "dimension": "interoperability", "status": "covered", "notes": "Explicit projection profile with pinned target specification versions, per-field fidelity, and recorded conflicts. Includes the rule that a stable predicate type URI does not identify a specification version." }, { "dimension": "reproducibility", "status": "covered", "notes": "Declaration, environment record, timestamp normalisation and known nondeterminism, plus independent rebuild comparison. Modelled as a falsifiable claim, not a requirement, because reproducibility is not universally achievable." }, { "dimension": "integrity and attestation", "status": "covered", "notes": "Digest sets, manifest binding, attestation statements with subject matching, signature and trust-anchor references. Key custody and verification execution are out of scope." }, { "dimension": "authority and approval", "status": "covered", "notes": "Approval references, approver role, segregation-of-duties indicator and expectation-setting authority. Decision records themselves remain in the governance system." }, { "dimension": "measurement", "status": "covered", "notes": "Rebuild match counts, artifact sizes, mapping fidelity codes and support period boundaries. No quality metrics for tests are modelled, since those belong to WM-SFT-015." }, { "dimension": "security", "status": "covered", "notes": "Build platform isolation claims, hardening flags, embargo handling and security-release classification. Enforcement of platform controls and admission decisions are excluded." }, { "dimension": "regulatory obligations", "status": "gap", "notes": "Only Regulation (EU) 2024/2847 was examined as a primary legal source, together with NIST SSDF as US federal guidance. US Executive Order attestation regimes, UK, Japanese and other national product-security regimes were not researched, so regime-specific release obligations beyond the EU are unsupported and marked as a gap rather than presented as canonical." }, { "dimension": "spatial and jurisdictional distribution", "status": "gap", "notes": "Distribution targets carry locations, but export control, sanctions screening and geo-restricted distribution are not grounded in any primary source consulted here. Treat as an unsupported area requiring a separate model or further research." }, { "dimension": "privacy", "status": "not-applicable", "notes": "Release records are about software artifacts. The only personal data is incidental — approver, signer and author references — which is handled by the access exceptions and delegated to the adopting Dimension's privacy policy rather than modelled here." } ], "known_omissions": [ "Firmware, embedded and over-the-air update release flows, including delta updates, A/B slot semantics and device-side update campaigns.", "Ecosystem-specific registry rules for npm, Maven Central, PyPI, crates.io, Debian and RPM repositories: publication constraints, unpublish and yank windows, and namespace claiming differ materially and were not modelled.", "Machine-learning artefact releases: model weights, training data lineage, evaluation cards and model-specific versioning conventions.", "Monorepo and multi-package coordinated releases, including release trains, atomic multi-artifact publication and cross-package version constraints.", "Export control classification, sanctions screening and geo-restricted distribution.", "Licence compliance obligations attached to distribution, including source-offer requirements for copyleft licences.", "Air-gapped, offline and physical-media distribution, and long-term archival format migration.", "Build cost, capacity, scheduling and build-queue operational concerns.", "Verification Summary Attestations and the recursive verification of dependency provenance, which sit on the verifier side of the boundary.", "Source track provenance for the source revision itself, which belongs to a source-control model." ], "conflicts": [ "The SLSA v1.2 build provenance schema illustrates timestamps in a UTC-only form ending in Z, while this model requires RFC 3339 with an explicit offset or Z. Projections must normalise and retain the original source string; do not treat the illustration as forbidding offsets.", "Semantic Versioning states that published version contents MUST NOT be modified, but several package ecosystems permit unpublish or delete within a window. This model resolves the conflict by treating withdrawal as an availability change only, and flags hard-delete practices as a violation of the immutability assumption other evidence depends on.", "SLSA describes resolvedDependencies completeness as best effort, while SSDF PS.3.2 and CRA Annex I Part II expect documented components for each release. These are different scopes: build-time fetches versus shipped components. Treating resolvedDependencies as an SBOM substitute would be a conformance error.", "purl per ECMA-427 carries no digest, and in-toto matches subjects purely by digest. A purl alone is therefore an insufficient artifact identity; the two must be carried together.", "SWID corpus tags describe pre-installation state while primary and patch tags describe installed state, so the SWID tag family straddles the boundary between this model and WM-SFT-009. Only corpus-level identity is claimed here.", "The SLSA provenance predicate type URI has remained https://slsa.dev/provenance/v1 across specification versions, including a version now marked retired. Predicate type URI alone cannot be used to determine which specification version applies, so a separate version field is mandatory.", "NIST SSDF is guidance rather than law outside contexts that incorporate it by reference, while the CRA imposes binding obligations within its scope. Mixing them into a single conformance claim would overstate both." ], "regional_assumptions": [ "Regulation (EU) 2024/2847 obligations, including the support period of no less than five years unless the product lifetime is shorter and the end-of-support information to users, are assumed to apply only to products with digital elements placed on the EU market. Support period modelling is otherwise driven by contract or producer policy.", "NIST SP 800-218 is treated as a US-originated practice framework and modelled as a claim with evidence, not as an obligation, outside contexts that incorporate it by reference such as US federal software acquisition.", "Producers are assumed to operate across time zones, so an explicit offset is required rather than assumed UTC; where a build platform emits UTC-only values, the original string is retained alongside the normalised value.", "Distribution channel and registry conventions are assumed to be those of publicly reachable internet package ecosystems; regulated, classified or air-gapped distribution environments are outside the assumptions used here.", "No assumption is made that any particular jurisdiction requires artifact retention for a specific period; retention is derived from the declared support period plus any regime the adopting Dimension names." ], "adversarial_checks": [ "Tested whether deployment concepts had leaked in: rollout strategy, environment promotion, install verification and runtime rollback were all rejected and assigned to WM-SFT-009. Publication is modelled as making a release obtainable; the model stops before installation. SWID primary and patch tag semantics were also pushed to the deployment side.", "Tested whether SBOM content had leaked in: an early structure carried component and licence elements. These were removed, leaving only document reference, binding digest, declared format and generation stage. The resolvedDependencies finding carries an explicit question about why it is not an SBOM.", "Tested whether test semantics had leaked in: result schemas, coverage and defect fields were rejected; only the evidence pointer, gate binding, outcome pointer and subject digests remain, per the WM-SFT-015 relation rationale.", "Tested whether the model had claimed evaluation, enforcement or audit ownership: verification expectations are modelled as producer declarations with an explicit question naming the evaluating party as external; signature and trust-anchor data are references only; transparency-log entries and audit trails are named in boundary notes as externally owned. The access layer's audit requirements state that logs belong to the enforcing layer.", "Searched for counterexamples to reproducibility as a requirement: many toolchains remain non-deterministic and the Reproducible Builds definition is conditional on identical environment and instructions. Reproducibility was therefore modelled as a declared, evidenced claim with a known-nondeterminism element rather than as a mandatory property.", "Tested identity discipline against attractive shortcuts: version strings, Git tags, build numbers and build dates were each rejected as primary identifiers because they are non-unique across rebuilds, mutable, or date-like. The artifact rules state this explicitly.", "Tested whether SLSA conformance could be claimed: it cannot without a verified attestation, so all standards links are recorded as ALIGN and framework adoption is modelled as a claim with an evidence reference and an explicit non-conformance field.", "Tested whether the six bundles collapse: identity, provenance, attestation, lifecycle, distribution and evidence linkage each answer a distinct question and none can be derived from another. The thinnest, evidence linkage, survives because the relation ledger makes those bindings mandatory context that must live somewhere addressable." ] }, "researchAdjudication": { "providerMode": "single-provider-waiver", "activeProviders": [ "claude" ], "waivedProviders": [ "grok" ], "providerPolicy": { "contract_version": "1.0.0", "mode": "single-provider-waiver", "effective_at": "2026-08-29T09:06:27Z", "scope": "Queued subject-model research from WM-XCT-013 onward", "active_providers": [ "claude" ], "waived_providers": [ { "provider": "grok", "authorized_by": "repository owner", "authorized_at": "2026-08-29T09:06:27Z", "reason": "The repository owner explicitly instructed the research queue to continue without Grok after repeated structured-output failures." } ], "review_rule": "Claude-only results require a separate no-tools adversarial audit and remain reviewable drafts with a visible single-provider hold." }, "boundaryDecision": { "entry_kind": "aggregate", "status": "accepted", "rationale": "Two axes must not be conflated. On the record plane the frozen registry entry vr.wm-sft-008 carries entry_kind 'standalone-mm', which classifies how the world-model record itself is held (a standalone meta-model entry at NAV.INF.SFT.REL, parent WM-SFT-007, composition_role REFERENCE, contains_ids empty); that value is absent from the subject-model enum and is therefore never usable as the subject kind. On the subject plane the defensible schema kind is 'aggregate'. A Release is a consistency and immutability boundary whose child records — artifact descriptor set, release manifest, variant index, build environment specification, rebuild comparison reports, archive bundles — are identified relative to the release identifier (serial_naming_rule scopes every sequence to it), are published, withdrawn, archived and disposed as one unit under the immutability and retention policies, and have no lifecycle outside it. 'entity' understates the composed children and the atomic publish/withdraw/dispose invariants; 'event' describes a build run, not a release; 'relationship', 'registry', 'classifier', 'mixin' and 'pattern' do not fit the subject at all. There is no contradiction with the registry: intra-model composition (aggregate) and model-plane composition_role (REFERENCE to WM-SFT-012 and WM-SFT-015) are different statements, and the result honours the REFERENCE constraint by carrying pointers and binding digests only. Accepted rather than split: the residual tension is that the build run record carries a platform-issued authoritative identifier and can exist with no release at all, which is deferred to registry review rather than resolved by an auditor with no second provider." }, "decisions": [ { "concept": "Entry kind: registry 'standalone-mm' versus subject kind 'aggregate'", "disposition": "accepted as aggregate", "rationale": "The frozen registry value classifies the record plane and is not a member of the subject-model enum; aggregate is the defensible subject kind because release children are release-scoped and share one publish, withdraw and dispose boundary." }, { "concept": "Aggregate root scope: Build Run treated as a composed child of Release", "disposition": "deferred to registry review", "rationale": "A build run carries a platform-issued authoritative identifier, may produce no release, and may feed several releases, so its composition inside the release aggregate is asserted rather than demonstrated; the model's own release-identity-q-vs-build question exposes the tension without settling it." }, { "concept": "Mandatory parent-component reference in the create rule", "disposition": "deferred pending a relations-ledger entry", "rationale": "Creation requires a resolvable parent component reference, but the frozen relationship contract carries only WM-SFT-012, WM-SFT-015 and the inbound WM-SFT-009 edges; the WM-SFT-007 parent exists solely as a registry parent_ids field, so the precondition is currently unenforceable." }, { "concept": "Coverage claim of three candidate relationship links flagged for registry review", "disposition": "rejected as stated", "rationale": "The relationships checklist asserts three further candidate links but none is enumerated in the structure, the boundary notes or registry_links, so the claim cannot be checked against the frozen contract and must be enumerated or withdrawn before publication." }, { "concept": "Access exception permitting pseudonymisation of signer and approver identities", "disposition": "rejected; restrict at read only", "rationale": "Pseudonymising an identity inside a signed, digest-bound attestation would break subject matching and violate the integrity and append-only rules; the privacy objective must be met by withholding fields at read, never by mutating retained evidence." }, { "concept": "Privacy checklist status recorded as not-applicable", "disposition": "rejected; reclassify as delegated", "rationale": "The access layer defines a personal-data exception and the delete rule strips personal and contact data at disposition, so personal data is handled by the model even though it is incidental; not-applicable understates the obligation the model already carries." }, { "concept": "Access scopes limited to bundle, layer, finding and artifact", "disposition": "deferred; field-level scope required", "rationale": "The embargo and restricted-distribution exceptions withhold coordinates, artifact locations and change content while keeping identity, digests and support declarations visible, which is a field-level operation the four declared structural scopes cannot express." }, { "concept": "OCI sources SRC-010 and SRC-011 cited at 'main branch'", "disposition": "rejected as a normative pin", "rationale": "A moving branch reference is not reproducible and contradicts the model's own compatibility rule that every external target specification version be pinned separately from its type URI; a tag or commit digest is required." }, { "concept": "SLSA v1.2 'Approved' pin across SRC-001 to SRC-004", "disposition": "accepted subject to a live verification hold", "rationale": "Four of sixteen sources and the whole provenance bundle rest on a version and status that cannot be checked without tools, and the model's own conflict list records that the provenance predicate URI is stable across versions including a retired one, which is exactly the failure mode an unverified pin produces." }, { "concept": "Authority tier scheme placing CRA, NIST guidance and ECMA-427 together at tier 1", "disposition": "deferred to the source-tier policy owner", "rationale": "The scale conflates binding legal force with national guidance and de jure standards-body standing, which sits awkwardly beside the model's own conflict entry warning that SSDF and the CRA must not be merged into one conformance claim." }, { "concept": "Source support for release-state-model (SRC-002, SRC-007, SRC-008)", "disposition": "accepted with a grounding annotation required", "rationale": "None of the cited sources defines a release state machine; the vocabulary is Dimension-governed, as the owner package requirements concede, so the finding must mark its states as locally governed rather than source-derived to keep the falsifiability policy honest." }, { "concept": "SRC-013 (TUF) cited on support-period-declaration", "disposition": "rejected for that finding", "rationale": "TUF governs metadata expiry, freshness and rollback, not support duration, its determination basis or end-of-support notification; SRC-014 plus declared producer policy carries the finding and retaining TUF there overstates grounding." }, { "concept": "Question resolveddeps-q-not-sbom phrased as 'Why must this record not be treated as...'", "disposition": "accepted with rephrasing required", "rationale": "It asserts a boundary rather than eliciting an instance fact; rephrase to ask what is knowingly absent relative to shipped components, leaving the boundary assertion in the WM-SFT-012 boundary note where it is already stated." }, { "concept": "Function coverage gaps for archival, notes and support publication, and schema projection", "disposition": "deferred; additions barred under the waiver", "rationale": "release-archive-record, change-content-and-release-notes, support-period-declaration and interoperability-profile each declare artifacts, and an interoperability steward role exists, yet no function creates or publishes them; add_functions must stay empty in single-provider mode, so the gap is logged for the next pass." }, { "concept": "Serial naming of the build run record against its authoritative invocation identifier", "disposition": "accepted as an alias, never as identity", "rationale": "identity_priority makes the platform-issued invocation identifier authoritative while serial_naming_rule assigns a release-scoped sequence; the sequence must be documented as a filename alias so a single run feeding two releases cannot acquire two identities." }, { "concept": "Immutability, withdrawal and retention triad", "disposition": "accepted", "rationale": "Withdrawal alters availability only, tombstones preserve identifier, version designation, digest set, reason and disposition time, and dangling-reference protection covers deployment, SBOM and evidence links; the three rules are mutually consistent and survive the documented semver-versus-yank conflict." } ], "publicationHolds": [ "Live source and version verification hold: every one of the sixteen source URLs must be re-verified live before this record is published as anything beyond a reviewable draft, and specifically the SLSA v1.2 'Approved' status on SRC-001 to SRC-004, the ECMA-427 first-edition December 2025 pin on SRC-009, the TUF 1.0.36 pin on SRC-013, and the two OCI citations on SRC-010 and SRC-011 that currently point at a moving 'main branch' rather than an immutable tag or commit.", "Single-provider hold: this result was produced by Claude alone under the repository-owner waiver recorded at 2026-08-29T09:06:27Z for Grok, so no independent second-provider review exists, entry_kind agreement is 'waived' rather than confirmed, source and structure overlap is zero by construction, and every publication artifact must carry a visible single-provider notice naming the waiver, its authorising party and its date while the record remains a reviewable draft.", "Relations hold: the create rule's mandatory parent-component precondition depends on a WM-SFT-007 edge that appears only as a registry parent_ids value and is absent from the frozen relationship contract, and the coverage claim's three unenumerated candidate links must be enumerated in the relations ledger or withdrawn from the claim.", "Correction hold: the signer and approver pseudonymisation exception, the not-applicable privacy status, and the absence of a field-level access scope must be corrected before the access, retention and disposition rules are presented as implementable.", "Independent second-provider review was explicitly waived by the repository owner; this Claude-only result remains a reviewable draft." ], "deferredResearch": [ "Non-EU release obligations, including US federal secure-software attestation regimes and UK, Japanese and other national product-security rules, to close the regulatory-obligations gap the coverage checklist already marks as unsupported.", "Export control classification, sanctions screening and geo-restricted distribution, which carry no primary-source grounding anywhere in the current source set despite distribution targets recording locations.", "Whether Build Run should be split into its own subject model as an event linked by a REFERENCE edge, tested against continuous-integration platforms where most build runs never become releases and one run can supply several releases.", "Downstream repackaging and re-distribution, covering distribution rebuilds, mirrors and vendored forks, and whether a repackaged artifact constitutes a new release aggregate with its own provenance chain or a variant of the upstream release.", "Ecosystem-specific unpublish, yank and namespace-claiming windows for npm, Maven Central, PyPI, crates.io, Debian and RPM, measured against the immutability policy that the rest of the evidence model depends on.", "Joint SWID boundary review with WM-SFT-009 to confirm the corpus versus primary and patch tag split once the deployment model is researched, since the tag family straddles the two boundaries today.", "Firmware, embedded and over-the-air update flows and machine-learning artefact releases, both declared as omissions and both likely to need sibling models rather than extensions of this aggregate." ] }, "statistics": { "sources": 16, "bundles": 6, "layers": 13, "findings": 27, "questions": 109, "artifacts": 15, "functions": 11 } }