--- 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-06-09 last_link_verified: 2026-06-09 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 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 the ordinary product meaning: tested, supported, unlikely to change underfoot. Stable in the Chromium sense warrants something narrower. It means the project has authorized general exposure for the full user population, through a specific release and governance process. That boundary explains why *Zombie Origin Trial*, *Experiment That Became Permanent*, and *Supply-Chain Vulnerability Lag* are not separate mistakes. Each misreads what Stable does and does not promise. ## 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 has to work on supported operating systems and architectures, against representative production traffic, and without data loss. It must not weaken 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)). It also must not break [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 fact that does the work. A change reaches Canary on the same working day its code lands. It needs no review beyond OWNERS approval and a green commit queue; the population is around 1% of installs, so the stability bar is low. Reaching Stable 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, plus documented launch readiness across the [four-channel](four-channel-pipeline.md) soak. The same source tree feeds both channels. The same patch can produce both behaviors through 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 when the feature appears in the Stable build's source tree behind a flag, because that is exposure-controlled. It also does not begin during a [Finch](finch-variations.md) experiment below 100%, because that is rollout-controlled. Locating a feature on the rollout curve is the practical test for whether the trust-boundary claim has attached. ## Why It Matters Without this boundary, release decisions collapse into vague channel labels. A team cannot tell whether a feature is generally launched, merely present behind a flag, temporarily exposed through Finch, or still protected by a trial. That distinction is what makes release policy, deprecation planning, and downstream security response specific enough to operate. 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." That treats Stable as patched against known vulnerabilities, erasing 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." That collapses the trust-boundary claim onto a permanence claim and 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 to keep available to dependent sites unless it is deliberately and visibly deprecated through the [*Deprecation Trial*](deprecation-trial.md) machinery. Removing a Stable feature costs more than adding one: UseCounter measurement, a deprecation-trial window, a warning campaign, and a final flip. That cost is why 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 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 its actual content discovers the gap during an incident; a policy that treats it as narrower over-invests in 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" and "is defaulted on for all users on Stable." The first is a release-engineering claim: the binary is built and rolling out. The second is a trust-boundary claim: the project is standing behind the feature for the general population. Reading these phrases interchangeably loses the distinction the boundary names. Reading them apart calibrates 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: upstream Stable's patch date, the vendor's own Stable date, and the gap as the 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 keeps the Stable default but names exceptions. Feature X is disabled because it is incompatible with legacy application Y. Feature Z's Finch rollout is monitored via IT-side telemetry before the default is allowed. Security patches outside the four-week milestone cadence follow the standing emergency-release schedule. The boundary's standing claim is what the policy depends on. The boundary's edges are what the exceptions enumerate. ## Consequences Naming the boundary gives release work a sharper vocabulary. A team can read a Stable launch and identify whether the trust-boundary claim attaches yet. It can write an enterprise deployment policy whose claims line up against the standing-claim shape. It can interpret a downstream-vendor security bulletin as a calibrated commitment against the boundary rather than an unconditional guarantee. It 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 instead of 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. 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. Neither reader can import the ordinary meaning of "stable" and be done. 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 outweighed 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 whether the boundary can absorb features that affect every site on the web. Treating the boundary's content as static loses accuracy over the medium term. Its shape is more stable: a standing claim of general suitability gated by the Intent process and enforced by Finch and feature flags. With that shape in view, every cadence change is a calibration of the same boundary rather than a redefinition of it. Release-discipline practices operate on the boundary from different sides. [*Feature Flag Guarding*](feature-flag-guarding.md) enforces it in code. [*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. [*Zombie Origin Trial*](zombie-origin-trial.md) is the failure mode the boundary has to resist. ## Notes for Agent Context For launch-state code, treat "defaulted-on at 100% of Stable" as the operational definition of launch; never collapse it with Stable-build availability or any sub-100% Stable rollout. For enterprise deployment policy, name the channel and Finch rollout state the policy depends on; never assert a frozen Stable feature set or treat Stable as immune to mid-milestone security patches. For Intent to Ship summaries, identify what the three API owner LGTMs are signing off on: general suitability claims about Stable, not a generic approval step. For downstream-vendor security bulletins, calibrate the claim against the upstream Stable date the patch reached, reject the downstream build date as the security reference point, and surface the lag 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: Release Branch Merge Gate](release-merge-gate.md) - [Previous: Origin Trial Token Deployment](origin-trial-tokens.md)