An automated ticket-triage workflow acts on the top reranked precedent — an attacker's own closed ticket ranks first. Is that a reranking defect?

## The chain, stated plainly An automated triage workflow answers new tickets by retrieving prior resolved tickets as precedent, reranking them, and carrying out the routing or runbook step the top precedent implies. Nobody reads the intermediate result. Someone files tickets of their own through the ordinary self-service path and closes them himself, writing resolution notes that read as an exemplary handling of a class of incident. Later a real ticket of that class arrives; the notes are retrieved, promoted to first place, and the workflow acts on a third party's ticket accordingly. ## What each artefact proves - The **rank** proves the passage was retrieved and read as the most relevant precedent. It does not prove the store was breached; the records went in through a sanctioned path. - The **corpus membership** proves the record is stored inside the system. It does not prove a member of staff wrote it. On a self-service queue, the resolution notes on a self-closed ticket are authored by the requester. - The **action log** proves which step ran with which values. It does not prove a person chose that step — the precedent did. Getting these directions right is most of the write-up. A finding that says "the ticket store was poisoned by an intruder" will be disproved and will take the real point down with it. ## Bug or design limit The pipeline owner's "working as designed" is a correct statement about the reranking stage and an incorrect conclusion about the system. A relevance scorer that promotes the passage reading most like the best answer is doing precisely what it exists to do, and no accuracy improvement changes the outcome — a *better* scorer promotes a well-written plant more reliably, not less. So the defect is not inside that component. It is in the composition, and it has three named parts worth stating separately, because they have different owners: 1. the corpus admits records authored by whoever files a ticket, and the workflow reads them back later as its own history rather than as outside content; 2. the ordering that decides which record wins carries no signal about who wrote it; 3. the step that acts on the winner runs with nobody in the path. A design limit is still a finding when the composition is deployed. What changes is the shape of the report: it describes a property of the system rather than an error in a component, and its persuasive force comes from the chain, not from a single surprising screenshot. ## Reproduction, honestly This kind of result is probabilistic in two places: which candidates the first step returns, and how the rescoring orders them for a given phrasing. A construction that reaches first place on four of five phrasings of the incident is a real finding with a scope. State the query class, the phrasings tried, the observed placement rate, and the action the workflow took. Do not round it up to "always", and do not discard it because it missed once — a single miss no more disproves the property than a single hit proves a guarantee. ## What the chair actually has to decide The person triaging this is deciding what the organisation is being told. Two framings are available. "The reranker ranked a malicious document first" invites an argument about scoring quality that cannot be won and should not be had. "An unattended action is taken on the output of a stage that ranks relevance over a corpus with an open write path" describes the system as built, survives a retest, and is the sentence somebody can act on. Choosing the second framing — and conceding freely that the scoring stage is not at fault — is the judgement being assessed.