> ## Documentation Index
> Fetch the complete documentation index at: https://harisfazillah.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 🏛️ Architecture Decision Records Skill

> Writes and maintains Architecture Decision Records (ADRs) following standard MADR formats to document significant technical choices, tradeoffs, and cons...

## Purpose

The `architecture-decision-records` skill provides a structured framework for documenting significant technical decisions through Architecture Decision Records (ADRs). It captures the context, rationale, trade-offs, and consequences behind architectural choices, ensuring historical clarity and facilitating decision reviews.

***

## When to Write an ADR

Write an ADR when making significant architectural or technological choices, such as:

* Selecting or replacing a database technology, framework, or message broker.
* Adopting a new system-wide security, deployment, or state synchronization pattern.
* Making trade-offs between latency, consistency, complexity, and operational cost.

*Do NOT write an ADR for*: Minor dependency version bumps, bug fixes, or localised code refactorings.

***

## Standard ADR Format (MADR Schema)

```markdown theme={null}
# [Short Title of Solved Problem and Decision]

* Status: [proposed | accepted | rejected | deprecated | superseded by ADR-XXXX]
* Deciders: [List of stakeholders involved]
* Date: YYYY-MM-DD

## Context and Problem Statement
Describe the technical context and the specific problem requiring a decision.

## Decision Drivers
* Driver 1 (e.g. Latency requirements)
* Driver 2 (e.g. License compatibility)

## Considered Options
* Option 1: Description
* Option 2: Description

## Decision Outcome
Chosen option: **[Option 1]**, because [summary of primary justification].

### Positive Consequences
* Consequence 1
* Consequence 2

### Negative Consequences / Trade-offs
* Consequence 1

## Pros and Cons of Options

### Option 1
* Good, because [argument]
* Bad, because [argument]

### Option 2
* Good, because [argument]
* Bad, because [argument]
```

***

## Best Practices

* **Durable Explanation**: Focus on *why* the decision was made given the constraints at the time.
* **Explicit Triggers**: State what conditions or metrics would prompt the team to revisit the decision in the future.

***

*Deep State of Mind (DSOM) For My AI Protocol | Harisfazillah Jamel (LinuxMalaysia) | 2026-09-02*
*Standard: UK English | DBP-standard Bahasa Melayu Malaysia (Piawai) | GNU General Public License v3.0*


## Related topics

- [Zero-Global Memory: The Sovereign AI Memory Architecture](/governance/zero-global-memory.md)
- [📖 DSOM Operational Guide (Level 3 - Specialised Tasks)](/governance/operational-guide.md)
- [🛡️ CRISP² Operational Strategy: The Five Pillars of Persistence](/governance/crisp2-operational-strategy.md)
- [DSOM Cognitive State Preservation & Minimal Downstream Adoption Architecture](/governance/dsom-cognitive-state-preservation-proposal.md)
- [The Deep State of Mind (DSOM) Framework: Defense-in-Depth Architecture](/governance/dsom-architecture-analysis.md)