--- slug: stable-trust-boundary type: concept summary: "Reaching the Stable channel is a standing warranty about what the Chromium project commits to its users, and a precise account of what that warranty does and does not cover." created: 2026-05-12 updated: 2026-05-13 last_link_verified: 2026-05-13 sources_audited: 2026-05-13 related: four-channel-pipeline: relation: complements note: "The four-channel pipeline names the channels and their populations; this concept names what reaching the last channel warrants and what it does not." intent-ship-pipeline: relation: produced-by note: "The Intent to Ship gate is what establishes Stable suitability; the trust boundary is the standing claim the gate underwrites." api-owner: relation: enforced-by note: "API owners are the population that holds the line on Stable suitability; their three-LGTM gate is the human authority structure behind the boundary." three-lgtm-gate: relation: enforced-by note: "The three-LGTM gate is the procedural mechanism through which Stable suitability is established for web platform changes." feature-flag-guarding: relation: enforced-by note: "Feature flag guarding is the mechanism that lets a feature reach Stable without ever having been exposed by default earlier than the Intent to Ship authorized." finch-variations: relation: enables note: "Finch operates inside the trust boundary; population-percentage rollouts on Stable are the mechanism the boundary tolerates because reversal is fast and per-population." origin-trial: relation: protected-by note: "The trial is what keeps an unvalidated feature out of Stable; the trust boundary is the contract the trial protects." origin-trial-tokens: relation: complements note: "Origin trial tokens carry channel scope; the trust-boundary lens is what makes the difference between a Beta-scoped and Stable-scoped token operationally significant." zombie-origin-trial: relation: violates note: "A zombie origin trial rests on the misreading 'stable means stable, so a deployed token will keep working'; this concept names the contract that the misreading breaks." permanent-experiment: relation: violates note: "An experiment that never sunsets bypasses the Intent to Ship gate that establishes Stable suitability; the boundary is the standing claim the antipattern erodes." web-backward-compatibility: relation: complements note: "Backward compatibility is the trust-boundary claim about feature removal; this concept is the trust-boundary claim about feature addition. The two claims compose." supply-chain-lag: relation: violated-by note: "The antipattern rests on collapsing 'we ship from stable, so we are safe' onto 'stable is patched'; this concept names the contract the lag breaks." embargoed-disclosure: relation: complements note: "The embargo's public-disclosure moment aligns to a Stable channel transition; the trust boundary is what makes Stable the meaningful publication target." downstream-advance-access: relation: complements note: "Downstream advance access is the privileged window that closes when upstream Chrome reaches Stable; this concept is the boundary the window is timed against." --- # Stable as Trust Boundary > **Concept** > > Vocabulary that names a phenomenon. *Chromium's Stable channel is not merely the last stage of the release pipeline but an explicit trust boundary: a feature on Stable is considered generally suitable for the full user population, including users with no tolerance for instability, data loss, or security regression.* An IT director writing a Chrome deployment policy reaches for the word "stable" and assumes it warrants what the word warrants in other product categories: a thing that won't change, a thing that's been tested, a thing the vendor will stand behind. Stable in the Chromium sense warrants something narrower and more specific. The concept names what the warranty is, where it begins, where it ends, and what the procedural and architectural machinery is that the project relies on to keep the warranty true. Readers who carry the trust-boundary lens through the rest of the section read the antipatterns it organizes — *Zombie Origin Trial*, *Experiment That Became Permanent*, *Supply-Chain Vulnerability Lag* — as the canonical misreadings of the same boundary from three different angles. ## What It Is The Chromium project treats Stable as a contract with the general user population. Once a feature defaults on in Stable, the project is committing that it has cleared a launch review whose explicit bar is general suitability: the feature works on supported operating systems and architectures, against representative production traffic, without producing data loss, without weakening the security posture established by prior decisions ([*Site Isolation*](site-isolation.md), the [*V8 Heap Sandbox*](v8-heap-sandbox.md), the [*Untrusted Renderer Axiom*](untrusted-renderer-axiom.md)), and without breaking [web-platform backward compatibility](web-backward-compatibility.md) for content the field is known to be running. The asymmetry between Canary and Stable is the load-bearing fact. A change reaches Canary on the same working day its code lands, with no review beyond OWNERS approval and a green commit queue; the population is around 1% of installs and the stability bar is correspondingly low. Reaching Stable, by contrast, requires the [*Intent to Ship*](intent-ship-pipeline.md) gate: three [API owner](api-owner.md) LGTMs on the blink-dev thread, addressed compatibility, privacy, and security review, and a documented launch readiness across the [four-channel](four-channel-pipeline.md) soak. The same source tree feeds both channels and the same patch produces both behaviors, conditionally on the [feature flag's](feature-flag-guarding.md) channel-dependent default; what separates them is the standing claim the project makes about each population. Reversal on Stable is rare and high-bar by design. Routine bugs are addressed by a security or stability patch on the next milestone; a regression severe enough to warrant pulling a feature server-side calls for [Finch](finch-variations.md) kill-switch traffic and produces an incident review; the rarest case (a code-level revert on Stable) is handled by a backport CL with release-engineering approval and typically Chrome VP-level signoff. The bar is high because the trust-boundary claim is what the bar protects: if Stable could be reverted casually, the standing claim would mean nothing, and downstream consumers who depend on Stable as a predictable artifact would plan against a moving target. The boundary is not symmetric in time. Stable's claim begins the moment a feature defaults on at 100% of the channel and persists until the feature is deprecated through the [*Deprecation Trial*](deprecation-trial.md) machinery or removed under web-platform-backward-compatibility constraints. It does not begin the moment the feature appears on the Stable build's source tree behind a flag (that is exposure-controlled), and it does not begin during a [Finch](finch-variations.md) experiment at less than 100% (that is rollout-controlled). The reader who can locate where on the rollout curve a feature currently sits can locate whether the trust-boundary claim attaches to that feature yet. ## Why It Matters A reader who cannot name the boundary cannot reason about three of the section's antipatterns, cannot calibrate the cost of a Chromium deprecation decision, and cannot write an enterprise deployment policy that says anything specific. The vocabulary is the precondition for the operational arguments that follow. The boundary anchors the section's antipatterns by negation. [*Supply-Chain Vulnerability Lag*](supply-chain-lag.md) rests on the misreading "we ship from stable, so we are safe": collapsing the trust-boundary claim ("Stable is generally suitable for the full user population") onto a security claim ("Stable is patched against known vulnerabilities") erases the calendar gap between upstream Stable and downstream Stable. [*Zombie Origin Trial*](zombie-origin-trial.md) rests on the misreading "stable means stable, so a deployed token will keep working": collapsing the trust-boundary claim onto a permanence claim erases the distinction between trial-period exposure and Stable suitability. [*Experiment That Became Permanent*](permanent-experiment.md) rests on the inverse misreading at the project's own scale: a trial that accumulates dependents until removal is prohibitive has reached Stable in fact without having cleared the Stable suitability gate in form. Each antipattern is the same boundary read incorrectly from a different seat. The boundary also calibrates the cost of the project's own decisions. Web-platform [backward compatibility](web-backward-compatibility.md) binds in part because the trust-boundary claim binds: a feature that has reached Stable is one the project has committed will remain available to dependent sites unless deliberately and visibly deprecated through the [*Deprecation Trial*](deprecation-trial.md) machinery. The asymmetric cost of removing a Stable feature versus adding one (UseCounter measurement, a deprecation-trial window, a deprecation warning campaign, a final flip) is what the boundary costs the project, and is the standing reason every new web-platform addition is gated more heavily than additions in a typical software product. For an enterprise organization deploying a Chromium-based product, the boundary is what makes "deploy Stable" a meaningful policy. Stable warrants what the launch review establishes; it does not warrant a feature set frozen against [Finch](finch-variations.md) rollouts, against per-channel security patches that arrive between milestones, or against a downstream-vendor configuration that consumes upstream Stable on its own lag. A policy that treats Stable's claim as broader than the claim's actual content discovers the gap when an incident lands; a policy that treats it as narrower over-invests in compensating tests for guarantees the project already underwrites. ## How to Recognize It The clearest indicator that the trust-boundary is in operation is the asymmetric procedural bar at the channel transitions. A Canary regression is filed against the Tree Sheriff and addressed within days; a Stable regression escalates to the release-engineering team within hours, names a release-blocker priority, and typically produces a post-mortem. The procedural weight is what the boundary's standing claim is worth. In an Intent to Ship thread on blink-dev, the boundary surfaces as the language API owners use to evaluate the request. "Suitable for general use," "we have sufficient compatibility data," "no known regressions in Beta soak," and "ready to default on in Stable" are claims the API owner LGTM is signing off on. The thread that does not address those claims explicitly does not clear the gate; the thread that addresses them with citations to Origin Trial data, UseCounter measurement, and Finch rollout results is the canonical shape of an approved Intent. In a Finch experiment configuration, the boundary surfaces as the difference between the rollout curve and the launch state. A feature defaulted-on at 100% of Stable has reached the boundary; a feature defaulted-on at 1% of Stable is inside the rollout window the boundary explicitly tolerates because reversal is fast and per-population. Reading a `chromiumdash.appspot.com` rollout curve and identifying where the 100% line is reached is identifying when the trust-boundary claim attaches. In a Chrome Releases blog post, the boundary surfaces as the distinction between "is now available on the Stable channel" (release-engineering claim — the binary is built and rolling out) and "is defaulted on for all users on Stable" (trust-boundary claim — the project is standing behind the feature for the general population). An enterprise IT administrator reading these two phrases interchangeably loses the distinction the boundary names. An administrator reading them apart calibrates their pilot and deployment policy against the right surface. ## How It Plays Out A web standards engineer at a major browser-engine vendor is shepherding an API addition through the Chromium Intent process. The Intent to Experiment cleared three months earlier and the Origin Trial has produced compatibility data from a dozen partner sites. The engineer files an Intent to Ship; two API owners LGTM within a week, the third asks for a UseCounter measurement showing the API's polyfill usage on the open web before approving. The engineer runs the UseCounter for two milestones, returns with the data, and receives the third LGTM. The feature defaults on at 100% of Beta in milestone N+1, defaults on at 1% of Stable for the first three days of milestone N+2, and reaches 100% of Stable a week later. The trust-boundary claim attaches at the 100% Stable moment, not earlier; the engineer's launch checklist documents that moment as the launch date because the boundary is the operational definition of the launch. A downstream Chromium-based enterprise browser vendor maintains a Stable build that tracks upstream Chrome Stable on a seven-week lag (per the [*Four-Channel Pipeline*](four-channel-pipeline.md) and [*Supply-Chain Vulnerability Lag*](supply-chain-lag.md) entries). The vendor publishes a security bulletin for each Chromium CVE patched between the vendor's previous Stable and the upcoming Stable; the bulletin's standing claim is calibrated against the trust boundary, naming upstream Stable's patch date, the vendor's own Stable date, and the gap as the calibrated exposure window the vendor commits to closing. The vendor's customer documentation doesn't say "Stable is patched"; it says "Stable's claim is what reaches the user with each milestone release." An enterprise security engineer is writing a Chrome deployment policy. The first draft says "Deploy Chrome Stable to all employees." A peer reviewer asks the engineer to specify what Stable's claim covers and what it does not. The revised policy reads: "Deploy Chrome Stable with the following enterprise overrides: feature X disabled (incompatible with legacy application Y); feature Z's Finch rollout monitored via IT-side telemetry before allowing the default; security patches outside the four-week milestone cadence applied on the standing emergency-release schedule." The boundary's standing claim is what the policy depends on; the boundary's explicit edges are what the policy's exceptions enumerate. ## Consequences Naming the boundary gives the reader the vocabulary the rest of the section's antipatterns require. They can read a Stable launch and identify whether the trust-boundary claim attaches yet. They can write an enterprise deployment policy whose claims line up against the standing-claim shape. They can interpret a downstream-vendor security bulletin as a calibrated commitment against the boundary rather than an unconditional guarantee. They can engage a blink-dev Intent thread in the procedural register the thread is written in, naming what the API owner LGTMs are signing off on rather than treating the gate as an opaque approval step. The cost of the vocabulary is calibration. The trust-boundary claim is narrower than the consumer-product sense of "stable" and wider than the engineering-purity sense; readers from either end of the spectrum have to recalibrate. An IT administrator who assumed Stable was a frozen feature set learns that [Finch](finch-variations.md) rollouts run inside the boundary continuously. An engineer who assumed Stable was just "the last channel" learns that the channel transition carries a standing claim with procedural weight. It isn't the meaning of "stable" the consumer-product world uses, and neither reader can be expected to bring the boundary intact from prior domain experience. The boundary's content also evolves. The Stable cadence shortened from six weeks to four weeks in Chrome 94 (2021) when the project judged that the security-patch-delivery half of the claim was outweighing the stability half at the longer cadence; the bar for API additions has tightened as the standards community's compatibility-review machinery matured; the Privacy Sandbox's launch sequence has tested the boundary's capacity to absorb features that affect every site on the web. Readers who expect the boundary's *content* to be static lose accuracy over the medium term; readers who expect its *shape* to be stable (a standing claim of general suitability, gated by the Intent process, enforced by Finch and feature flags, reversed by exception) read every cadence change as a calibration of the same boundary rather than a redefinition of it. The patterns in this section operate on the boundary: [*Feature Flag Guarding*](feature-flag-guarding.md) is its implementation-side enforcement, [*Finch Variations*](finch-variations.md) is the rollout infrastructure it tolerates, [*Origin Trial Token Deployment*](origin-trial-tokens.md) is the operator-side surface that issues tokens against channel scope, and [*Zombie Origin Trial*](zombie-origin-trial.md) is the canonical failure mode against which its claim has to be defended. ## Notes for Agent Context When generating release-engineering code that reasons about a Chromium feature's launch state, treat "defaulted-on at 100% of Stable" as the operational definition of launch and never collapse it with "available on the Stable build" or "defaulted-on at <100% of Stable." When writing an enterprise deployment policy or an enterprise-policy override, name the channel and the Finch rollout state the policy depends on; never write a policy that asserts a frozen Stable feature set or that treats Stable as immune to mid-milestone security patches. When summarizing an Intent to Ship thread, identify what the three API owner LGTMs are signing off on (general suitability claims about Stable) and don't paraphrase the gate as a generic approval step. When generating a downstream-vendor security bulletin, calibrate the bulletin's claim against the upstream Stable date the patch reached, not against the downstream build date, and surface the lag explicitly as part of the trust-boundary calibration. ## Sources The Chromium project's [Intent to Ship process documentation](https://www.chromium.org/blink/launching-features/) at chromium.org/blink/launching-features is the most direct source for the procedural shape of the Stable suitability claim; the documented requirements (three API owner LGTMs, compatibility review, privacy review, security review, launch readiness) are what the trust-boundary claim is procedurally backed by. The page describes the gate in the project's own working language and is the source of the "general use" framing the trust-boundary concept names. The Chrome Releases blog at [chromereleases.googleblog.com](https://chromereleases.googleblog.com/) is the working historical record of the boundary's operational events: every channel promotion to Stable, every emergency security release outside the milestone cadence, every published rollback. The four-week Stable cadence introduced in Chrome 94 was [announced on the Chromium blog in March 2021](https://blog.chromium.org/2021/03/speeding-up-release-cycle.html); the post explains the project's reasoning about the security-versus-stability tradeoff inside the boundary's two-sided claim. [Chromium Dash](https://chromiumdash.appspot.com/) and the [Chrome Platform Status](https://chromestatus.com/features) "Available on" column expose the channel-state and rollout-curve data the trust-boundary lens depends on for distinguishing pre-100% rollouts from launch. Chrome Enterprise's [Manage Chrome browser releases](https://support.google.com/chrome/a/answer/9027636?hl=en) page articulates the enterprise-pilot warranty on Beta and the deployment-warranty content of Stable in the project's own language for an IT-administrator audience; the page is the closest the project comes to a vendor-side statement of the trust-boundary claim. ## Technical Drill-Down - [Chromium project — Launching Features](https://www.chromium.org/blink/launching-features/) — the procedural map of the Intent process and the project's own statement of what reaching Stable warrants; the three-LGTM gate is documented here. - [Speeding up the release cycle (Chromium Blog, March 2021)](https://blog.chromium.org/2021/03/speeding-up-release-cycle.html) — the project's reasoning behind the four-week Stable cadence; the post is the trust-boundary's most recent calibration on the record. - [Chrome Releases blog](https://chromereleases.googleblog.com/) — the working historical record of channel promotions, emergency releases, and the rare Stable rollback; the empirical surface against which the boundary's operational content is verifiable. - [Chromium Dash — `chromiumdash.appspot.com`](https://chromiumdash.appspot.com/) — release-engineering surface; rollout curves and channel-promotion history. - [Chrome Platform Status — `chromestatus.com`](https://chromestatus.com/features) — per-feature channel state; "Available on" column carries the trust-boundary-attaching vocabulary. - [Chrome Enterprise — Manage Chrome browser releases](https://support.google.com/chrome/a/answer/9027636?hl=en) — the project's vendor-side articulation of what Stable warrants for an enterprise audience. --- - [Next: Zombie Origin Trial](zombie-origin-trial.md) - [Previous: Origin Trial Token Deployment](origin-trial-tokens.md)