How to Refer to the 40 Triz Principles to Identify and Resolve Contradictions (TRIZ)

The 40 TRIZ principles come from Genrich Altshuller and colleagues in the Soviet Union, mid‑20th century, after they analyzed thousands of patents to find recurring inventive patterns. The common trap is thinking of TRIZ as an abstract list or a specialized engineering tool; people often skim the principles and never apply them. Another failure point: treating principles as one‑size‑fits‑all; they are heuristics that need interpretation. Outcomes change when we pair a principle with a concrete constraint (weight, time, or cost) and test small prototypes within 30–90 minutes. TRIZ improves creative resolution rate by giving us ~40 focused moves instead of infinite vague options.

Why this matters now: we live with many trade‑offs—speed vs. quality, cost vs. durability, privacy vs. convenience. TRIZ helps us name a contradiction and then pick targeted moves (like Segmentation, Local Quality, or Parameter Change) that commonly have worked to overcome similar trade‑offs in engineering, software, logistics, and product design.

A practice‑first promise We will not only read the principles aloud; we will choose a personal contradiction, try at least two TRIZ moves in a real micro‑experiment, and log outcomes with Brali. We imagined an office task where we want faster turnaround on client reviews (improve speed) without losing quality (worsen quality). We assumed a simple "do faster" approach would work → observed reviews became 20–30% sloppier → changed to "segmented review + buddy check" and regained quality. That pivot is the explicit learning thread you will use: assume → observe → change.

Part 1 — Naming the contradiction: anatomy and quick check We begin with a small action. Take a timer. In 5 minutes, write one sentence that states the contradiction as two competing goals, separated by “but” or “however”. Examples:

• “We want to reduce meeting time to 30 minutes, but we also want to preserve the same decision clarity.”
• “I want to eat 500 kcal less per day, but I don’t want to feel hungry at 8 pm.”

Rigidly phrasing the contradiction matters because TRIZ works on conflicts between features or parameters. If we can’t express the tension in one sentence, we’re not specific enough.

Micro‑sceneMicro‑scene
we sit at a kitchen table. Clock set on 5 minutes. Pen, or the Brali quick note. We write: “We want to shorten code review cycles from 72 h to 24 h, but we can’t increase reviewer errors above 2%.” The act of putting numbers (72 h → 24 h; 2%) converts a fuzzy desire into an actionable constraint.

Why numbers? Because they create measurable targets. TRIZ is most useful when a parameter is quantifiable—time, temperature, weight, count, percent. If your goal is vague (“better quality”), translate it into something like “reduce post‑release bug count from 5/week to ≤2/week.” We will assume quantification often forces a change in strategy; if we leave goals fuzzy, we’ll choose vague principles and then stop.

Action now (≤10 minutes)

• Open Brali LifeOS, create a new task: “TRIZ: Name contradiction (5 min)”. Use that task to save the sentence and numeric targets. Use the app link: https://metalhatscats.com/life-os/triz-40-principles-contradiction-guide
• Spend 5 minutes on the sentence and numbers.
• Tag a calendar block (25 or 45 minutes) to run experiments next.

Part 2 — A quick map of the 40 principles and how we’ll use them We will not list all 40 principles here as an unread checklist; instead we group them functionally so we can pick a few moves quickly. Each group is a cognitive frame; when we notice one fits our micro‑scene, we try an Actionable Move.

