TRIZ

Resolve technical design contradictions without midpoint compromise. Name the conflict, separate the opposing states, and transform the system so both benefits hold.

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.

Procedure