Experiment That Became Permanent

A feature launched as a time-boxed Origin Trial accumulates dependents during its trial window, the sunset is never invoked, and the feature operates indefinitely as production code that was never approved through the Intent to Ship gate.

The name describes the pipeline state, not a metaphor. The Intent pipeline names two terminal states for a trial: shipped, or removed. A feature stuck between them, renewed twice or three times or five times, with a growing dependent population and no Intent to Ship thread in sight, has entered a third state the pipeline doesn’t name. Documentation still calls it “in trial.” Production traffic treats it as shipped. The sunset has stopped being a real date.

Symptoms

• The feature carries origin-trial status on chromestatus.com more than two milestones past its most recently announced expiry, annotated “extended” or “renewed.”
• The blink-dev history shows two or more Intent to Experiment threads requesting extensions, with no Intent to Ship thread between them.
• The Explainer in its WICG repository carries unresolved “open questions” not edited in six months or more.
• The Origin-Trial HTTP response header is observable on production traffic from major sites months after the documented end date.
• Third-party JavaScript libraries reference the feature as a stable capability, with no caveat about the trial gate.
• A downstream Chromium-based product’s release notes describe shipping the feature without naming its trial status.
• The feature’s base::Feature flag defaults to FEATURE_DISABLED_BY_DEFAULT years after the trial began, with the trial layer functioning as the effective enablement surface.

Why It Happens

The Intent pipeline’s machinery is asymmetric. Approving an Intent to Experiment clears a smaller surface than approving an Intent to Ship: the trial is opt-in, time-boxed, and revocable, which lowers the bar for a three-LGTM approval. Removing a feature with an active dependent population requires an Intent to Deprecate, a Deprecation Trial, UseCounter measurements below a removal threshold, and a commitment that survives months of internal review. Starting a trial is cheap. Ending one is expensive. The antipattern is the equilibrium that asymmetry produces.

Two further forces compound it. First, dependent-population growth: the trial’s purpose is to gather compatibility data from real production sites, which is the same as saying its mechanism is to attract them. Early integrators ship, and the feature accretes a constituency whose collapse becomes an institutional event. Second, team turnover: the feature owner who proposed the trial typically rotates within a year or two, and the ship-or-remove decision falls on a successor who didn’t author the Explainer and inherited unresolved open questions. Driving to ship is a multi-quarter project; driving to removal is another multi-quarter project requiring downstream migration. Extending and revisiting next quarter is locally cheapest and structurally favored.

Institutional vocabulary completes the trap. The Origin Trials infrastructure tracks enrollment, expiry, and renewal, but raises no alarm on cumulative renewal counts or long gaps without an Intent to Ship. The pipeline names “in trial,” “shipped,” and “removed”; it doesn’t name “trial-as-production.” A feature in that third state operates as production code without its procedural warrants, and the absence of a name is part of why the API Owner population has no automatic signal to escalate.

The Harm

End users of dependent sites run code whose interface, semantics, and security properties haven’t been ratified by the three-LGTM gate. The trial’s defining property is that the feature may change syntax, change semantics, or be removed. In practice that property has been replaced by a tacit commitment to keep the feature working — a commitment that looks like a shipped feature without the procedural backing of one. The site operator who built on the trial has the worst of both situations: an integration shipping to users as production code, with the guarantees of an experiment.

The project carries the maintenance cost of a feature with none of Stable’s review backing. The trial layer in content/browser/origin_trials/ and the feature’s implementation continue to receive security review, platform-update accommodation, and architectural-change adaptation work, while chromestatus.com reads “trial” and the base::Feature flag stays FEATURE_DISABLED_BY_DEFAULT.

The downstream symptom is the Zombie Origin Trial operators encounter when the project finally does disable a stalled trial server-side. Tokens keep working until the Chrome team explicitly disables them, often months past the documented end date and without the migration window an Intent to Deprecate / Deprecation Trial pair would have committed to. The end is, by construction, an unmanaged migration: sites discover the disablement while debugging a production outage.

