Home / The cost ABP / Step 4

Step 4: what a clause over a count cannot do

Every clause on the last page is the second barrier kind: a rule written down. For cost it is worse than that, because some of the rules are over numbers the agent cannot see, and a limit you cannot measure is one you cannot keep on purpose. This page says which is which, and what would actually cap each one.

The four barriers, applied to a number

Read the last two rows together. A limit you set is a setting; a limit somebody else set that you cannot remove is a boundary. The same number, in the same place, is one or the other depending on who can change it, which is the enforcer test applied to a quantity.

Take the cost rules we wrote and mark every clause with the one thing that would actually
stop you breaking it, using exactly these names: NOTHING, EXPECTATION, SETTING, BOUNDARY.

Then three lists:

  1. Clauses over a number you can count yourself: files, commits, fetches, subagents,
     questions, things handed over.
  2. Clauses over a number you cannot see: tokens, money, pipeline minutes, other
     people's time. For each, say who could check it and from what.
  3. Clauses that would survive a task written to make you break them: a request that
     says do whatever it takes.

Do not soften the second list. A rule over a number you cannot see is a rule you can only
keep by accident.

The ledger is a claim, and the bill is the log

The ledger from step three is the most useful thing in this walkthrough and it is a self report. This site counts a self report as a claim rather than a measurement: it stays a claim until something held outside the agent agrees with it. For files and commits that thing exists today, in the repository's history. For fetches it exists if there is a proxy. For tokens it is the platform's bill, which the agent never sees. For a person's hour it does not exist at all.

That is universe u11 in one paragraph. The runtime is where quantity lives, it is owned by whoever holds the logs, and this site has no node in it and will not. A cost ABP is the first ABP that cannot be checked from the ABP's own side of the line.

Last one. For each clause you marked EXPECTATION, name the specific thing that would make
it a SETTING or a BOUNDARY, and who would own it: a turn cap in the harness, a spend limit
an administrator locks on the account, a rate limit at the platform, a pipeline budget the
repository owner sets, a branch that cannot be pushed to without review, a proxy that
counts fetches, a log that somebody other than you reads.

For each one say whether I could turn it off myself. If I could, it is a SETTING and say
so. Where nothing available to me today would cap it, say that nothing available today
would cap it, and do not offer me a rule as a substitute.

Why write it anyway

• It is the only document that names your budget. The platform knows what you spent; nothing knows what you meant to spend until you write it.
• It moves where responsibility lands. An agent that wrote forty files nobody asked for did something you left open. One that did it against a clause departed from an instruction.
• Every expectation line is the specification for a cap nobody has set. You cannot ask an administrator for a spend limit until you know the number, and step two is where the number came from.
• The ledger changes behaviour even as a claim. An agent that knows its ledger will be read by an accountant tends to spend as if it were counted, which is the cheapest control there is and not a control at all.

Before you do anything in this session: read before you fetch, batch before you push,
tell me the count before any turn that writes more than ten files, never create work for
another person without asking me, and end every turn with a ledger of what you spent and
what you could not count.

Where to go from here