Bundle/Unbundle Menu¶
Choice interface — instantiates Access-Conditioned Bundle Decoupling
Presents the desired access and each attached condition as separately choosable, separately priced options, so a person can take what they need without the unrelated add-ons.
A Bundle/Unbundle Menu takes a package that used to arrive as a single take-it-or-leave-it offer and renders it as a set of separately choosable, separately priced lines — the desired access on one line, each attached condition on its own. Its defining move is to make separability visible and priced at the moment of choice: it exposes where the package can be cut and what each piece costs on its own, so a person can pick up exactly the access they came for and decline the rest. It does not decide whether a condition is separable — it presents an already-known separable set as an à-la-carte choice — and it does not supply the fallback service someone falls back to. It is the interface where "you must take all of this" becomes "here is what each part costs, choose."
Example¶
An airline sells a trip. Historically the fare arrived bundled: seat selection, a checked bag, and priority boarding all folded into one price the traveler paid whether or not they wanted them. A Bundle/Unbundle Menu breaks the fare into lines — base transportation at one price, an assigned seat at another, a checked bag at another, priority boarding at another — each with its own standalone cost shown beside it. A traveler carrying only a backpack sees that the seat and the bag are optional, pays for the flight plus nothing else, and boards. Someone flying with a family and luggage sees the same menu and adds the two items they actually need. The desired access — getting on the plane — is obtained without the unrelated add-ons riding along, and the true price of each add-on is now legible instead of buried in a single number.
How it works¶
- Draw each line at a separability cut. Every menu line marks a place the package can be divided; the desired access sits on its own line, uncoupled from the extras.
- Attach a standalone price to each. Each option shows what it costs alone, so the add-on's real price is visible rather than hidden inside a bundle total.
- Default the extras off. The base access is the starting selection; optional conditions are added by choice, not removed by effort.
- Mark the genuinely inseparable. Items that truly must travel with the access (a safety or compatibility requirement) are labelled required — honestly, not as a place to hide opportunistic add-ons.
Tuning parameters¶
- Menu granularity — how finely the package is split; finer gives more freedom but can overwhelm and let a seller price-partition every micro-feature.
- Default state — whether add-ons start unselected (protects choice) or pre-selected (lifts attach rates but corrodes real refusal).
- Standalone price spread — how the base price compares to the bundle; a punitive standalone price offers nominal choice while steering everyone back into the package.
- Inseparable-item labelling — which lines are marked truly required versus optional; mislabelling an opportunistic add-on as "required" quietly defeats the menu.
- Bundle-discount transparency — whether the genuine savings of buying the package are shown, so choosing the bundle is an informed decision rather than a default.
When it helps, and when it misleads¶
Its strength is that it restores a real choice where a tie used to force acceptance: it makes the cost of each add-on legible and lets a buyer obtain the desired access without paying for the rest. Its failure mode is that separability can be nominal — a seller sets the standalone price so high, or buries the base option so deep, that the menu technically exists while everyone is funnelled back to the bundle. The classic misuse is building the menu backwards, to justify a pre-decided package by pricing the à-la-carte alternative into irrelevance rather than to widen choice. The concept it works against is tying[n1]; the discipline that keeps it honest is to benchmark each standalone price against the item's standalone value and to verify that every "required" flag is a genuine necessity, not a repackaged add-on.
How it implements the components¶
separability_boundary— the menu is the separability boundary made user-facing: every line is a declared place where the package can be cut apart.standalone_price_or_value_anchor— each option carries its own price, anchoring what the item is worth on its own rather than only as part of the bundle.
It renders a known, separable set as priced options; it does not discover the full list of attached conditions (that's Access-Condition Inventory Workshop) or stand up the guaranteed fallback service and exit support that make refusal survivable (that's Standalone Base-Service Path).
Also instantiates¶
Versioning and Quality Discrimination — The very same priced à-la-carte menu doubles as a self-selection screen for buyers whose willingness-to-pay a seller cannot observe. Where the primary facet uses the menu to let someone decline an unwanted attached condition, here the menu's differently-priced lines invite a buyer to reveal their type by what they add: the backpack traveler takes the base fare and nothing else, while the business traveler picks up the assigned seat, the checked bag, and priority boarding — and the seller captures more from the high-value buyer without ever asking who they are. The buyer's own choice among transparent, ordered options does the sorting that intrusive identity-based segmentation would otherwise require. The discipline is the same guardrail read from the other side: each line must map to a real value difference and the base option must stay genuinely usable, so the menu screens preferences honestly instead of degrading the cheap tier into a punitive trap.
Related¶
- Instantiates: Access-Conditioned Bundle Decoupling — it is the interface where a coupled package becomes a set of separable, priced choices.
- Consumes: Access-Condition Inventory Workshop — supplies the enumerated conditions the menu splits into lines.
- Sibling mechanisms: Access-Condition Inventory Workshop · Granular Opt-In Flow · Standalone Base-Service Path · Severability Clause and Review Rule · Access Dependency Heat Map
Editorial Notes¶
Form Classification¶
Form family: Interface, Display & Cue
Rationale: Presents the desired access and each attached condition as separately choosable, separately priced options, so a person can take what they need without the unrelated add-ons, making its operative form a user-facing perceptual surface, prompt, label, or affordance that shapes attention or action.
Independent corroboration: The frozen evidence defines Bundle/Unbundle Menu as 'Presents the desired access and each attached condition as separately choosable, separately priced options, so a person can take what they need without the unrelated add-ons', so its operative form is Interface, Display & Cue.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Economics & Finance
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Industrial-organization and pricing practice separates an already-divisible bundle into independently priced components; interface design makes optional extras visibly opt-in.
Related originating lineages:
- Human-Computer Interaction — HCI contributes interface, navigation, usability, or user-evaluation practice that materially shapes this mechanism.
- Law & Governance — Law and governance contribute the charter, contract, adjudication, rights, disclosure, or procedural-accountability form used here.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
The menu presupposes that the separability decision has already been made — it displays cut-lines, it does not prove them. Where an item is genuinely inseparable (a security check the access can't work without), the honest menu marks it required rather than pretending it can be dropped; deciding which conditions are truly necessary belongs to the Necessity/Proportionality Checklist, not here.
[n1] In competition law, a tying arrangement conditions the sale of a desired product on the buyer also taking a separate, unwanted one. Offering a real standalone price for the desired product is the standard structural response — it is what lets a buyer decline the tied item — and that is exactly the move this menu operationalizes at the point of choice. ↩