Guardrails are code, not a polite request in a prompt

Every team that automates ad spend eventually writes the same sentence into a system prompt: “never raise the daily budget above X”. It works until it does not — a new model version, a long context, a cleverly phrased user request, and the limit is gone.

AdBeeCore treats the prompt as a suggestion and the code as the law. Before any change reaches an ad network, it passes Guard — a deterministic check with no model in the loop.

What Guard checks

• Daily budget cap per ad account: the change is refused if the account total would exceed it.
• One change per campaign per attribution window — the second one is blocked, not delayed.
• Campaign and ad deletion is never allowed; the worst case is PAUSED.
• Bid moves outside the configured corridor are refused rather than clipped.
• Irreversible actions require an explicit human confirmation bound to the tool, arguments and workspace.

Why refusal beats correction

It is tempting to “fix” a bad request: clamp the budget to the cap and continue. We refuse instead. A silent correction teaches the model that its arithmetic does not matter, and it makes the change log lie about what was asked. A refusal returns the reason to the agent, which then has to propose something that fits.

The audit trail is part of the limit

Every accepted change is written to change_log with the previous value, the new value, the actor (human, agent, or an external sync) and the timestamp — before the network call is made. If the call fails, the change is marked failed rather than lost. That is what makes a 72-hour window enforceable at all: you cannot reason about decisions you did not record.

If a limit can be argued away in natural language, it is not a limit.