In a ticket-triage workflow, what must hold for text in a filed ticket to reach the parser reading the assistant's answer?

## What is actually being attempted A ticket-triage workflow takes a customer-filed ticket, has an assistant read and summarise it, and hands the assistant's answer to a parser that lifts out the values the workflow acts on: a queue, a priority, an owner. Nobody reads the answer at the time; the only human sight of it is a digest of routing decisions the next morning. The construction under discussion does not try to make the model say something forbidden. It tries to get a span from the ticket body to arrive in the assistant's answer *in a place where the parser's grammar gives it force*. The harm classifier in front of the answer is looking for abuse and violence; a span that looks like an ordinary fragment of a support ticket scores nothing. That sounds easy and it is not, because three separate things must hold at once. ## Condition 1 — carriage The model is not a pipe. Between the ticket body and the answer sits a summarisation step, and summarisers paraphrase. A span survives when the model has a reason to reproduce it rather than restate it: material that presents itself as a quotation, an identifier, a code, a verbatim line the summary would naturally carry through. Material that reads as prose the model can compress is compressed. **This is the single largest source of failure in the class**, and it is not deterministic — the same ticket, the same model, and the span arrives in one attempt and not the next. Anyone reproducing such a finding runs into this immediately. ## Condition 2 — position The parser assigns meaning by *place and marker*. A field value is a field value because of where it sits, not because of what it says. So a span can survive carriage perfectly and still do nothing, because it landed in the narrative half of the answer rather than the half the parser reads. Getting the position right requires knowing something about the grammar — and the attacker is guessing. Common shapes get guessed successfully far more often than one would like, precisely because these consumers are usually simple and conventional. ## Condition 3 — an unbroken path Even with carriage and position, anything between the model and the parser can dissolve the effect: a normaliser that collapses whitespace or strips characters, a templating step that wraps the answer, a service that re-serialises it, a truncation budget that cuts the answer short. None of these were put there for this reason, which is why the class often stops working for reasons no one records. It also means the finding can evaporate on a deployment change that nobody associated with security. ## What it costs the attacker - **No feedback.** In an unattended workflow the ticket author sees an acknowledgement, not a parse trace. Whether the answer was read as structure is invisible from outside. - **Blind on the grammar.** The consumer's field names, markers and positions are not published; attempts are guesses against an unseen target. - **Probabilistic on every attempt.** Carriage varies by generation. A construction that works one time in five is genuinely working, but that is not the same as a reliable finding. - **Cheap per attempt, though.** Filing a ticket costs nothing, and the workflow will process every one of them. That asymmetry is the honest summary: high uncertainty per attempt, near-zero cost per attempt, and a consumer that never gets tired. ## Where it stops working It stops when the answer stops being the thing the workflow reads for its values — when what the consumer acts on no longer originates as generated prose. Note that this is a statement about *where the property lives*, not a recommendation: the point for an interview is that the boundary sits at the consumer, and every attempt to stop it at the producer is fighting a probability rather than a mechanism. Naming that boundary correctly is what separates a candidate who has thought about this class from one who has read a list of attack names.