github.com/cosmos/cosmos-sdk@v0.50.10/docs/architecture/adr-template.md (about)

     1  # ADR {ADR-NUMBER}: {TITLE}
     2  
     3  ## Changelog
     4  
     5  * {date}: {changelog}
     6  
     7  ## Status
     8  
     9  {DRAFT | PROPOSED} Not Implemented
    10  
    11  > Please have a look at the [PROCESS](./PROCESS.md#adr-status) page.
    12  > Use DRAFT if the ADR is in a draft stage (draft PR) or PROPOSED if it's in review.
    13  
    14  ## Abstract
    15  
    16  > "If you can't explain it simply, you don't understand it well enough." Provide
    17  > a simplified and layman-accessible explanation of the ADR.
    18  > A short (~200 word) description of the issue being addressed.
    19  
    20  ## Context
    21  
    22  > This section describes the forces at play, including technological, political,
    23  > social, and project local. These forces are probably in tension, and should be
    24  > called out as such. The language in this section is value-neutral. It is simply
    25  > describing facts. It should clearly explain the problem and motivation that the
    26  > proposal aims to resolve.
    27  > {context body}
    28  
    29  ## Alternatives
    30  
    31  > This section describes alternative designs to the chosen design. This section
    32  > is important and if an adr does not have any alternatives then it should be
    33  > considered that the ADR was not thought through. 
    34  
    35  ## Decision
    36  
    37  > This section describes our response to these forces. It is stated in full
    38  > sentences, with active voice. "We will ..."
    39  > {decision body}
    40  
    41  ## Consequences
    42  
    43  > This section describes the resulting context, after applying the decision. All
    44  > consequences should be listed here, not just the "positive" ones. A particular
    45  > decision may have positive, negative, and neutral consequences, but all of them
    46  > affect the team and project in the future.
    47  
    48  ### Backwards Compatibility
    49  
    50  > All ADRs that introduce backwards incompatibilities must include a section
    51  > describing these incompatibilities and their severity. The ADR must explain
    52  > how the author proposes to deal with these incompatibilities. ADR submissions
    53  > without a sufficient backwards compatibility treatise may be rejected outright.
    54  
    55  ### Positive
    56  
    57  > {positive consequences}
    58  
    59  ### Negative
    60  
    61  > {negative consequences}
    62  
    63  ### Neutral
    64  
    65  > {neutral consequences}
    66  
    67  ## Further Discussions
    68  
    69  > While an ADR is in the DRAFT or PROPOSED stage, this section should contain a
    70  > summary of issues to be solved in future iterations (usually referencing comments
    71  > from a pull-request discussion).
    72  > 
    73  > Later, this section can optionally list ideas or improvements the author or
    74  > reviewers found during the analysis of this ADR.
    75  
    76  ## Test Cases [optional]
    77  
    78  Test cases for an implementation are mandatory for ADRs that are affecting consensus
    79  changes. Other ADRs can choose to include links to test cases if applicable.
    80  
    81  ## References
    82  
    83  * {reference link}