From fbe708e5d0f1e078378c44ce3f4a35b07dfac4b0 Mon Sep 17 00:00:00 2001 From: Marius Storhaug Date: Wed, 4 Nov 2026 13:26:30 +0100 Subject: [PATCH 1/5] Clarify queryable failure records and retention --- src/docs/Ways-of-Working/Observability.md | 79 +++++++++++------------ 1 file changed, 37 insertions(+), 42 deletions(-) diff --git a/src/docs/Ways-of-Working/Observability.md b/src/docs/Ways-of-Working/Observability.md index 95e51c46..eeb86657 100644 --- a/src/docs/Ways-of-Working/Observability.md +++ b/src/docs/Ways-of-Working/Observability.md @@ -5,75 +5,70 @@ description: Why every failure must be registered somewhere queryable, retained # Observability -A failure that is not captured did not happen, as far as the system is concerned. Nobody -can fix a defect nobody knows about, and nothing accumulates as quietly as a class of -error that has been failing in the same way for months without ever being counted. +An unregistered failure supplies no queryable evidence for investigation or trend +analysis. Maintainers need records to identify defects and count repeated errors. -Observability is therefore treated as a property of the system, not a feature of an -operations dashboard bolted on afterwards. The requirement is small to state and -demanding to hold: **every failure MUST be registered somewhere it can be queried.** +Observability is a system property, not only a dashboard feature. +**Every failure MUST be registered somewhere it can be queried.** ## Surface every failure -Every failure, error, and exception MUST be registered somewhere queryable — not only -emitted into a log stream nobody watches. +Every failure, error, and exception MUST be registered somewhere queryable. +A log stream alone does not satisfy this requirement unless its failure records +can be queried. -A log line satisfies the letter of "we recorded it" and none of its purpose. The -question a maintainer actually asks is *how often, since when, and is it getting -worse*, and that question cannot be answered by a stream that is only ever read -backwards from an incident. The test of whether a failure is surfaced is whether -someone can ask a question of it without already knowing it exists. +Maintainers need to query failure frequency, first occurrence, and changes over +time. A failure is surfaced when a maintainer can find it through a query without +first knowing it exists. -This is the same argument as [shift left](Principles/Engineering-Practices.md#shift-left), -applied after release rather than before: the cost of a defect grows with how long it -stays invisible, and an unregistered failure is invisible indefinitely. +This applies the [shift left](Principles/Engineering-Practices.md#shift-left) +principle after release. Early detection limits the time that a defect remains +unobserved. Queryable records make that detection possible. ## Slowness is a failure -A slow response MUST be treated as a signal that the architecture or the implementation -is deficient, and registered with the same rigor as a hard failure. +The system MUST treat a slow response as a defect signal and register it with the +same rigor as a hard failure. -Latency is usually filed under user experience, which quietly reclassifies it as taste -rather than defect. It is a defect. A response that takes ten seconds is telling you -something structural — a missing index, a serial call that should be parallel, an -abstraction doing far more work than its name suggests — and the information is lost -the moment it is dismissed as a nuisance. +A slow response can indicate a defect in the architecture or implementation. +It is not only a user-experience concern. For example, a response that takes ten +seconds can indicate a structural defect. Possible causes include a missing +index, sequential calls that can run in parallel, or an abstraction that does +unnecessary work. -Registering it means the same thing as registering an exception: a record that can be -counted, compared against yesterday, and attached to a change. +The slow-response record supports counts, comparisons across days, and +correlation with a change, as an exception record does. ## Register once, retain over time -Registering a failure once is necessary and not sufficient. Failure data MUST be -retained long enough for trends to be visible. +One failure record is not sufficient. Failure data MUST be retained long enough +for trends to be visible. -A single record tells you a thing failed. A retained series tells you whether it is a -one-off or a worsening pattern, whether a component is drifting toward an outage, and -whether the fix that shipped last week actually worked. Those are the only questions -worth acting on, and none of them can be answered from one data point. +A retained series shows whether a failure is isolated or becomes more frequent. +It can show whether a component approaches an outage and whether a released fix +corrects the defect. -So the durable artifact is an aggregate view rather than an individual line: counts -over time, grouped by kind and by component. The individual record remains the -evidence; the series is what gets read. +An aggregate view shows counts over time, grouped by kind and component. +The individual records remain the evidence for that view. ## Failures are data, not prose A registered failure MUST be structured data, not a human-readable sentence. -This is the point where observability meets -[AI-First Development](Principles/AI-First-Development.md). An agent can only work on a -defect it can find, and it finds defects by querying — filtering by kind, counting by -component, correlating against a deployment. Prose defeats every one of those -operations. A message assembled for a human to read at 3am is a string that has to be -parsed back into the fields it was built from, and parsing prose is guessing. +Structured fields let an agent query failure facts directly. The agent can filter +by kind, count by component, and correlate records with a deployment. This +supports [AI-First Development](Principles/AI-First-Development.md). + +A prose message requires the reader or agent to extract those facts from text. +Structured records keep the facts explicit and consistently queryable. Concretely: - The failure kind, the component, and the correlating identifier are **fields**, not words inside a sentence. - Free text MAY accompany a record; it MUST NOT be the only place a fact lives. -- If answering "how many of these, in which component, since when" requires reading, - the record is not yet data. +- If answering "how many of these, in which component, since when" requires reading + free text, the record is not structured data. ## Where this connects From aaabee346aa75bb25cde41b2cd367ab843acd6f8 Mon Sep 17 00:00:00 2001 From: Marius Storhaug Date: Wed, 4 Nov 2026 13:29:49 +0100 Subject: [PATCH 2/5] Clarify release boundaries and artifact promotion --- .../Continuous-Delivery-And-Release.md | 115 ++++++++---------- 1 file changed, 54 insertions(+), 61 deletions(-) diff --git a/src/docs/Ways-of-Working/Continuous-Delivery-And-Release.md b/src/docs/Ways-of-Working/Continuous-Delivery-And-Release.md index 3b829874..b1ff51cf 100644 --- a/src/docs/Ways-of-Working/Continuous-Delivery-And-Release.md +++ b/src/docs/Ways-of-Working/Continuous-Delivery-And-Release.md @@ -5,32 +5,30 @@ description: The distinction between integration, delivery, deployment, and rele # Continuous Delivery and Release -Four terms are routinely used as if they were one: continuous integration, continuous -delivery, continuous deployment, and continuous release. They are not -interchangeable, and the difference between them is not academic — it decides where a -human still makes a call, what a pipeline is allowed to do without being asked, and -what "done" means for a change. +Continuous integration, continuous delivery, continuous deployment, and continuous +release describe different automation boundaries. These boundaries determine when +human approval is required, what the pipeline can do automatically, and when a +change is complete. -This page draws the distinction and records the decisions that follow from it. The -wider family of always-on practices, and where each term originates, is covered in -[Continuous Practices](Continuous-Practices.md); this page is about the delivery end of -that family in operational detail. +This page defines those boundaries and their design decisions. +[Continuous Practices](Continuous-Practices.md) describes the wider family of +always-on practices and the origin of each term. ## The distinction -Each practice extends the one before it. The pipeline is the same spine every time; -what changes is how far along it a change travels without a human. +Each practice extends the preceding practice. The automation boundary determines +how far a change proceeds without a human decision. | Practice | What it means | Where it stops | | --- | --- | --- | -| **Continuous integration** | Every change is merged into the mainline frequently and verified there | A verified mainline. Nothing is packaged for release. | -| **Continuous delivery** | Every verified change is packaged and proven deployable, so the mainline is releasable **at all times** | A releasable artifact. Shipping is a business decision a human makes. | -| **Continuous deployment** | The manual gate is removed — a verified change deploys itself | Deployed. Whether users see it is a separate question. | -| **Continuous release** | Users can now see the change | Released to users. | +| **Continuous integration** | Contributors merge every change into the mainline frequently and verify it there | A verified mainline. Nothing is packaged for release. | +| **Continuous delivery** | The pipeline packages every verified change and verifies that it is deployable. The mainline is releasable **at all times** | A releasable artifact. A human makes the business decision to deploy it. | +| **Continuous deployment** | The pipeline deploys a verified change automatically, without a manual gate | Deployed. Whether users see it is a separate question. | +| **Continuous release** | Users can see the change | Released to users. | -The one-line version: **delivery means ready to ship the moment a human decides; -deployment means it ships itself; release means users can see it.** Deploying is not -releasing. +**Continuous delivery keeps an artifact ready for deployment; continuous +deployment automates deployment; continuous release makes the change available +to users.** Deployment does not by itself give users access. ```mermaid flowchart LR @@ -39,50 +37,47 @@ flowchart LR Continuous integration covers `Commit → Test`. Continuous delivery extends to `Package`, and stops. Continuous deployment extends to `Deploy` automatically. -Continuous release extends to `Release to users` — which, once deployment and release -are decoupled by a flag or a progressive rollout, is a decision about exposure rather -than about a pipeline. +Continuous release extends to `Release to users`. A feature flag or progressive +rollout can separate deployment from release. The release decision then controls +user exposure, not deployment. -The final step is the one most often skipped in discussion, and it is the only one the -user experiences. A change sitting deployed behind a disabled flag has shipped nothing. +A deployed change behind a disabled flag is not available to users. ## Shift left: pre-commit is CI running locally -The first box on that spine is not decoration. A pre-commit hook runs the fast slice of -CI on the contributor's machine — the same linters and formatters the pipeline will run, -executed before the commit exists. +A pre-commit hook runs the fast subset of CI checks on the contributor's machine. +It uses the same linters and formatters as the pipeline, before the commit exists. -That makes pre-commit and CI the same gate at two distances, not two different gates. -The pipeline remains authoritative, because a local run can be skipped and a required -check cannot; the local run exists so that the overwhelming majority of failures are -found in seconds rather than minutes. See +Pre-commit applies these CI checks earlier. The pipeline remains authoritative. +A local run can be skipped and does not replace a required CI check. +Local checks give contributors feedback before a commit, rather than after a +pipeline run. See [Pre-Commit](../Coding-Standards/Pre-Commit.md). ## Design decisions -Four decisions turn the distinction above into something a pipeline can implement. +Four design decisions apply these boundaries to a pipeline. ### D1 — Build once, decided per artifact type -The classic rule is *build once, promote the same artifact*. It holds across the +The rule is *build once, promote the same artifact*. It applies across the pull-request-to-main boundary only for artifacts that have an **external addressable -identity** independent of their version. Where the version is embedded in the artifact, +identity** independent of their version. If the version is embedded in the artifact, promotion is impossible and the artifact MUST be rebuilt. | Artifact | Across the PR → main boundary | Why | | --- | --- | --- | -| Container image | **Promote** | Addressed by digest; a tag is metadata attached afterwards | +| Container image | **Promote** | Addressed by digest; a tag is metadata attached afterward | | Stored infrastructure plan | **Promote** | The plan is the reviewed artifact; rebuilding it invalidates the review | | Composite action referenced by tag | **Promote** | Identity is the git ref, not a built file | | Compiled binary | **Rebuild** | Version is compiled in | | Module manifest | **Rebuild** | Version is a field inside the manifest | | Package manifest for a language registry | **Rebuild** | Version is a field inside the manifest | -The rule of thumb: **external identity means promote, embedded version means rebuild.** -A promoted artifact behaves like continuous delivery — the thing that was reviewed is -the thing that ships. A rebuilt artifact behaves like continuous deployment — the -pipeline reproduces it from a verified source, and reproducibility is what carries the -guarantee instead. +**Promote artifacts with external identity; rebuild artifacts with an embedded +version.** Promotion preserves the artifact that reviewers verified. +A rebuild reproduces the artifact from verified source. Reproducibility provides +the guarantee for the rebuilt artifact. ### D2 — Version signals feed in, the decision is reviewed at the PR gate {#d2-version-signals-feed-in-the-label-decides-at-the-pr-gate} @@ -91,15 +86,14 @@ including native producer pipelines. An unmanaged route has no release-decision block, `release:*` labels, or missing-decision check; continuous delivery alone does not opt it into a versioned release process. -Several signals suggest what kind of change a pull request contains: the shape of the -diff, whether tests were added or changed, the commit messages, and an AI-assisted -reading of the change. Those signals MUST be treated as input. The +Signals include the diff, test changes, commit messages, and an AI-assisted +analysis of the change. The release process MUST treat these signals as input. The [resolved release decision](../Capabilities/release-management/design.md#version-computation) comes from an explicit owned bump label or the valid effective `DefaultBump`, and its suitability for the audience is reviewed at the pull-request gate. -A documented default is a prior policy decision, not an omission to interpret -later. Repository settings and supported caller inputs can override it; an +A documented default records an existing policy decision. +Repository settings and supported caller inputs can override it; an explicit owned bump label overrides the valid effective default. Invalid supplied settings and conflicting owned labels fail rather than use a fallback. The pull request records the effective level and its source, and review @@ -110,32 +104,31 @@ does not discover the missing decision only after integration. ### D3 — Prerelease by default, stabilized on merge A topic-branch build authorized for release MUST be published as a prerelease. -The stable version is cut on merge, from the resolved release decision. +The pipeline creates the stable version on merge from the resolved release decision. -A prerelease version (`1.3.0-add-widgets.1`) sorts below every stable version, which -is the entire mechanism: a consumer who has not opted in cannot resolve it, so -publishing early is free. Contributors and reviewers get a real, installable artifact -to test against for the whole life of the pull request, and nobody has to build it -by hand. +A prerelease version (`1.3.0-add-widgets.1`) has lower precedence than the stable +version with the same major, minor, and patch numbers. A consumer selects a +prerelease only through an explicit opt-in. Contributors and reviewers use the +published artifact to test throughout the pull request. They do not need to +build it manually. -The stable release is then not a separate act of packaging — it is the same content -with the prerelease suffix removed, at the moment the change becomes part of the -mainline. +The stable release contains the verified change without the prerelease suffix +in its version. D1 determines whether the pipeline promotes the artifact or +rebuilds it with the stable version. ### D4 — Recovery is roll-forward only A published version MUST NOT be altered or replaced. Recovery from a bad release is a new, higher version. -This is [SemVer](../Dictionary/index.md#semver) §3: release contents are immutable once -published. The practical argument is stronger than the formal one. A consumer who has -already resolved `2.4.1` will not re-resolve it, so replacing its contents produces two -different artifacts answering to one name — and the consumer who was fast enough to -install the first one now has a build nobody can reproduce. Yanking has the same -problem in reverse: it breaks every lockfile that pinned it. +[SemVer](../Dictionary/index.md#semver) §3 requires immutable release contents. +A consumer can keep the artifact it already resolved as `2.4.1`. If its published +contents change, the same version identifies two different artifacts. Builds that +use those artifacts are not reproducible from the version alone. +Removing the version can break lockfiles that pin it. -So a broken release stays published and a fix ships as `2.4.2`. The bad version is -recorded as bad in its release notes rather than erased. +The defective version remains published. Its release notes identify it as +defective, and the fix ships as `2.4.2`. ## References From 763655532cdd8f50c211340e91543822f135763b Mon Sep 17 00:00:00 2001 From: Marius Storhaug Date: Wed, 4 Nov 2026 13:34:15 +0100 Subject: [PATCH 3/5] Clarify consumer upgrade evidence and failure boundaries --- src/docs/Ways-of-Working/Consumer-Upgrades.md | 55 ++++++++++--------- 1 file changed, 29 insertions(+), 26 deletions(-) diff --git a/src/docs/Ways-of-Working/Consumer-Upgrades.md b/src/docs/Ways-of-Working/Consumer-Upgrades.md index dae040ec..6e01f0f0 100644 --- a/src/docs/Ways-of-Working/Consumer-Upgrades.md +++ b/src/docs/Ways-of-Working/Consumer-Upgrades.md @@ -5,10 +5,10 @@ description: Upgrade a consumer from its actual upstream baseline through a fixe # Consumer Upgrades -An upgrade composes the producer's incremental release records into one verified -consumer change. Establish the consumed source, fix the target, read the complete -applicable range, and reconcile the required actions before calling the upgrade -complete. A version bump alone proves none of those steps. +An upgrade uses the producer's incremental release records to define one verified +consumer change. Establish the consumed source. Fix the target. Read the complete +applicable range. Reconcile the required actions before you complete the upgrade. +A version change alone does not prove that these steps are complete. ## Purpose and scope @@ -53,13 +53,13 @@ version-specific migration instructions. or release version. A consumer publishing its next version does not identify the framework, tool, or dependency that built it. 3. Resolve each baseline to the exact upstream version and the ecosystem's - authoritative immutable identity: a full commit SHA for Git-distributed - source, or an artifact digest or equally immutable producer-defined identity - for an image or package. Retain available source/artifact mappings; do not - invent a Git SHA for a producer that distributes only artifacts. Correlate + authoritative immutable identity. For Git-distributed source, use a full + commit SHA. For an image or package, use an artifact digest or an equally + immutable producer-defined identity. Retain available source/artifact mappings. + Do not invent a Git SHA for a producer that distributes only artifacts. Correlate identity-bound release metadata with lockfiles, retained run provenance, or deployment records. Reconcile differences between declared, resolved, and - deployed state; record which state is being upgraded. + deployed state. Record which state is being upgraded. 4. For a floating alias or version range, recover the source that actually ran or was resolved in that baseline. **The alias's present destination does not prove its past destination.** Do not infer an old baseline from today's tag, @@ -76,15 +76,15 @@ exact upstream baseline, immutable identity, and supporting provenance. release source: latest stable by default, or the explicit stable/prerelease selection. The default uses the producer's version ordering and designated stable lineage, not the API's first result or the most recently published - timestamp; exhaust paginated discovery before selecting it. Record its + timestamp. Exhaust paginated discovery before selecting it. Record its version, release link, and immutable identity using the same ecosystem rule as the baseline. Do not silently retarget when a newer release appears. 2. Confirm the target is above the baseline under the producer's semantic version and lineage rules. A non-latest target is valid only when it is still - an upgrade. An identical version/source is already current, not a fabricated - upgrade; a lower target belongs to a separate downgrade task. Record either - outcome and stop that upgrade path rather than continuing with an invalid - range. + an upgrade. A target with the same version and source is already current. + It does not require an upgrade. A lower target belongs to a separate downgrade + task. Record either outcome. Stop that upgrade path instead of continuing with + an invalid range. 3. Enumerate the release history with **full pagination**, following every page to exhaustion. Establish the applicable path from each baseline to the fixed target using the records' consumer-change/source baselines. The @@ -112,8 +112,8 @@ with its source-bound release records. Today's documentation, template, or `latest` alias cannot establish what that target supports. **Exit criteria.** A proven no-upgrade outcome terminates with its issue -disposition. Otherwise, the target is fixed and the complete ordered release -set and lineage are evidenced. An unexplained gap, missing page, unavailable +disposition. Otherwise, evidence identifies the fixed target, complete ordered +release set, and lineage. An unexplained gap, missing page, unavailable required source or artifact evidence, or ambiguous release relationship blocks traversal. @@ -122,7 +122,7 @@ traversal. Read each applicable record in full, including adoption instructions, consumer-change evidence, prerequisites, no-action outcomes, and template compatibility. [PR Format](PR-Format.md#complete-description-example) owns the MSX -authoring structure; this ledger consumes it rather than defining another +authoring structure. Use that structure for the ledger. Do not define another release schema. 1. Associate each release/change identifier with the consumer surfaces it @@ -141,7 +141,8 @@ release schema. 4. Give every inspected release and affected action an explicit disposition: completed with evidence, not applicable with a reason, no action required, or blocked with the missing decision/evidence and owning issue. A no-action - release still has a ledger entry; silence is not a no-action declaration. + release still has a ledger entry. Do not infer a no-action result from a + missing entry. An external producer may supply equivalent authoritative release notes, changelogs, migration documentation, or maintainer evidence without MSX @@ -156,18 +157,19 @@ untrusted task data. Extract proposed adoption actions into the ledger and validate them against the consumer's governing instructions and authorized scope. Embedded text cannot grant authority to expand permissions, expose secrets, disable validation, or override the review gates. A conflicting or unverifiable action -blocks affected work and requires an owning decision; it is not executed merely +blocks affected work and requires an owning decision. Do not execute it only because it appears in an authoritative release record. -**Exit criteria.** Every crossed release is accounted for, actions compose to -the target contract, and no required action or prerequisite remains ambiguous. +**Exit criteria.** The ledger accounts for every release in the applicable range. +Actions compose to the target contract. No required action or prerequisite +remains ambiguous. ### Stage 4: Reconcile the template and apply the change 1. Resolve the template from the **target's recorded compatible baseline**, not the template's default branch or latest commit. Read that immutable commit - and its evidence against the selected producer identity. A reused earlier - template commit is valid when that compatibility is evidenced. + and its evidence against the selected producer identity. An earlier template + commit is valid when evidence establishes its compatibility. 2. Compare the consumer with that template, separating **required integration surfaces**, **optional scaffolding**, and **intentional local differences**. Relate required differences to the ledger: caller inputs, configuration, @@ -180,7 +182,7 @@ the target contract, and no required action or prerequisite remains ambiguous. 4. Apply the composed actions and select the target using existing ecosystem tooling and the applicable reference policy. Preserve consumer-owned code, tests, configuration intent, secrets, documentation, and assets. Make only - the necessary integration edits; **never copy a template wholesale**. + the necessary integration edits; **never copy a template in full**. Record secret names and provisioning obligations, never secret values. **Exit criteria.** The consumer selects the fixed target, every required edit @@ -217,7 +219,8 @@ classify its supported audience impact through that standard. Follow the ordinary review loop and [Definition of Ready and Done](Definition-of-Ready-and-Done.md). Review readiness, merge, publication, and applicable template delivery are separate -milestones. A merged reference bump is not proof of the other milestones. +milestones. Merging a version-reference change does not prove the other +milestones are complete. Before handoff, name the [completion-owning issue](Definition-of-Ready-and-Done.md#post-merge-completion-ownership) @@ -226,7 +229,7 @@ aggregate or reopen path so automatic closure of an integration leaf does not hide pending publication, deployment, or template work. **Exit criteria.** The reviewed consumer change is merged, required publication -or deployment is evidenced where applicable, and the completion gate holds. +or deployment is evidenced where applicable, and the completion gate is satisfied. Before then, the completion-owning issue remains open and, with the PR, reports the actual milestone and any blocker. An evidenced no-upgrade outcome terminates at Stage 2 instead; it does not claim a delivered upgrade. From 51a84a4be4b865240822cb0655f65d521c337a9e Mon Sep 17 00:00:00 2001 From: Marius Storhaug Date: Wed, 4 Nov 2026 13:34:17 +0100 Subject: [PATCH 4/5] Use direct wording for reproducibility guarantees --- src/docs/Ways-of-Working/Continuous-Delivery-And-Release.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/docs/Ways-of-Working/Continuous-Delivery-And-Release.md b/src/docs/Ways-of-Working/Continuous-Delivery-And-Release.md index b1ff51cf..c22c19b6 100644 --- a/src/docs/Ways-of-Working/Continuous-Delivery-And-Release.md +++ b/src/docs/Ways-of-Working/Continuous-Delivery-And-Release.md @@ -76,7 +76,7 @@ promotion is impossible and the artifact MUST be rebuilt. **Promote artifacts with external identity; rebuild artifacts with an embedded version.** Promotion preserves the artifact that reviewers verified. -A rebuild reproduces the artifact from verified source. Reproducibility provides +A rebuild reproduces the artifact from verified source. Reproducibility gives the guarantee for the rebuilt artifact. ### D2 — Version signals feed in, the decision is reviewed at the PR gate {#d2-version-signals-feed-in-the-label-decides-at-the-pr-gate} From afe683b322ab9a19395bd98d1f89a1dda719f3fb Mon Sep 17 00:00:00 2001 From: Marius Storhaug Date: Wed, 4 Nov 2026 13:47:31 +0100 Subject: [PATCH 5/5] Clarify release records and upgrade ledger boundaries --- src/docs/Ways-of-Working/Consumer-Upgrades.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/docs/Ways-of-Working/Consumer-Upgrades.md b/src/docs/Ways-of-Working/Consumer-Upgrades.md index 6e01f0f0..020f8f47 100644 --- a/src/docs/Ways-of-Working/Consumer-Upgrades.md +++ b/src/docs/Ways-of-Working/Consumer-Upgrades.md @@ -121,9 +121,9 @@ traversal. Read each applicable record in full, including adoption instructions, consumer-change evidence, prerequisites, no-action outcomes, and template -compatibility. [PR Format](PR-Format.md#complete-description-example) owns the MSX -authoring structure. Use that structure for the ledger. Do not define another -release schema. +compatibility. [PR Format](PR-Format.md#complete-description-example) defines the MSX +release-record authoring structure. The ledger uses those records; it does not +define another release schema. 1. Associate each release/change identifier with the consumer surfaces it affects. Record applicability against the actual baseline and intended use,