Cloud security has seven structural contradictions. Every vendor treats them as trade-offs — improve one side, accept the other gets worse. TRIZ says trade-offs are engineering failures. Contradictions can be resolved. All seven resolved to the same architecture.

Every cloud security tool makes trade-offs:

• "We give you flexibility, but you'll get more misconfigurations."
• "We check before deployment, but it slows your engineers down."
• "We scan continuously, but the results aren't reproducible."

Trade-offs feel reasonable. They're not. They're engineering failures — situations where improving one property worsens another because the framing of the problem is wrong.

There's a methodology — 80 years old, derived from analyzing 200,000 patents — that says: don't trade off. Resolve the contradiction. Keep both properties. The trick is splitting what was previously one thing into two — one that keeps the desirable property, one that absorbs the opposite.

I applied that methodology to cloud security. Seven contradictions were resolved to produce the architecture. Every contradiction resolved to the same three components. That convergence is the validation and the reason the resulting product is 1,030 lines of code that didn't need to be rewritten.

Contradictions vs trade-offs

The distinction matters:

A trade-off accepts the framing. A resolution changes the framing. The methodology — TRIZ, by Genrich Altshuller — provides the discipline for finding which framing change resolves which contradiction.

The seven contradictions

Four months of analysis before writing code produced seven structural contradictions in cloud security. Each is a pair of desirable properties that the industry treats as mutually exclusive:

1. Flexibility vs Safety

We want engineers to build anything. But more flexibility produces more misconfigurations.

What every tool does: Add a scanner with a checklist. The checklist grows. Flexibility doesn't shrink. The contradiction persists.

Resolution: Configuration stays flexible — Terraform, CDK, Pulumi can produce anything. The result is evaluated against invariants. Flexibility lives in the authoring. Safety lives in the evaluation. They're separated.

2. Speed vs Correctness

We want engineers to ship fast. But fast shipping produces insecure configurations.

What every tool does: Add another CI check. Engineers learn to bypass with // skipcq and nosec. The check becomes a speed bump, not a safety net.

Resolution: The invariant evaluation runs in milliseconds. The engineer's velocity is unaffected. The security architect writes the control once. Every subsequent evaluation is automatic. Speed and correctness operate on different clocks — neither blocks the other.

3. Decentralization vs Control

We want decentralized ownership (each team manages their own infrastructure). But decentralization produces inconsistency.

What every tool does: Add a central policy registry. The registry becomes the bottleneck teams route around.

Resolution: The invariant catalog is centrally declared (one canonical set of controls). The snapshots are decentrally produced (each team collects their own). The evaluation runs at the edge — wherever the snapshot is. Central authority over WHAT must hold. Decentralized responsibility for collecting evidence.

4. Human Judgment vs Reliability

We want human contextual judgment (this role needs broad permissions for the migration). But human judgment is inconsistent and irreproducible.

What every tool does: Add severity scores and ML-based triage. The ranking is opaque. The queue is unchanged. The human still decides.

Resolution: The judgment goes into the invariant when it's authored — the security engineer encodes "PHI buckets must never be reachable by anonymous principals" once. Subsequent evaluations are mechanical. Zero judgment at evaluation time. The judgment was upstream, in the control definition. The evaluation is downstream, deterministic.

5. Expressiveness vs Complexity

We want expressive IaC (conditional resources, dynamic blocks, modules calling modules). But expressiveness produces complexity where errors hide.

What every tool does: Add a static analyzer for the IaC source. The analyzer can't see what the IaC produces at apply-time — it analyzes the source, not the result.

Resolution: Evaluate the PRODUCED STATE, not the source code. The snapshot is the JSON representation of what Terraform/CDK/Pulumi produced after plan or apply. The IaC source can be as expressive as needed. The snapshot reduces all that expressiveness to typed facts the evaluator can read. Expressiveness lives in the source. Verifiability lives in the snapshot.

6. Dynamic Systems vs Stable Security

We want dynamic infrastructure (auto-scaling, ephemeral, managed services). But dynamic infrastructure breaks static security assumptions.

