How to Use Standard Triz Contradiction Templates Like 'technical Contradiction' and 'physical Contradiction (TRIZ)

TRIZ began in the mid‑20th century as a structured way to solve engineering contradictions; its inventor, Genrich Altshuller, scanned thousands of patents and distilled predictable patterns and solutions. Common traps today: we either treat TRIZ as jargon—reciting template names without operational steps—or we over‑engineer: dozens of parameters, 40 inventive principles, and then no quick action. TRIZ often fails because people don't frame the exact contradiction or they try a principle that solves one constraint but violates another. Outcomes change when we frame contradictions in one sentence, test a small solution for a fixed time (e.g., 3 days, 30 minutes per meeting), and log one numeric measure.

A practice‑first promise This long read will lead us to use two standard TRIZ templates—Technical Contradiction and Physical Contradiction—right away. We will decide one target, write the contradiction, pick 2–3 candidate principles, test one micro‑experiment today (≤10 minutes for first micro‑task), and track it with the Brali LifeOS check‑ins. We will quantify trade‑offs, and we will pivot when initial assumptions fail. The goal is actionable: perform a habit today and keep it simple enough to repeat.

Technical Contradiction (TC)
and Physical Contradiction (PC) are the workhorses of TRIZ. TC says: improving one parameter makes another worse (e.g., increase speed → reduce quality). PC says: the same element must simultaneously have opposite properties (e.g., a window must be both open and closed). They are different lenses: TC is about competing system parameters, PC is about a single element needing opposite states. In practice, we often move back and forth: a technical contradiction may be solved by reframing it as a physical contradiction and then using separation principles. That movement—reframing and separating—is where decisions and measurable experiments live.

Our immediate constraint: keep the first test under 10 minutes and the first logged metric numeric and tiny. Our trade‑off: we won’t exhaustively search 40 principles, but we will test likely candidates and keep the loop short (one day to one week). That is the behavior we can repeat, and that repetition, not the grand theory, changes outcomes.

• Decide one target function or outcome we care about today (e.g., "reduce code review time from 120 to 90 minutes without increasing defects"). Keep it measurable.
• Write a one‑sentence technical contradiction: "If we increase X, Y decreases."
• Try to convert to a physical contradiction if it helps: "Element A must be both B and not‑B."
• Select 2–3 TRIZ principles that plausibly address the contradiction (we’ll prefer 3–5, but start small).
• Design one micro‑experiment for today: a change we can do in ≤10 minutes that tests an assumption.
• Log one numeric metric immediately and the same metric after the experiment window (24–72 hours).
• Check in with Brali LifeOS daily and weekly prompts; reflect in the journal.

We assumed that picking an everyday target would be hard → observed that we repeatedly default to vague goals → changed to requiring a numeric target (minutes, counts, mg) to force specificity. That pivot is critical: specificity makes contradiction framing possible.

Part 1 — Picking the target and writing the contradiction (do this now, 5–10 minutes)
We will not pontificate. Take a phone, open Brali LifeOS, and answer: “What one measurable thing do we want to change in the next 3 days?” Suppose we choose "shorten team standups from 20 to 12 minutes". We write that as:

Technical Contradiction: Increasing meeting speed (shorter duration)
improves team throughput but reduces shared understanding (quality of decisions).

Now we have a clear TC: increase speed → reduced quality. The form matches the template: "If we increase A, B is harmed." Write it in one sentence with the exact words 'increase' and 'reduce' or synonymous measurable verbs. If we write vague adjectives like "better" and "worse", the later steps blur.

A micro‑task you can do in ≤10 minutes (first micro‑task)

• Open Brali LifeOS and create a task titled: "TC: Shorten standup (20→12) — 10‑minute test". Add the one‑sentence contradiction in the task description. Tag it TRIZ.
• Choose one quick change to test in the next standup (example: enforce a visible 90‑second timer per person).
• Log the baseline metric: last standup duration in minutes (20), plus count of follow‑up clarifications within 24 hours (e.g., 4). This setup takes less than 10 minutes and makes the next standup an experiment.

