Decision log vs ADR vs RFC: which to use when
Teams use these three names loosely and often mean the same thing - or run all three and duplicate work. The distinction is actually simple: an RFC happens before a decision, an ADR records the decision itself, and a decision log is the index across all of them.
RFC: the proposal, before the decision
A Request for Comments is a design document written to make a decision: here is the problem, here is my proposed approach, here are the alternatives, poke holes in it. Its job is to gather disagreement early, while changing course is cheap. An RFC is inherently a snapshot of a debate - once the decision lands, the RFC's job is done, and reading it later tells you what was proposed, not always what was decided. Use RFCs when a choice is expensive to reverse and multiple people hold relevant context.
ADR: the decision, on the record
An Architecture Decision Record is written at the moment of decision: context, options, choice, consequences, in under a page. Where an RFC captures the argument, the ADR captures the outcome and the reasoning that survived the argument. ADRs have statuses (accepted, superseded) precisely because decisions get revisited - the record is meant to live with the system, usually in the repository.
Decision log: the index across decisions
A decision log is a running list - a table or register with one row per decision: date, decision, owner, link to the detail. It exists to answer “what have we decided lately?” and “where is the record for X?” at a glance, across a team or project. Logs are common in project management and less common in engineering, where the repo-adjacent ADR folder often plays the role. A log without linked detail decays into a list of conclusions nobody can interrogate; its value is entirely in the pointers.
How they fit together
In a team running all three well: a hard problem gets an RFC; the discussion converges; the outcome is recorded as an ADR that links back to the RFC; and the decision log gains a row pointing at the ADR. Proposal, record, index. Most teams need ADRs first - an RFC process without decision records produces beautifully argued proposals whose outcomes nobody wrote down, and a log without records is a list of unexplained verdicts.
What none of them capture
All three share a failure mode: they only hold what someone remembered to write, at the time they wrote it. The decision made in a pull request thread, the tradeoff accepted in a ticket comment, the assumption that quietly broke two quarters later - none of it lands in the RFC, the ADR, or the log, and the documents do not update themselves when reality moves on. That gap - between the artifacts a team produces and the reasoning those artifacts imply - is what Rationale is built for: it reads RFCs, ADRs, tickets, and pull request discussions as they are written and maintains the decisions, evidence, and supersessions as one connected Decision Map that stays current as the artifacts change.