We spent weeks applying a systematic diagnostic method — TRIZ's Function-Failure Analysis — to every major cloud security tool category. To find out whether the gap everyone senses but nobody names has a precise structural description.
It does and it's the same gap in all six categories. The same gap, it turns out, that's now emerging in AI-assisted software development. Same function missing. Different domain.
The diagnostic method
Function-Failure Analysis (FFA) is a TRIZ discipline for finding what's missing in a system. It's not retrospective — it doesn't ask "what went wrong?" It's structural — it asks "what function should exist here but doesn't?"
The method has four steps:
- Define the system boundary. Enumerate the components.
- Map every relationship as Subject → Verb → Object. Strict noun-verb-noun. No adjectives, no qualifications, no hand-waving.
- Classify each function: useful-sufficient, useful-insufficient, useful-excessive, harmful, or missing.
- The missing arrows are the design brief.
The discipline that makes this rigorous rather than speculative: you apply the analysis to the tools that currently attempt to solve the problem, not to a hypothetical ideal. The analysis reveals where those tools fail. The failures define what comes next.
We ran this at four nested scopes: the entire cloud delivery ecosystem, then the 16 components of the cloud control system, then each existing tool category individually, then the feedback and control trend across all engineering disciplines. Each scope produced the same structural gap.
Six tool categories, same missing function
Here's what FFA found for each category, stripped to the essential Subject → Verb → Object:
CSPM (Cloud Security Posture Management)
What it does: Scanner → detects → known misconfiguration.
What's missing: Scanner → prevents → unknown misconfiguration. The rule library is extensional — it enumerates specific known-bad patterns. Novel misconfigurations pass through because no rule matches. The tool reacts to what it recognizes. It can't regulate against what it hasn't seen.
CNAPP (Cloud-Native Application Protection Platform)
What it does: Platform → correlates → signals across runtime and posture.
What's missing: Platform → blocks → unsafe configuration before deployment. CNAPP integrates CSPM, CWPP, and CIEM into a unified view — useful for triage, insufficient for prevention. The correlation is retrospective. The function that's missing is prospective.
SIEM (Security Information and Event Management)
What it does: Aggregator → detects → known event pattern.
What's missing: Aggregator → predicts → event from configuration state. SIEM operates on events — things that already happened. It can tell you an unauthorized access occurred. It can't tell you the configuration that permits unauthorized access exists right now, before anyone exploits it.
SOAR (Security Orchestration, Automation and Response)
What it does: Orchestrator → remediates → detected incident.
What's missing: Orchestrator → prevents → incident precondition. SOAR automates the response to incidents that already fired. The function that's missing is eliminating the precondition so the incident can't fire.
IaC Scanners (Infrastructure as Code)
What it does: Scanner → flags → known-bad IaC pattern.
What's missing: Scanner → verifies → IaC satisfies declared invariant. IaC scanners check templates against rule libraries — the same extensional approach as CSPM, applied to code instead of running infrastructure. Novel violations of unlisted properties pass through.
ML Detection
What it does: Model → recognizes → anomalous behavior matching training distribution.
What's missing: Model → guarantees → deterministic verdict. ML detection is probabilistic, requires training data of known failures, and produces confidence scores rather than proofs. The function missing is a deterministic, pre-deployment verdict that doesn't depend on having seen the failure mode before.
The gap is identical across all six:
Machine-verifiable, pre-deployment, deterministic verdict per resource — evaluated against what must always be true, not against what has previously gone wrong.
Every existing category uses the same verb family: detect, recognize, correlate, flag, alert. All reactive. All retrospective. All dependent on having seen the failure mode before. The missing verb is verify — proactive, prospective, deterministic, cause-independent.
Why "without understanding the cause" is the decisive property
Here's the function statement that unifies the gap:
A system must regulate itself in a changing environment without fully understanding the cause of failure.
Every existing tool requires the cause to be enumerable. CSPM enumerates misconfiguration patterns. SIEM enumerates attack signatures. ML models enumerate failure modes in training data. All three break the moment the cause is novel.
The invariant-based approach inverts this. The regulator only needs to know what property must hold. The causal mechanism that produces a violation can be brand new — a misconfiguration nobody's cataloged, an attack technique nobody's published, a drift pattern nobody's observed — and the regulator still catches it, because the violation is observable in the state, not in the cause.
This is the same architectural move across every domain that's solved this problem:
| Domain | Property declared | Cause not needed |
|---|---|---|
| Fly-by-wire | "Stay inside the flight envelope" | Doesn't matter why a pilot input would exit it |
| Pre-trade risk | "Don't take a position > N" | Doesn't matter what model said to |
| Predictive load shed | "Frequency must stay in band" | Doesn't matter what load surged |
| Cloud security | "This invariant must hold across the snapshot" | Doesn't matter what config drift produced the violation |
The property is declared. The state is observed. The verdict is deterministic. The cause is irrelevant to the detection — only relevant to the remediation, which comes after.
The same function is missing from AI-assisted development
This is where the analysis crossed domains in a way we didn't expect.
AI coding agents generate code faster than developers can understand it. The tools built to manage this — linters, code review bots, quality gates, documentation generators — are structurally identical to the cloud security tools analyzed above. They all use the same verb family: detect, flag, report, correlate. All reactive. All dependent on recognizing known patterns.
The missing function is the same:
The development system must regulate itself in a fast-changing codebase without fully understanding the cause of code that violates the specification.
A linter detects known code smells — it can't detect a novel violation of an architectural invariant it hasn't been programmed to check. A code review bot flags suspicious patterns — it can't verify that the AI-generated code satisfies a typed specification. A quality gate blocks below-threshold coverage — it can't verify that the code preserves the interface contract the system depends on.
The missing verb is the same: verify. Pre-merge, deterministic, cause-independent verification against a declared property. The code can be generated by any AI agent, using any model, from any prompt. The cause doesn't matter. The specification either holds or it doesn't.
The function statement maps term by term:
| Term | Cloud security | AI-assisted development |
|---|---|---|
| A system | Cloud infrastructure | The codebase |
| must regulate itself | Safety invariants in CI | Specifications verified on every change |
| in a changing environment | Config drift from humans and automation | Code changes from multiple AI agents |
| without understanding the cause | Don't enumerate all misconfiguration causes | Don't enumerate all ways AI generates non-compliant code |
Two domains. One missing function. Same verb. Same architectural resolution.
Why the name keeps changing
While running this analysis, we observed something instructive about naming. Every time a new capability shipped, the natural name for the category shifted:
| Capability shipped | Name that felt right |
|---|---|
| S3 compound risk detection | "Compound Risk Engine" |
| CEL predicates | "System Invariant as Code" |
| Multi-engine reasoning | "Risk Reasoning Engine" |
| AI agent controls | "AI Guardrails" |
| Intent verification via tags | "Intent Engine" |
| Safety engineering frame | "Cloud Safety Verification" |
Each name tracks the LAST thing shipped. That's the signal that you're naming the capability, not the problem. Capabilities change as you ship. The problem doesn't.
The FFA-identified missing function never changed across any of these capability expansions:
Machine-verifiable, pre-deployment, deterministic verdict per resource — Stage 4 feed-forward control over what must always be true.
Whether the implementation expresses that function via compound risk chains, CEL predicates, SMT solvers, AI-agent guardrails, intent specifications, or safety verification — the function is the same. New capabilities expand the catalog, not the category.
The lineage that makes the name stable
The stable name eventually emerged from a lineage:
Infrastructure as Code (IaC) → Policy as Code (PaC) → System Invariant as Code
HOW you provision WHAT is allowed WHAT MUST ALWAYS BE TRUE
IaC (Terraform, Pulumi, CloudFormation) codified provisioning. The artifact is a template that declares desired state. The verb is provision — create the infrastructure as specified.
Policy as Code (OPA/Rego, Cedar, Sentinel) codified authorization and admission. The artifact is a rule that declares what's permitted. The verb is enforce — allow or deny actions based on policy.
System Invariant as Code codifies safety properties. The artifact is a predicate that declares what must always be true. The verb is verify — determine whether the state satisfies the invariant, deterministically, before deployment.
Each step in the lineage raises the abstraction:
| Generation | Artifact | Scope | Verb |
|---|---|---|---|
| IaC | Template | One deployment | Provision |
| Policy as Code | Rule | One decision point | Enforce |
| System Invariant as Code | Predicate | The entire state, always | Verify |
IaC says: "create this bucket with these settings." Policy as Code says: "allow this action if these conditions hold." System Invariant as Code says: "no matter what actions are taken, what templates are applied, or what policies are evaluated, this property must hold in the resulting state."
The invariant is upstream of both IaC and Policy as Code. A template that violates an invariant should be rejected before provisioning. A policy that permits an invariant violation should be flagged as inconsistent. The invariant doesn't replace IaC or PaC — it sits above both as the property they must collectively satisfy.
The function that stays when everything else changes
The FFA diagnostic landed on a pattern that repeated at every level of the analysis: the function is stable, the implementation changes, and the name should track the function.
In the cloud security tool categories, every tool's implementation was different (rule matching, ML scoring, event correlation, remediation orchestration). The missing function was the same in all six.
In the capability expansion of the tool we built to fill that gap, every new capability changed what the tool could do. The function it served — machine-verifiable, pre-deployment, deterministic verdict — never changed.
In the name-drift table, every capability-tracking name felt right for a month and wrong the next. The function-tracking name ("System Invariant as Code") has been stable since it was identified — because it names the practice, not the product.
The diagnostic question FFA answers isn't "what should we build?" It's "what function is missing?" The answer to the first question changes quarterly. The answer to the second has been the same since weeks before the first analysis was run — and the same, it turns out, since 1972 when Parnas identified human cognitive capacity as the bottleneck, and since 1977 when Lamport proved safety properties are mechanically verifiable.
The function was always missing. The speed of change just made it visible.
- The "Pre-deployment" nuance: While the article emphasizes pre-deployment, invariants are equally powerful for continuous runtime verification. Verify is an ongoing state, not just a gate.
- Decoupling Invariants from Policies: Policy as Code (like OPA) can express invariants. Policy is often applied to a Request (admission control), whereas an Invariant is applied to the Resultant State (the whole graph).
Function-Failure Analysis (FFA) is one of twelve analytical tools in the TRIZ methodology. The four-scope diagnostic described here drew on Darrell Mann's adaptation of classical FFA for service and software systems. The feedback-control trend referenced is documented across Mann's work and in Altshuller's original patents analysis.
This article is part of a series: "Six Contradictions Behind Cognitive Debt" (TRIZ analysis), "A 1972 Paper Predicted the AI Coding Crisis" (Parnas), "The Next Platform Won't Track Configurations" (Su-Field model), and "Your Resource Tags Are Safety Invariants" (the intent bridge).
Top comments (0)