The reputational cost is the erosion of the trial contract itself. The project’s ability to use Origin Trials as a compatibility-data-gathering mechanism depends on operators trusting that participation is reversible and the announced sunset is real. Each stalled trial degrades that trust, and operators bifurcate into two camps. Some learn to treat every new Origin Trial as a soft commitment. Others stop taking the announced expiry at face value and build on the feature anyway. Both responses are bad for the project.

The Privacy Sandbox program is the canonical large-scale instance. The deprecation of third-party cookies spans chromestatus feature pages over multiple years, multiple Intent to Experiment threads, multiple announced timelines, and a dependent population that includes the entire third-party advertising and analytics industry. The April 2024 announcement, in which Chrome stated it would not unilaterally disable third-party cookies and would instead route the decision through the user via a new browser-level prompt, was the project’s explicit acknowledgment that the trial-shaped feature had accreted a constituency whose collapse the project could not unilaterally absorb. The third-party cookie path is its own case, but it shows the antipattern at its limit, where the dependent population is not “many sites” but “an industry.”

The Way Out

Options divide into prevention and remediation. Prevention is cheaper; both are institutional rather than technical.

Prevention starts with the Intent to Experiment’s required content. The thread should commit to a maximum total trial duration including extensions (“at most three milestones, after which the feature will be removed if no Intent to Ship has cleared”); a dependent-population review threshold (“if enrollment exceeds N origins, the feature owner will surface a status update on blink-dev and request an API owner check-in”); a named successor owner who inherits the decision if the original rotates off; and a Deprecation Trial commitment naming the fallback if Intent to Ship doesn’t clear. None of these are enforced by tooling today. Strengthening them as API owner review practice would shift the equilibrium without new infrastructure.

A complementary move is a named third state in the pipeline. A trial renewed past a documented threshold (three extensions, or twelve months total) would transition to a stalled-trial status on chromestatus.com, surfacing in API owner review queues independently of any single renewal request. The status wouldn’t force a decision. It would name the state and so prevent the antipattern’s defining property: invisibility to institutional review.

Once a trial has stalled, remediation takes one of two paths. The Deprecation Trial path converts the trial. Dependent sites receive notification, the Origin Trial token mechanism gives them a continued-use window, and the feature is removed on the announced date. The force-ship path applies when the feature has become operationally important enough that removal is unacceptable. The feature owner produces the compatibility evidence and security review the original Intent to Ship would have required, the API owner population grants the three LGTMs, and the feature transitions to Stable with FEATURE_ENABLED_BY_DEFAULT. Force-ship doesn’t vindicate the irregular path, but it terminates the third state. Both mechanisms exist and have been invoked on historical features.

The institutional move that makes either path workable is a forcing function: an annual chromestatus.com audit of every active Origin Trial older than twelve months, naming every feature in the third state and requiring its owner to commit to ship, deprecate, or accept the stalled-trial status. The audit doesn’t require new infrastructure. It requires the API owner population to spend the institutional attention the antipattern consumes whether the attention is spent or not.

How It Plays Out

A Chrome team launches an Origin Trial for a long-requested hardware-integration capability. The Intent to Experiment clears in two weeks; the trial runs for two milestones; a one-milestone extension clears for compatibility data. By then, two major JavaScript libraries document the feature as stable, neither noting the gate. A second extension clears for security feedback; the original feature owner rotates off. A third extension six months later clears with a blink-dev thread asking for a status update at the next API owner check-in. The update never arrives. Eighteen months past the announced end, the feature ships in production traffic on hundreds of major sites and chromestatus.com still reads “origin trial.” A new API owner inherits the gate-keeper role and asks the question the previous owners deferred: ship or remove? The owner finds no margin to drive either decision.

