Published

Build / Release

vr.wm-sft-008 · wm-sft-008-build-release

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.

World Models Information and virtual systems INF.SFT.REL

Bundle → Layer → Finding → Questions Classifiers What it is Why it exists Distinguishing features What robots and AI may and may not do Moral aspects Owners Links to other meta-models Identity and identifiers Direct properties Recognition Capabilities and actions Hazards and failure modes Standards and interfaces Context of use Sources

Bundle → Layer → Finding → Questions Filled

6 bundles · 13 layers · 27 findings · 109 questions

Release Identity and Designation What a release is, how it is identified and versioned, and which concrete artifacts constitute it.

Release Designation

Identifiers, version designation and classification of a single release.

Release Identity and Identifier Scheme

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.

Which system of record issues the authoritative identifier for this release? identity
Which governed global identifiers designate this release and its package coordinates? interoperability
What distinguishes the release record from the build run or runs that produced its artifacts? definition
Which product or component owns this release, and at what packaging granularity? composition

Version Designation, Precedence and Release Classification

The version string, its scheme and ordering semantics, and the classification of the release by change type and distribution channel.

Which version scheme governs this release, and how is precedence against sibling releases determined? classification
What guarantees that the contents published under this version will never be modified? constraint
What class of change does this release carry, and does it break a published interface? decision
Which distribution channel and maturity does this release target, and for which audience? classification

Artifact Identity and Packaging

The concrete files, images and packages that constitute the release, and their variants and roles.

Artifact Descriptor Set and Digests

The enumerated set of artifacts released, each addressed by cryptographic digest with media type, size and retrieval location.

Which artifacts constitute this release, and which of them are consumer-facing distributables? composition
Which digest algorithms address each artifact, and which algorithm is authoritative for matching? identity
How can a consumer verify that a retrieved file is the artifact this release declares? validation
What media type and size does each artifact carry, and from where can it be retrieved? interoperability

Artifact Variants and Roles

How platform, architecture, locale or edition variants are grouped under one release and what role each artifact plays.

Along which axes does this release vary, and what is the full variant matrix? classification
What role does each artifact play within the release? composition
Which variant is canonical for a consumer that cannot express a platform preference? decision
What single reference lets a consumer resolve the whole variant group as one release? relationship

Build Provenance What was built, from which inputs, on which platform, in which run, and whether it can be rebuilt to the same result.

Build Definition and Inputs

The declared build template, its parameters and the dependencies resolved during the build.

Build Type and Build Parameters

The build template identifier and the external and internal parameters that determined how the build ran.

Which buildType template identifies how this build was performed, and where is that template documented? definition
Which parameters were under external or tenant control for this build? provenance
Is the external parameter set claimed to be complete, and on what basis? quality
Which platform-controlled internal parameters were recorded, and are they needed to reproduce the build? constraint

Source Revision Binding

The exact source repository, revision and subpath the build consumed, and whether the tree was modified before building.

Which repository and revision digest did this build consume? provenance
Is that repository the canonical source a verifier should expect for this release? authority
Was the source tree patched or modified between checkout and build, and how is that recorded? exception
Which model owns the change history and review state behind this revision? ownership

Resolved Build-Time Dependencies

The artifacts fetched during build initialisation and execution, recorded as descriptors with digests on a best-effort basis.

Which artifacts were fetched during build initialisation and execution? provenance
On what basis is this dependency record considered complete, and what is knowingly absent? quality
Why must this record not be treated as the release's software bill of materials? interoperability
How were dependency versions pinned so that the same set resolves on a rebuild? constraint

Build Platform and Execution

Which platform ran the build, at what declared assurance level, and what the individual run produced.

Build Platform Identity and Declared Assurance

The identity of the trusted build platform and the assurance properties claimed for it.

Which builder identity represents the transitive closure of the trusted build platform for this release? identity
What build assurance level is claimed for this platform, and who asserts it? evidence
Which isolation properties are claimed: hosted, isolated between runs, and ephemeral per run? security
Which party operates and enforces those platform controls? ownership

Build Run Execution Record

The specific invocation that produced the artifacts, its timing and its byproducts.

Which invocation identifier distinguishes this build run from every other run of the same definition? identity
When did the build start and finish, and in which time reference were those values asserted? temporal
Which byproducts and logs did the run emit, and which of them are retained as evidence? event
When was this run record observed and ingested into the release record, as distinct from when the build ran? provenance

