Incorporating AI into the industry and other branches, such as network and infrastructure management or manufacturing and production, will increase complexity to such levels that having complexity-assisted monitoring and control systems will become necessary to safeguarde these very same systems from falling off of a fragility cliff.
It is obvious that AI makes systems more complex, but AI also introduces new forms of “brittleness” and “invisibility,” which in turn require more sophisticated monitoring and control to prevent systemic collapse. The “fragility cliff” we’re concerned about typically refers to “digital cliff” or “algorithmic collapse”—sudden performance degradation or failure under out-of-distribution inputs or extreme conditions.
Why AI Increases Infrastructure Fragility
Adversarial escalation and attack surface expansion: AI is entering operational technology control loops, while attackers are already using AI to map control loops and discover vulnerabilities. The speed mismatch between defenders (requiring months to detect) and attackers (AI can exploit within 15 minutes) makes “blind operation” extremely dangerous.
Inherent brittleness of models: AI models exhibit “digital cliff” effects when facing data drift—performance plummets suddenly, and the models themselves cannot perceive this failure, continuing to output seemingly confident but incorrect results. In physical infrastructure, this can directly lead to safety accidents or cascading failures.
Loss of human oversight: For the sake of efficiency, human supervision of AI decisions is decreasing. Errors are not eliminated but delayed and concealed; small errors are absorbed by the system, only erupting after dependencies accumulate, at which point the failure has already become systemic.
Why Monitoring and Control Becomes Necessary
Precisely because AI makes systems more opaque and unpredictable, traditional “deploy and forget” models no longer suffice. To prevent systems from “falling off the cliff,” we indeed need complexity-assisted monitoring systems, i.e. those that incorporate QCM technology.
Our QCM’s core value lies precisely in using complexity measurement itself as an independent monitoring dimension, rather than relying on AI to understand AI. It provides an additional safety layer against systems “falling off the fragility cliff” due to excessive or rising complexity.
QCM’s Core Logic: Complexity Itself is a Measurable Risk
Ontonix’s foundational proposition is: excessive, or rapidly rising complexity is a primary source of fragility; systems near “critical complexity” are fragile, dominated by disorder, and difficult to govern. To manage this risk, complexity must first be measured. QCM’s role is to provide a bounded complexity metric, where the upper limit (critical complexity) represents the maximum complexity a system can sustain. When a system’s complexity continues to rise or suddenly spikes, QCM detects the trend of “approaching critical complexity,” thereby issuing early warnings before actual failures occur.
Why This Constitutes an “Additional Safety Layer” Rather Than AI Assistance
The technical positioning of QCM determines that it can serve as an independent layer of protection:
It Monitors “Structural Changes,” Not Sensor Thresholds
QCM does not monitor the numerical values of individual sensors, but rather the dependency structure between all sensor outputs. When a component degrades, the distribution of complexity shifts before any threshold is crossed, which constitutes the pre-alarm signal. This means it can detect anomalies that traditional threshold monitoring cannot see.
It Does Not Require Training, Hence No Blind Spots from Training Bias
QCM (we call it “Artificial Intuition”) does not require machine learning training with large amounts of historical data. It identifies sudden complexity spikes as anomalies—this itself is the anomaly; no prior definition and training to recognize specific fault patterns is needed. For critical infrastructure, the number of potential anomalies is enormous, making it impractical to train on all of them.
Complexity in a Feedback Loop
From a practical standpoint, imagine that complexity is used in a feedback loop to keep system complexity under control. This is a new concept, in that in addition to controlling a system’s state, it also provides safeguards against the mentioned high complexity or complexity spikes. The idea is that of a dual-loop control architecture: the classical state-control loop (keeps the plant in a desired operating state) runs alongside a complexity-control loop (keeps the system’s complexity bounded), and the two interact through a supervisory / arbitration layer that enforces complexity safeguards — i.e., it can override, restrict, or reshape the state-control action when complexity approaches unsafe levels. See the diagram below, which illustrates the concept.

The three cooperating layers are:
- State-control loop — the classical regulator:
r(t) → K(s) → u_state. This is what keeps the system in its desired state. Nothing changes here; it is the existing control law. - Complexity-regulation loop — the new layer: the complexity estimator measures
C(t)(and its spectrumC(ω)) from the plant output and the applied controlu(t); the complexity controllerKc(s)drivesC(t)toward the target/budgetC*(t)by producingu_cplx. This is regulation of complexity itself, in parallel with state regulation. - Complexity safeguard — the supervisor blends
u_stateandu_cplxinto the actual actuationu(t), but it also enforces hard bounds: ifC(t) > C_maxor the spectrum trend is rising, the safeguard trigger forces an override (safe mode, mode degradation, actuator constraints, or graceful shutdown). This is what makes the scheme safety-relevant rather than merely performance-optimizing.
Why this is new: classical control optimizes where the system is (state error → zero). This architecture additionally treats complexity as a controlled variable — it must stay within a budget, and its spectrum is monitored so that rising structural complexity is detected before it manifests as state deviation. The safeguard layer guarantees that, even if the state loop is satisfied, the system cannot drift into an unacceptably complex regime, see diagram below (click to enlarge).

The implementation of complexity-based control systems requires QCM2, the next generation Quantitative Complexity Management technology.

0 comments on “Complexity-based Control Systems: A Safeguard Against the Fragility Cliff”