An LLM triage run logged an alert-route change — what does that record prove about who chose the arguments?

## What kind of artefact you are holding A run record is a record of execution. That is a narrow and useful thing, and treating it as a record of intent is the mistake this question exists to catch. It supports these claims: - A call of a particular name executed during a particular run. - The argument values that were passed. - The trigger that started the run, if the trigger was recorded. It does not support these: - **Who chose the values.** They were produced by a model conditioned on a window of text. The record shows the output of that selection, not its input. - **That the reason is a reason.** A model-authored justification string is generated by the same process whose behaviour is in question. It is an output, never an attestation. - **Which text in the window was authored by the system and which was quoted into it.** Unless a source list survives with per-source origin, quoted characters and system prose are indistinguishable in the artefact. ## Reading the record in a second-order case In a triage deployment, the assistant reads recent error strings and alert payloads, produces a shift summary, and adjusts routing on the low-severity path. If a span was planted as a rejected field value, echoed into a validation log, and quoted into the window, then the run record is the first place anyone notices anything — and it points at the run. What you can do with it depends entirely on how much of the assembled window survived: | What the run captured | What you can establish | |---|---| | The call and its arguments only | An action happened; nothing about its cause | | Plus the list of sources read | That a value corresponds to text from a specific store | | Plus the retrieved text per source | That a quoted line, not an alert payload, carried the phrasing | | The summary it produced only | Nothing — quoted characters read as system prose | The last row is the common one and the reason this is a hard triage. A shift summary is a produced artefact; once a quoted span is folded into it, the summary reads as the system's own account, and the next reader inherits it with no way to tell. ## The chain the record does not cover Even in the best case the record ends at the store, not at the person. To attribute further you would have to walk from the log line back to the request that produced it — a request identifier, a source address, a timestamp — and that evidence lives in a different system, under a different retention, quite possibly already rolled. So an honest write-up says: the action was taken by the run; the argument values correspond to text quoted from a validation log; the origin of that text is not recoverable from anything retained. That is not a failure of nerve. Overstating it — writing that an attacker caused the route change when what you have is a correspondence between an argument value and a quoted string — is the kind of claim that collapses under review and takes the real finding with it. ## The general rule to state Each artefact in this path proves one narrow thing, and every step of inflation is a misconception: - A tool-call record proves which call ran, not who chose the arguments. - A logger name proves which component emitted a line, not who wrote its contents. - A model acting on retrieved text proves the text reached the context, not that any store was breached. - A generated reason proves the model produced text shaped like a justification, nothing more. - One reproduction proves the path exists, not how often it fires. Someone inheriting months of retained logs and generated summaries and asked which entries the system authored and which it quoted should be able to say plainly that, for the summaries, the question is not answerable from what was kept — and to say which of the artefacts above would have been the one that carried the answer.