Add Volume, Spend, and Time Limits

Every action that consumes something finite goes through a single point that checks a local ledger before the call and records the consumption after it.

The failure mode is having two. Two callers with two ledgers is not a budget, it is two budgets that disagree, and the moment there are two, the answer to “how much have we spent today” becomes a reconciliation problem rather than a lookup.

Over the limit means deferred, not dropped

This is the whole design, and it is one word.

When work exceeds the cap, mark it deferred and re-process it on the next cycle. Do not drop it. The difference between deferring and dropping is the difference between a delay and silent data loss, and from the inside they look identical, because in both cases nothing happens.

Dropping is what you get by default. The call fails, an exception is swallowed somewhere, and the record simply never gets processed. Nobody finds out, because a record that was never enriched looks exactly like a record that had nothing to enrich.

Show the budget where the decision is made

A well-designed enrichment console puts the remaining daily allowance directly above the rules, so whoever is about to enable one can see what is left before they enable it.

That placement is the entire control. A budget on a different screen is a budget nobody consults. A budget in a weekly report is a post-mortem.

Publish what the control does not cover

The most honest thing in this class of system is a cap that states plainly that it meters only the spend it can see, that the larger share happens in a vendor's own interface where it has no hook, and that this has to be controlled by other means.

That paragraph is not an apology. It is part of the control. A team that believes the cap is total will make decisions on that basis and be wrong. A team that knows exactly where the boundary is can put something else on the other side of it.

Target the spend using coverage

The last piece is about not spending it in the first place. A per-field fill-rate view across your objects is how enrichment gets pointed at the fields that are actually thin, rather than re-buying data you already hold. Without one, a per-unit tool quietly becomes the largest line in the stack regardless of its subscription price.