Numbers people are paid to move

A risk register asks how likely something is and what it would cost. That framing works when the thing is an event. It does not work here, because on a public ledger the conditions for the behaviour are permanently present: the rule is readable, participation is open, and one party can hold as many addresses as it cares to create. There is no state of the world in which those conditions are absent, so there is no probability to estimate.

The shift that follows is small to say and large to run. You stop asking whether the user base is adversarial and start asking which share of it is, and in which direction that biases each number you publish. The first question has a yes or no answer that is always yes. The second has an answer you can measure, report and act on, which is what the live box in part 2 does.

• Target. A measure that somebody is rewarded against. The moment a measure becomes one, its relationship to the thing it was measuring starts to come apart.
• Published target. A target whose exact definition is readable by the parties responding to it, without being told and without asking. Part 1.
• Manufactured identity. An address created so that a count of addresses reads higher. Not a disguise and not a breach, just a row.
• Operator. In Larkfield's world, a party deliberately running many addresses. There are 4 of them and they run 60 each.
• Adversarial data. A dataset where some rows exist because somebody wanted your metric to read differently. Session 1 named it, tonight measures it.
• Ceiling. The clustered figure from session 2. An upper bound on the entity count, with no floor.
• Detection. Work aimed at finding deliberate multi-address behaviour. Session 2 measured how much of the gap it can possibly recover, and the answer was small.
• Record linkage. Joining records about the same party by fuzzy attributes and probability. That craft lives in learn-entity-resolution-with-phoebe; the evidence here is transaction structure, so the machinery differs.

Every mitigation written for a targeted metric leans somewhere on the actor not knowing the exact rule. Hold the definition back. Change it without announcing. Keep the thresholds in a document that does not circulate. Measure something adjacent so the obvious lever is not the one being counted. All of these work by putting a gap between what the actor thinks is counted and what actually is.

On a public ledger that gap cannot be created, because the rule that issues the reward is readable by anyone in exactly the form that runs. There is no version of it held back. An actor does not have to infer what triggers the reward from its own results over three months, which is the slow and error-prone route; the actor reads it, once, and is then correct about it.

The consequence is that secrecy stops being available as a control, and any plan that quietly depended on it has to be replaced rather than tightened. That is not the same as saying nothing can be done, and part 2's build-along works on what is left.

The second feature is the larger one and it is the one with no precedent in the usual framing. In the familiar version an actor facing a target changes what it does. It works the measured thing harder and the unmeasured thing less, and the damage is that your measure and your intent come apart. The actor remains one actor throughout, which is why the harm is describable as distortion.

Here the actor has a second move. Rather than changing behaviour it can change how many of it there are, because an identity in this dataset is an address and an address is a row. A party wanting a per-party count to read higher does not need to do anything differently. It needs to be more numerous, and being more numerous is free of everything except the rows.

That breaks the mitigation of last resort as well. When you cannot hide the rule, the standard fallback is to normalise the metric per user, so that working the lever harder does not help. Per user normalisation assumes the user count is a fact about the world. It is a fact about the data, and the data is what the actor is adding to.

It is tempting to treat these as one phenomenon, and the reason not to is that they come apart in other settings and the remedies differ. A published target with a fixed identity set is a familiar situation: published benchmark criteria, published inspection standards, published eligibility rules. It is uncomfortable and it is workable, and the working answer is usually to make the target hard to satisfy without also doing the underlying thing.

A manufacturable identity set with a private target is also familiar, in a smaller way: a referral programme where one person can hold several accounts, but nobody outside knows exactly what qualifies. The working answer there is verification at the point of identity, and the cost of it is borne once per identity.

Larkfield has both at once, so neither answer survives on its own. Making the target hard to satisfy without doing the underlying thing does not help when the underlying thing can be done sixty times by one party. Verifying identity is the right instinct and it is a decision about the product rather than the pipeline, since the only place to attach a verification is before the address becomes eligible. Session 6 puts that in the scoping questions, where it belongs, because by the time a data team meets this the choice has already been made.

Set the operators to run no addresses at all and the manufactured rows disappear from the count, which is what you would expect. The row worth staring at is the one below: the truth drops by 4 and the reported ceiling drops by a great deal more than 4. The four operators were four entities. They were being counted as something close to two hundred.

Now walk the slider back up and watch how the reported ceiling responds. It rises, and it rises by less than the number of addresses added, because the co-spend method does catch some of them. It never catches all of them, and the shortfall goes straight into the number Larkfield publishes as a bound.

Two things are worth saying out loud at this point. The first is that this is not a detection failure, since detection is exactly what the method is doing and it is doing it correctly. The second is that a party who wanted to defeat the method entirely would not have to work at it; session 2 measured that operator discipline moves the clustered count by 31 against a gap of 392, so the method is not being beaten by tradecraft. It is being outnumbered.

The practical rule that comes out of this is narrow enough to apply on a Monday. When a metric is published and a payment is attached to it, you do not wait for evidence of gaming before treating the figure as gamed. You write down, at the moment of publication, which direction the metric can be pushed and what one additional identity buys the pusher. Then you decide whether you are prepared to report it at all.

The reason to do this at publication rather than at first incident is that the first incident is not observable. There is no alert for an address that behaved normally. The 240 rows in Larkfield's month did not trip anything, would not trip anything, and are only visible here because the generator knows the answer. On real rows you would have the count and nothing else.

The version of this that a leader can hold people to is a single line in the definition of every metric that triggers a payment: who benefits if this number goes up, and what is the cheapest way for them to make it go up. If that line is empty the metric has not been reviewed, whatever else was checked.

One camp holds that you should publish the reporting definition in full, alongside the reward rule that is already public. Their argument is that the definition is effectively recoverable anyway: a determined party can infer it by watching what gets counted, and will, so withholding it disadvantages only the honest participants, your own analysts and anyone auditing you. Publishing also forces the definition to be good, because a rule that embarrasses you when read is a rule that should not be paying anyone.

The other camp holds that recoverable in principle and handed over in writing are different things, and the difference is measured in how many parties bother. Every published clause is a specification for satisfying it cheaply, and the people who read specifications carefully are exactly the ones you do not want optimising. On this view the reward rule has to be public because it executes, and the reporting definition does not, so keep them apart: pay on one and report on another, and never publish the second.

Both are held by people who have watched a metric collapse. The disagreement is empirical rather than philosophical, and it turns on how many parties will do the inference work if you do not do it for them. Notice that the second position has a cost the first does not: a reporting definition nobody outside can see is a figure nobody outside can check, which gives up the one advantage session 1 credited to the public arrangement in the first place.