Layer 7

Decisions: Architectural choices

What choice was made, why, and what does it supersede?

Canonical path	`decisions/`
Trigger	Architecture decisions, policy choices, trade-offs, reversals, accepted constraints.
Stores	ADR-style records with status, context, decision, consequences, and supersedence.
Avoid	Raw meeting notes and temporary task coordination.
Lifecycle	Prefer superseding records over rewriting accepted decisions.

Architectural choices

Decisions record commitments that should be visible when future work touches the same boundary. They are not meeting notes. They are the durable answer to "what did we choose and why?"

Status values	proposed, accepted, superseded, rejected.
Supersedence	Prefer a new decision that supersedes the old one over editing history in place.
Sync relevance	Decisions 0003 and 0005 point to sync.html for canonical-writer mechanics.

ADR shape

---
type: decision
id: 0005
status: accepted
supersedes: [0003]
date: YYYY-MM-DD
---
# Context
# Decision
# Consequences
# Links

Good decision entry

Decision 0005: Use canonical-writer sync through a bare
repository and post-receive hook so deployed references are
generated from one accepted source of truth.

Poor decision entry

We talked about sync and might use Git.

That is episodic or working memory until the choice, status, and consequences are explicit.