TRIZ Engineering Solver

A systematic analytical engine for solving engineering problems with Genrich Altshuller's Theory of Inventive Problem Solving (TRIZ). Replaces trial-and-error brainstorming with algorithmic problem-solving over a corpus of patent-derived patterns.

When to use

• Engineering trade-offs where improving parameter A degrades parameter B (technical contradiction)
• A single element must exhibit opposite properties (physical contradiction)
• Design bottleneck where conventional optimization has plateaued
• System redesign aimed at the Ideal Final Result

When NOT to use

• Pure software architecture without a physical analogue
• UX / interaction design
• Business or organizational strategy
• Open brainstorming with no concrete contradiction identified

Inputs required

Before analysis, collect from the user:

1. System description — current engineering system and its primary function
2. Problem statement — the specific bottleneck or undesired effect
3. Contradiction parameters — which parameter must improve, which one degrades
4. Constraints — environmental, cost, manufacturing, physical limits
5. Available resources — substances, fields, geometry, byproducts, environment

If any input is missing, use the self-prompting block in ## Intake prompt below.

Workflow

Step 1 — Formulate the Ideal Final Result (IFR)

Describe the outcome where:

• The desired function is achieved perfectly
• No additional cost, complexity, or harmful side-effect is introduced
• Only existing internal / external / temporal resources are used
• The problem "solves itself"

Question to drive Step 1: "In an ideal world, how would this system achieve [desired function] using only what already exists, with zero added complexity?"

Step 2 — Classify the contradiction

Technical contradiction: improving parameter A causes parameter B to worsen.

• Example: increasing strength (A) increases weight (B).

Physical contradiction: a single element must exhibit opposite properties simultaneously or under different conditions.

• Example: a surface must be rough (for grip) and smooth (for low friction).

Physical contradictions are typically resolved by separation in space, time, condition, or system level (parts vs. whole). For the decision procedure and the principles linked to each separation axis, see resources/separation_principles.md. Technical contradictions are resolved via the Contradiction Matrix → Inventive Principles.

Step 3 — Map to the Contradiction Matrix

1. Identify the improving parameter from the 39 — see resources/39_parameters.md.
2. Identify the worsening parameter from the 39.
3. Look up the cell in resources/contradiction_matrix.json. The cell lists 3–4 recommended inventive principle IDs.
4. For each suggested principle, retrieve its full description and sub-principles from resources/40_principles.md.
5. Apply the principles to the concrete system to generate candidate solutions.

Note: resources/contradiction_matrix.json contains the full Altshuller 39×39 matrix (1190 populated cells; 292 cells are legitimately empty in the original — Altshuller's patent analysis found no dominant principle for those contradictions). For empty cells, fall back to reasoning over the 40 principles directly and mark the suggestion as Source: inferred rather than Source: matrix. See the JSON meta.primary_source for transcription provenance.

Step 4 — Su-Field (Substance–Field) analysis

Model the system's function as a triad:

• S1 — object being acted upon
• S2 — tool / agent acting on S1
• F — field carrying the action (mechanical, thermal, chemical, electromagnetic, gravitational, acoustic)

Diagnose:

• Incomplete system (missing S2 or F): add the missing element, preferring existing resources.
• Insufficient/ineffective interaction: introduce a more controllable field, intermediate substance, or field additive.
• Harmful interaction: insert a barrier substance, introduce a counteracting field, or modify field properties.

For systematic Su-Field transformations, consult resources/76_standard_solutions.md — class taxonomy, diagnostic flow, and the most-cited operational sub-rules of the 76 Standard Solutions (Altshuller, grouped into 5 classes). When you cite a Standard Solution, mark Source: standard-solution-<class.subclass> in the output.

Step 5 — Resource utilization

Enumerate before generating concepts:

• Internal resources: unused properties of components, byproducts, idle time, geometric features (holes, surfaces, edges).
• External resources: environmental substances (air, water, gravity), environmental fields (magnetic, thermal gradients), supersystem (adjacent systems).
• Temporal resources: pre-process preparation, post-process utilization, parallel operations.

Prefer concepts that consume free resources over concepts requiring new components.

Step 6 (optional) — ARIZ deepening

For hard problems where the 40-principles pass yielded no strong concept (no concept reaches ideality > 1, see Output format below), switch to ARIZ-85C (Algorithm for Inventive Problem Solving) — a formal 9-part procedure that reframes the problem mini-problem → operational zone → operational time → substance-field resources → IFR-1 → physical contradiction → standard solution. Full procedure and operational checklist: resources/ariz_85c.md. Invoke explicitly when the user asks for "deep TRIZ" / "ARIZ analysis" or when the quickstart fails the ideality bar.

Step 7 (optional) — Trends of Engineering System Evolution

For prognostic / roadmapping questions ("where will this technology go next?"), map the system to the 8 trends (increasing ideality, non-uniform development of parts, transition to supersystem, transition to micro-level, increasing dynamism, complexity → convolution, matching/mismatching, reducing human involvement). Full list, S-curve framing, and the diagnostic procedure: resources/evolution_trends.md. Out of scope for the contradiction-resolution workflow above — invoke only when the user's question is prognostic, not corrective.

Output format

The full machine-readable template lives in resources/output_template.md — use it verbatim. The sections below are the inline summary for quick reference. Every concept must report a numeric (or banded) ideality estimate (see "Ideality metric" below). Concepts with ideality ≤ 1 are dropped, not compromised.

Generate a structured analysis containing the sections below. Keep each section tight; this is an engineering deliverable, not an essay.

1. Contradiction statement

Technical contradiction: improving [Parameter A, with #] causes [Parameter B, with #] to worsen.
— OR —
Physical contradiction: [Element X] must be [Property 1] AND [Property 2].
  Separation strategy candidate: [space | time | condition | system-level].

2. Ideal Final Result

IFR: The system achieves [desired function] using [existing resource],
without adding [cost/complexity/harm], where [problem element] solves itself.

3. Inventive concepts (3–5)

For each concept:

• Concept name — short descriptive title
• TRIZ principle(s) applied — number + name (from resources/40_principles.md)
• Source — one of matrix (cell-derived), inferred (reasoning over the 40 principles), standard-solution-<class.subclass> (Su-Field, see resources/76_standard_solutions.md), or separation-<axis> (physical contradiction, see resources/separation_principles.md)
• Description — specific, actionable engineering solution (2–3 sentences)
• Resource utilized — which internal / external / temporal resource is leveraged
• Implementation path — high-level technical pathway
• Risks / open questions — what would need to be validated experimentally

4. Principle-to-concept summary table

Sorted by Ideality descending.