CUST.3:4.3 - Construct variations and choose their home
For each observed or proposed difference, ask whether it changes only a value, selects an already understood alternative, changes an interface, requires a different method or defeats the common result. Choose the smallest form that preserves the needed distinction.
| Proposed form | Construct it by | Return or rejection condition |
|---|---|---|
| Parameter or configuration | Define allowable values, their meaning and effects on other choices. | A permitted value changes the obtaining method or invalidates another condition. |
| Adapter or extension | State the stable receiving interface, which inputs or outputs need conversion, what each conversion must preserve, and who maintains the adapter or extension. | The extension changes an assumed invariant or requires unsupported access. |
| Separate supported profile | Name the distinct combination of assumptions, execution and support. | Profiles share only a label and no useful common basis. |
| Common component | Extract a function with qualified interfaces and replaceable local inputs. | Useful operation depends on unrepresented local judgement. |
| Repeatable service method | Explain the work, preparation, choices, help and acceptance that transfer. | Repetition still requires hidden invention or unavailable specialist effort. |
| Local residue | Bound the case, obligation and reason for not generalizing it. | The residue repeatedly changes the shared basis and is no longer genuinely isolated. |
Compare both directions of development. A top-down family starts from a deliberate platform or common service design and derives permitted members. A bottom-up family extracts a useful common basis from differing local solutions. Neither direction is inherently superior. Use the first when the expected variation and shared investment are sufficiently understood; use the second when actual differences are still teaching you what is common. They can meet as a prospective design is corrected by deployment evidence.
When later engineering change, platform development or interface evolution is the live technical problem, obtain the complete result from SYSE.23 — Choose What to Change So Later System Changes Become Easier, SYSE.25 — Decide Whether and How to Improve a Platform from Practitioner-Task Evidence, SYSE.26 — Design a Supported Platform-Use Path or SYSE.27 — Evolve Platform Interfaces and Contribution Paths. Bring back the actual supported function, interface, use path and change restrictions. CUST places those results within an offering family; it does not replace the engineering design.