thinking-triz

1# TRIZ
2 
3Resolve technical design contradictions without midpoint compromise. Name the conflict, separate the opposing states, and transform the system so both benefits hold.
4 
5## When to Use
6 
7- Architecture, API, or system parameters pull in opposite directions (stable vs evolving, fresh vs cached, strict vs frictionless).
8- You are about to accept a trade-off because "you can't have both."
9- Every candidate solution shares the same structural weakness—the conflict is in the requirements, not the options list.
10 
11## When NOT to Use
12 
13- One option is simply better under stated constraints → pick it; do not manufacture a contradiction.
14- A cheap measurement shows which side actually matters → measure instead of inventing a separation.
15- A standard pattern already resolves it (cache-aside, CQRS, feature flags, versioning) → apply the pattern directly.
16- Non-technical people/org conflicts → out of scope; separation targets system parameters.
17- Ordinary prioritization or resource allocation without opposing states of the same parameter.
18 
19## Procedure
20 
211. **Name the contradiction in template form.** Write: "We need [PARAMETER] to be [STATE_1] for [BENEFIT_1] BUT [STATE_2] for [BENEFIT_2]." If this form fails, stop—use another method.
222. **State the ideal final result (IFR).** Describe both benefits held with minimal new machinery and no permanent midpoint sacrifice.
23…