Deployment

Unit of deployment and record granularity

Defines what is counted as one deployment (one release, one target scope, one intent) and distinguishes a deployment occurrence from the deployable object, the pipeline run and the running service instance.

1. What exactly constitutes one deployment record, and what is the smallest change that starts a new one rather than updating an existing one? definition
2. When a single release is rolled out to many targets or many components at once, is that one deployment or many, and how is the grouping represented? composition
3. How is a deployment record distinguished from the pipeline run that produced it and from the service instance that results from it? relationship
4. Does a configuration-only or parameter-only change with no release change produce a deployment record? decision

Deployment identifier and correlation keys

How a deployment is identified across systems, including the priority of authoritative identifiers over minted ones and the natural keys used to reconcile duplicate reports of the same deployment.

1. Which system is the authoritative master system for this deployment identifier, and what identifier does it assign? identity
2. When no authoritative identifier exists, what governed identifier or minted surrogate is used and who minted it? authority
3. What natural key set is used to detect that two reports describe the same deployment occurrence? validation
4. Is the deployment identifier stable across retries, resumed rollouts and orchestrator restarts? constraint

Deployment kind and intent classification

The controlled vocabulary distinguishing initial install, upgrade, rollback, configuration-only change, redeploy and removal, aligned to the CDEvents service predicates.

1. Which deployment kind applies, and which controlled vocabulary term is used for it? classification
2. Is this a planned deployment, an emergency or hotfix deployment, or unplanned rework triggered by an incident? classification
3. Is the deployment declared reversible, and what is the declared reversal path? constraint

Release reference and binding integrity

How the deployed release is referenced and pinned, carrying the reference, the artifact coordinate and the digest used to prove the binding, without reproducing release lifecycle.

1. Which release is bound to this deployment, and by what pinned reference and artifact coordinate? relationship
2. Which content digest and algorithm were recorded at binding time to prove that the intended release was the one deployed? evidence
3. What happens to this deployment record if the referenced release is later revised, withdrawn or re-tagged upstream? exception
4. Can one deployment bind more than one release or component, and how is the set bounded? composition

Environment reference and target placement

The pinned environment reference plus the deployment-specific target selector describing which cells, regions, tenants or device groups received the release.

1. Which runtime environment is targeted, and by what pinned reference and environment tier name? relationship
2. Within that environment, which subset of targets was selected for this deployment? composition
3. In which geographic or jurisdictional locations did the deployed instances actually run as a result of this deployment? spatial
4. Which tenants, customers or device cohorts were in scope, and were any explicitly excluded? constraint

Deployed instance and installed-software correlation

How the deployment record correlates to the concrete running or installed instances it produced, so that observed installed software can be reconciled to a deployment.

1. Which service instance identifiers, container identities or device identifiers are attributable to this deployment? identity
2. What installed-software evidence on the target corroborates that this release is present? evidence
3. How is an observed running instance attributed to exactly one deployment when several deployments overlap in time? validation

Desired state declaration and its version

The declarative statement of the intended post-deployment state, its immutable version reference and its source of truth, kept distinct from the reconciliation that applies it.

1. Where is the declarative desired state held, and which immutable version of it does this deployment assert? provenance
2. What does the declaration assert about the target after deployment, in format-neutral terms? definition
3. How is divergence between the declared desired state and the reported actual state recorded on the deployment? state
4. Who is authorised to change the desired state declaration for this target, and is the change recorded as a new deployment? authority

Deploy-time parameter and secret-reference binding

The subject-specific configuration values, feature toggles and opaque secret references bound at deployment time, together with the secure-default baseline they deviate from.

1. Which parameter keys and values were bound for this deployment, and which deviate from the documented secure default configuration? constraint
2. How are credentials and key material referenced without being carried in the deployment record? security
3. Which bound parameters are sensitive or personal-data-relevant and therefore require redaction on read? privacy
4. Which parameter values were actually effective at completion, as opposed to merely requested? validation

Declared rollout strategy