A second team avoids the trap. Their Intent to Experiment names a hard maximum of three milestones, a successor owner, and a committed Deprecation Trial fallback. The trial accumulates similar dependent-population characteristics. At the third milestone the feature owner hasn’t produced the data Intent to Ship would require, so per the original commitment the feature transitions to a Deprecation Trial. Dependent sites get six months’ notice; two major sites migrate, one negotiates a custom extension, the rest migrate or accept the loss. The feature is removed on schedule.

A third scenario shows remediation on an inherited stalled trial. A new API owner running an annual audit identifies a feature extended five times over four years, with major-site dependents and three rotations of feature owner. The audit forces a decision. The feature owner produces a force-ship case: removal is unacceptable, the compatibility evidence is now adequate. The Intent to Ship clears with three LGTMs and a thread that explicitly names the irregular path. The feature transitions to FEATURE_ENABLED_BY_DEFAULT with a Stable-shaped contract, and the chromestatus.com entry carries a permanent annotation that it shipped after the third state.

Notes for Agent Context

When generating code that depends on an origin-trial feature, an AI coding agent must check the feature’s chromestatus.com page for current trial status and most recent announced expiry, and must surface to its user that the feature is gated behind an origin trial whose long-term availability isn’t warranted. The agent must not frame an origin-trial feature as a stable platform capability in documentation, release notes, or commentary, even when the feature has been continuously available and is referenced in third-party libraries as if it were stable. The agent must not infer trial completion from continued availability of the Origin-Trial header on production sites; continued availability is consistent with the antipattern and isn’t evidence the feature has reached an Intent to Ship decision. When asked to advise on whether to integrate a feature whose chromestatus.com status is “origin trial,” the agent must name the antipattern and present both the dependent-population risk to the project and the removal risk to the operator; do not collapse the decision into a recommendation in either direction.

Related Patterns

Sources

The Origin Trials framework was introduced in 2017 and is documented on developer.chrome.com/docs/web-platform/origin-trials as the canonical reference for trial registration, token deployment, and expiry. The third-party cookies path is the canonical large-scale instance of a trial-shaped governance program accreting a dependent population the project couldn’t unilaterally collapse; it is tracked in the Privacy Sandbox program updates and at the chromestatus.com feature page for third-party cookie phaseout, which together record the multi-year sequence of announced timelines, trial extensions, and the April 2024 decision to route the cookie decision through a user-facing browser prompt rather than a unilateral disablement. The Intent pipeline’s own documentation at chromium.org/blink/launching-features names the procedural states a feature passes through but doesn’t name a third “stalled-trial” state; the absence is itself part of the conditions this antipattern produces. The blink-dev archive is the primary record of Intent to Experiment renewals, deprecation discussions, and the API owner review threads that shape the trajectory of any individual trial; pattern instances are visible in the renewal-count metadata across feature threads.

Technical Drill-Down

• Origin Trials documentation — the canonical reference for the trial mechanism, including the registration surface, token deployment, and trial-extension semantics that the antipattern abuses.
• Privacy Sandbox program updates — the public record of the multi-year third-party cookie deprecation trajectory; the April 2024 update naming the user-prompt routing is the project’s explicit acknowledgment of the dependent-population constraint.
• chromestatus.com feature page for third-party cookies phaseout — the per-feature operational view of how the project tracks a trial-shaped governance program over time, with the renewal and timeline metadata that show the antipattern’s signature at scale.
• Chromium feature-launch documentation — the procedural states the Intent pipeline names and doesn’t name; the absence of a third “stalled-trial” state is part of the conditions the antipattern operates in.
• blink-dev mailing list archive — the primary record of Intent to Experiment renewals and Intent to Ship deferrals; pattern instances visible in renewal-count metadata across feature threads.
• Deprecations and Removals announcement series — the remediation-path documentation; an Experiment That Became Permanent is moved back to a governed state by entering this announcement queue as a Deprecation Trial.