The brakes: budgets, approvals, and audit

Continuity keeps Paperclip work from disappearing, but it does not decide whether more work should be allowed. This chapter follows the control loop around cost and authority: how a run's usage becomes attributed spend, how a warning becomes a hard stop, where a human decision enters, and what the resulting audit record can actually prove. The goal is to see governance as an operating mechanism rather than as a button added beside an autonomous system.

Autonomy creates a distinctive failure mode around money and authority. A single inefficient run may be tolerable; a repeated run with no effective stop can consume a budget before anyone understands what happened. Conversely, a system that asks for approval on every low-risk action may be safe in theory but unusable in practice. Paperclip's model tries to keep routine execution flowing while making cost thresholds, intervention, and attribution durable.

A budget is a control loop, not a chart

Paperclip records cost events in the same graph that describes the work. A cost event can be associated with the company, agent, issue, project, goal, and heartbeat run, as well as the provider, model, token counts, billed cents, and time of occurrence. This structure answers more than “how much did we spend?” It can support questions such as: which agent consumed the spend, which project was affected, which goal was it serving, and which run created the charge?

That attribution is essential because a budget is enforced against a scope. Policies can apply to a company, an agent, or a project. They can use a calendar-month or lifetime window, set a warning percentage, enable notifications, and enable a hard stop. The same number has a different meaning depending on the scope and window. A project may have a lifetime ceiling while an agent has a monthly allowance. A company warning may indicate broad burn-rate pressure even when no single task looks excessive.

The budget service evaluates observed billed-cent spend against those policies. Before a threshold is reached, the system can show utilization and create a warning incident. The warning is a signal to inspect or adjust; it is not yet a claim that work must stop. This matters for an autonomous company because a warning can be handled by changing priorities, reviewing a runaway task, or deciding that a planned burst of work is worth the cost.

A hard stop changes the state of the organization. When observed spend reaches an enabled ceiling, Paperclip creates a hard incident and an associated budget-override approval record, pauses the relevant company, agent, or project, and cancels work through the enforcement hook. Invocation checks also refuse to start new work while the hard-stop condition remains. The budget is therefore not only a dashboard limit. It becomes an admission rule for future execution.

The order is important. Paperclip does not wait for an operator to notice a red chart before stopping the next run.