Skip to content

README.md

Latest commit

 

History

History
36 lines (24 loc) · 1.8 KB

README.md

File metadata and controls

36 lines (24 loc) · 1.8 KB
Raw

Architecture Decision Records

Each ADR captures one architectural decision that was hard to reverse, had non-obvious tradeoffs, and would be questioned later. Format follows MADR lightly. ADRs are immutable once Accepted — if a decision changes, a new ADR supersedes the old one.

# Title Status Date
ADR-0001 0G Chain (Aristotle) + Phala dstack TDX as the privacy platform Accepted 2026-05-11
ADR-0002 SD-JWT VC for selective disclosure over PCD or zkSNARK Groth16 Accepted 2026-05-11
ADR-0003 Per-receipt RA quote with report_data binding over boot-quote binding Accepted 2026-05-11

When to write an ADR

Add a new file ADR-NNNN-short-slug.md when:

  • The decision affects component boundaries, data flow, or protocol semantics.
  • The decision is hard to reverse (chain choice, credential format, enclave platform).
  • The decision has at least two viable alternatives the team considered and rejected.
  • A future maintainer will ask "why did we do it this way?"

Do not write an ADR for:

  • Library version bumps, lint rules, formatting — these belong in the commit message.
  • Decisions with one obvious answer ("use HTTPS").
  • Implementation details — ADRs are for why, not how.

Template

Copy any of the three ADRs above as a starting point — same MADR-lite structure (Context / Decision / Alternatives Considered / Consequences / References).

Supersession

When a new ADR replaces an old one:

  1. Set the new ADR's Supersedes: field to the old ADR number.
  2. Set the old ADR's Status: to Superseded by ADR-NNNN.
  3. Do not edit the old ADR's body. The historical record is the point.