---
title: Independent Feature Boundary
status: draft
maturity: hypothesis
families: [composition, execution]
scales: [L1, L4]
admission: research-candidate-only
---

# Independent Feature Boundary

Context: a cohesive frontend capability needs a release cadence different from its
host or neighboring capabilities. Delivery autonomy competes with integration cost,
shared experience and runtime dependency management.

Proposed solution: define the capability's public composition contract and package it
as a separately releasable unit with an explicit activation mechanism. State supported
host/API/dependency versions, lifecycle and cleanup behavior, route ownership, and
which shared state may cross the boundary. Validate compatible old/new combinations
before changing the binding that activates a release.

Publishing bytes, activating them and retiring the old version are separate actions.
Plan for cached bindings, lazy loads and running sessions that retain old code. Define
rollback scope, artifact retention and failure behavior; neither an asset rollback nor
unmount reverses accepted domain operations. A new incompatible contract may require
a coordinated migration despite separate pipelines.

Result: compatible changes can be activated without rebuilding unrelated features,
but compatibility testing, observability and composition policy add cost. A directory,
repository, lazy chunk or lifecycle export alone does not provide this independence.
Shared runtime/startup dependencies can still couple failures. Code in the same browser
context is not thereby security-isolated. Preserve usable navigation and focus across
partial loading, replacement and teardown.

Evidence: [deployment-boundary review](../reviews/FeatureDeploymentBoundaries.md)
D04–D09 locates runtime binding, lifecycle exports and separate workflow definitions
in one example family, with documentary alternatives. CI success, actual deployment
independence and complete-pattern recurrence are unverified. No canonical identity
or admitted graph relations; hypothesis only.

Alternative: a coordinated application release with [Vertical Feature Slice](VerticalFeatureSlice.md)
when separate cadence is unnecessary. Proposed relations: may use
[Failure Boundary](FailureBoundary.md) for a specified fault scope and
[URL-addressable State](URLAddressableState.md) for shared route contracts. Neither
separate activation nor [Islands of Interactivity](IslandsOfInteractivity.md) entails
the other. Boundaries can coincide without becoming the same pattern.

Next test: [VC-06](../walkthroughs/VC06-MicrofrontendEstate.md) proposes compatible and
incompatible feature releases, failed loading and binding rollback across fresh and
already-open sessions. A bounded native-module experiment now exercises these cases; see the update below.

## Executed activation/session evidence — 2026-09-26

[Feature release experiment](../reviews/FeatureReleaseExperiment.md) meets 14/14
expected observations across two browsers in an authored native-module fixture.
Distinguish retained artifact, per-document binding and evaluated module lifetime:
a fresh session follows activation/rollback while an existing session retains its
binding; deleting the old artifact can break its delayed first load. A post-import
API check runs after evaluation and is not a security boundary. A shared startup
failure can block otherwise separate features. These are bounded mechanism observations,
not execution of the source examples or proof of full-pattern production independence.

## Activation conflict and reload policy — 2026-09-26

[Follow-up tests](../reviews/ActivationConflictsAndReload.md) demonstrate lost updates
under blind binding replacement and explicit conflict rejection/refetch for disjoint
intent. A same-feature stale rollback is not automatically reapplied. Atomicity is
verified only in the single-process fixture, not a distributed deployment service.

For unfinished work, distinguish defer, preserve-and-reload and authorized explicit
discard. Block unsafe progress on storage refusal or unresolved operation outcome;
read the latest draft after asynchronous checks. Revalidate stored schema in the new
session because activation can change after preflight. The tested per-tab preservation
is not native-unload/crash protection or a substitute for retention policy.