Items from 2021-09-23 meeting

[ahouseholder]

Followup to #149 with a few more items from our conversation this morning.

Vector

• Use ISO 8601 dates in vector representation instead of Unix Epoch Seconds #150
• Vector should include both "simple" and "complex" decision outputs, but without calling attention to which type they are

PDF

• PDF output should have "Recommendation" as the first item under Summary

JSON decision_points

• should allow for "simple" (no dependencies) or "complex" (which depend on answers to other decision points)
• idea: for "complex" decisions, the "options" structure could mirror the decision table structure e.g., a list of items such as { "situated safety impact": "Major", "mission impact":"MEF Failure", "output": "High"}
• should be flat, not nested (i.e., decision_points is just a list of simple and complex things. The complex ones will need to refer to the simple things of which they are composed, but the simple ones don't need to say anything about how they show up in complex things. This should allow more composability without overly increasing complexity in the future.
• Should "complex" types should be composable? I.e., complex(A) depends on complex(B) and simple(C); complex(B) depends on simple(D) and simple(E). This seems like something that's going to come up, although the judges will also accept YAGNI as a counterargument.

[ahouseholder]

If I've missed anything in the above, please either edit the description directly or leave a comment here with additions.

[sei-vsarvepalli]

The current schema allows for a child identifier in the schema itself

SSVC/data/schema/SSVC_Provision_v2.01.schema.json

Lines 59 to 66 in e2d0f0a

	"decision_type": {
	"type": "string",
	"enum": [
	"child",
	"complex",
	"simple",
	"final"
	],

In the new setup, I will get rid of it or basically collapse "child" into "simple" as you guys suggested. Comment if you "disagree" or want to change it.

Currently tree structure also has the "children" which is the recursive decision points the way I explained. But I think the preference is to leave this flat.

SSVC/data/schema/SSVC_Provision_v2.01.schema.json

Lines 69 to 73 in e2d0f0a

	"children": {
	"type": "array",
	"items": { "$ref": "#/definitions/decision_points" },
	"minItems": 1
	}

If I change this, the children will only point to the child either by "shortcut key" decision_point.key or by full decision_point.label using anyOf in JSON schema setup. Just making sure the schema changes are understood and digested.

[sei-vsarvepalli]

Should we preserver also deeper information on choices made by analyst. For e.g., Public Well-being Impact in the current tree is complex and can use multiple reasons for picking a particular "option" . An analyst choosing "Material" option for "Public well-being impact" can be either be due to perceived "Physical harm" to be "Physical distress or injuries for users of the system OR introduces occupational safety haz-ards OR reduction and/or failure of cyber-physical system’s safety margins." or "Financial" harm to be "Financial losses that likely lead to bankruptcy of multiple persons."

[sei-vsarvepalli]

A small schema update is pending for this to be complete. The schema update needs to represent the current efficient way to have child decisions (branches) of an SSVC decision tree to end up with a cumulative path on the decision tree. Hopefully can get that tested next week.

[j---]

We decided that all decisions made by the analyst should be stored.
I think that is implemented in #172 ? Is this issue resolved?

[ahouseholder]

Given @j---'s comment above, I'm going to close this. If there is anything remaining to be done, please open a new issue or discussion as appropriate.