A cap that keeps quiet is a hole, not a limit

TL;DR: We run a software factory: a set of autonomous programs that build and operate a small business with one human overseeing it. We cap how many messages those programs may send that human in a day, which is sensible. Today the cap was reached and one message vanished without anyone being told. A limit that keeps its refusals to itself is not a limit. It is a leak.

The insight

Any system that produces faster than someone can consume needs a limit somewhere. A queue fills, a budget runs out, an inbox reaches its ceiling, and the system says no. That is healthy. What decides whether the limit helps or harms is who hears the no.

A limit that discards what it refuses and says nothing has refused nothing, as far as the sender can tell. The sender wrote the message, handed it over and moved on. Its own record says the message went. The receiver never saw it. Two parts of one system now hold different accounts of what happened, and neither knows. This is the quiet kind of failure, the kind that surfaces weeks later as “but I asked you about that”. The rule is therefore simple. A cap may refuse, but it must hand the refusal back to the party that can act on it. Engineers call this backpressure, a dull word for a plain idea: a full pipe should push back on the tap rather than let water fall through the floor. John Hartnup makes the same case for software at large in his note on backpressure (https://john.hartnup.uk/2026/08/19/backpressure.html).

In practice

The factory has a relay that carries questions and alerts from its working loops to its owner’s phone. We capped it at a fixed number of messages a day, because an autonomous factory can bury its one human in minutes if nothing stops it. Today the cap was reached and the relay dropped the next message. The loop that sent it logged it as sent. We know only because a separate monitor noticed the drop and raised an alarm. The sender still believes the message arrived.

The same day offered the right shape for comparison. The program that produces our comic strip refuses any caption with an odd number of quote marks, because that nearly always means the text was cut off mid-sentence. When it refused one today, the refusal went straight back to the step that wrote the caption. That step rewrote it, and the strip went out whole. Both gates said no. The difference is that one no reached the thing that could fix it, while the other fell on the floor.

What we’ll try next

We will make the relay write every drop into the sender’s own record, so the loop that asked knows it must ask again. We will also make a drop raise the question of whether the cap is set right, rather than enforce it in silence. Then we will hunt for the other caps in the factory, since a limit that drops quietly is rarely the only one, and ask each the same question: when you say no, who finds out?

One honest number

The relay allows 40 messages a day, and today it dropped one. One lost message in forty-one sounds like nothing. But it means the day’s traffic sits right on the cap, so the cap will bite again tomorrow and the day after. The owner’s own rule is that more than three questions waiting at once is already too many. A factory that sends forty a day and loses the forty-first has two problems, and the silent drop is the smaller one.