Summarizing a conversation between @sei-vsarvepalli and myself earlier today:

1. consider choices as a dict of lists rather than list of single-element dicts; e.g., '''choices = { "exploitation": ["none","poc","active], ...etc '''
2. consider changing the name of the object "choices" in the decision spec to "options" to avoid conflict with the name "choices" in the answers spec
3. allow for out-of-order answers to questions within trees: While it's ok for the order of questions to be consistent in the JSON format that doesn't mean that answers will always answer q1 then q2 then q3 etc.
4. allow for underspecified answers: related to above, it should be possible to say things like "exploitation" = "none" or "poc" but not "active". If each value is a list of values, then this just means the cardinality of the list can be >1 up to the max of all the possible options for that item. Furthermore this just means that a fully-specified answer is a list with cardinality = 1.
5. (moved to Vector docs should specify whether parameter order and inclusion is required  #109) in the vector notation, address underspecification as well: E.g., E:[N,P] for the previous example.
6. (moved to Vector docs should specify whether parameter order and inclusion is required  #109) in the vector notation, consider a wildcard character in place of a full list when a decision is entirely unspecified e.g., X:* instead of X:[A,B,C,D] if X has four options, but X:[A,B] if we know X is neither C nor D.
7. add "key" to the full tree specification to decisions and options to their corresponding short-form key in vector notation. The goal is to allow full parsing of the vector notation to a verbose interpretation given the tree description.
8. (moved to Vector keys should allow more than 1 character #111) We should allow for vector keys and possibly value keys to be more than 1 character. We can declare by convention a preference for single character keys, but being able to accomodate longer ones without having to rev the spec will likely be convenient in the future. We are likely to run out of letters in the decision options first because we're already using a sizable fraction of 26. Within any given decision it's really only necessary that the option values are unique to that decision (i.e., "E:A" is not the same "A" as "D:A", but we can't have two "D:A"s). And it seems like if we have a single decision with >26 options maybe we're doing something wrong.
9. (moved to Vector should indicate which stakeholder tree it addresses #110) vector notation should specify both version and role so it's clear which tree the vector is addressing. Suggest sticking with "/" as field separator, and "k:v" as key:value syntax for these. E.g., /V:2/R:C/
10. (moved to Vector should indicate which stakeholder tree it addresses #110) in the ensuing discussion of the above, we realized we might have a need for tree IDs in the future, to avoid having to rev SSVC just because we change an option in the Coordinator tree for example. That's likely a future request, but I'm noting it here first just to get it written down.
11. While it's not necessary that all the above be addressed to close this issue, if any are left unresolved when this issue is closed, please ensure that they are propagated to new issues so they can be revisited in future revisions. And resolved needn't mean implemented. It could also mean "we thought about it and decided not to". My concern here is just to avoid a situation where we defer an item for the future but it gets closed out in this issue and forgotten. See Vector docs should specify whether parameter order and inclusion is required  #109, Vector should indicate which stakeholder tree it addresses #110, Vector keys should allow more than 1 character #111

Originally posted by @ahouseholder in #65 (comment)