Architecture Decision Record (ADR) Process

Node Docs

Learn about cheqd Product Updates Governance GitHub

Search…

cheqd: Node Documentation

Guides

Setting up a new cheqd node

Setting up and configuring validators

cheqd Cosmos CLI

Building from source

Client-app Identity APIs

Architecture

Architecture Decision Record (ADR) Process

Architecture Decision Record (ADR) Process

This is a location to record all high-level architecture decisions for cheqd-node, the server/node portion of purpose-built network for decentralised identity.
An Architectural Decision (AD) is a software design choice that addresses a functional or non-functional requirement that is architecturally significant.
An Architectural Decision Record (ADR) captures a single AD, such as often done when writing personal notes or meeting minutes; the collection of ADRs created and maintained in a project constitute its decision log.
Rationale
ADRs are intended to be the primary mechanism for proposing new feature designs and new processes, for collecting community input on an issue, and for documenting the design decisions. An ADR should provide:
Context on the relevant goals and the current state
Proposed changes to achieve the goals
Summary of pros and cons
References
Note the distinction between an ADR and a spec. The ADR provides the context, intuition, reasoning, and justification for a change in architecture, or for the architecture of something new. The spec is much more compressed and streamlined summary of everything as it stands today.
If recorded decisions turned out to be lacking, convene a discussion, record the new decisions here, and then modify the code to match.
Creating new ADR
Use the ADR template when creating a new ADR.

Error messages

Next - Architecture

List of ADRs

Last modified 2mo ago

Export as PDF

Copy link

Edit on GitHub

Outline

Rationale

Creating new ADR