TRIZ Separation Principles
An Evaporating Cloud names the contradiction: two requirements that seem to demand opposite things from the same part of a system. Naming it is necessary but not sufficient — you still have to design the fix. TRIZ separation principles are the specific, reusable moves for doing that: instead of compromising between the two requirements, you separate them so each gets what it needs without touching the other.
This is a Loop Step 4 instrument — designing the intervention — and it sits directly after the Evaporating Cloud, not before it. The Cloud tells you what the contradiction is. TRIZ separation tells you how to dissolve it. You need the Cloud's five boxes filled in before a separation principle has anything to act on.
What TRIZ is
TRIZ — the Theory of Inventive Problem Solving — was developed by the Soviet engineer Genrich Altshuller from the 1940s onward, based on his analysis of around 200,000 patents. Altshuller's central finding: across wildly different fields of engineering, the same small number of underlying contradictions and the same small number of underlying solution patterns kept recurring. An engineer solving a problem in hydraulics had often, without knowing it, reinvented a solution pattern already used decades earlier in a completely unrelated field. Altshuller catalogued these recurring patterns as 40 inventive principles.
Most of TRIZ's 40 principles are mechanical-engineering specific and don't transfer cleanly to organisational or process problems. Two do almost all of the useful work for the kind of structural contradictions this site is concerned with: Principle 1, Segmentation, and Principle 10, Prior Action. This page covers Segmentation in depth, since it is the principle used in every worked example elsewhere on this site. Prior Action is covered briefly at the end.
The alternative to compromise
When two requirements conflict, the default response is to compromise — find a midpoint that partially satisfies both and fully satisfies neither. A connector that is somewhat flexible and somewhat safe. A support team that is somewhat responsive and somewhat unburdened. A product that is somewhat customised and somewhat standard. Compromise is often treated as the mature, realistic response to a hard trade-off.
TRIZ's claim is that compromise is usually a failure of imagination, not a necessity. The contradiction feels unavoidable only because both requirements are being asked of the same part of the system at the same time. Separation asks: what if the two requirements didn't have to coexist in the same place? Four standard separations recur across almost every contradiction:
| Separation | The move | Question to ask |
|---|---|---|
| Space | Put the two requirements in physically or structurally different places | Can requirement A live in one part of the system and requirement B in another? |
| Time | Have the two requirements apply at different moments | Can requirement A hold before a point in time, and requirement B after it? |
| Condition | Make the two requirements apply under different circumstances | Can requirement A apply in one situation and requirement B in another, distinguishable situation? |
| System level | Move one requirement to a different level of the system entirely | Can requirement A be handled at the component level while requirement B is handled at the whole-system level? |
None of the four separations ask anyone to give something up. That is the entire point. A genuine separation makes the contradiction disappear rather than splitting the difference.
Worked example — the wrong-route medication contradiction
The fullest worked example on this site is the NHS Never Events case, covered in detail on the Moonshot Protocol page. The contradiction: “to remain functionally versatile, we must use interchangeable parts; but to ensure safety, we must use route-exclusive parts.”
- Space: ENFit connectors are shaped differently per administration route. Versatility within a route, exclusivity across routes — the two requirements now live in different physical spaces rather than fighting over the same connector.
- Condition: Colour-coding the connectors so the wrong choice is visually obvious before connection is made. The requirement for visual distinguishability applies under the specific condition of route mismatch, without constraining the connector design itself.
- System: Removing the universal Luer connector from the procurement supply chain entirely for this use case. The contradiction is dissolved at the system level — if the dangerous option is never stocked, ward-level versatility and safety stop competing.
All three are genuine implementations of TRIZ Principle 1. None compromises between flexibility and safety — each removes the false choice by separating where each requirement is allowed to apply.
Worked example — the variety-absorption contradiction
The same principle applies outside healthcare. A specialist software company stalled for a decade with the contradiction: “to capture revenue, we accept variety; to scale, we must absorb variety.” See the full business worked example on the Moonshot Protocol page.
The pivot — build a variety-absorption engine — is a Principle 1 separation at the system level. Customer-specific variation no longer propagates into 44 separate bespoke codebases (where it would have to be handled, expensively, at the component level, every single time). Instead, a defined configuration layer absorbs the variety once, at the system boundary. The question changes from “should we accept this customer’s custom request?” (the false choice between revenue and scalability) to “does our absorption layer already handle this category of variation?” (a question the redesigned system can usually answer without anyone reopening the original trade-off).
Principle 10 — Prior Action
Where Segmentation dissolves a contradiction by separating two requirements, Prior Action dissolves a different kind of problem: harm that occurs because a dangerous condition was allowed to exist in the first place, with the fix arriving only after the fact. Prior Action arranges the system in advance so the harmful condition cannot arise, rather than relying on detection and correction after it does.
The clearest example on this site is methodological rather than physical: the pre-committed Bootstrap CUSUM prediction. Before an intervention is implemented, the expected outcome and timeframe are stated in writing. This is Prior Action applied to evaluation itself — it removes the possibility of reinterpreting whatever happens afterward as success. The baseline and the prediction exist before the data that will be judged against them, which is what makes the later verdict honest rather than retrospectively rationalised.
How to apply this yourself
- Start with a completed Evaporating Cloud. You need the contradiction stated precisely — both requirements named, the conflict between them explicit — before separation can do anything.
- Ask each of the four separation questions in turn: can this be separated in space, in time, by condition, or by system level? Most genuine structural contradictions yield to at least one.
- Generate more than one candidate separation if you can. The Never Events case used three simultaneously — they are not mutually exclusive, and combining them increases robustness.
- Check the result against the test on the Moonshot Protocol page: if I am still relying on human willpower or vigilance to avoid the original problem, have I actually solved it? A genuine separation removes the need for vigilance. A compromise just makes vigilance slightly easier.
- Verify with data. A separation is a hypothesis until Bootstrap CUSUM confirms a structural change point in the outcome metric.