Nobody sees the outcome

Why can a monthly bill not control spending, and why does control need two loops?

The first three parts assumed a single agent who sees the price, makes the design decision and pays. That agent does not exist. The person who writes the query, the person who owns the table, the person who approves the commitment and the person who receives the invoice are four different people. Only the last one sees the result. The constraint in this article is informational and organizational, not physical. It is the reason cost problems persist in organizations that are technically able to solve them.

Describe the loop precisely, because every mechanism below responds to a specific defect in it.

• The sensor lags. Billing closes monthly. Cost APIs report at best every 4 to 24 hours.
• The sensor aggregates. Spend arrives added up across the boundary you needed it split by.
• The actuator sits with someone who never reads the sensor.

A control loop cannot regulate anything faster than its own delay. So a loop with a monthly time constant cannot regulate anything that can multiply within a month. That is most things: a bad partition specification, a runaway backfill, a scheduled query set to run every five minutes.

That one fact forces the architecture of everything below:

The most widely deployed control, a monthly budget alert, is the one most clearly defeated by the loop delay: it fires after the damage. Anomaly detection on spend is the one thing that shortens the sensor delay without changing the meter: it watches daily or hourly spend and flags a sudden change in level, instead of waiting for a total to cross a line. And approval and provisioning gates (who may create a warehouse, a cluster or a bucket) are the only control that acts before the spend exists.

Confusing the two loops causes the standard failure: quarterly cost reviews aimed at problems that need per-query enforcement, and per-query limits aimed at problems that need a design change.