Every cloud security tool category — CSPM, CNAPP, SIEM, SOAR, IaC scanners, ML detection — shares the same structural limitation. They detect known problems after they occur. Policy-as-Code tools (OPA/Rego, Kyverno, CloudFormation Guard, Sentinel) come closest to breaking this pattern — they gate deployments before changes take effect, which is genuine Stage 4 feed-forward control.
But each Policy-as-Code tool is domain-scoped and implementation-coupled. OPA policies for Kubernetes don't compose with Sentinel policies for Terraform. CloudFormation Guard rules don't talk to Cedar authorization policies. Each tool verifies its own domain against its own rule format. There is no cross-domain specification layer where safety properties are declared once and verified everywhere — across providers, across tools, across the entire configuration lifecycle.
The gap isn't that feed-forward tools don't exist. It's that they aren't a platform. No tool tracks safety intent as a first-class, typed, composable entity that composes across the configuration lifecycle.
An important engineering clarification: cross-domain doesn't mean a Universal Data Model where all providers map to one schema. History is littered with failed universal models. The architecture is different: the observation contract has provider-specific schemas — an AWS S3 bucket schema, a GCS bucket schema, an Azure Blob Storage schema — each capturing that provider's configuration properties accurately. The evaluation engine is provider-agnostic — it evaluates CEL predicates against typed JSON regardless of which provider's schema produced the JSON. The cross-domain property lives in the engine, not in the data model. New provider features require extending the provider's schema, not rewriting the engine.
