thinking-triz

name: thinking-trizdescription: When two design requirements seem mutually exclusive, name the contradiction, separate conflicting states, then invent a concrete no-compromise resolution.disable-model-invocation: true

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

1. 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.
2. State the ideal final result (IFR). Describe both benefits held with minimal new machinery and no permanent midpoint sacrifice.
3. Try separation before invention. Test, in order: time (different moments), space (different components/layers), condition (context, load, risk), scale (interface vs implementation, aggregate vs element). Keep the first separation that delivers both benefits without hidden compromise.
4. If separation fails, apply an inventive transform. Prefer resource-light moves: segmentation, preliminary action, inversion (push/pull), intermediary, copying/replication, dynamization (flags/config), another dimension (metadata/versioning/events). Scan only principles that map to the named parameter conflict.
5. Reuse existing resources first. Before adding services or stores, check data, traffic, headers, schedulers, and side effects already present that can carry the separation.
6. Lock a concrete resolution and stop. Specify the design change, where each state lives, and how both benefits are preserved. Stop when a no-compromise design is stated, or when honest analysis shows only a constrained trade-off remains—then document the residual trade-off explicitly rather than forcing TRIZ theater.

Output

Emit a TRIZ resolution:

• contradiction: parameter / state_1+benefit_1 / state_2+benefit_2
• ideal_final_result: both benefits without permanent compromise
• separation_tried: time | space | condition | scale → result each
• inventive_move: principle or pattern used if separation alone was insufficient (or none)
• resources_reused: existing capabilities leveraged
• resolution: concrete design decision and where each state holds
• residual_tradeoff: none, or the honest remaining compromise

Verification

• Template gate: if the contradiction cannot be written in the required form, do not apply TRIZ.
• No-compromise check: a pure midpoint on the trade-off curve without a separation or inventive move is a failed application.
• Separation-first: principles without attempted time/space/condition/scale separation are incomplete.
• Over-application guard: if measurement or a standard pattern settles the design, skip TRIZ.
• Stop: one named contradiction → separation/inventive pass → concrete resolution; do not cycle principles as decoration.