What every tool does: Make the security controls dynamic too — continuous scanning, runtime agents, real-time detection. Trades adaptability/predictability for responsiveness/reproducibility. The new contradiction is worse: same infrastructure, different results on different days.

Resolution: Keep the controls STATIC. Make the OBSERVATIONS dynamic. The invariant ("anonymous users must not reach PHI data") doesn't change when the infrastructure changes. The snapshot captures the infrastructure at a point in time. The evaluation reruns the static invariant against the dynamic snapshot. Deterministic, reproducible, composable.

This is the most consequential resolution in the set — and the only one where the textbook TRIZ principle (Dynamization — make the static thing dynamic) was INVERTED. Every vendor followed the textbook. The inversion produced the opposite architecture — and it's the reason the product is deterministic where competitors aren't.

7. Granular Permissions vs Manageability

We want fine-grained IAM permissions (least privilege). But 17,000 IAM actions produce an unmanageable rule set.

What every tool does: Add a policy generator. Generated policies are accurate today, stale tomorrow. The complexity moves from "write the policy" to "maintain the generator."

Resolution: Humans declare role intent at the category level ("this is a read-only data role"). The control catalog encodes which permission patterns match which intent. The 17,000 IAM actions stay fine-grained — the manageability lives at the intent layer above them. An intermediary between human-readable intent and machine-readable permissions.

The four physical contradictions underneath

Underneath the seven technical contradictions sit four deeper ones — statements where a single thing must have opposite properties:

Every resolution has the same shape: split the thing that was previously one into two. One piece keeps the desirable property. The other absorbs the opposite. The split happens at a different point each time (source vs result, intent vs enforcement, control vs observation) but the move is the same: segmentation.

The convergence

The seven contradictions resolved and kept landing on the same three components:

The three components are:

1. A fixed declarative artifact that states a property that must hold → the invariant (YAML control).
2. A mutable observational artifact that captures the world at a point in time → the snapshot (JSON observation).
3. A deterministic evaluator that runs the first against the second → the engine (CEL predicate evaluation).

Resolving the seven contradictions shaped the architecture.

The convergence is the validation. If the seven contradictions had resolved to seven different architectures, the analysis would have decomposed the problem into seven sub-problems but missed the structural one. The convergence proves the seven are symptoms of one shape underneath and the three-component architecture is that shape.

The nine inventive principles

The TRIZ contradiction matrix suggested specific principles for each contradiction pair. Nine principles did work across all seven:

The same principles appearing across multiple contradictions is the signature of an architecture with high internal cohesion. The same moves do work across different problem dimensions — because the problem dimensions are symptoms of one underlying structure.

What the industry accepts as trade-offs

Every item is a trade-off the industry accepts. Every item is a contradiction that can be resolved:

Seven trade-offs the industry treats as laws of nature. Seven contradictions that are resolvable with known techniques. The techniques are 80 years old. The application to cloud security is new.

Why convergence matters for builders

If you're facing multiple contradictions in your own domain and each one seems to need a different solution, you haven't found the structural contradiction yet. The surface contradictions are symptoms. The structural contradiction is underneath them.

The test: do your resolutions converge?

If seven contradictions resolve to seven different architectures, you've decomposed the problem into seven sub-problems. Each sub-solution adds a component. The result is a complex system with seven moving parts.

If seven contradictions resolve to one architecture, you've found the shape underneath. The single architecture is simpler than seven sub-solutions. It's more coherent. And it's more likely to be correct — because the convergence itself is evidence that you've identified the structural problem, not just the symptoms.

Four months of analysis. Seven contradictions named. Nine inventive principles applied. One architecture produced. 1,030 lines of kernel code. No rewrites.

The thinking was the foundation. The code was the proof.

---

The three-component architecture — invariant (2,650 YAML controls), snapshot (obs.v0.1 JSON), evaluator (1,030-line CEL predicate engine) — is implemented in Stave, an open-source Risk Reasoner. Seven contradictions resolved. One architecture. Every conclusion deterministic, traceable, and provable. Try it: bash examples/demo-ai-security/run.sh