Reproducibility

Whether and under what conditions the release artifacts can be recreated bit-for-bit, and what independent rebuilds found.

Reproducibility Declaration and Build Environment Record

The claim made about reproducibility together with the recorded build environment attributes needed to act on that claim.

Is this release declared reproducible, and under exactly which conditions does the claim hold? quality
Which build environment attributes are recorded so a third party can recreate them? provenance
How are embedded timestamps and other varying inputs normalised during the build? constraint
Which sources of nondeterminism are known to remain, and what is their effect on comparison? exception

Independent Rebuild Verification

Outcomes of attempts by independent parties to recreate the release artifacts and compare them bit-for-bit.

Which independent party performed the rebuild, and what is their relationship to the original producer? provenance
Did the rebuild produce bit-for-bit identical artifacts, and for which artifacts specifically? measurement
Where outputs diverged, what differed and was the cause identified? validation
When was the rebuild performed and observed, relative to the original build? temporal

Integrity, Attestation and Declared Expectations How evidence is cryptographically bound to the release artifacts, and what the producer declares a consumer should expect.

Attestation and Signature Binding

Which signed statements cover which artifacts, and which references establish signer and trust anchor.

Attestation Statement Binding

The attestation statements that apply to this release, how their subjects bind to artifact digests, and which predicate types and spec versions they carry.

Which attestation statements apply to this release, and what does each assert? evidence
How does each statement bind to the release artifacts, and what happens if a digest does not match? validation
Which specification version does each predicate conform to, given that the predicate type URI may be stable across versions? interoperability
In which envelope and media type is each attestation carried? interoperability

Signature and Trust Anchor References

References to the signatures covering release artifacts and attestations, the asserted signer identity, and where the trust anchor is documented.

Which signatures cover which artifacts and attestations of this release? evidence
Which signer identity or key is asserted by each signature? identity
Where is the trust anchor for these signatures documented for consumers? access
Which party owns key custody, rotation and the execution of signature verification? ownership

Declared Verification Expectations

What the producer publishes for consumers to check against, and the freshness constraints of the channel.

Producer-Published Verification Expectations and Freshness Constraints

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.

Which expectation values does the producer publish for this release? requirement
Who is authorised to set these expectations, and how is that declaration itself authenticated? authority
What conditions does the producer state should cause a consumer to reject this release? constraint
Which anti-rollback and freshness constraints apply to this release within its channel? temporal
Which party evaluates these expectations, and where is the outcome recorded? ownership

Release Lifecycle and Authority The states a release passes through, who authorises transitions, what users are told, and how long it is supported.

Lifecycle States and Supersession

State model of a release and the semantics of superseding or withdrawing it.

Release State Model and Transitions

The states a release occupies, the evidence required to enter each, and when each transition occurred.

Which states can a release occupy in this Dimension, and which are terminal? lifecycle
What evidence must exist before a release may enter its published state? requirement
When did each state transition occur, and when was it observed by the recording system? temporal
When two systems report different states for the same release, which record is authoritative? state

Supersession and Withdrawal

How a release is replaced or withdrawn without violating the immutability of its published content.

Which release supersedes this one, and does the successor fully replace it? relationship
If this release is withdrawn, what is the coded reason and when did withdrawal take effect? event
How does withdrawal change availability without modifying the artifact content already published under this version? constraint
What remains retrievable after withdrawal so that historical builds can still be reproduced and audited? retention

Authority, Change Content and Support

Who authorised the release, what changed, and what commitment is made to users.

Release Authority and Approval References

Accountability for the release and references to the decisions that authorised its publication.

Which party is accountable for this release once published? ownership
Who authorised publication, acting in which role, and against which criteria? authority
Which decision records evidence the approval, and where are they held? evidence
Was the release approved by a party distinct from the one that produced it? security

Change Content and Release Notes

What changed in this release, which changes are breaking or security-relevant, and what users must be told.

What changed in this release relative to its predecessor? composition
Which changes break a published interface or documented behaviour? classification
Which security fixes does this release carry, and which advisories or vulnerability identifiers do they reference? relationship
What action must a user take on adopting this release? requirement

Support Period and End-of-Support Declaration

