# Case 10: what should be standard versus client-specific?

**HVE-DECISIONS-1.0. Fictional interview/design feedback. Use RULE-05, RULE-10 and Nora's change brief.**

## Client interview evidence

- **C10-F1 / Partner lead:** "Reuse the supplier-service learning, not a copy of Zava's customer data or project identity."
- **C10-F2 / Nora:** "We need North/South service region before an application enters review."
- **C10-F3 / Nora reviewer:** "Our team, notification destination and supplier identities are different. Missing settings must not fall back to another client."
- **C10-F4 / Receiving consultant:** "I need to know why a feature/field was chosen and which assumptions must be checked again."
- **C10-F5:** Use actual lab-05 decision artifacts if available; otherwise use its business boundary as a proposed baseline without invented history.

## Technology-specific decision context

Power Platform solutions can package components, but reuse starts with the intended features, logical model, business rules and variation boundaries. Decide whether a request needs configuration, an additive schema change, a new feature or a separate product variant.

Do not assume an optional Region field, existing feature flag, actual package or target deployment. Those are implementation facts to verify later.

## Proposal to inspect

- **C10-P1:** Every new client gets a separate fork with no explanation of what changed.
- **C10-P2:** Put all possible client variations into the first common schema, whether anyone needs them.
- **C10-P3:** Rename Zava's entire project and contacts Nora, and treat earlier decisions as approved by the new client.

## Change for discussion

- **C10-C1:** Nora may add more regions later. Compare a fixed Choice with a managed Region reference entity against actual ownership/change needs.
- **C10-C2:** Another client wants two reviewers for high-risk applications. Identify feature/rule/schema impact without imposing that feature on every client.

## Supplied fictional design-review feedback

| ID | Walkthrough finding |
|---|---|
| C10-T1 | The receiving person can see field names but not which client need each supports. |
| C10-T2 | Nora's required-region feature has no schema/business-rule consequence. |
| C10-T3 | Target team/destination/identity are assumed inherited from Zava. |
| C10-T4 | No distinction exists between a reusable capability and a client-specific decision. |

These are design-transfer findings, not solution import logs or evidence of deployed reuse.