<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Decision-Records on Derek's Guides</title><link>https://guides.derekleeds.cloud/tags/decision-records/</link><description>Recent content in Decision-Records on Derek's Guides</description><generator>Hugo</generator><language>en</language><lastBuildDate>Tue, 07 Jul 2026 06:48:39 -0500</lastBuildDate><atom:link href="https://guides.derekleeds.cloud/tags/decision-records/index.xml" rel="self" type="application/rss+xml"/><item><title>Architectural Decisions: Writing Down the Why</title><link>https://guides.derekleeds.cloud/docs/infrastructure/architectural-decisions/</link><pubDate>Tue, 07 Jul 2026 00:00:00 +0000</pubDate><guid>https://guides.derekleeds.cloud/docs/infrastructure/architectural-decisions/</guid><description>&lt;p&gt;Most architecture problems are not caused by a bad decision.&lt;/p&gt;
&lt;p&gt;They are caused by a decision that nobody remembers making.&lt;/p&gt;
&lt;p&gt;Six months later, someone asks why the DNS control plane is shaped a certain
way, why Home Assistant is allowed to observe infrastructure but not mutate it,
or why one service stayed in Compose while another moved to Kubernetes. If the
answer is “it was in a chat somewhere,” congratulations: the system now has
load-bearing folklore.&lt;/p&gt;</description></item></channel></rss>