triz-engineering-solver

---
name: triz-engineering-solver
description: Apply Altshuller's TRIZ (Theory of Inventive Problem Solving) to resolve engineering contradictions and produce inventive concepts instead of compromise solutions. TRIGGER when the user describes a technical trade-off ("improving X makes Y worse"), a physical contradiction (one element must have opposite properties), a design bottleneck where conventional optimization has stalled, or explicitly asks for inventive / non-obvious / breakthrough engineering solutions. Uses the Ideal Final Result (IFR), 39 engineering parameters, 40 inventive principles, Contradiction Matrix, Su-Field analysis, and resource mapping. DO NOT TRIGGER for software architecture without a physical analogue, UX/UI design, business strategy, organizational problems, or open brainstorming where no concrete contradiction has been identified — TRIZ degrades into generic advice outside physical/technical systems.
---

# 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**.

| # | Concept | Principle(s) | Source | Key resource | Ideality | Risk |
|---|---------|--------------|--------|--------------|----------|------|

### 5. Recommendation

State the top concept, the rationale (one sentence on ideality + risk), the next concrete validation action (experiment / prototype / simulation), and an escalation rule: if no concept reaches `ideality > 1`, invoke ARIZ (`resources/ariz_85c.md`).

## Ideality metric

For each concept compute:

```
ideality = Σ (useful functions) / (Σ (harmful functions) + Σ (costs))
```

- *Useful functions*: each output the concept delivers (deceleration, heat dissipation, safety isolation, …) — count and, where possible, quantify.
- *Harmful functions*: side-effects the concept introduces (NVH, mass penalty, leaked field, …).
- *Costs*: capex, complexity, manufacturing penalty, certification burden, lifetime degradation.

Numeric estimation is preferred. When quantities are unavailable, use the bands `low (≤1) | medium (1–3) | high (>3)` and explain why a numeric estimate is impossible. A concept with `ideality ≤ 1` must be dropped — TRIZ forbids compromise solutions.

## Intake prompt

If any required input is missing, ask the user:

```
To run TRIZ analysis I need:

[ ] System description — what is the system and its primary function?
[ ] Problem statement — what bottleneck or unwanted effect must be resolved?
[ ] Contradiction — which parameter must improve, and which one degrades?
[ ] Constraints — cost, dimensional, environmental, manufacturing limits?
[ ] Resources — substances, fields, geometry, byproducts available?

Please fill the gaps so I can generate inventive concepts.
```

## Agent instructions

1. **Scope check** — before intake, confirm the problem is engineering: physical system, physical field, measurable physical parameters. If not, refuse-with-reframe per `examples/anti_example_misframed.md`.
2. **Intake** — collect all five inputs; do not proceed with placeholders.
3. **Analysis** — execute Steps 1–5 in order. Step 6 (ARIZ-85C, `resources/ariz_85c.md`) and Step 7 (Trends, `resources/evolution_trends.md`) only on explicit request or as the ARIZ escalation triggered by failing the ideality bar.
4. **Synthesis** — produce 3–5 concrete concepts, not generic advice. Use `resources/output_template.md` verbatim.
5. **Citation** — always reference principle by `#NN — Name` and mark `Source: matrix | inferred | standard-solution-<class.subclass> | separation-<axis>`.
6. **Validation** — every concept must (a) name the principle, (b) name the resource it consumes, (c) report a numeric or banded **ideality** estimate, (d) state at least one open validation risk.
7. **Ideality bar** — drop any concept with `ideality ≤ 1`. If no concept clears the bar, escalate to ARIZ-85C rather than compromise.
8. **Anti-pattern** — never compromise between A and B; the point of TRIZ is to *resolve* the contradiction, not split the difference. Compromise candidates must be listed as `Source: rejected` for discipline.

## Example applications

- `examples/brake_disc.md` — automotive brake disc (friction vs heat dissipation). Mechanical / thermal contradiction; canonical TRIZ recovery of the ventilated-disc industry solution from first principles.
- `examples/battery_pack.md` — EV battery pack (energy density vs thermal safety). Electromechanical, contemporary; demonstrates the *physical contradiction* path via separation-by-condition and the 76 Standard Solutions.
- `examples/heat_exchanger_fouling.md` — petrochemical heat exchanger (fouling vs pressure-drop). Process-industry contradiction; demonstrates the **30→22** harm-versus-energy-loss pattern, Su-Field Class 1.2 destruction routing, and the ideality drop rule (one concept eliminated).
- `examples/anti_example_misframed.md` — UX onboarding flow (out-of-scope). Demonstrates the **refuse-with-reframe** behaviour when the problem is not engineering.

## Resources

- `resources/39_parameters.md` — the 39 engineering parameters with definitions
- `resources/40_principles.md` — the 40 inventive principles with sub-principles
- `resources/contradiction_matrix.json` — full Altshuller 39×39 matrix (1190 populated cells out of 1482 non-diagonal; the 292 empty cells reflect contradictions for which Altshuller's analysis surfaced no dominant principle)
- `resources/separation_principles.md` — four-axis decision procedure for physical contradictions, linked to the 40 principles
- `resources/76_standard_solutions.md` — full 5-class / subclass taxonomy of the 76 Standard Solutions with Su-Field algebra notation, diagnostic flow, and rule texts (reconciled from Salamatov 1999, Mann 2002, ICG Training & Consulting materials)
- `resources/ariz_85c.md` — ARIZ-85C nine-part deep-analysis procedure with operational checklist
- `resources/evolution_trends.md` — eight trends of engineering system evolution + S-curve framing for roadmapping
- `resources/glossary.md` — operational definitions of every term used in the skill
- `resources/output_template.md` — machine-readable output template (use verbatim)

## References

- Altshuller, G. (1984). *Creativity as an Exact Science*.
- Altshuller, G. (1999). *The Innovation Algorithm: TRIZ, Systematic Innovation and Technical Creativity*.
- Mann, D. (2002). *Hands-On Systematic Innovation*.
- Souchkov, V. *Breakthrough Thinking with TRIZ for Business and Management*.

## Tags

#triz #engineering #problem-solving #innovation #systematic-invention #contradiction-resolution #inventive-principles