Skip to content

MAINT Decompose scorer execution policy and result finalization #2413

Description

@romanlutz

Is your feature request related to a problem? Please describe.

Scorer.score_async in pyrit/score/scorer.py is the central execution path for every scorer and currently combines several distinct policy stages in roughly 121 lines and 27 branches:

  • structured-refusal and partial-content substitution;
  • validator and role-filter handling;
  • error-result skip policy;
  • objective inference;
  • subclass score execution;
  • blocked-scorer and exception policy;
  • fallback-score construction;
  • score validation;
  • ephemeral message-piece foreign-key cleanup;
  • persistence to memory.

All of these responsibilities belong at the scorer layer, but keeping their decision matrix in one method makes edge cases difficult to audit and extend. Changes to blocked content, structured refusals, or persistence can unintentionally affect every scorer and downstream attacks such as Crescendo.

Describe the solution you'd like

Keep Scorer.score_async as the public orchestration entry point, but extract cohesive internal units rather than pass-through wrappers. One possible design is:

  1. A typed scoring-input/policy decision that produces the effective message, objective, and skip decision.
  2. A narrowly scoped execution/error-policy step around _score_async.
  3. A result-finalization helper that applies fallback behavior, validates results, clears ephemeral foreign keys, and persists scores.

The refactor must preserve scorer ownership of these policies and should not move decisions into targets, attacks, or memory.

Describe alternatives you've considered, if relevant

A new service/facade would add an abstraction without clarifying ownership. Extracting every conditional into a tiny helper would reduce method length but increase navigation and leave the policy matrix implicit. A typed intermediate result is preferred because it makes the allowed states and invariants testable.

Additional context

Acceptance and validation should include:

  • all scorer unit tests;
  • blocked response with and without partial content;
  • structured refusal substitution;
  • skip_on_error_result and role-filter combinations;
  • explicit and inferred objectives;
  • scorer-owned blocked responses with both raise/fallback policies;
  • PyRIT and non-PyRIT exception propagation;
  • fallback scores for empty/filtered pieces;
  • ephemeral versus persisted message pieces;
  • exact memory writes and score validation;
  • Crescendo and red-teaming caller tests.

This is a medium-confidence design proposal with high compatibility impact. Please preserve behavior and add matrix-style tests before moving logic.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requesthelp wantedExtra attention is needed

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions