Internal operations · our own workspace

A cap that refuses,
not a policy that asks nicely.

We run our own back office on the principles we sell. The interesting part is not that there is a budget — it is that the budget is a line of code that exits, rather than a sentence in a document that somebody remembers.

Our own back office, running against real spend every day.

How it works Book a 15-minute call Your numbers, on the call
The refusal happens before the request A call is about to be made. The script sums the month from an append-only ledger and asks whether this call would cross the cap. If it would, a refusal: exit 2, before the request rather than after the response, with no flag or prompt to override it. EVERY METERED CALL GOES THROUGH ONE SCRIPTA call is about to be madeSum the monthfrom an append-only ledgerWould this call cross the cap?EXIT 2 — BEFORE THE REQUESTNo flag, no prompt, no override
Before the request. A cap that checks afterwards has already spent the money.

Every figure here is a build fact — counted, not claimed. No outcome numbers appear on this site until a client’s system produces one.

  • $0overspend to date
  • exit 2before the request, not after
  • 1script every metered call passes through
  • 0override flags, by design
  • 1file to change the cap
  • append-onlyhow the ledger records spend
  • 1mode that cannot reach the paid API at all
  • every callchecked against the month so far

A limit in a document is a request.

A spending limit written in a policy works until the day somebody is in a hurry, and then it fails silently — you find out at the end of the month, from the invoice. Anything unattended that can spend money needs the limit to be structural, because the whole reason it is unattended is that nobody is there to remember.

So every metered call goes through one script. Before it issues a request it sums the month from an append-only ledger, compares it against the cap, and exits non-zero if the next call would cross it. There is no flag to override it in the moment and no prompt that can talk it out of refusing.

How it works

What happens before a paid call.

Four steps, and the order of them is the entire design.

  1. 01

    A call is about to be made one entry point

    Every metered call goes through the same script. A second path is a second cap, and a second cap is no cap.

  2. 02

    Sum the month from the ledger

    The ledger is append-only, so the total is the history rather than a figure someone maintains. Nothing is edited in place and nothing has to be trusted.

  3. 03

    Compare against the cap before the request

    The refusal happens before the request, not after the response. A cap that checks afterwards has already spent the money — it is a report, not a control.

  4. 04

    Refuse, or proceed exit 2

    Over the line, it exits non-zero and the work stops. There is no flag, no prompt and no environment variable that reopens it in the moment.

The ladder, in one sentence

Everything above the line refuses; everything below it asks. A rule in a document is a request, and a request is not a control — which is why the cap, the tool allowlist and the draft-only mailbox are all code rather than sentences.

Enforcement above, requests below A ladder of controls. At the top, a spend cap enforced in code that exits before issuing a request. Below it, a tool allowlist. Below that, draft-only mail. At the bottom, written instructions — which are requests, not enforcement. ENFORCEMENT — refusesSpend cap in codesums the month, exits before the callTool allowlistonly the commands the job needsMail is draft-onlyno send tool is reachableREQUESTS — asks nicelyWritten instructionsA reminder in a document
Everything above the dashed line refuses. Everything below it asks.

What you get

What this is worth to somebody buying automation.

A known ceiling

The bill cannot surprise you

The most common fear about anything unattended is that it runs away with a card attached. This is the answer to that fear, and it is checkable rather than promised.

One file

The cap is one number

Changing it is changing one value in one place. Nothing else in the system knows how to spend, so nothing else has to be checked.

Refusal, not warning

It stops rather than notifies

A warning depends on somebody reading it in time. A refusal does not depend on anyone at all, which is the whole difference on the day it matters.

The same pattern goes into every client build: anything unattended that can spend gets a cap enforced in code, never a reminder.

Want this one walked through against your own numbers? Email info@adapton.io and we will show you the parts that transfer and the parts that do not.

The limits

What it costs us.

The honest version, because a control with no cost is usually a control that does not bind.

  • A cap this strict occasionally refuses something we wanted. That is the trade, and it is the right one — the alternative is a limit that is really a suggestion, which is the same as no limit on the day it counts.
  • It caps spend. It does not make the spend worthwhile — that judgement is still a person’s.
  • The cap is never raised on anyone’s behalf, including our own, and including in the middle of something.
  • One mode of the tool is structurally unable to call the paid API at all. Not discouraged, not warned about — unreachable.
  • This runs on our own workspace. It is a pattern we reuse, not a product we sell on its own.
Forbidden by construction Three controls that are unreachable rather than discouraged: a free mode that cannot call the paid API at all, a mailbox with no send tool, and a tool allowlist limited to the commands the job needs. FORBIDDEN BY CONSTRUCTIONThe free modecannot reach the paid API at allMaildraft-only — no send tool existsToolsonly the commands the job needsNone of these has a flag that reopens it.
Discouraged is a request. Unreachable is a control.

Next step

Show us the thing you do every morning.

Fifteen minutes. We ask three questions and do the arithmetic with your real numbers. If it is not worth automating we will say so on the call.

Send us the details

All case studies · info@adapton.io