Abstracting outcome sets

[ahouseholder]

This is an emerging idea, but I wanted to capture it before I forget it (again).

A lot of our decision models are coming down to mapping onto outcome sets having size between 2 and 6 (4 is pretty common). I've run across a situation or two where maybe 7 or 8 might be viable. But what I'm wondering is whether we should just abstract out the outcome sets by size and then let the association of semantics be part of the customization step in adopting SSVC.

So for example, we might just make generic sets:

Cardinality	Generic Options	Example Uses
2	A, B	(No, Yes)
3	A, B, C	(Low, Medium, High)
4	A, B, C, D	(Defer, Scheduled, Out-of-Cycle, Immediate); (Won't, Could, Should, Must), (Low, Medium, High, Critical)
5	A, B, C, D, E	Some IT Service Management SLEs
6	A, B, C, D, E, F	#358
7	A, B, C, D, E, F, G	?
8	A, B, C, D, E, F, G, H	?

So most of the tooling would just operate on generic outcome sets and labels could be a late-binding thing.

I suppose this is more about implementation, tooling, and customization than it is about what decisions SSVC is modeling. But I'll drop it here for comments in the meantime. There's no technical reason that 8 is a limit in terms of generating dummy policies from a decision point group and an outcome set, it's more about the practicality of discriminating that many categories in a decision function that is supposed to be human-comprehensible. So while I expect tooling would be able to handle hundreds or more outcome values, that's way out into probably-bad-process-for-humans territory.

I could imagine the bootstrap process looking like:

• enumerate your outcome categories
• choose the default outcome set that matches the cardinality
• configure labels
• run tools to generate starter policy mapping(s)
• tune policy mapping(s) as needed

But that way the tools don't have to really care all that much about what the outcome set labels are, they just need to know that $A \lt B \lt C \lt D \lt E \lt F \lt G \lt H \lt \dots$ holds then bind the generics to the labels before the output step.

[Crashedmind]

As a user, a large part of the value of SSVC outcomes is that there's some prescriptive guidance / ~SLA (Service Level Agreement) associated with them i.e. it isn't just a score left open for interpretation but an expectation about when it should be fixed ala "Act, Attend...". (Similar commendable pragmatic approach with CISA KEV).

In terms of how I use my SSVC-based DT for Risk Based Prioritization, the value of leaf node is also/more important. The grouping to Act/Attend/... is a convenience for humans. So I use both together e.g. 3-Attend is higher priority than a 10-Attend where in this example 3 and 10 are the numbers of the leaf nodes - starting at 1 for the highest risk leaf node - and there are 10 nodes labeled "Attend".
(This also gives context because it uniquely identifies what path was taken on the tree)

Also, in practice, many users will likely have existing risk prioritization processes/tools and associated levels - and they will map the DT outputs (leaf node numbers, or the grouping) to these (rather than change their existing processes/tools and associated levels to match SSVC levels).

Bottom line: whatever you do here won't work for everyone - so "Act, Attend,...." is pretty good - when used by users in conjunction with the leaf node users can self-serve map to what they want.
The only tweak to the groupings I made was to split out "Act" per #359

https://www.cisa.gov/ssvc-calculator