Most teams record the decision they made. Few preserve the one they almost made — and six months later, that is often the artifact that matters.
An ADR records where the team landed. An RFC records the live argument: options, rejected paths, and the conditions that would reopen the call. Keep both because they have different readers. The ADR should stay clean enough for someone to understand the current architecture quickly. The RFC should keep the messier reasoning from disappearing.
Put the RFC one step before the ADR. It holds the deliberation while the answer is still "maybe," so the final decision record stays clean and the rejected alternatives survive in a place a future engineer can find them.
The decision you can read, and the one you can't
Open any mature codebase's decision log and you will find a clean list of what the team decided: this database, that router, this auth model. Each entry tells you the destination.
What you cannot see is the wrong turn that saved you. The tool someone evaluated for two days and rejected. The architecture that looked obvious until somebody did the resource math. That reasoning lives in a closed Slack thread, or in one person's head, or nowhere — and it evaporates exactly when it is needed, which is the day a new engineer proposes the thing you already turned down.
An ADR answers "what did we decide." It is structurally incapable of answering "what did we consider and turn down, and would that still hold today." Those are different questions, and the second one is the expensive one to re-answer.
The maybe layer
The fix is a document type that sits one step earlier in the pipeline. In this codebase the pipeline is explicit: idea, then RFC, then ADR, then feature spec.
The RFC is the "maybe" space — the proposal stage, before a decision is yes or no. It holds structured discussion while the answer is still open. The ADR comes after, and only if the decision is architectural. The split is defined by a single sharp test: if you are changing how the system works, you write an RFC; if you are changing what it does, you write a feature spec. When the ceremony applies — and when it does not — is in the next section.
A rejected RFC is a gift to your future self
The incident that made this concrete was a deployment-platform evaluation: a self-hosted web UI over Docker, automatic Git deploys, built-in SSL. The author had used it happily on simpler projects. The question was whether that experience would transfer.
The RFC's answer was no, and the rejection was useful because it did more than say no.
It named three specific conflicts with existing decisions — the reverse-proxy choice, the existing infrastructure-as-code workflow, and the edge-networking model — and explained each as a concrete incompatibility, not a preference. It did the resource math: the new platform would add roughly 1.4 GB of memory overhead on a VPS that didn't have the headroom, which by itself forced a server upgrade the project didn't want. And it cited external evidence — a public discussion thread documenting that the platform's reverse proxy produces redirect-loop errors behind the team's edge-networking setup. Opinion became engineering.
Then it did the part most rejections skip. It wrote a "revisit if" checklist: reconsider this decision if we abandon the edge-networking model, if we abandon the current infrastructure-as-code tooling, if we upgrade to a larger VPS, or if the platform adds support for our reverse proxy. Writing that list felt fussy at the time — four bullets for a decision we were sure about. It was the only part anyone opened six months later.
We rejected the platform in December 2025. By June, three of the four conditions had changed on their own schedule: the project moved off the infrastructure-as-code tooling the RFC named, replaced the edge-networking model, and grew the VPS well past the size threshold. The fourth — the platform adding support for our reverse proxy — had not. That gap matters: you can see which assumption still blocks the old answer without re-running the whole evaluation.
That is not the RFC being wrong. That is the RFC being useful. Because the reasoning was on disk, anyone re-examining the deployment decision today can see precisely which load-bearing assumptions changed — and reopen the question with evidence rather than memory. The rejected reasoning outlived the rejection.
Why the "revisit if" list is the whole point
That checklist is the difference between a decision and a dead end.
A bare "no" rots the moment circumstances change. Six months later someone asks "why aren't we using that platform?" and nobody remembers, so they re-evaluate from scratch and pay the full cost again. A "no" with explicit revisit conditions converts the decision into a tripwire: when one of the named conditions fires, you know the decision is worth reopening, and you know exactly why.
The layers exist for different readers
What actually matters is that the three document types solve three different problems, and blurring them makes every reader do extra work.
An RFC is the place the argument is still allowed to be messy: the options you considered, the paths you rejected and the concrete reasons, plus the short list of conditions that would make you reopen the call. The ADR is the settled record you want a future engineer to read in five minutes without the noise. The feature spec is the contract for what gets built. When one document tries to do two of those jobs, the person who only needs one of them has to wade.
Keeping the stages separate also makes it cheaper to be honest while the answer is still open. Once you have declared a decision final it is awkward to tack on "we seriously considered the other road and here is why it lost." The proposal stage gives the doubt somewhere to live before the verdict is written down.
When I would not write an RFC
The maybe layer is a tax, and on small or reversible changes the tax costs more than the decision it documents. A bug fix, a new feature inside the existing architecture, a single-file refactor — writing a proposal for any of those is ceremony for its own sake, and a team that demands it everywhere trains people to write the document and skip the thinking. That inverts the point. The RFC is reserved for changes whose blast radius justifies writing the reasoning down: adding or removing a technology, shifting an architectural pattern, a schema change that spans features, a breaking API contract.
There is a second, sharper limit. An RFC is only worth its weight if the rejection is honest. A proposal stage used to manufacture consensus — where the "alternatives considered" are strawmen propped up so the predetermined answer looks rigorous — is worse than no RFC, because it launders a foregone conclusion as deliberation. The format does not create candor; it only gives candor a place to live. If the decision is already made, skip the ceremony and write the ADR. The maybe layer earns its keep only when the answer is genuinely still maybe.
What to actually change Monday
You do not need a new tool. You need one document type and one routing rule. Before the next architectural change — a new technology, a removed one, a pattern shift — write a one-page proposal first: the options, the one you recommend, and the alternatives you are rejecting with the reason for each. End every rejection with a "revisit if" list.
Then keep it, rejected or not. The accepted RFCs justify your architecture. The rejected ones stop your team from re-deciding the same question every time the context shifts.
A rejected RFC is not waste. It is how you avoid paying for the same decision twice.
Series linkage
Part 3 of 3 in Gates that make rigor and speed compound. Read in order: schema-aware gates (validate, don't coerce), definition of done (cite an artifact, not a self-assertion), then this piece — the maybe layer before ADRs.
About AmanERP
AmanERP is an ERP for SMBs built in public — rejected proposals included. We treat decision records as infrastructure you can re-read when context shifts. www.amanerp.com