The strategy declared for this deployment, such as recreate, rolling update, blue-green or canary with staged weights and pauses, recorded as intent rather than as executable mechanics.

1. Which rollout strategy was declared, and which strategy-specific limits such as surge, unavailability or step weights were set? classification
2. Which pauses in the declared strategy require an explicit promotion decision rather than elapsing automatically? decision
3. Under what declared conditions is the rollout to be aborted, and what does abort mean for the recorded state? exception
4. Does the declared strategy accept service interruption, and was that interruption expected and communicated? requirement

Deployment plan, sequencing and permitted window

The planned schedule, ordering dependencies among deployments, and the freeze or maintenance windows constraining when the deployment may proceed.

1. Within which permitted window was this deployment scheduled, and in which local offset is that window expressed? temporal
2. Which other deployments must complete before or after this one, and what happens if a predecessor fails? process
3. What plan-level mapping of components to target nodes was declared before execution began? composition
4. Did execution deviate from the plan, and what deviation was recorded? exception

Deployment state vocabulary and transitions

The controlled set of deployment states, which are terminal, and which transitions are permitted, recorded as an append-only transition history.

1. Which states can a deployment occupy, and which of them are terminal? state
2. Which state transitions are permitted, and which actor or source may assert each of them? lifecycle
3. How is a paused or awaiting-promotion deployment represented, and does pause time count toward deployment duration? state
4. When the state is reported by an external orchestrator, how is the reported value mapped into this model's vocabulary? interoperability

Progress reporting and completion criteria

The declared criteria by which a deployment is judged to have progressed, completed or failed, and how externally observed progress reports are recorded against them.

1. What criteria must be satisfied for this deployment to be declared complete, and who declared them? requirement
2. What deadline applies before a non-progressing deployment is treated as failed, and what happened when it elapsed? constraint
3. Which observed counts or signals were reported against the declared criteria, and by which reporting system? measurement
4. When a deployment failed, what reason code was recorded and was that reason produced locally or received from the orchestrator? provenance

Revision history and current-deployment resolution

The ordered history of deployments for a target, the rule that resolves which deployment is currently in effect, and the bounded retention of superseded revisions.

1. Which deployment is currently in effect for a given environment target, and by what deterministic rule is that resolved? state
2. How are deployments to the same target ordered when their reported timestamps are equal, missing or out of order? temporal
3. How many superseded revisions are retained in usable form, and what is retained once a revision falls outside that bound? retention
4. How is a gap in the history detected when deployments occurred without being recorded? quality

Rollback, roll-forward and recovery linkage

The typed links between a remediating deployment and the deployment it reverts or repairs, together with the recovery outcome as reported.

1. Which prior deployment does this rollback revert, and which release state is restored as a result? relationship
2. What triggered the remediation, and was it an automated abort or a human decision? event
3. How long did recovery take from the failed deployment to a restored serving state, and against which two recorded instants is that measured? measurement
4. Was the rollback complete, partial or unsuccessful, and what residual state was left behind? exception

Event time versus observation and ingestion time

Separates when the deployment was requested, started, completed or superseded from when those facts were observed and ingested, and fixes the representation rules for all of them.

1. Which distinct instants are recorded for this deployment, and which of them are mandatory? temporal
2. When was each reported fact observed by the reporting system and ingested into this model, and how is that kept separate from the event instant? provenance
3. In which offset was each instant originally expressed, and is that original offset preserved alongside any derived normalised value? constraint
4. Which upstream instant anchors change lead time for this deployment, and is that anchor owned by this model or referenced? measurement

Deployment authorisation and accountable actors

The recorded authorisation for this deployment, the change or approval reference relied upon, the actors involved, and the separation-of-duties assertion, all carried as references to externally governed decisions.

1. Which change or approval record authorised this deployment, and what was its recorded verdict at the time of binding? authority
2. Which human or automated actors requested, approved and initiated the deployment, and in which roles? ownership
3. Was separation of duties satisfied between the actor who approved and the actor who initiated, and how is a violation recorded? constraint
4. If normal authorisation was bypassed under an emergency procedure, what retrospective authorisation is required and by when? exception

