Most documentation initiatives fail because they impose a format before anyone has proven the content is worth capturing. We started this one backwards, with no format at all, and it has outlasted several more formal attempts.
What it actually is
A single running document per project where anyone can add a dated, short entry: a decision made and why, an approach tried and abandoned, a surprising thing learned about a dependency or the client's data. No required fields, no review process, no length minimum. The only rule is that it is dated and it is short enough that someone would actually write it.
Why the lack of structure is the feature
Every structured decision log we tried before this — architecture decision records with mandated sections, a wiki page per topic — accumulated entries for the first few weeks and then stopped, because writing a properly structured entry took long enough to feel like separate work rather than a natural extension of the work just done. A two-line dated note takes under a minute and gets written far more often, which matters more than any individual entry being thorough.
What ends up in it
- "Tried X, didn't work, because Y" — the dead ends that would otherwise get rediscovered by someone else, or by the same person, six months later.
- "Client confirmed Z verbally, no ticket needed" — the small decisions that never made it into a formal specification but that someone needs to be able to find later.
- "This dependency behaves oddly under condition W" — the kind of operational knowledge that used to live only in whoever happened to hit the problem first.
Where a model earns its keep here
Searching a year-old, twelve-thousand-word informal log for something relevant to today's problem is exactly the kind of retrieval task a model handles well, better than a person skimming, because the log has no index and was never meant to have one. We treat it as a source the model can search, not a document it writes into — the entries stay human-authored, in the moment, because that is what keeps them honest and short.
The most useful documentation on a project is often the document with the lowest bar to writing in it, not the one with the most complete template.
What we would tell a team starting one
Do not name it anything more formal than what it is. The moment it acquires a template, a required cadence or an owner who reviews entries for quality, it starts costing more than a minute to update, and the entries stop coming at exactly the rate that made it useful in the first place.