How do you choose the norm and radius for red-teaming a forecaster whose input window participants partly supply?
answer
- start from capability, not convention
- which coordinates can they write
- legal postings, not continuous values
- the ball and the reachable set only overlap
- nobody looks at a number series
basics
~20 sDerive both from what a participant can legally post, not from convention. Restrict the coordinates to the ones they write, size the radius by the postings their own volume supports, and measure the payoff as the decision the forecast moved.
solid answer
~50 sStart from capability, not from a number borrowed out of another input domain. An enrolled participant writes only their own postings, so the bound applies to a sub-block of the window rather than all of it. Their values must be legal: sign-constrained, granular to a tick or lot, and backed by volume they actually hold -- so the reachable set is discrete and asymmetric while a ball is continuous and symmetric, and the two only overlap. Size the radius from what a participant of a given size can post without anything rejecting it, and state a second, larger scope for a colluding group. The perceptual justification does not travel here: nobody eyeballs a number series, so "imperceptible" has no validator and cannot set the radius. Finally, report the payoff at the decision -- the money or capacity the moved forecast committed -- rather than only as error inside a ball.
go deeper
Know that the budget should come from what the attacker can actually do in this system, and that a number copied from elsewhere carries none of that.
Be able to name the constraints that define what a participant may post -- sign, granularity, volume, validity checks -- and explain why they do not form a ball.
Show the full derivation: coordinate scope first, size from legality, collusion as a separate tier, and the finding converted into the decision it moved.
Own the decision of which tiers get tested and which are declared out of scope, and be ready to defend that split to somebody who disagrees about who the attacker is.
## The wrong starting point The common approach is to open a red-team exercise by choosing a familiar norm and a familiar radius, then reporting how the model held up. That produces a number about a hypothetical attacker who may or may not resemble anyone near this system. On a forecaster whose input is a rolling window of recent market history -- posted quantities and quotes that participants themselves supply -- the attacker is concrete and their capability is enumerable, so the budget should be derived rather than borrowed. ## Derive the coordinate scope first Before the size, decide *which* coordinates the attacker can write. An enrolled participant posts their own quantities and quotes. They do not write anyone else's, and they do not write the settled outcomes. A bound stated over the whole window silently grants them everything in it, which is not a conservative assumption but a wrong one -- it produces a robustness figure against an attacker with more reach than exists, and it can also *understate* the problem by burying the block they truly control inside a total budget spread across coordinates they never touch. So the first line of the threat model is the sub-block: these coordinates, belonging to this participant, over this stretch of the window. ## Then derive the size from legality, not from a convention What a participant can post is constrained by rules that already exist and that you can read off the venue: values are sign-constrained, granular to a tick or a lot, bounded by the volume the participant can actually stand behind, and visible to others in whatever form the market publishes. Those constraints define a *reachable set*, and it has three properties a ball does not: it is discrete, it is asymmetric, and it is bounded by economics rather than by magnitude. The consequence worth stating plainly is that the ball and the reachable set overlap rather than nest. Parts of any ball you draw correspond to values nobody can post. And a value a participant may perfectly legally post can sit far outside a small radius -- there is no rule of the venue that keeps postings inside your chosen epsilon. Evaluate against the reachable set, then report the ball that most nearly contains it and say which parts of each fall outside the other. ## "Imperceptible" does not transfer A great deal of the intuition around perturbation radii comes from input domains where a person inspects the input and the argument for the radius is that a change that small is one nobody would notice. On a window of numbers feeding a forecaster nobody inspects the input at all. There is no perceiver, so the perceptual proxy has no validator, and a radius justified that way is a number with no argument behind it. What replaces it is the venue's own acceptance: a change is "unnoticed" exactly when it passes validity checks, plausibility rules and whatever other participants can see. That is checkable, it is specific to the deployment, and it is the honest analogue. ## Tier the adversary One participant is one threat model. A group acting together is another, and it is not obtained by enlarging the radius -- it is obtained by enlarging the *coordinate scope* to several participants' blocks while keeping each participant's own posting limits intact. State them as separate tiers with separate assumptions, and be explicit about how many colluders the second tier assumes. Reporting a single number for "the attacker" when two very different attackers exist is where these exercises lose their meaning. ## Measure the payoff where the harm is A result expressed only as forecast error inside a ball invites the reader to judge the radius rather than the harm. The interesting quantity is the decision the moved forecast produced: capacity committed, positions taken, money settled differently. A small legal nudge that shifts a forecast slightly across a whole horizon can be worth a great deal, and that conversion is the part a reviewer can act on. Conversely, a large permitted change that moves no decision is a finding you can close. ## What you hand back The deliverable is not a single figure. It is: the coordinate scope, the legality constraints that define the reachable set, the ball you evaluated as an approximation of it, the tier structure for collusion, and the harm converted into the deployment's own units. A reader can then disagree with any one of those explicitly -- which is the point of writing a threat model down instead of inheriting one.
- How do you handle collusion between participants in the budget?As a separate tier, not a larger radius. Keep each participant's own posting limits intact and enlarge the coordinate scope to several participants' blocks, stating how many colluders you assume. Turning up the radius on one participant models someone who can post more than they are allowed, which is a different and less useful fiction.
- The reachable set is discrete and the ball is continuous. Which do you evaluate against?The reachable set, because that is what an attacker can actually produce. Report the ball as the nearest standard description so the result is comparable to how these claims are usually stated, and note explicitly which parts of the ball are unreachable and which legal postings fall outside it.
saying these in an interview costs you the question
- Picks a conventional radius from another input domain unchanged
- Bounds the attacker over the whole window rather than their own postings
- Justifies the radius as imperceptible where nobody inspects the input
- Models collusion by enlarging the radius instead of the coordinate scope
- Reports error inside the ball and never the decision it moved