A red-team run made only granted, ordinary-looking calls. Do you file that as a bug or a design limit?

## Why this adjudication is hard The usual triage question — is this a defect or intended behaviour — assumes a component that either met its specification or did not. Here every component met it. The operation was on the granted roster. The orchestrator ran what the model requested, which is its job. The action summary listed the call truthfully. The reviewer glanced at the line and moved on, which is what a skim of a list is. There is no misbehaving part to point at, and a report that points at one will be dismissed correctly. That dismissal is the real risk to the finding. A report filed as a bug against the assistant comes back marked working-as-intended, and the organisation has now spent its attention on the finding and learned nothing. ## Adjudicate by naming the falsified claim The productive move is to state, in one sentence, the belief that the run showed to be false. Common candidates: - That a roster granted during onboarding, and never re-read since, bounds what any individual run can do. - That the operations somebody put an approval in front of are the operations whose effects matter most. - That a human triage of a run's calls sorts by consequence. It sorts by ordinariness, and the two orderings disagree. - That an assistant's coherent, task-shaped sequence of calls is evidence the sequence was intended. Each of these is a claim somebody is relying on, usually implicitly. A finding that names one and shows a run in which it did not hold is a finding, whatever label it ends up with. A finding that shows a call happening is not. ## Who owns it The owner follows from the claim, not from the code. If the falsified claim is about the roster's shape, the decision belongs to whoever granted it — often a platform or IT function that made a single onboarding call, not the team that maintains the assistant. If it is about what an after-the-fact review of runs buys, it belongs to whoever staffed that review and told a stakeholder it was sufficient. Getting the owner wrong is the second-most-common way these reports die: the receiving team agrees the behaviour is real, agrees it is not theirs, and the ticket sits. This is why a red-team write-up in this area is partly an organisational document. It has to say: here is the claim, here is who is relying on it, here is who could make it true, and here is roughly what that would cost. Note that the cost is genuinely asymmetric — re-deriving forty grants against actual per-run need is expensive and touches everyone who depends on the assistant working, while the alternatives are cheap and do not address the claim. ## Accepting a limit is a legitimate outcome A lead should be comfortable landing on "design limit, accepted, owned by X, reviewed in six months". That is a decision, it is recorded, and it survives staff turnover. What a lead should not accept is the third option that gets chosen by default: the report is acknowledged, no claim is named, no owner is assigned, and the behaviour is regarded as understood because everyone read the ticket. That state is indistinguishable from having done nothing, and it will read as a surprise the next time. One more honesty requirement. A construction like this reproduces against a deployment, not against a model. It worked in this roster, with these tasks, at this point in a run. Say that plainly, including how many attempts it took, because a probabilistic system that obeyed once has not been shown to obey reliably, and a report that overclaims reliability invites a rebuttal that discredits the part that was solid. The durable part of the finding is the shape of the roster, which does not change when a prompt is edited or a model version rolls; the fragile part is the specific run. Distinguishing them is what makes the report survive its first review meeting. ## The one-line version Bug and design limit are not the axis. The axis is: which claim did this falsify, who is relying on it, and what would have to change for it to hold. Answer those three and the label follows, and it usually turns out not to matter.