【Control】🧩 10. Envelope Control and Design Recovery Control

— Handling “Boundaries” and “Assumptions,” Not Control Itself

topics: [“control”, “design”, “architecture”, “AI”, “LLM”]

🧭 Introduction

Recently, in discussions around control and AI,
it is common to hear phrases such as:

• “Control with LLMs”
• “AI optimizes the controller”

However, in real physical systems and device design practice,
a very different intuition dominates:

• Control is something applied last
• What truly breaks are design assumptions and operational boundaries
• Putting AI into real-time control loops is dangerous

Based on this perspective, this article introduces
two architectural control concepts.

| Envelope Control        | Protects runtime (operational) boundaries |
| Design Recovery Control | Restores design-time assumptions           |

Neither concept is about “control itself.”
They deal with structures that prevent control from breaking.

🛡 What Is Envelope Control?

Envelope Control is the concept of:

Constraining a system to a safe operating region (the envelope)
under uncertainty.

The key points are what it does not aim to do:

• It does not pursue high performance
• It does not optimize
• It does not learn

What it does is extremely simple:

• Monitor physical quantities such as voltage, current, temperature, speed
• Enforce non-negotiable bounds on those quantities at runtime

Conventional controllers (e.g., PID) operate normally inside the envelope.
But the moment the system approaches the boundary,
operation is restricted or suppressed.

👉 Envelope Control answers not
“How should we control?”
but
“How far are we allowed to operate?”

🧠 What Is Design Recovery Control?

Design Recovery Control (DRC) operates on
a completely different time axis.

It addresses failures caused by broken design assumptions themselves,
not by control errors.

DRC explicitly does not:

• Generate control inputs
• Intervene in real time
• Optimize through learning

Instead, it examines and updates:

• Whether PID gains are still valid
• Whether FSM transition conditions still match reality
• Whether operating mode definitions have become outdated

Even when LLMs are involved:

• They never execute actions
• They only generate proposals
• Humans or systems must explicitly approve changes

👉 DRC is not control.
It is structured design review and recovery.

🔗 Relationship Between the Two (Critical)

These two concepts do not compete.

In short:

• Envelope Control
  → “How do we safely constrain operation right now?”

• Design Recovery Control
  → “Why did the original design assumptions stop working?”

Only when both exist can
ordinary control remain ordinary control.

🧱 This Is About Positioning, Not Implementation

It is important to emphasize:

This is not a discussion about control algorithms.

This comes before questions such as:

• PID tuning
• Mathematical formulations
• Stability proofs

Instead, it addresses:

Where responsibility is divided in system design

🔗 Reference Links

Definitions and concept documents are available here:

• Envelope Control
  https://samizo-aitl.github.io/envelope-control/
  https://github.com/Samizo-AITL/envelope-control

• Design Recovery Control
  https://samizo-aitl.github.io/design-recovery-control/
  https://github.com/Samizo-AITL/design-recovery-control

🧭 Closing Remarks

Before making control more sophisticated,
it is far more important to clarify:

• Where systems break
• What assumptions were made
• When design must be revisited

Structurally separating these questions
is what makes real systems robust.

Envelope Control and Design Recovery Control
are design-side tools for that purpose.

Before making control “smarter,”
design a structure that prevents control from breaking.

That is the role of these two concepts.