The agent’s TRIZ library.

The theory of inventive problem solving: a systematic methodology developed from recurring patterns in inventions and patent literature.

Improving one property of a system worsens another property.

The same element must have opposing properties to satisfy different requirements.

A classification should cite evidence supplied in the request, rather than invent observations.

Uncertain classification and insufficient problem descriptions require clarification before implementation.

Split the conflicting system, responsibility, data, or workflow into independently changeable parts so each can be optimized without forcing the same trade-off on the whole.

Extract or isolate the component, responsibility, data, behavior, or dependency causing the harmful effect, or retain only the part actually required.

Replace uniform treatment with locally specialized structure, behavior, configuration, or policy so each part operates under conditions suited to its role.

Break unnecessary symmetry: allow different components, replicas, paths, users, or states to have different roles or policies when identical treatment creates the conflict.

Combine compatible components, resources, requests, or operations in space or time when duplication, separation, or coordination overhead creates the conflict.

Let one component or abstraction perform several compatible functions so redundant components, interfaces, dependencies, or transformations can be removed.

Compose components, scopes, containers, or abstractions hierarchically so one can contain, encapsulate, or pass through another.

Offset load, latency, cost, risk, or resource pressure with a compensating mechanism rather than strengthening the constrained mechanism directly.

Apply a compensating or protective action before an expected harmful effect occurs so the later effect is neutralized when it arrives.

Precompute, preload, prefetch, preconfigure, validate, reserve, or position what will be needed before the latency-sensitive or failure-sensitive path begins.

Prepare redundancy, rollback, fallback, reserve capacity, circuit breaking, recovery data, or other emergency protection before a failure occurs.

Equalize states, representations, interfaces, privileges, or operating levels so useful work no longer requires repeated expensive transitions between them.

Reverse direction, responsibility, dependency, ownership, control flow, or operation; make the active side passive or the fixed side movable when the conventional direction creates the conflict.

Replace unnecessarily linear structures or flows with cyclic, ring, rotational, curved, or recursive organization when linearity creates the constraint.

Make components, parameters, policies, capacity, topology, or bindings adjustable and reconfigurable so behavior can change with operating conditions.

When the exact target is expensive or difficult to achieve directly, deliberately under-shoot or over-shoot it and handle the smaller remaining difference separately.

Add an axis, layer, hierarchy, partition, channel, dimension, or level of indirection to escape a constraint imposed by the current representation.

Replace static behavior with controlled oscillation, pulsing, polling, heartbeats, resonance, or higher-frequency interaction when periodic variation exposes a better operating regime.

Replace continuous work with periodic, event-driven, scheduled, sampled, or batched action; tune the cadence and use the gaps for other useful work.

Keep useful work flowing and minimize idle or intermediate stages through streaming, pipelining, concurrency, background processing, or reuse of otherwise idle capacity.

Perform an unavoidable harmful, inconsistent, blocked, or risky transitional state quickly so the system spends the minimum possible time exposed to it.

Turn a harmful factor, waste product, failure mode, contention signal, or rejected result into a useful resource or signal; combine harmful effects when doing so can neutralize them.

Observe the actual outcome and feed it back into control decisions so behavior adapts instead of accepting the trade-off; change the feedback loop when the existing one is ineffective or unstable.

Insert a mediator, proxy, adapter, broker, queue, cache, buffer, gateway, or temporary abstraction between conflicting parties.

Make a component observe, maintain, heal, configure, replenish, or clean up itself, and reuse otherwise wasted outputs or resources where practical.

Operate on a replica, cache, snapshot, proxy, model, simulation, projection, or transformed representation when operating on the original is expensive, dangerous, unavailable, or disruptive.

Replace an expensive long-lived element with inexpensive disposable or ephemeral instances when durability, lifecycle, or cleanup guarantees create unnecessary complexity.

Replace direct or tightly coupled interaction with signals, metadata, events, sensing, declarative rules, virtualization, or another more controllable interaction mechanism.

Replace rigidly provisioned capacity with elastic or flow-based mechanisms such as queues, streams, pools, buffers, backpressure, or dynamically allocated resources.

Use a lightweight flexible boundary such as a wrapper, facade, policy layer, filter, interceptor, or virtual boundary instead of rigid structural separation.

Make a boundary selectively permeable using controlled openings, filters, extension points, plugins, admission rules, sampling, or pre-established channels.

Change representation, labeling, visibility, transparency, telemetry, or observability so otherwise hidden state, differences, or behavior become distinguishable.

Make interacting elements use the same or closely compatible representation, protocol, abstraction, runtime, or substrate to reduce conversion and mismatch costs.

Expire, discard, release, recycle, or transform elements after their useful function is complete, and regenerate or restore them when they become necessary again.

Resolve the conflict by changing state, configuration, granularity, consistency, concentration, flexibility, precision, capacity, or another governing parameter rather than redesigning the whole system.

Move the element into a qualitatively different operating state, mode, representation, or lifecycle phase whose properties remove the original conflict.

Use controlled expansion or contraction of capacity, scope, buffering, replication, or resource allocation in response to changing operating conditions.

Increase the strength or activation level of an enabling mechanism stepwise—such as validation, enforcement, isolation, replication, or signal intensity—when a weaker interaction requires compensating complexity.

Run the interaction in an isolated, neutralized, sandboxed, side-effect-free, simulated, or otherwise controlled environment so harmful interactions cannot propagate.

Combine heterogeneous components, representations, storage models, algorithms, or execution strategies so the composite provides properties that a uniform design cannot.

Let each opposing requirement hold in a different component, node, region, layer, partition, namespace, or architectural location.

Let each opposing requirement hold at a different time, phase, transaction stage, deployment window, operating mode, or lifecycle state.

Let the same element satisfy opposite properties for different users, requests, tenants, relationships, contexts, modes, workloads, or other operating conditions.

Place one required property at the whole-system or supersystem level and the opposing property at a subsystem, component, instance, or lower abstraction level.

Change state, representation, protocol, parameters, or mechanism so both opposing requirements can hold simultaneously rather than being separated.

Redesign the workflow, interaction, architecture, or system boundary so the conflicted parameter or requirement becomes irrelevant instead of being optimized.