Reframe Decision Points as first-order objects in SSVC

[ahouseholder]

Building off of discussion #289, it seems like we are shifting towards making Decision Points be the first-order objects in SSVC.

We will need to update the documentation to reflect that, and there will be implications for the json schema definitions and code as well.

Roughly speaking,

• Decision Points should be versioned objects following rules like those outlined in discussion What are the versioned objects in SSVC? #289.
• Decision functions (trees) are pinned to specific versions of specific Decision Points
• Outcomes (not the policy mapping, but the enumerated vocabulary) should probably be similarly versioned, I think. That might warrant a separate discussion.

We'll need to flesh out this issue with specifics, but for now I'm just capturing it to have something on record.

Also related: issue #252

[j---]

Is our first task to decide exactly the versioning rules we want to use?

[laurie-tyz]

Decision Points.pptx
This is my thinking of the decision points.
Laurie

[ahouseholder]

Decision Points should be versioned objects following rules like those outlined in discussion #289.

• addressed by add ADR proposals for decision point versioning. #350, which added ADR-0002
• addressed by Add Decision Point Group Versioning ADRs #368, which added ADR-0006

Decision functions (trees) are pinned to specific versions of specific Decision Points

• addressed by Add Decision Point Group Versioning ADRs #368, which added ADR-0004 and ADR-0005

Outcomes (not the policy mapping, but the enumerated vocabulary) should probably be similarly versioned, I think. That might warrant a separate discussion.

Not yet addressed by a PR.

Remaining items for this issue:

• create an issue/PR if needed to address outcome set versioning
• identify where/how to update docs/**/*.md with words clarifying this "shift" in emphasis

[ahouseholder]

I think this issue is partially addressed in each of:

• Revise topics/ home page #424
• Add building block analogy explainer #447

and that, taken in combination, this issue can be resolved once #447 is merged.