Skip to content

Platform Variant Option Model

Product-line model — instantiates Controlled Inheritance Propagation

Defines a common platform as a catalog of options that variants inherit, override at declared points, and eventually fork from when divergence outgrows the shared base.

Platform Variant Option Model treats a family of products as one shared platform plus a bounded set of variation points — the specific options a variant is allowed to change — with everything else held common and inherited unchanged. Where the access- and policy-flavored siblings ask "what flows down and what may override it," this model's distinctive question is "which parts are deliberately open for variation, and how far can a variant diverge before it should stop being a variant at all?" It is the sibling built around a fork threshold: it makes commonality the default, variation an explicit and catalogued choice, and separation a governed exit rather than a slow drift.

Example

A consumer-electronics maker ships one smart-thermostat platform across three variants: a mass-market model, a premium model, and a utility-partner model sold through energy companies. The platform defines a catalog of options — radio module, display type, number of relay channels, and the eco-scheduling feature set — and marks each as fixed or variable. The safety-certified power board and the core control firmware are fixed: no variant may override them, because changing them would break the shared certification. The display, the radio, and the eco-scheduling tier are declared variation points. The premium variant overrides display (color touchscreen) and eco-scheduling (advanced); the utility variant overrides the radio (adds a utility mesh protocol) and locks the thermostat's setpoint range to the partner's demand-response contract.

Two years on, the utility variant has accumulated overrides on setpoint logic, reporting, provisioning, and now billing hooks — none of which the other variants want. The model's fork criterion trips: when a variant overrides more of the platform than it inherits, and its overrides serve a divergent roadmap, it is cheaper and safer to fork it into its own line than to keep bending the shared base around it. The utility model graduates to a platform of its own.

How it works

  • Publish the option catalog. Every property a variant might set is enumerated once, each tagged fixed or variable, with allowed values for the variable ones.
  • Hold commonality by default. A variant inherits the entire platform and specifies only its deltas at declared variation points; unspecified options stay common.
  • Constrain the option space. Not every combination is valid — the catalog encodes which option choices are compatible, so a variant can't select a display its board can't drive.
  • Watch the fork line. Track each variant's override ratio and roadmap divergence; when both cross threshold, trigger a deliberate fork rather than another special-case.

Tuning parameters

  • Commonality/variability split — how much is fixed versus open. A large fixed core maximizes reuse and shared certification but starves variants of flexibility; a large variable surface flatters marketing but erodes the platform.
  • Variation-point granularity — whether options are coarse ("premium feature set") or fine ("this one toggle"). Fine points give precision at the cost of a combinatorial option space to validate.
  • Fork threshold — how much divergence is tolerated before a variant exits. Set it loose and the platform rots under special-cases; set it tight and you spawn forks that could have stayed shared.
  • Override budget per variant — an explicit cap on how many variation points one variant may bend before it needs review, keeping "just one more option" from becoming a shadow product.

When it helps, and when it misleads

Its strength is that it makes reuse the path of least resistance while keeping variation honest: commonality is inherited for free, every deviation is a catalogued choice with a compatibility constraint, and divergence has a defined exit instead of accreting forever. This is the discipline of software product-line engineering and its commonality/variability analysis[1] applied to any platform-plus-variants family.

It misleads when the catalog lies about what is really variable. If a "fixed" core turns out to need per-variant exceptions, teams either smuggle in undocumented overrides — the exact invisible propagation the archetype warns against — or contort the shared base until it serves no variant well. The related misuse is running the fork criterion backwards: declaring a fork already decided for political reasons and then padding the override count to justify it. The guard is to treat the option catalog and fork threshold as reviewed artifacts with real owners, and to fork on measured divergence, not on preference.

How it implements the components

  • inheritable_property_catalog — the enumerated set of options, each tagged fixed or variable with allowed values; the model's backbone.
  • invariant_vs_default_boundary — the fixed/variable tag on each option is the line between what a variant must never override and what it may.
  • fork_or_exit_criterion — the divergence threshold at which a variant should graduate to its own platform rather than remain a variant.

It does not resolve conflicts between competing overrides (precedence_and_conflict_rule — that's Trait or Mixin Composition Rule), record individual override declarations (override_scope_declaration — Template Clause Override Register), or plan migration when the platform changes (migration_and_backfill_plan — Schema Extension and Override Check).

References

[1] In software product-line engineering, commonality/variability analysis separates what all products in a family share from the bounded points where they may differ (often captured in a feature model). The fixed/variable catalog here is that separation made into a live, inheritable artifact. ↩