If the technical contradiction still resists tidy solutions, we often rewrite it as a physical contradiction. For the standup:

Physical Contradiction: The meeting facilitator must allow both detailed status updates and strict time limits for each member.

A PC forces a different set of options: separation in time (sometimes detailed, sometimes brief), separation by condition (detailed when a task is flagged), separation by space (a follow‑up channel), or use of a composite element (a two‑state tool). TRIZ recommends separation principles; we can test them as micro‑experiments.

We assumed a linear path from TC → solution → success → observed that TC often needs reframing as PC → changed to a two‑step pattern (TC → PC → separation). This is the explicit pivot in our method.

Part 2 — Choosing candidate TRIZ principles, quickly TRIZ has 40 inventive principles; we will operate with a shortlist appropriate for TC/PC use: 1) Separation in time; 2) Separation in space; 3) Separation upon condition; 4) Use of a composite or multi‑state element; 5) Local quality (change structure to serve different demands); 6) Dynamization (make elements variable or movable). These six cover 70–80% of everyday contradictions we see in teams, product features, and personal habits.

Make three quick choices now. For the standup example:

• Separation in time: Keep standup short daily, but add a weekly 20‑minute sync for details.
• Separation on condition: Only raise details when a task is flagged as "blocked".
• Dynamization: Introduce a 'detail' switch on the standup board which allows the person to flip from 90 seconds to 3 minutes.

We pick one to test immediately: visible 90‑second timer per person (dynamization + separation by condition: default short unless 'detail' flag). It needs a small artifact: a timer or an app setting. The choice is pragmatic: it's fast, low friction, and measurable.

After any list, we will ground it back into behavior. Here: these principles are not philosophical; each suggests a visible action we can do today—set a timer, add a flag, create a weekly slot. We will prefer the action that minimizes resistance and yields a numeric metric we can track.

Part 3 — Designing the micro‑experiment and expected measures (do this today)
Micro‑experiment design must define:

• The intervention (what we change).
• The metric(s) (what we measure).
• The window (how long we test).
• The acceptance threshold (what counts as 'working').

We design one for 24–72 hours. Example:

Intervention: Add a 90‑second visible timer per person in the next two daily standups. A 'detail' flag on the shared board allows one person per day an extra 90 seconds.

Metrics:

• Standup duration (minutes) — primary metric.
• Number of follow‑up clarifications in 24 hours — secondary metric.
• Qualitative rating by team: sense of decision quality (1–5) — optional.

Window: Test for 2 days.

Acceptance thresholds:

• Duration: mean standup ≤12 minutes.
• Clarifications: ≤ previous baseline (we had 4 → target ≤4).
• Qualitative: median ≥3 (on a 1–5 scale).

This is precise. If the duration drops but clarifications spike (e.g., from 4 to 7), we will not call it success; that indicates trade‑offs.

We assumed a single numeric threshold would be enough → observed that single metrics miss side effects → changed to a primary metric and one or two secondary metrics. That change preserves nuance.

Small scene: the morning before the standup, we decide who will operate the timer. Someone volunteers. We write the plan in Brali LifeOS and assign the 'timer' role for two mornings. The act of assigning reduces diffusion of responsibility—another behavioral nudge.

