Skip to content

[Short title of solved problem and decision]

  • Status: [proposed | rejected | accepted | deprecated | superseded by ADR-XXXX]
  • Deciders: [List everyone involved in the decision]
  • Date: [YYYY-MM-DD when the decision was last updated]

Technical Story: [description or issue reference]

Context and Problem Statement

[Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.]

Decision Drivers

  • [driver 1, e.g., a force, facing concern, ...]
  • [driver 2, e.g., a force, facing concern, ...]
  • [...]

Considered Options

  • [Option 1]
  • [Option 2]
  • [Option 3]

Decision Outcome

Chosen option: "[Option 1]", because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force ... | … | comes out best (see below)].

Positive Consequences

  • [e.g., improvement of quality attribute satisfaction, ...]
  • [e.g., easier to test, ...]

Negative Consequences

  • [e.g., compromising one quality attribute, ...]
  • [e.g., operational complexity introduced, ...]

Architectural Invariant Mapping

  • Preserves: [e.g., I2 (Evidence Provenance), I3 (Evidential Independence)]
  • Potential Tensions & Boundary Conditions: [e.g., I6 (Bounded Autonomy) requires strict timeout budget]
  • Empirical Validation Strategy: [e.g., automated regression backtests, chaos canary injections]

Pros and Cons of the Options

[Option 1]

[example | description | pointer to more information]

  • Good, because [argument a]
  • Good, because [argument b]
  • Bad, because [argument c]

[Option 2]

[example | description | pointer to more information]

  • Good, because [argument a]
  • Good, because [argument b]
  • Bad, because [argument c]

TIDIR Architecture — GitHub Project · Apache 2.0 Licensed