Rename the section on Backward Compatibility to Forward & Backward Compatibility Add a prolog to that section that defines each and describes FHIR's objectives. Specifically: FHIR strives to be forward-compatible - i.e. Content that is conformant in an old release will remain conformant with future versions. That doesn't guarantee that all old systems will interoperate with future systems. Backward compatibility means that instances created against future versions of the specification will interoperate with older versions of the specification. This is not guaranteed by FHIR, though there are strategies systems can adhere to to increase their changes of such interoperability. Make clear that it is allowed to add new codes, new resources, new operations, etc. If unrecognized codes are found in an element marked as a "modifier", the application should treat the element as an unrecognized modifier. Add a new section on invariants & business rules: We will not generally create invariants or business rules that prohibit "valid" practice from an older version, but we may create invariants that prohibit content where the community consensus is that such content is not (and never has been) sensible. Change "e.g. Operation signatures cannot change; instead..." to "Changes to operations that would violate the preceding constraints will be handled by defining new operations and, potentially, deprecating the old operations." Within the CapabilityStatements for defined FHIR Services or 'core' implementation guides, additional operations may be added. These additions might be optional (MAY/SHOULD) or mandatory (SHALL). Note that the introduction of mandatory operations would break forwards compatibility and will only occur with community consultation. In the terminology section, note that there will be some normative value sets that will break the forwards compatibility rules because they are generated from artifacts that aren't wholely normative. For example, the code system of all resources may have codes that are dropped or renamed if STU or draft resources are dropped or renamed. Indicate that this set of rules applies to content within the core specification as well as to normative IGs published by HL7 International. Implementation Guides cannot change their global profiles When one conformance resource points to another conformance resource, the reference may be changed to point to a newer version of the conformance resource or to a distinct conformance resource so long as the new resource adheres to the compatibility rules with respect to the previously referenced version. 2018-8-01 addendum from FMG: Grahame to draft a process for approving technically breaking changes that are believed not to impact any implementations and submit for review by FMG, MnM and SGB