CUST.3:4 - Solution

CUST.3:4.1 - Establish the result family is meant to serve

State the receiving result in terms that survive a change of implementation. For an analytical service, this might be a defensible eligibility decision from supplied records, not “the same dashboard everywhere.” State who uses it, the operating interval, required quality and the limits beyond which another offering is needed.

Choose cases that expose consequential variation: different inputs, operating environments, levels of recipient capability, support arrangements or acceptance conditions. Include a boundary case that might not belong. Similar sector or customer size can help locate candidates but does not prove commonality.

Do not require an arbitrary number of sales. A qualified design basis can support a prospective family; multiple unexamined deployments can fail to do so. Mark which claims rest on observation, analysis or an untested proposal.

CUST.3:4.2 - Recover the common causal and operating basis

Compare how each case obtains its result. Identify the operation, information or capability that performs the same useful function, then the conditions on which that function depends. Remove local names only after the meaningful role is clear.

For example, two deployments both “validate access,” but one checks a monthly file before analysis and another makes a live authorization decision. A shared phrase does not make their timing, failure handling or evidence interchangeable. They may share a narrower operation while needing different offerings.

Build an initial account of the invariants: what must remain true for all proposed members. Include meaningful input conditions, required operations, acceptance, support and continuing responsibilities where they determine the result. Explain why each invariant matters. “All members use component X” is weak if a replacement could preserve the function; “all accepted records have an interpretable eligibility status under the agreed policy” states the needed condition.

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.

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.

CUST.3:4.4 - Build a member and a boundary, not only a schema

Take a proposed member and assemble it from the common basis plus the selected variations. Follow input preparation, operation, delivery, acceptance and support. Explain any conversion between supplier results and the receiving work. If “use the common module” leaves someone to invent a local procedure, either develop that procedure as a variation or retain the case outside the family.

Now change a consequential condition. Determine whether the member adapts by an allowed choice, needs requalification or leaves the family. This gives the variation rule operational meaning. A configuration table without this construction can admit combinations nobody can deliver.

Construct exclusions positively: explain what condition fails and what alternative remains. “Disconnected sites require a separately qualified synchronization and support method” is useful. “Unsupported configuration” alone is not an adequate return for the customer or field team.

CUST.3:4.5 - Separate what can transfer from what may transfer

Identify the materials and knowledge proposed for reuse, the next recipient and the purpose. Permission to perform local work, access information, learn from a case, disclose an example and redistribute an artifact can differ. Obtain the applicable result through MKT.12 — Investigate a Customer or Market Question for a Decision and MKT.14 — Develop and Change a Programme for Selected Customer Organisations, including their permitted-use and local-material conditions. Obtain specialist advice where the right or obligation depends on it.

Construct the common contribution from permitted inputs. Options include a separately agreed use, a narrower explanation, independently obtained examples or another allowed component. Removing customer names or calling derived data synthetic does not alone establish that the receiving use is allowed.

If permission or an adequate replacement is absent, preserve the local result and stop that transfer. If a replacement changes the evidence basis, repeat the affected qualification. Do not imply that technical portability supplies a missing right.

CUST.3:4.6 - Make provision part of the family

For each member class, identify who can choose it, perform delivery, obtain help, accept the result and maintain the common and local parts. A technically reusable primitive can be one input; a supported offering also needs the obtaining work.

Use CUST.6 to develop and transfer that work. Use CUST.7 to compare common preparation, local adaptation, variation qualification, support and changes over the relevant horizon. A broader family can save setup while increasing interaction testing and support. Include that possibility before admitting the breadth.

For a changed delivery or outcome model, receive the integrated concept from SYSE.8 — Develop an Integrated Offering and Provider Concept for Using an Engineered Result where its engineered-result conditions fit. Carry responsibility, evidence and risk boundaries into the proposed members. A family of technical configurations does not automatically support a family of outcome guarantees.

CUST.3:4.7 - Decide what becomes supported and keep the reason revisable

Admit the common contribution only when its result, applicable members, variations, provision, permissions and ongoing responsibilities fit together. The decision can instead require a narrower family, a separately funded investigation, a local service or no change. A gate is the point at which these constructed grounds are judged; it is not a substitute for them.

Identify the common owner and any local owner by their actual responsibility, not merely repository access. Give future users enough explanation to recognize membership and return an exception. CUST.4 provides the choice method and CUST.8 the change method.

When a case challenges the family, decide whether it exposes a local error, an omitted variation, a failed invariant or a mistaken general rule. Revise only the affected scope. Preserve existing supported members and their obligations while a broader claim is reconsidered.