![[Clarity#^decisions|Clarity and decisions]] There are many visible symptoms of poor [[Decision making|decision making]] in projects. One of the most obvious appears the moment someone new joins a project. They open the codebase, scan through the architecture, see a few “interesting choices,” and immediately think: ![[Decision log & Onboarding#^symptom|Onboarding]] That reaction rarely comes from incompetence - it comes from the _absence of context_. The decisions behind these choices are unclear, undocumented, or scattered. It’s perfectly natural to want to understand the reasoning… but the moment you try to find answers, you hit the next symptom: ![[Decision log & Single source of truth#^symptom|Single source of truth]] Documentation? Maybe. Meeting notes? Possibly. Slack history? Good luck. The code itself? It shows _what_ was done, not _why_. Eventually, someone will tell you to “just ask X, they’ll know.” But in many long-running projects, the next sentence hits even harder: ![[Decision log & Tribal knowledge#^symptom|Tribal knowledge]] And now you have a real problem. Because as soon as the business comes with a change request, you’re stuck asking yourself: ![[Decision log & Changes#^symptom|Changing past decisions]] You investigate. You trace dependencies. You refactor with extra caution, hoping you’re not undoing something important. After spending hours reconstructing missing context, you finally deploy the change. Then, a day later, frustrated clients report that [[Fragility|something else has broken]] - and someone on the team connects the failure back to your update and asks: ![[Decision log & Ad-hoc changes#^symptom|Ad-hoc change]] And that question reveals something even more important: YOUR decision was made without proper discussion, without aligning with the team, and without surfacing constraints that someone else could have caught much earlier. This leads to the final, most painful symptom of all: > How can we deliver quality if no one understands the full context of the decisions their work relies on? Lack of clarity isn’t just inconvenient - it undermines reliability, predictability, safety, onboarding, architecture, and cross-team collaboration. It creates wasted time, duplicated effort, avoidable regressions, and fragile knowledge held by a few individuals rather than the organization. This is why clarity in decision making matters. Not for the sake of documentation - but for the sake of _collective understanding, continuity, and safe change_.