The period for which this release will receive vulnerability handling and security updates, and how end of support is communicated.

For how long, and until which date, is this release supported with security updates? requirement
On what basis was the support period determined? decision
How and when are users informed that support for this release is ending? process
How does this release's support window relate to the product-level support commitment? relationship

Distribution, Provenance Availability and Retention Where a release is published and made obtainable, how its provenance travels with it, and how it is archived and eventually disposed of.

Publication and Provenance Availability

Where the release is obtainable and how its evidence is discovered alongside it.

Distribution Targets and Coordinates

Where the release is published, the coordinates that identify it in each target, and its availability scope.

To which registries, repositories or download locations is this release published? spatial
Which coordinates identify the release within each target? identity
Is the release publicly obtainable, restricted, or embargoed until a stated time? access
Which target is canonical when the same release appears in several places? authority

Provenance Co-Distribution and Discovery

How attestations and provenance are made discoverable next to the artifacts they describe.

Where is the provenance for this release published so that a consumer can find it? access
Which naming or attachment convention relates each provenance document to its artifact? interoperability
Does the producer distribute provenance directly, or does the package ecosystem do so on their behalf? process
What is the declared state when provenance is unavailable for a published artifact? exception

Archival and Retention

What is preserved for each release and for how long.

Release Archive Record

The archived set of files and supporting data preserved for a release, including integrity verification information and provenance data.

Which files and supporting data are archived for this release? composition
How is the archive protected against undetected alteration? validation
Where is the archive held, and under whose custody? ownership
Who may retrieve the archive, and how long does retrieval take? access

Retention, Disposition and Tombstone

How long release records and archives are kept, what disposition applies when retention lapses, and what remains as a tombstone.

Which retention class applies to this release record and its archive, and what sets that class? retention
When does disposition become due, and what triggers the clock to start? temporal
What remains discoverable after disposition, and in what form? exception
Which party executes disposition, and where is execution recorded? ownership

External Evidence Linkage and Interoperability Typed references from a release to evidence and documentation owned by other models, and the mapping of this record onto external schemas.

External Evidence References

Bindings from a release to SBOM documents and test evidence records held in sibling models.

SBOM Reference Binding

How a release points at the SBOM documents that describe it, without reproducing their content.

Which SBOM documents describe this release, and at which lifecycle stage was each generated? relationship
How is each SBOM bound to this specific release rather than to the product generally? validation
When several SBOMs exist for one release, which is authoritative for consumers? authority
Which facts about components does this model deliberately not record? ownership

Test Evidence Reference Binding

How a release points at the test evidence records that informed its release gates, without owning test semantics.

Which test evidence records did this release reference, and for which gate? relationship
What outcome does each referenced evidence record report, as recorded at reference time? evidence
Do the referenced records apply to the exact artifacts in this release? validation
Which model interprets these results and owns their lifecycle? ownership

Compliance Linkage and Interoperability

Regulatory documentation references and the projection of this record onto external schemas.

Regulatory and Framework Documentation Linkage

Which regimes and practice frameworks apply to this release and where the supporting documentation is held.

Which regulatory regimes apply to this release, and on what basis? classification
Which technical documentation must reference this release, and where is it held? provenance
Which secure-development practice framework does the producer claim to follow for this release? decision
What evidence supports that claim, and what is explicitly not claimed? quality

Interoperability Profile and Schema Projection

Which external schemas a release record projects onto, which fields map losslessly, and where conflicts require a decision.

Which external schemas does this release record project onto? interoperability
Which fields map losslessly, and which lose information in projection? measurement
Where do target schemas conflict with this model's rules, and how is each conflict resolved? constraint
How is the version of each target specification pinned, given that some type URIs remain stable across versions? validation

Classifiers Filled

Family: World Models
Category: Information and virtual systems
Entry kind: aggregate
Navigation path: NAV.INF.SFT.REL
Domain: INF.SFT.REL
Industry: Cross-industry
Tags: buildreleaseinf.sft.rel

What it is Filled

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

Why it exists Filled

Distinguishing features Filled

Binds release identity to the build run, its artifacts and attestations, unlike a version tag in source control.
Differs from a deployment, which puts a release into a runtime environment.
Carries lifecycle and support declarations, such as end of support or withdrawal.
References SBOMs and test evidence by link instead of containing them.

