Business Strategy as Code
Conventions
Rules across this method carry the key words of Request for Comments (RFC) 2119 (Bradner, 1997), read together with RFC 8174 (Leiba, 2017). A key word carries its special meaning only when set in capitals; each chapter fixes these key words' scope independently of the others, since each chapter stands alone. MUST and MUST NOT mark a requirement: an input or an output that breaks one does not satisfy that chapter's method. SHOULD and SHOULD NOT mark a strong default, departed from only for a good, recorded reason whose consequences are understood. MAY marks a genuine option that chapter neither favours nor discourages. Everything else is informative, including any count an illustration shows.
Two things stay local to each chapter rather than living here: the specific other chapters a chapter's key words are fixed independently of, and the noun a MUST or MUST NOT binds to (a diagnosis, a digital-transformation strategy, an artefact). Each chapter's own §1.2 (or equivalent) states both, and links here for the shared wording above rather than repeating it.
References
- S. Bradner, “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119 (RFC Editor, 1997) — https://www.rfc-editor.org/rfc/rfc2119
- B. Leiba, “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174 (RFC Editor, 2017) — https://www.rfc-editor.org/rfc/rfc8174