Reading a change request like a diff

A proposal that says a budget will be six hundred has told you nothing. Six hundred is fine if the current value is five hundred and alarming if it is fifty.

So the first thing a reviewable record has to carry is the state it would change from. Without it the reviewer either approves blind or goes and looks the value up somewhere else, and in practice they approve blind, because looking it up is exactly the work the record was supposed to remove.

This is why a record written afterwards cannot substitute. A log entry describes what happened; it arrives too late to be acted on and usually without the prior value, since the prior value was overwritten by the thing being logged. A record written before the change has both halves by construction, which is what makes it a diff rather than a receipt.

The same property is what makes an undo ordinary. If every applied change carries what it changed from, the inverse is always available as a normal proposal at the same gate rather than as a privileged rollback path with its own rules.

A diff is reviewed hunk by hunk, but a reviewer looks at the file list first, and the equivalent habit matters more here.

A campaign, the group inside it and the ad inside that are three changes and one intention. They should be proposed as one reviewable unit, with each child pointing at the entry that creates its parent so that nothing carries an identifier that does not exist yet, and they should succeed or fail as one intention.

That gives the reviewer something a row-by-row queue cannot: the shape of what is being asked. And the shape is where the surprises are. Fifteen rows for an instruction about two campaigns is not a reason to read fifteen rows carefully — it is a reason to stop and ask what the instruction was understood to mean, which is a much shorter conversation than fifteen approvals.

A batch also belongs to one connection, which means work spanning two connections is two batches. That is not an inconvenience to work around; it is the system refusing to let you approve, in one act, something that will be applied in two.

The first pass is three fields and takes about ten seconds.

The authority. Pending, or the name of a rule that cleared every row on the way in. If a rule you did not expect appears here, stop reading rows and go and read the rule.

The row count against what was asked for. Covered above, and the highest-yield check in the whole exercise.

The warnings. Each row carries any it collected, each with a message saying what the condition means for the answer it travels with and a link to the record it concerns. The ones worth slowing for are an amount near the account's ceiling, a large move from the current value, increases on the connection already adding up over the last day, and a budget shared across several campaigns so that changing it changes all of them.

A warning never changes a value and never refuses anything. It says what is near, which is exactly what a reviewer wants and exactly what a system optimising for a clean interface would suppress.

Only then the rows: the operation and the level, the amount with its currency — stamped from the target account rather than supplied by whatever asked for the change — and what it is changing from.

Approve, which takes the group or named rows and moves them whole or not at all.

Reject, which is terminal: a rejected row can never be cleared, by anybody or by any rule.

And replace the payload, which is the one people forget and the one that corresponds to how code review actually works. A row with a wrong number does not have to be thrown away and re-proposed. Replacing its payload re-validates it, re-stamps the currency from the target account and re-runs the checks. That is amending a commit rather than abandoning a branch, and it keeps the reasoning attached.

Rejecting a proposal because one figure is wrong is the review equivalent of closing a pull request over a typo.

It is not a promise that a person reads everything. It is a place where the authority for a change is established and recorded, and there are two authorities: you, or a rule you wrote. A record that could not distinguish them would be worth much less, which is why the distinction is on the row rather than in a log somebody has to reconstruct.

Which is why the thing under review is a proposal rather than a report. A connection reads; it does not alter. What a caller asks for becomes a row carrying the state it would change from and the checks it passed, and that row is cleared by you or by a rule you wrote before anything moves. Nothing after that reaches an account either: no platform write reaches a customer account until that platform has granted write access, and applying one is in private beta.

Read what changed, not what it changed to. Read the group before the rows. Treat a surprising count as a question about the instruction rather than as more reading. Amend rather than abandon. And when something has been applied, read the record the same way — from the previous value forward, which is the only direction in which a change means anything.

None of it is specific to advertising. It is what a decade of code review worked out about looking at somebody else's proposed change, applied to a domain where the proposals spend money.

Why every change is a draft is the argument for the unit, and Review a batch of campaign changes is the procedure.