domains / families / general / thinking-triz

thinking-triz

separate

When two design requirements seem mutually exclusive, name the contradiction, separate conflicting states, then invent a concrete no-compromise resolution.

When to use

• Architecture, API, or system parameters pull in opposite directions (stable vs evolving, fresh vs cached, strict vs frictionless).
• You are about to accept a trade-off because "you can't have both."
• Every candidate solution shares the same structural weakness—the conflict is in the requirements, not the options list.

When not to use

• One option is simply better under stated constraints → pick it; do not manufacture a contradiction.
• A cheap measurement shows which side actually matters → measure instead of inventing a separation.
• A standard pattern already resolves it (cache-aside, CQRS, feature flags, versioning) → apply the pattern directly.
• Non-technical people/org conflicts → out of scope; separation targets system parameters.
• Ordinary prioritization or resource allocation without opposing states of the same parameter.

Skill page

Source