Deployment gate decision references

References to verdicts issued by external verifiers or policy engines that were relied upon at the deployment boundary, recorded without any local evaluation, re-evaluation or enforcement.

1. Which gate verdicts were relied upon for this deployment, and which verifier issued each one? evidence
2. Against which policy identifier and version was each relied-upon verdict issued, and where does that policy live? provenance
3. How recent must a gate verdict be to remain valid for this deployment, and what happens when it is stale? constraint
4. Was any failing or missing gate verdict overridden, and what override record justifies proceeding? exception

Pre-deployment integrity evidence

The evidence relied upon before installation that the artifact bound to the deployment is authentic and unmodified, referenced from the archived release and signature or attestation sources.

1. What integrity check was performed before installation, and was its result recorded as passed, failed or not performed? validation
2. Which signature, attestation or archived-release reference supports the authenticity of the deployed artifact? evidence
3. What is recorded when the digest presented at install time differs from the digest bound at planning time? exception

Post-deployment verification outcome and acceptance

The recorded outcome of post-deployment checks and the acceptance decision closing the deployment, captured as received verdicts rather than as executed tests or live health monitoring.

1. What post-deployment verification verdict was received, from which checking system, and at what instant? evidence
2. Who accepted the deployment as successful, and on what basis was that acceptance recorded? decision
3. Which defects, degradations or incidents were attributed to this deployment after completion, and how are they referenced? quality
4. Is there a declared observation period after completion before the deployment is considered stable, and when does it end? temporal

Delivery metrics and measurement validity

The metric definitions computed from deployment records, the population and window they apply to, and the record-completeness conditions under which the results are valid.

1. Which delivery metrics are computed from these records, and by which exact definition and denominator? measurement
2. Over which time window and target population is each metric computed, and in which offset is the window expressed? temporal
3. Which record-completeness conditions must hold before a computed metric may be published, and what is reported when they fail? quality
4. Which deployments are excluded from metric populations, and on what documented basis? constraint

Deployment record provenance and reconciliation

The origin, capture path and trust level of each deployment record, including whether it was asserted by a pipeline, reconciled from observed state, or entered manually.

1. Which system asserted this deployment record, and through which capture path did it reach the model? provenance
2. What confidence level is attached to the record, and which fields are inferred rather than asserted? quality
3. When observed installed state contradicts the recorded deployment, which source wins and what correction entry is written? validation
4. Which parts of a terminal deployment record are immutable, and how are later corrections expressed? constraint

Record access, sensitivity and redaction

The sensitivity classification of deployment record content and the rules governing who may read which parts, including production target detail and parameter bindings.

1. What sensitivity classification applies to each part of the deployment record, and who set it? privacy
2. Which roles may read production target placement, parameter bindings and evidence references, and at what scope? access
3. Under what emergency conditions may normal read restrictions be bypassed, and what must be recorded when they are? exception

Retention, disposition and tombstones

How long deployment records are kept, what reduced form survives disposition, and which external policy owns the execution of deletion.

1. What retention period applies to a deployment record, and from which instant is it measured? retention
2. What minimal tombstone survives disposition, and which fields are purged? retention
3. What suspends disposition, such as legal hold or an open investigation, and who may set and release it? authority
4. When a referenced release or environment record is deleted upstream, what happens to this deployment record? exception

External standard alignments and identifier exchange

The declared alignments to external deployment vocabularies, the identifier and digest schemes used to exchange deployment facts, and the explicit statement that alignment is not conformance.

1. Which external vocabulary terms does each local element map to, and at which version of that vocabulary? interoperability
2. Where is a mapping lossy, approximate or unavailable, and what is recorded in place of a value? quality
3. Which identifier and digest schemes are exchanged with external systems, and how are they normalised on ingest? identity
4. Is conformance to any external specification asserted, and if so on what cited evidence? evidence