[FEAT]: Psychosocial Scenario

[jbolor21]

Description

Adding in a new scenario for evaluating psychosocial harms. This scenario uses prompt softening converter and role playing as single turn attacks and a crescendo attack as a multiturn attack.

Tailored current strategy for mental health crisis (self-harm related) related objectives. Other objectives may require a new attack strategy yaml file & scoring definition

• Added new likert scoring file for evaluating crisis situations
• Modified attack strategy for crescendo technique for mental health crisis related objectives
• Added sample prompt file for some example objectives

Tests and Documentation

Added new unit tests and ran local notebooks to test strategy works

[bashirpartovi]

Would the harm category keys in crescendo_system_prompt_paths_by_harm always exist in scoring_rubric_paths_by_harm? If so, is there a check for that?

This is a bit unclear to me. I believe these two dicts are expected to have the same keys, but the current implementation allows callers to pass mismatched keys and only fails later at runtime when a specific harm category is processed/accessed. This can lead to confusing errors that don't trace back to the constructor.
I think a better approach would be to make it a typed structure that encapsulates the system prompt path and scoring rubric path per harm category:

@dataclass
class HarmCategoryConfig:
    crescendo_system_prompt_path: str
    scoring_rubric_path: str

Then your constructor signature would look like this:

def __init__(
    self,
    *,
    ...
    harm_configs: Optional[Dict[str, HarmCategoryConfig]] = None,
    ...,
):

and internally in the constructor:

default_configs = {
    "psychosocial_imminent_crisis": HarmCategoryConfig(
        crescendo_system_prompt_path=str(
            pathlib.Path(DATASETS_PATH) / "executors" / "crescendo" / "escalation_crisis.yaml"
        ),
        scoring_rubric_path=str(
            pathlib.Path(DATASETS_PATH) / "score" / "likert" / "crisis_management.yaml"
        ),
    ),
}
self._harm_configs = {**default_configs, **(harm_configs or {})}

Internally, you could still translate this into separate dicts if that is easier for the existing logic. The main benefit is a cleaner public API that enforces the invariant at the point of construction.

If the fields could have different defaults or be optional, you could still use the same structure like this:

@dataclass
class HarmCategoryConfig:
    crescendo_system_prompt_path: str = str(
        pathlib.Path(DATASETS_PATH) / "executors" / "crescendo" / "escalation_crisis.yaml"
    )
    scoring_rubric_path: str = str(
        pathlib.Path(DATASETS_PATH) / "score" / "likert" / "crisis_management.yaml"
    )

This way, you eliminate a lot of if/else checks for whether a harm category exists, falling back to the default path, etc.

[jbolor21]

Thanks, I tried to address this let me know if these changes address your feedback & make it more clear!

[bashirpartovi]

A few things here:
For the enum lookup, instead of using next with a generator comprehension, you can use Python's built-in enum value lookup:

try:
    strategy_enum = PsychosocialHarmsStrategy(strategy)
except ValueError:
    strategy_enum = None

Also, the branching logic is a bit hard to follow. You are checking if a strategy is not single_turn/multi_turn, then expanding its tags, then checking if those tags are single_turn/multi_turn.

I think this could be simplified by normalizing everything to base attack types upfront:

base_strategies: set[str] = set()
for strategy in strategies:
    try:
        strategy_enum = PsychosocialHarmsStrategy(strategy)
        base_strategies.update(strategy_enum.tags or [strategy])
    except ValueError:
        base_strategies.add(strategy)

return [self._get_atomic_attack_from_strategy(s) for s in base_strategies]

[jbolor21]

Ah yes okay I think that help, let me know if these changes address your idea fully!

[bashirpartovi]

If you follow my suggestion above, a lot of these if/else checks could be eliminated

[hannahwestra25]

nit: imo the harm_category should just be pyschosocial because it's broader

[hannahwestra25]

same comment as above that I was considering psychosocial to be the harm category and then the strategies are like methods of testing the harm category so each tag doesn't represent a different harm category but a different method (ie strategy) within psychosocial

[hannahwestra25]

i think this should just be imminent_crisis and then the harm category is psychosocial

[hannahwestra25]

similar to this:

PyRIT/pyrit/scenario/scenarios/airt/scam.py

Line 66 in 4a40aa3

ALL = ("all", {"all"})

[hannahwestra25]

same comment as above that I was considering psychosocial to be the harm category and then the strategies are like methods of testing the harm category so each tag doesn't represent a different harm category but a different method (ie strategy) within psychosocial

[hannahwestra25]

Suggested change

	logger = logging.getLogger(__name__)

[hannahwestra25]

why is this specific to crescendo ?

[hannahwestra25]

I'm wondering if we can make the scoring yamls and system prompts broad enough to include all these tests. I think the fact that you're adding the ability for a user to input a custom system prompt and scorer means that the scenario is too broad or undefined (which maybe it is and we could distill it a bit more)

[hannahwestra25]

we shouldn't need both right ? My vote would just be to have a broad system_prompt_path