Playbook and risk based approach

[fdevaulx]

Suggestions from Alex Rebo

2 suggestions, Fred:

1. It seems like by the end of the "Assessment" and "Org Readiness"
   we can assume we have everything necessary to engage in the
   endeavor.
2. By the end of the "Selection" we have everything both
   necessary and sufficient. ​

​3. If we restate every outcome in terms of risks, we would have
one common denominator across all the phases. ​

Every phase in the has outputs and outcomes (and we differentiate between the 2).
However, to measure the success (or fiasco) of a given phase, it's outcomes have to be measurable.
Providing a uniform metric across phases would help compare the results.

​​​The ​​purpose of the p​laybook ​​is to walk the reader through the phases
gradually reducing the risks of failure of introducing BC into his
enterprise.
Ex.: one of the risk mitigation options following the Assessment is
avoidance.

As the reader moves from left to right, the risks are gradually reduced
till they reach an acceptable level.
Hence the suggestion to make outcomes risk based.

Here is my subjective take on BC related risks ​
​(not necessarily a ranked list, ​but reflecting
the gravity perception).

​1. Mismatch / wrong timing
Reason: BC fails to solve existing pressing
biz problems.
Addressed by : Assessment ​

​2. ​​Implementation failure.
Reason: (for any reason) failed implementation
is, likely, to shut the door for any
subsequent BC introduction. ​
​ Addressed by : Readiness, Customization, Selection

3. Immutable garbage
   ​ Reason: while transaction's integrity is not disputed
   (indeed, transaction took place @ between
   participants A & B), however nothing attests the
   integrity of its content.
   Ex.: there is no mechanism in place allowing to
   dispute the nature of the transaction.
   Addressed by : none

4. Ever growing costs
   Reason : the older / longer the chain the more expensive
   is the verification.
   ​ ​Addressed by : none
   ​ (how expensive is ​total consensus :
   what is the work-factor of N ?)

​5. Permanent visibility
Reason : whether private or public, BC exposes
the transaction's history to those
authorized.
Ex.: expunged records still visible,
potentially affecting subsequent
decisions, therefore, effectively
negating "expungement".
Addressed by : none
(encryption protects from prying
eyes, however, it won't address
prejudiced decision making)

6. Interference (this is intentionally selected to avoid
   malicious connotation)
   Reason : interference (for any reason) should only
   be considered in context of the particular
   implementation, as, conceptually (apart from
   key distribution, which is not unique to BC)
   it is perceived as invincible, especially when
   based on the 0KP protocol.
   Addressed by : none

---

How would we express that in the phases?

Let's walk the line and consider the
(potential) problems, which each phase
can (should, IMO) address

1. Assessment
   a. misalignment between BC capabilities
   (due to "b" or otherwise) and immediate
   enterprise needs ;

   b. misunderstanding BC capabilities

2. Org Readiness
   a. organization's EA strategy "rejects" BC
   (for whatever the reason) ;

   b. organization's technology "rejects" BC

   (It would be informational to learn exactly
   why ;
   while both "a" & "b" might be attributable
   to the lack of CBA, there might be other
   reasons, so proper risk mitigation strategy
   can be developed ;

3. Customization
   a. introduction of the inadequately configured
   BC might be both overwhelming and inappropriate
   for both business and technology ;

   b. "champion's" inadequate perception of (possible)
   BC configurations vs needs might pave the road
   to an up-sell.

4. Selection
   a. ...

All these are just an examples

---

Some clarifications on the previous message
4. Ever growing costs
Reason : the older / longer the chain the more expensive
is the verification.
​ ​Addressed by : none
​ (how expensive is ​total consensus :
what is the work-factor of N ?)

​Clarification: consensus is the ratio of the number of "votes" required to
acknowledge the transaction (a block containing that
transaction) ;
Ex.: in the SSA fictitious example all 56 administrative
units needed to approve the issuance / deprecation
of an SSN ;
This is what is called total consensus = 1.

​ Naturally, it is reasonable to suggest some proportional
dependency between the number of participants, N, and the
number of false (intended or otherwise) stmts.
Now the Q: does this affect work factor and if yes, how ?

​5. Permanent visibility
Reason : whether private or public, BC exposes
the transaction's history to those
authorized.
Ex.: expunged records still visible,
potentially affecting subsequent
decisions, therefore, effectively
negating "expungement".
Addressed by : none
(encryption protects from prying
eyes, however, it won't address
prejudiced decision making)

​Another illustrative example would be GDPR Consent​:
"GDPR requires the data subject to signal agreement by “a statement
or a clear affirmative action”". If GDPR is retroactive,
and would be reasonable to assume it should be, then the
ability to permanently remove the pertinent info should
be in place.