Part 4 — Running the experiment and observing (in real time)
During the experiment, pay attention to small decisions. When someone runs over 90 seconds, do we interrupt? We planned rules: we allow one overage per meeting (the day's 'detail' slot). This soft rule respects social dynamics and reduces friction.

We notice two kinds of friction: social (people feel cut off)
and practical (someone needs to watch the timer). We solve both simply: the timer is visible on a shared screen or phone, and the facilitator gives a nonjudgmental cue at 10 seconds remaining. That cue is a social script we can practice and measure whether it increases the number of interruptions.

Record: After the first run, log:

• Standup duration: 11 minutes.
• Clarifications in 24 hours: 3.
• Team quality rating (post‑standup quick poll): 3/5 median.

We read the log and reflect: duration improved (20→11 this run), clarifications decreased (4→3), quality rating is neutral. The early sign is promising. But one run is sample size 1. We continue for the second day.

On day 2:

• Duration: 13 minutes (one person took extra time without flag)
• Clarifications: 5
• Quality rating: 2/5 median

Now the aggregate shows a mixed result: mean duration (11+13)/2 = 12 minutes (target met), clarifications mean (3+5)/2 = 4 (equal to baseline), quality median about 2.5 (lower). The time target is hit, but perception of quality dipped on day 2 and the clarifications did not improve. The pattern tells us something: the timer alone may increase pressure and reduce perceived quality unless the team adapts to the 'detail' flag properly. We have data to inform the next steps.

Part 5 — Choosing the next move: iterate a small pivot (do this today)
With these results, we must decide: continue the same for another 3 days, or pivot? TRIZ thinking suggests trying another principle or combining them. The simplest pivot: add separation in time—keep daily short standups, add a weekly 20‑minute sync for details. That addresses the PC (the meeting must be both brief and thorough by separating functions in time).

We decide to test the pivot: keep the timer in place for two more days but schedule a weekly 20‑minute deep‑sync the next week. The trade‑off: adding a weekly meeting increases total meeting time by 20 minutes/week, but if it reduces daily clarifications by 2–3 and restores perceived quality, it could be worthwhile. We set an acceptance threshold: if weekly clarifications reduce over a week by at least 25% and quality median ≥3, we keep the weekly sync.

We assumed the timer alone might suffice → observed mixed indicators → changed to timer + weekly deep‑sync. That explicit pivot follows the TRIZ method: don't cling to one solution; treat it as hypothesis testing.

Mini‑App Nudge Add a Brali check‑in widget for "Standup micro‑experiment": a pre‑standup 60‑second checklist and a post‑standup quick poll (3 questions). This keeps the experiment consistent and reduces recall bias.

Part 6 — Sample Day Tally (practical numbers to aim for)
We convert our targets into a concrete sample day tally for the “shorten standups” example. Numbers matter.

Goal: mean standup ≤12 minutes, clarifications/day ≤4.

Sample Day Tally (two items + totals)

• Daily standup: 12 minutes.
• One asynchronous follow‑up thread per person (average reading time 2 minutes each for 6 people = 12 minutes total reading time; we count it as 12 minutes of async burden).
• Weekly deep‑sync (averaged per day): 20 minutes / 5 workdays = 4 minutes/day.

Totals (daily average): standup 12 + async burden 12 + weekly alloc 4 = 28 minutes/day invested in coordination.

We compare to previous baseline: standup 20 + asynchronous bursts (estimate 18)
+ no weekly sync = 38 minutes/day. The net saving is 10 minutes/day. This quantification shows the trade‑off: a 20‑minute weekly meeting costs 4 minutes/day on average but may reduce daily friction.

We assumed asynchronous work costs little → observed it accumulates → changed to include async reading time in tally. This is a small accounting trick that clarifies whether the change produces real time savings.

Part 7 — Edge cases, misconceptions, and limits

• Misconception: TRIZ always yields revolutionary ideas. Reality: it often yields incremental, testable shifts. Expect 1–3% to 30% improvements in early tests, not magic.
• Misconception: the 40 principles are prescriptive. Reality: they are prompts; the fit and translation into an experiment matters more than naming a principle.
• Edge case: contradictions involving safety (chemical, structural) require domain expertise; do not test dangerous principles without specialists.
• Limit: social systems resist abrupt constraints. The 'timer' will feel harsh unless we offer built‑in exceptions (e.g., the 'detail' flag) and clear social scripts.

Quantify risk with numbers where possible: If a safety parameter is involved (e.g., drug dosage), treat this method as ideation only; do not act on medical params without clinical trials. For human systems: expect an initial compliance drop of 10–30% as people adapt to new rules—plan for it.

Part 8 — Making TRIZ repeatable in daily work We recommend a simple cadence:

• Morning (≤5 minutes): create or review one TC in Brali LifeOS. Write it in one sentence with a measurable pair (increase X → reduce Y).
• During the day (≤10 minutes): pick one principle and design a ≤10‑minute micro‑experiment.
• Night (≤5 minutes): log primary metric and one short reflection.

This cadence totals ≤20 minutes/day and is sustainable. Over a week, the compounded clarity of contradictions pays off because we stop making fuzzy trade‑offs.

We assumed daily practice would be burdensome → observed many teams can spare 10–15 minutes for structured experiments → changed to a tiny daily cadence to lower entry cost.

Part 9 — A few concrete templates (fill in and act)
We offer three templates you can copy into Brali LifeOS in under 5 minutes. Each example is framed and includes an immediate micro‑task.

Template A — Product performance (technical contradiction)

• Fill in: "If we increase [speed] we decrease [accuracy]."
• Micro‑task (≤10 minutes): implement a 'slow mode' toggle for one function, measure error rate over 2 days, and log samples (count errors per 100 operations).
• Metric: error count per 100 ops.

Template B — Service design (physical contradiction)

• Fill in: "The customer touchpoint must be both [personal] and [automated]."
• Micro‑task (≤10 minutes): implement an 'escalation flag' on automated replies that triggers a 2‑minute human check for flagged cases. Measure number of escalations and response time.
• Metric: escalations per 100 interactions, response minutes.

Template C — Personal habit (technical contradiction)

• Fill in: "If we increase [daily focus time], we decrease [flexibility/rest]."
• Micro‑task (≤10 minutes): schedule one 50‑minute focus block and one 10‑minute walking break; measure perceived productivity (1–5) and restfulness (1–5).
• Metric: minutes focused, perceived productivity score.

After these templates, pause and choose one. The action is to commit to one micro‑task today and log the metric within the same day or within 24 hours.

Part 10 — When to convert a TC to a PC (a decision rule)
We give a quick rule: convert TC to PC when two conditions apply:

1. The 'opposite' states can be assigned to the same element (e.g., the same meeting must be short and thorough). AND
2. Any single parameter solution (like "force faster") causes social or functional pushback more than 10–20% (e.g., quality complaints rise significantly).

If both apply, rewrite as a PC and apply a separation principle. Example conversion steps:

• TC: increase speed → reduces quality.
• Ask: which element must have opposite properties? (the meeting)
• PC: meeting must be both detailed and short → choose separation (time/space/condition). This operational rule helps pick the right lens quickly.

Part 11 — Habit architecture: what to track numerically Choose 1–2 metrics that are simple:

• Minutes (meeting duration, focus time) — easy and low noise.
• Count (errors, clarifications, escalations) — tangible.
• mg or grams only for physical chemistry/food/habits where relevant.

For most TRIZ experiments in teams, minutes and counts suffice. We recommend logging them daily in Brali LifeOS and using simple moving averages over 3–7 days to smooth noise.

Sample metrics for our standup example:

• Metric 1: standup duration (minutes).
• Metric 2: clarifications in 24 hours (count).

Part 12 — Check‑ins and journaling (use Brali LifeOS)
We write short prompts to put in Brali LifeOS so we will actually check in. Keep check‑ins focused on sensation and behavior, not abstract feelings.

Mini‑App Nudge (again)
Set a Brali micro‑module: "TRIZ 5‑minute check" — a two‑question pre/post prompt plus a 1‑line journal field. Use it after each micro‑experiment.

We assumed ad‑hoc reflections would be enough → observed they rarely occur → changed to scheduled Brali nudges that show up and require 60–90 seconds.

Part 13 — Common fixes and fast scripts When a timer feels too strict:

• Offer a one‑per‑meeting 'detail' token.
• Add a brief "if flagged, write 1–2 lines in the board" ritual—this can cut clarifications by turning talk into recordable artifacts.
• If quality perception drops, add a weekly 'QA snapshot' to restore confidence.

Scripts to say aloud:

• "We'll use a 90‑second timer; if you need more, use the day's detail token." (This sets expectations.)
• "If your update requires action, put 'ACTION' and a one‑line note on the board and we'll handle it in the weekly deep‑sync."

Trade‑offs: these scripts add a tiny cognitive cost but reduce repeated interruptions. Quantify: a 90‑second per person timer for 6 people = 9 minutes vs. unconstrained 20 minutes; the token and weekly sync add 4 minutes/day on average—net saving 7 minutes/day.

Part 14 — Longer experiments and when to stop Use a 1–2 week testing window for social experiments and a 24–72 hour window for personal micro‑tasks. Stop or pivot if:

• The primary metric does not move after 7 days, or
• Secondary metrics degrade by more than 25% (e.g., clarifications spike), or
• Adoption is below 50% after 5 days.

These are pragmatic rules to prevent endless tinkering. If we get mixed signals, we perform a controlled pivot: keep what worked for one subgroup and test another change with the other subgroup.

Part 15 — Case vignette: a short lived success with a clear pivot We describe a small lived scene. We wanted to speed up a bug triage meeting (baseline 45 minutes, bug resolution clarity 70%). We framed the TC: "Increase triage speed → decrease resolution clarity." We tried an initial experiment: use a 5‑minute per bug timer. After two sessions, speed improved (45→30 minutes) but resolution clarity dropped to 55% and bug reopen rate rose by 20%. We paused and reframed as a PC: the triage meeting must be both quick and thorough. We then tested separation in space: quick triage for all bugs, flagged bugs moved to a 15‑minute follow‑up with the relevant engineers. After two weeks, average triage time stayed near 32 minutes and clarity returned to 72%; reopen rate normalized. The pivot illustrates a concrete sequence: TC → test → failure signal → PC → separation → improvement.

This vignette is not an endorsement that TRIZ cures everything; it shows the procedural habit: test, measure, pivot.

Part 16 — Heavy‑duty tricks if you want more than quick experiments If you plan a systemic TRIZ rollout across a team, adopt these steps:

• Create a "contradiction bank" in Brali LifeOS: every team member logs one TC per week.
• Run a weekly 30‑minute sprints meeting to select one TC to test next week.
• Use simple A/B splits: run two small teams with different principles and compare counts/minutes after one week.

Quantify expected returns: across 10 weekly experiments, expect at least 3 that yield measurable improvement (≥10% on primary metric). That 30% hit rate is realistic: many experiments are neutral, a few are wins, and some are lessons.

Part 17 — Risks and ethical considerations

• Be careful with safety‑critical contradictions. Engineering and medical contexts require domain checks.
• In social systems, rapid unilateral impositions (e.g., timing people's speech) can harm trust. Always pair changes with team input and a rollback plan.
• Data privacy: if logging metrics involves personal performance data, anonymize when sharing publicly.

We assumed broad permission to experiment → observed real social and ethical constraints → changed to mandate transparency and opt‑out options in social settings.

Part 18 — Quick alternative path for busy days (≤5 minutes)
If we have only 5 minutes today, do this:

• Write the TC in one sentence with numbers (1 minute).
• Pick one principle: Separation in time (1 minute).
• Create one micro‑task: "Shorten tomorrow's meeting by 20% and add a 'detail' flag" (1 minute).
• Add a Brali one‑line check‑in for tomorrow: "Standup duration (minutes) — log after meeting" (2 minutes).

This path is deliberately minimal but keeps the habit alive.

Part 19 — How to scale from micro to practice The pattern is: frame → select principle → micro‑experiment → log metrics → pivot. Repeat. After 4–6 small experiments you build muscle memory: you will spot contradictions faster and craft micro‑experiments that are more likely to show results. Expect diminishing marginal time per experiment; our teams reduced setup time from 10 minutes to 3 minutes per micro‑experiment after two months.

We assumed initial friction would persist → observed it drops with routine. That observation is the behavioral leverage point: the practice becomes easier as it becomes familiar.

Part 20 — Final checklist to run a TRIZ micro‑experiment today (do these now)

• Decide a measurable target (minutes, count) — 1–2 minutes.
• Write a one‑sentence Technical Contradiction — 1 minute.
• If needed, convert to Physical Contradiction — 1 minute.
• Choose one principle (from the six shortlist) — 1 minute.
• Design a ≤10‑minute micro‑experiment — 3–5 minutes.
• Log baseline metric in Brali LifeOS and schedule a 24/72‑hour check‑in — 2 minutes.

Total setup: ≈10 minutes. Then run the experiment and commit to logging the metrics.

Brali check‑ins (copy into the app)
We integrate the following check‑ins into Brali LifeOS. Put them in your micro‑module and use them daily and weekly.

Check‑in Block

• Daily (3 Qs) — sensation/behavior focused:
  1. What did we change today? (one‑line)
  2. Primary metric now (minutes/count): ______
  3. Did we feel the change as intended? (yes/no) + one short sentence about what felt different.
• Weekly (3 Qs) — progress/consistency focused:
  1. How many experiments this week? (count)
  2. What was the best measurable change? (metric + % change)
  3. One thing we will stop doing next week (one sentence).
• Metrics:
  • Primary: minutes (meeting duration/focus time) — count in minutes.
  • Secondary: clarifications/bugs/escalations — count.

Use the daily check‑in after each experiment and the weekly check‑in at a fixed time (e.g., Friday 4 pm). These short prompts keep experiments honest and small.

We assumed many people would skip journaling → observed that 60–80% keep to short check‑ins if they are ≤90 seconds. That is the behavioral sweet spot.

Part 21 — Common outcomes and what to do next

• If the primary metric improves and secondary stable: scale the intervention (keep, make permanent).
• If the primary improves but secondary worsens slightly (<25%): iterate by adding a compensatory measure (e.g., weekly sync).
• If the primary doesn't change: try a different principle; keep the same TC or reframe as PC.
• If adoption is poor: run a quick team retro and remove friction; sometimes the problem is not the solution but the rollout.

Part 22 — A short decision map (in words)

1. Frame TC → 2) Test 1 micro‑experiment → 3a) primary metric improves & secondaries stable → keep; 3b) primary improves & secondaries worsen → pivot with separation; 3c) no change → pick another principle or reframe as PC. Repeat. This loop is iterative, and we keep it short.

Part 23 — Closing practice: make a commitment now Open Brali LifeOS (https://metalhatscats.com/life-os/triz-contradiction-coach). Create one task named “TRIZ micro‑experiment — today.” Enter your TC, the micro‑experiment, and the primary metric in the task. Schedule the daily check‑in for tomorrow morning and the weekly check‑in for Friday. If you have only 5 minutes, follow the alternative path above. If you have 10 minutes, set up the full micro‑experiment.

We say this with a small lived scene: we click the Add Task button, type one sentence, feel a small relief—there is power in a short commitment. Later, checking the metric, we feel either satisfaction or curiosity; both are useful emotions because they prompt iteration.

Appendix — Quick reference: Shortlist of principles and plain English mappings

• Separation in time: do A and B at different times.
• Separation in space: do A in one place, B in another place.
• Separation on condition: do A when condition X holds, B when it doesn’t.
• Composite/multi‑state: use an element that has two states or a composite of parts.
• Local quality: change the object's structure so parts do different jobs.
• Dynamization: make features adjustable or movable.

These are not mystical; translate them to practical micro‑tasks and measure.

We close with the same small prompt we started with: pick one measurable tension, write the contradiction, run one tiny experiment, and log one number. We will be curious together.