What robots and AI may and may not do Filled

Must not

Promote a release to published or supported state without authorization.
Publish artifacts whose digests do not match the recorded build.
Sign a release with a key it was not issued for.
Rewrite or delete a published release instead of withdrawing or superseding it.
Omit known security issues from release notes.

Only with a human decision

Approving publication of a release.
Withdrawing a release for security or legal reasons.
Declaring end of support.

May

Assign release identity and record build provenance.
Bind artifacts with digests to the release.
Record reproducibility checks and their outcome.
Publish release notes and change communication drafts for review.

Moral aspects Filled

Users depend on accurate release notes to judge the risk of upgrading.
Withdrawn or vulnerable releases left available can harm users who cannot tell the difference.
End of support affects people who cannot afford to upgrade quickly.

Who is affected

Users and operators of the software
Developers and release managers
Downstream distributors

Owners Filled

Steward

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.

Roles

Release owner: Accountable for the release record and its published claims; Declares version scheme, release type, channel and support commitment; Approves withdrawal and supersession decisions
Build provenance steward: 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
Release authorising officer: 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
Distribution and archive custodian: 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
Interoperability steward: 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
Boundary reviewer: 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

Links to other meta-models Filled

child

WM-SFT-007 - 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.

references

WM-SFT-012 - 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.
WM-SFT-015 - 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.
WM-SFT-009 - 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.
Signing key and trust anchor management model - 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.
Source control and change management model - 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.
Vulnerability and advisory management model - 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.

aligned

SLSA Build Provenance v1.2 predicate - 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.
in-toto Attestation Framework Statement v1 and ResourceDescriptor v1 - 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.
Package URL (ECMA-427) - 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.
Semantic Versioning 2.0.0 - 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.
OCI Image Format Specification and annotations - Projection of release metadata onto packaged container artifacts using pre-defined annotation keys, and use of the image index for variant grouping.
The Update Framework specification - 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.
NIST SP 800-218 SSDF v1.1 practices PS.1, PS.2, PS.3 and PW.6 - 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.
Regulation (EU) 2024/2847 (Cyber Resilience Act) - 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.

neighbor

WM-SFT-012 (SBOM) - 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.
WM-SFT-015 (Test evidence) - 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.
WM-SFT-009 (Deployment) - 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.
Signing key management and transparency-log services - 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 control / change management - 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.
Vulnerability and advisory management - A security release may reference fixed-vulnerability identifiers and advisories, but advisory authoring, severity assessment and disclosure workflow are not modelled here.

parent

WM-SFT-007

What else AI and robots need to interact with it Filled

Sources Filled

SLSA Build Provenance (predicate specification) - OpenSSF / SLSA community specification
SLSA Build track requirements (Producing artifacts) - OpenSSF / SLSA community specification
SLSA: Verifying build artifacts - OpenSSF / SLSA community specification
SLSA: Distributing provenance - OpenSSF / SLSA community specification
in-toto Attestation Framework: Statement layer (v1) - in-toto project (CNCF)
in-toto Attestation Framework: ResourceDescriptor (v1) - in-toto project (CNCF)
NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1 - National Institute of Standards and Technology (NIST)
Semantic Versioning 2.0.0 - Semantic Versioning (semver.org)
ECMA-427: Package-URL (PURL) Specification - Ecma International (TC54)
OCI Image Format Specification: Annotations - Open Container Initiative (OCI)
OCI Image Format Specification - Open Container Initiative (OCI)
Reproducible Builds: Definition - Reproducible Builds project
The Update Framework (TUF) Specification - The Update Framework / Linux Foundation (CNCF)
Regulation (EU) 2024/2847 (Cyber Resilience Act) - European Parliament and Council of the European Union
Using SWID Tags in the Software Lifecycle - National Institute of Standards and Technology (NIST), Software Identification (SWID) project
NISTIR 8060: Guidelines for the Creation of Interoperable Software Identification (SWID) Tags - National Institute of Standards and Technology (NIST)

Open questions

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.
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.

Machine files

Card as JSON Specification AGENTS.md Source Card backlog vercy.card/1

Provenance

world-models research · reviewable-draft

Built from: models/wm-sft-008-build-release/spec.yaml, ver-cy/world-models/card-supplements/wm-sft-008-build-release.json