Your red-team harness logs only the attack prompt and the model's final reply for each attempt against a hosted chat endpoint. Why can a colleague not re-run that attempt from the log, and what should the log capture instead?

### The mistake underneath the log format A prompt-and-reply log encodes an assumption: that the text you sent and the text you got back are the whole causal story. They are not. What answered you was an *application*, not a model. Sitting between your keystrokes and the tokens you read there is an application-owned **system prompt** (the instruction block the product prepends to every conversation), possibly a set of **retrieved documents** pasted in around your text by the app's retrieval layer, a set of **tool schemas** describing functions the model may call, a **decoding configuration** that governs how the next token is picked, a moderation classifier in front and often another behind, and a **served model build** sitting behind an endpoint name that never changes. Every one of those can change while your prompt stays byte-identical, and every one of them changes the reply. ### The four layers a usable capture record carries **1. Identity of what you hit.** The endpoint or deployment string you called, *and* the model identifier the provider echoed back in the response envelope — not the one you believe you configured. A deployment alias can be repointed behind you; the echoed value is the one that dates the finding. Where the provider also returns a backend or build fingerprint alongside the model id, keep it: it is the finest-grained "what served this" signal you will ever get from outside. **2. Request configuration as it went on the wire.** Effective decoding parameters — the temperature, top-p, maximum output tokens and stop sequences that were actually transmitted — plus tool schemas, any safety or moderation options you set, and the SDK and harness build that assembled the request. Record the *effective* values, not the ones present in your config file: a harness that silently defaults a temperature you never wrote is the single most common reason a re-run diverges. **3. Conversation state.** The system prompt verbatim, the retrieved chunks if the app does retrieval, and every prior turn in order, both sides. Multi-turn attacks work because of accumulated state; a prompt lifted out of the middle of a conversation usually does nothing on its own. **4. Provenance.** Timestamp with timezone, the provider's request id, and the operator. These look like bookkeeping until reproduction fails, at which point they are the only handles that let you ask the provider or the platform team what was serving that traffic. ### What the capture costs Next to nothing while the run is live, and it is unrecoverable afterwards — that asymmetry is the entire argument. Concretely it is two extra fields read off each response envelope, one system-prompt snapshot per run, and storing raw bodies instead of rendered text. No extra model calls, no extra spend at the endpoint. The real costs sit elsewhere: a sweep of a few thousand attempts with raw request and response bodies is on the order of tens of megabytes — trivial in bytes, not trivial in liability, because that store now holds working attack transcripts against your own systems plus whatever real user data arrived through production-shaped retrieval. Budget the access control and the retention clock, not the logging. ### Where the record misleads when you skimp The characteristic failure is not "we lost data", it is a **wrong conclusion stated confidently**. Someone re-runs the attempt from a prompt-and-reply log, gets a refusal, and writes *fixed*. Absence of the behaviour today is one sample from a system with at least three independently moving parts — the served build, the app's own prompt and filters, and sampling variance — and a log with no echoed model id and no system prompt gives you nothing to tell them apart with. The second misreading is subtler: a **rendered transcript read as raw output**. Rendering strips leading whitespace, refusal prefixes, truncation markers and structured response fields. A transcript that shows a harmful continuation but hides a finish reason of "stopped by content filter" reads as a complete success when it was a truncated partial one, and the severity you file off that reading is wrong in the direction that embarrasses you. ### What you would check before believing your own record Take one attempt at random and rebuild the wire request from the stored fields alone, on a different machine, without the harness. If you cannot reconstruct it, what you have is a diary, not a capture. Once, compare the stored decoding settings against what the SDK actually transmitted — that is how you find the default nobody wrote down. And scan the store for auth headers and customer data before any record leaves your team.