• Separate / Segment (e.g., Segmentation #1, Local Quality #3) Actionable move: Break the process into independent parts and change rules per part.
• Change parameters / Dynamics (#35, #15) Actionable move: Change a measurable parameter—speed, temperature, frequency—or make it dynamic (periodic, conditional).
• Use the environment / resources (#22, #24) Actionable move: Move function to surrounding environment or add auxiliary resources.
• Inversion / Repeat / Cushion (e.g., #13, #11) Actionable move: Flip a function, do the opposite of our instinct, or add redundancy.
• Composite / Combine / Self‑service (#5, #40) Actionable move: Merge roles or make parts feed themselves.

We will choose between two to three moves, run a tiny experiment, and measure.

We assumed X → observed Y → changed to Z We assumed “faster equals fewer steps” (X)
→ observed “quality fell 20%” (Y) → changed to Z: “keep steps but segment and parallelize rule changes” (Z). That pivot shaped our next experiments: instead of cutting steps, we made steps shorter and introduced a local quality check.

Part 3 — Practice: pick three TRIZ moves to try today (60–90 minutes)
We prefer trying 3 moves in sequence or in parallel. Each move has a short protocol with time and measures.

Move A — Segmentation + Parallelization (Principles: Segmentation #1, Local Quality #3) Why: Many contradictions arise because a single monolithic process must satisfy opposing goals. Splitting often allows different parts to optimize differently. Protocol (30–40 minutes)

• Identify process to split (e.g., review process: surface checks vs. deep architecture checks).
• Create two parallel lanes: Lane 1 = fast surface checks (format, typos) with a checklist (5 items, ≤10 min); Lane 2 = deeper checks for architecture/logic (≥30 min).
• Assign different people or rotate responsibilities. For instant practice, we split our own time: 10 min surface now; postponed deep check to another 60–90 min block. Measures: time per lane (minutes), error rate found in each lane (count), overall defects escaping to next stage (count). Expected trade‑offs: More handoffs possible (coordination cost), but each lane can be optimized for its goal.

Move B — Parameter Change: Make a parameter conditional or variable (Principles: Dynamicity #15, Parameter Change #35) Why: Contradictions often assume a fixed parameter. If a parameter can vary with context, the contradiction dissolves. Protocol (20–30 minutes)

• Pick a parameter (e.g., review depth measured in minutes).
• Make it conditional: triage incoming items; only items flagged “critical” get the deep check. Use a 3‑question quick triage taking ≤2 min.
• Implement the triage for the next batch of tasks for 24–48 hours. Measures: % of items triaged critical, average time per item, post‑release issues per triage class. Trade‑off: risk that triage misses something and misclassifies; we must allow a quick feedback path to catch missed critical items.

Move C — Use an auxiliary resource or environment (Principles: Another Dimension #17, Use of Intermediate #24) Why: Sometimes the contradiction is resolved by using external storage, asynchronous tools, or physical aids. Protocol (20 minutes)

• Find an auxiliary: a template, linting tool, a checklist bot, or an automated test that handles the part you cannot afford to do manually.
• Integrate it for one day or one sprint. For example, attach a 10‑item automated checklist that triggers a "fix me" label. Measures: number of issues auto‑caught, minutes saved per review, false positives per 100 checks. Trade‑off: initial setup time (maybe 60–120 minutes) for long‑term savings.

After the moves: a short reflection (5–10 minutes)
We gather the numbers and write a short note in Brali. Did we reduce our target parameter without increasing the other beyond the bound? If not, select another principle and run a fresh micro‑experiment.

Part 4 — A full micro example: Code reviews in a small team (walkthrough)
We narrate one lived micro‑scene to make the practice tangible.

Scene: Monday, 09:00. We have a backlog and a 72‑hour target currently failing. Our contradiction: “Shorten code review time from 72 h to 24 h without increasing reviewer errors above 2%.”

Step 1 — Name and quantify (5 minutes)
We write the contradiction and record it in Brali. Target: cycle time 24 h; error rate ≤2%.

Step 2 — Run Move A (Segmentation + Parallelization)
(40 minutes) We identify two sub‑tasks: superficial checks and deep logic checks. Surface checklist: build passes, style, obvious typos, test names, 10 items, 10 minutes. Deep logic: algorithm, architecture, security, 30–60 minutes.

Execution: We try to do surface checks immediately upon pull request opening. For demo purposes, one of us (A) takes surface checks for incoming PRs as they arrive and completes them in ≤10 minutes. Another coder (B) schedules deep checks in their 24‑hour window.

Outcome: Average cycle time dropped from 72 h to 36 h for the surface lane. Error rate in surface lane: caught 40% of issues; errors escaping to production fell from 5/week to 3/week. Not yet within the 2% target.

Step 3 — Run Move B (Parameter change — conditional depth)
(20 minutes) We add a triage: PRs tagged critical or >500 lines changed go to deep check; others get the surface lane and an automatic CI test. This condition reduces deep checks by 60%.

Outcome: overall cycle time median fell to 18 h for non‑critical PRs; error rate fell to 2.8% (still above 2%). We misclassified 1 in 30 PRs as non‑critical and a bug slipped into production.

Step 4 — Run Move C (Auxiliary resource — test harness)
(30–60 minutes, plus small setup) We install a quick static analysis tool that flags common mistakes, and add a 5‑minute pre‑merge checklist via CI. That took a setup of 45 minutes but then ran automatically.

Outcome: error rate drops to 1.6% over the next week; median cycle time stays at 20 h. We achieved our targets. The trade‑off: 45 minutes upfront, and a 3% increase in time for maintainers to triage false positives.

Reflection: numbers tell the story. We assumed immediate reduction by cutting steps alone would work; that produced worse quality. Segmenting plus conditional depth plus auxiliary automation produced a balance. Our explicit pivot—add tooling instead of further cutting—saved time and quality.

Part 5 — Sample Day Tally: how small actions add up We want to show concretely how minutes and counts reach the target. Sample target: reduce average review cycle to ≤24 h and keep defects ≤2/week.

• Surface checks (10 min each) × 6 PRs = 60 minutes
• Deep checks (45 min each) × 2 PRs = 90 minutes
• Automated CI/Static checks setup (initial) = 45 minutes (one‑off)
• Triage decisions (2 min each) × 8 PRs = 16 minutes

Totals (daily activity): 60 + 90 + 16 = 166 minutes (2.8 hours)
human time; initial tooling setup 45 min amortized over the week.

Expected outcome:

• Median PR cycle ≈ 18–24 h
• Defects escaping ≈ 1–2/week (assuming current baseline 5/week)

This tally shows that with around 3 hours of human time and a 45‑minute setup, a small team can reach the target. Numbers make it concrete and usable when we balance weeks and amortize setup costs.

Mini‑App Nudge Use a Brali check‑in that asks every time you close a PR: “Surface checks done (Y/N) — Minutes spent — Anything missed?” This creates a rapid feedback loop and collects the data needed for TRIZ decisions.

Part 6 — Which principles often map to which everyday constraints We list the most actionable mappings so we can find candidate moves fast. After each small list we add reflective sentences.

If the contradiction is about speed vs. quality:

• Segmentation (#1), Local Quality (#3), Dynamics (#15) We should aim to split tasks by type and adjust depth dynamically — this gives both speed and guardrails.

If it’s about cost vs. durability:

• Cushion (#11), Replace Mechanical Means (#28), Composite Materials (#31) We will trade small upfront cost for longer life or use design changes to reduce wear.

If it’s about privacy vs. convenience:

• Partial or Intermediate (#10, #24), Use of Locality (#2) We can keep private data locally and share derivative results; convenience preserved, privacy protected.

If it’s about capacity vs. throughput:

• Another Dimension (#17), Periodic Action (#19) Consider switching from serial to parallel or alternate scheduling.

Reflectively: these are heuristics; we will still test them. TRIZ is not guaranteed but it gives high‑probability moves.

Part 7 — Shortcuts and micro‑habits (what to do in 5 minutes or less)
We often need a very small path for busy days. Here are two micro‑tasks:

Alternative path for busy days (≤5 minutes)

• Quick triage micro‑habit (≤5 minutes): For each new item, answer three questions in 2 minutes: “Is this critical? Will it change public behavior? Does it touch security or money?” If any answer is yes, mark for deep review; otherwise surface lane.
• One‑minute checklist: paste a 5‑item checklist into PR description and require PR author to confirm. This shifts 1 minute per PR to the author and saves reviewer time later.

If we cannot run full experiments, adopt the triage micro‑habit for one day and log counts in Brali.

Part 8 — Common misconceptions, edge cases, and risks Misconception 1: TRIZ means forceful creativity; use all 40 principles at once. Reality: TRIZ is a menu of moves; usually 1–3 moves suffice. Each additional move adds complexity; we should prioritize based on measurable impact per minute.

Misconception 2: TRIZ only for engineers. Reality: The principles map to management, product, UX, cooking, and daily life. For example, Segmentation applies to meal prep; Parameter Change applies to sleep schedules.

Edge case: contradictory goals with no measurable parameter. Action: Translate one goal into a proxy numeric measure (e.g., “satisfaction” → Net Promoter-like score from 1–5, or “quality” → number of returned items per 100). If we can’t find any proxy, use a short 3‑day qualitative diary and convert patterns into counts after 72 hours.

RiskRisk
over‑automation and brittle systems. If we automize too aggressively (e.g., an over‑zealous CI linter), we might slow people down or create new bottlenecks. We must track "false positives" per 100 automated checks; if the rate exceeds 10/100, reconsider thresholds.

Trade‑offs explicitly Every move trades something. Segmentation gives faster response but may increase coordination load. Parameter dynamics give flexibility but raise complexity. Automation saves human time but demands maintenance. Make the trade explicit in your Brali notes: “Segmentation reduced time by 40% but increased coordination messages by +25%.”

Part 9 — How to choose the next move after a failed trial We will use a simple decision rule in Brali: the 5‑10‑30 rule.

• 5 minutes: take a quick note of what happened (what numbers moved).
• 10 minutes: list the top 2 likely causes of failure.
• 30 minutes: design one new micro‑experiment addressing the top cause.

Example: after segmentation, error rate still high. We spend 5 minutes to record counts. In 10 minutes we hypothesize: “Errors escape because triage misclassifies edge cases.” In 30 minutes we design an improved triage question that takes 2 more minutes but catches the edge cases.

Part 10 — Scaling the practice: weekly rhythm and what to track We create a rhythm that keeps TRIZ active in decision making. We prefer a weekly check‑in and a daily micro‑log.

Weekly rhythm (approx. 30–60 minutes)

• Review numeric metrics: cycle time (median), defect rate (count/week), false positives in automation (count/100).
• Survey the team: one question—“What felt faster or safer this week?” (one sentence from each).
• Choose one principle to try or refine.

Daily micro‑log (≤10 minutes)

• Record the one action you took (segmented, triaged, automated).
• Note numbers: minutes spent, items processed, errors found.

We will track three basic metrics continuously (these are the minimum set):

• Cycle time (minutes or hours) — median or mean
• Error/defect count (count/week)
• Time invested in changes (minutes/day)

Part 11 — Brali check‑ins and how to set them up We must move the practice into Brali LifeOS so the habit persists. Here are quick patterns.

Mini‑App Nudge (repeated)
Set a Brali micro‑check: After every PR close, log “Minutes spent — Surface done? (Y/N) — Surprises?” It’s that simple. Over one week this yields 5–7 data points per day for analysis.

Check‑in Block We include the official block you can copy into Brali or paper:

• Which TRIZ move did we apply today? (Segmentation / Parameter / Auxiliary / Other)
• Minutes spent on TRIZ actions today? (number of minutes)
• Sensation: Did we feel relief, frustration, or curiosity after the action? (one word)

• Progress: Is cycle time moving toward the target? (Yes / No / Unsure; note median)
• Consistency: How many days this week did we apply a TRIZ move? (count)
• Trade‑offs: What increased as a result (coordination, false positives, cost)? (one sentence)

• Cycle time (minutes or hours) — log median
• Defect count (per week) — log count

Part 12 — One month plan: from experiment to habit We offer a simple 4‑week progression with concrete tasks. Each week includes an explicit micro‑decision.

Week 1: Name contradictions and run 3 micro‑experiments

• Day 1–2: Write contradictions and pick 2–3 TRIZ moves.
• Day 3–7: Run experiments and collect data.

Week 2: Analyze and choose one principle to scale

• Choose the principle that produced the best "savings per minute".
• Harden its protocol into a template (e.g., triage questions, automation script).

Week 3: Automate or delegate

• Free up human time by pushing repetitive tasks to a small script, template, or role.
• Measure false positives; tune thresholds.

Week 4: Reflection and institutionalize

• Add one or two metrics to your team's dashboard.
• Create a standard operating procedure (SOP) that includes TRIZ decision rules (when to segment, when to triage).

If we invest 2–4 hours/week in this routine, most small teams see a 25–50% improvement in cycle time and 20–60% reduction in simple defects over 4 weeks, assuming the problems are process‑based rather than systemic.

Part 13 — Dealing with stubborn contradictions and hierarchy conflicts Some contradictions are structural and will not yield to quick fixes (e.g., regulatory requirements vs. agile release cadence). When we hit stubborn cases:

Step 1 — Find the real contradiction level Is the contradiction at the task level or the system level? For example, a regulation requiring full audit trails conflicts with speed. That’s a system‑level issue.

Step 2 — Use separation in time/space or by condition Principles that often help: Separation in time (#2), Separation in space (#12), Conditional parameters (#15). We might release non‑regulated features fast and batch regulated items into scheduled releases.

Step 3 — Create compensating controls If we must meet both, add compensating controls (e.g., automated logging and delayed publishing). This costs time but maintains compliance.

Part 14 — Quick reference: 10 high‑impact principles with one‑line actions We offer ten principles we use most, with a one‑line practical action.

We will pick one and try it within 30–60 minutes. After trying, return to Brali, record two numbers: minutes spent and one outcome metric.

Part 15 — Closing the loop: a small experiment we can run tonight We give you one concrete activity to do today in 45–75 minutes, with exact steps.

Tonight’s 60‑minute experiment

• 0–5 min: Name the contradiction and log it in Brali.
• 5–15 min: Choose two TRIZ moves from our short list (e.g., Segmentation + Triage).
• 15–40 min: Implement the moves: create a 10‑item surface checklist and a 3‑question triage form; paste them into the PR template or task description.
• 40–60 min: Apply to the next 3 items you handle today; log minutes and immediate outcomes into Brali.

Goal: move the median cycle time down the next day and record immediate findings. If we don’t see improvement, pick another principle following the 5‑10‑30 decision rule.

Check‑in Block (copy into Brali or paper)
Daily (3 Qs):

• Which TRIZ move did we apply today? (Segmentation / Parameter / Auxiliary / Other)
• Minutes spent on TRIZ actions today? (number)
• Sensation after the action? (relief / frustration / curiosity / neutral)

Weekly (3 Qs):

• Progress: Is cycle time moving toward the target? (Yes / No / Unsure — record median)
• Consistency: How many days this week did we apply a TRIZ move? (count)
• Trade‑offs: What increased as a result? (coordination messages, false positives, cost — write counts or one sentence)

Metrics:

• Cycle time (minutes or hours) — log median
• Defect count (per week) — log count

Part 16 — Final reflections: small decisions, visible numbers We close with a short philosophy that guides the practice. TRIZ becomes useful when we treat it as a pattern language for decision making. The most powerful habit isn't memorizing 40 principles; it's choosing one when we face a trade‑off and measuring the effect within a short feedback loop. We prefer moves that give a measurable return in less than a week—this keeps momentum.

We felt relief when our first segmented experiment reduced response time noticeably. We felt frustration when triage missed an edge case. We felt curiosity when automation dropped errors below the target. Those emotions anchor the practice; they make us notice the micro‑effects of each TRIZ decision.

• Commit 1: Name contradictions in one sentence with numbers. (5 minutes)
• Commit 2: Try at least one TRIZ move in ≤60 minutes and measure two numbers. (60 minutes)
• Commit 3: Log daily micro‑check‑ins in Brali for one week. (≤5 minutes/day)

We will do this today: name one contradiction, pick one TRIZ move, run it, and log the two numbers. If we keep doing it, we will find that 1–2 small moves per week produce the kind of incremental improvement that compounds.