A carrier finding reproduced for the reporter, but their bug tracker stripped the carrier from the ticket: is it a finding?

## The situation Someone files a finding: a carrier hidden in a public page reached the model and got obeyed. They say it reproduced for them. But **their bug tracker stripped the carrier out of the ticket** on the way in, so the artefact the triager opens no longer contains the thing that worked. The triager has to judge a claim whose evidence the reporting path itself destroyed. This is a principal-grade call because it is an **adjudication under constraint**, not a technical lookup, and getting it wrong has an organisational cost either way. ## The reporting channel is another lossy pass The key insight is that a bug tracker, a chat client, an email gateway, a ticket form, are all **transformations in the same family the finding is about.** They normalise, strip control and zero-width codepoints, re-encode, or rasterise pasted content, exactly like a pipeline stage. So a ticket that contains no visible carrier is not a null result; it is the carrier dying on the reporting path. **"There is nothing malicious in the ticket" is the finding reproducing, one hop further along.** A triager who reads the empty ticket as "cannot reproduce" has made precisely the error this leaf warns about: mistaking a lossy channel's coverage for the absence of a carrier. The correct read is the opposite: the reporting path just demonstrated that this carrier class is fragile to a normalise/strip step, which is information, not exoneration. ## What triage must actually do 1. **Recover the carrier through a preserving channel.** Ask for the artefact in a form the reporting path cannot flatten: a file attachment, a hex or codepoint dump, an out-of-band capture. The carrier's identity has to be reconstructed before anything can be judged. 2. **Reproduce against the real pipeline**, not against the ticket. The ticket is the wrong environment; it has its own kill-set. The claim is about the target's pipeline. 3. **Characterise reliability honestly.** A probabilistic model means a construction can work once and not the next time. One success against one deployment is a data point, not a reliable finding. If it reproduces one time in five, that has to be stated as such, because the fix decision depends on it. ## The harder adjudication Once reproduced, the principal question is **what kind of finding it is and who owns it:** - **Bug or design limit?** If the carrier rides a public field the organisation does not control, on a page anyone can author, then "the model can be reached by an authored public page" may be a design property of building an agent that ingests the open web, not a defect of one field. Deciding whether to fix, to accept with compensating measures, or to re-scope the agent's inputs is a judgment with a real cost attached. - **Which owner?** The carrier survived because of how the ingestion chain is built, but the impact lands where the obeyed instruction reached a capability. The finding may belong to whoever owns the ingestion path, or whoever owns the action the model took, and those can be different teams with different fix costs. - **How much does reliability change the verdict?** A carrier that reproduces every week is a different priority from one that reproduced once and cannot be repeated. The triager has to weigh a claim of durability against the reproductions they can actually get. ## The organisational trap, stated plainly The failure mode is administrative, not technical: **closing the finding because the ticket looks clean.** The reporting channel's lossiness is being read as evidence, and it is not evidence about the target at all, it is evidence about the bug tracker. The principal-level candidate names this explicitly, insists on out-of-band recovery and reproduction against the real pipeline, and only then argues about bug-versus-design and ownership. A weaker answer either accepts the reporter's word without reproduction or dismisses the finding because the ticket is empty, and both are wrong for the same reason: they let a lossy channel decide the verdict.