In PyRIT, an attack strategy object is constructed once with its prompt target and its scorer, while the objective is supplied each time you execute it. What does that split buy you when you have twenty objectives to test against the same endpoint, and what does each execution get of its own?

### What the objects are A PyRIT run is assembled from a few collaborating objects, and the question only makes sense once each one is named. A **prompt target** is the adapter that knows how to reach one endpoint — an API model deployment, a hosted chat app, some other HTTP surface — and return its reply. A **scorer** reads a reply and returns a verdict: a true/false judgement, a scaled number, or a classifier label. A **converter** rewrites an outgoing prompt before it is sent. An **attack strategy** is the driver that owns the send-and-score loop, and it is handed those collaborators when you build it. ### The split: configuration versus per-run input Target, scorer, converter chain and the turn budget are constructor-time arguments. Together they describe *how* you are testing: which endpoint, which judgement, which transforms, how many exchanges you are willing to pay for. The **objective** — a natural-language statement of what you want the target to end up doing — is supplied when you execute the strategy. It describes *what* this particular run is chasing. So a twenty-objective campaign is a loop over twenty strings against one constructed instance, not twenty constructed strategies. Each execution opens its own conversation, drives it under the shared wiring, and returns its own result carrying its own conversation identifier, so the twenty transcripts stay separately readable and separately re-scorable afterwards. What that buys you is **attributability**. Across the sweep exactly one variable moved. If objective seven behaves differently from objective eight, the difference is the objective — not a scorer you happened to re-instantiate with a different threshold, or a target you repointed at another deployment while editing. Constructing the strategy inside the loop is not wrong in itself; it is wrong because it invites two things to change at once and leaves you unable to say which one mattered. ### What it costs Object construction costs nothing worth counting. The money is in calls. A single-send sweep of twenty objectives is twenty target calls plus twenty scoring decisions — and if the scorer is model-backed, which is the normal case for anything more nuanced than a substring match, that is **forty metered calls, not twenty**. The scorer's call is not the cheap half either: it is billed on the prompt plus the whole response it is judging. Add an LLM-backed converter link and each of the twenty prompts costs a further call before it is even sent. Wall-clock runs the other way: single-send executions are independent, so they parallelise up to whatever concurrency the endpoint tolerates, and the practical ceiling is the provider's rate limit rather than the loop itself. ### Where the number misleads The headline this structure produces is “twenty objectives tested”, and that is a *count of executions*, not a measure of coverage. Three specific misreadings: - **The objective is not the rubric.** People write success criteria into the objective text and pair it with a generic scorer. The objective steers the attacker side of the run; the scorer alone decides the verdict. If the two describe different things, every verdict in the sweep is judging something nobody asked about — and the run still reports twenty clean results. - **Twenty objectives is not twenty behaviours.** If the list was produced by paraphrasing a handful of seeds, the denominators are near-duplicates and a single guardrail rule can generate twenty identical outcomes that read as twenty independent pieces of evidence. - **A missing result reads as a pass.** A loop that swallows an exception mid-sweep still prints the objectives it reached, and the count quietly comes back as seventeen. ### What I would check That the number of results equals the number of objectives submitted. That each result carries a distinct conversation identifier and that the transcript can actually be re-read from the memory store rather than only summarised. That the scorer named in the results is the one configured on the strategy, not a default picked up somewhere. And that a human read a sample of transcripts instead of trusting the verdict field. If a rubric genuinely differs for a subset of objectives, that is a second configured strategy with a second scorer — and the report must then say which subset ran under which configuration, because those two subsets are not comparable to each other.