Blog · 2026-06-06 · ~10 min read

Decisions that never get written down: the "not building this" record type

Q: Should I write an ADR for a decision not to build something?

Yes, if the 'no' decision names a rejected proposal that team members are likely to re-propose, creates a constraint on future work, or was reached after deliberation that took more than a few minutes. The ADR tier is appropriate when the constraint is load-bearing — when knowing about it would change a new engineer's behavior. For lighter 'no' decisions (scope trimming, preference calls), the decision log tier is sufficient: a one-line title, the rejected option, and the revisit condition, without full ADR ceremony.

Q: What's the difference between a 'not building this now' and a 'not building this ever' record?

A 'not building this now' record should have an explicit revisit condition — the specific thing that would have to be true before the decision is worth reconsidering (a new API becoming available, the team reaching a size threshold, a cost curve changing). A 'not building this ever' record should have no revisit condition, or a revisit condition that describes a fundamental change in product direction. The practical test: if the constraint that produced the 'no' can realistically go away within 18 months, write a revisit condition. If the constraint is structural to the product architecture or the business model, leave it blank and note why. A deferred decision without a revisit condition defaults to a permanent ban — which is fine intentionally, but often accidental.

Eight months after deciding not to build real-time sync, someone proposed it again. Thoughtful proposal — clear user value, rough implementation sketch, small scope estimate. The engineering team sat with it for a moment. Then someone pulled up the decision log and found a record from Q1: No real-time sync across devices. Rejected because no conversation-history API exists on any major AI platform; any sync implementation would require intercepting network traffic, which is incompatible with the product's client-side-only privacy model. Revisit when: any of the three major platforms exposes a public conversation-history API. The meeting ended in four minutes. The "not building this" record had done its job.

TL;DR

The most valuable and most commonly missing entries in a decision log are the deliberate "no" decisions — the choices not to build something. "Yes" decisions leave artifacts (the code, the deploy, the PR). "No" decisions leave nothing except the reasoning, which lives in a chat session that's impossible to search eight months later. AI chat extraction catches these specifically well because engineers work through rejection reasoning in far more detail in conversation than they would in a formal ADR write-up. Documenting a "no" decision doesn't veto the idea — it raises the burden of proof to the right level. A new engineer who finds one of these records can reopen the proposal with a targeted argument. Without the record, they re-litigate from scratch or never propose at all.

Why "no" decisions vanish and "yes" decisions don't

When you build something, evidence accumulates automatically. The code lands in the repository. The deployment runs in production. The PR review thread discusses the trade-offs. A new engineer who joins six months later can git log --follow a file and see the history. They can read the PR description. The decision to build something is, in a sense, self-documenting — the artifact proves the choice was made, and the artifact's shape encodes some of the reasoning.

When you decide not to build something, none of that happens. There's no commit. There's no deploy. There's no PR. The only artifact of the decision is the reasoning itself — which, in 2026, means a chat session on ChatGPT or Claude. That session lives on a platform that doesn't expose it as searchable text to teammates, can't be grep-ped, and is effectively inaccessible to anyone who wasn't in the original conversation.

This asymmetry is structural. It's not a failure of diligence. Even engineering teams that write ADRs religiously tend to write them for decisions to build things — you write the ADR when you're starting the implementation, as a way to record the thinking before you begin. The "decided not to build X" record has no natural trigger: there's no pull request to attach it to, no sprint to start it in, no deployment to prompt the write-up. The decision happens in a conversation and then disappears.

The result is a decision log that's systematically incomplete in a specific direction: it records what was built, but not what was deliberated and rejected. For a new team member, this creates a false picture of the decision history — every documented choice looks like something the team was confident about from the start, and the rejected alternatives look like things nobody considered.

The re-litigation tax

What happens when "no" decisions aren't documented: the team relitigates.

Re-litigation is expensive in ways that compound. The immediate cost is engineer-hours: the original reasoning has to be reconstructed from memory. The experienced engineer on the team argues from gut intuition — "we looked at this before" — which is technically accurate but not persuasive to someone who doesn't have the history. The proposing engineer argues from first principles, which is usually a well-structured case that addresses every objection except the specific one that was decisive eight months ago. The meeting ends inconclusively, or with a spike to re-evaluate, or with a vague "let's revisit next quarter" that means neither party was satisfied.

The second-order cost is to team trust. The engineer who made the original "no" decision feels like their deliberation is invisible — they know the reasoning is good, but they can't articulate it sharply because they're reconstructing from memory. The engineer who proposed the idea feels like they hit an undocumented veto, like the rules of the game weren't visible before they played. Neither experience builds the culture of documented reasoning that makes a team's decisions trustworthy over time.

The third-order cost is decision quality. The reconstruction is usually incomplete. The decisive objection from the original deliberation — the specific technical constraint, the architectural incompatibility, the business model constraint — rarely survives intact in a reconstructed argument. What survives is the conclusion ("we decided against it") not the mechanism ("because no conversation-history API means any sync implementation requires browser extension network interception, which is incompatible with the client-side-only privacy model"). Without the mechanism, the proposing engineer has no way to know whether their updated proposal addresses the original objection or not.

The 1,200-chats extraction post mentioned one concrete example: a "don't build sync" analysis from eight months prior that stopped a duplicate proposal in a single reference. The record had survived because it was extracted from the original decision conversation. Without the extraction, the analysis would have been as invisible as every other "no" decision made in that period.

Why AI chat captures rejection reasoning better than ADR tooling

The standard advice for documenting decisions is to write the ADR at decision time — ideally before you start implementing, as a lightweight forcing function to articulate the trade-offs before you're committed. This works reasonably well for "yes" decisions. It works poorly for "no" decisions, for a structural reason: you're not typically in "ADR writing mode" when you decide not to build something.

When an engineer decides to build X, they're at the start of an implementation. There's a sprint to plan. There are tickets to write. The decision is the beginning of activity, and the ADR is a record of what that activity is for. The ceremony is proportional to the stakes: a new feature gets an ADR because the implementation cost is large enough to justify the documentation cost.

When an engineer decides not to build X, they're at the end of a consideration. The deliberation happened. The conclusion is "no." The immediate next action is nothing — there's no implementation, no sprint, no activity to record. The ADR has no natural home in the workflow. Most engineers don't write one. It feels like documenting a decision to stay on the couch.

AI chat, counterintuitively, captures rejection reasoning better than ADR tooling because of when and how the deliberation happens. When an engineer is considering whether to build something, the chat session is where they work through the objections in real time — the devil's advocate back-and-forth, the exploration of edge cases, the "but what if we" branching. The rejection reasoning is proportional to how close they came to saying yes. A quick "no, that's obviously wrong" doesn't produce much reasoning in chat. A serious "I spent 45 minutes working through how this would actually work, concluded it's not feasible for these specific reasons" produces exactly the kind of multi-turn, reasoning-dense conversation that the extractor is built to surface.

The WhyChose extractor catches these records through two specific pattern groups: trade-off markers (phrases that indicate the engineer explicitly weighed alternatives) and reversal markers (phrases that indicate the engineer reversed a tentative position). The engineering essay on the extractor's pattern design covers both in detail. The reversal markers group — "actually no, scratch that," "decided against," "won't implement" — is the primary mechanism for catching "no" decisions; trade-off markers are the secondary signal that elevates their confidence score. Together they surface a category of decision that ADR tooling almost never captures.

What a "not building this" record looks like in practice

Abstract descriptions of "no" decision records are less useful than a concrete example. Here's one that closely mirrors the real-time sync example from above:

Title: No real-time sync across devices (v1)
Date: 2026-01-14
Decision: Not implementing real-time sync in v1 or the foreseeable product roadmap
Context: Weekly team discussion on whether cross-device sync should be a table-stakes
  feature for the target ICP (senior engineers, solo-founder CTOs using the
  product across work + personal machines). Approximately 45 minutes of
  deliberation across two chat sessions.
Rejected: Yes, building sync
Rejection reason: No conversation-history API exists on OpenAI, Anthropic, or
  Perplexity as of 2026-01-14. Real-time sync would require intercepting
  platform network traffic (browser extension model), which is incompatible
  with the client-side-only privacy model that the product's core value
  proposition is built on. A sync feature that required a browser extension
  would require abandoning the "nothing sent to a server" positioning — not
  a trade-off this product can make.
Revisit when: Any of the three primary platforms exposes a public
  conversation-history API with user-level authorization. Not on any known
  public roadmap as of this date.

Notice what this record does, and what it doesn't do.

It names the specific technical constraint (no API). It names the architectural incompatibility (browser extension model vs. client-side-only positioning). It provides a revisit condition that's precise enough to evaluate: if the API status changes, the record is immediately relevant again; if it hasn't changed, the record is still valid. And it records the date, so anyone reading it later can assess whether eight months of product and platform development have changed the constraints.

What it doesn't do: it doesn't ban the proposal. A new engineer who wants to reopen the sync question can do so — but now they know what they're arguing against. Their proposal needs to either address the API constraint (perhaps by proposing a polling model that doesn't require a browser extension) or explicitly take on the privacy positioning trade-off with a business case for why the trade-off is now worth making. Either argument is substantive. Neither can be dismissed with "we looked at this."

The format follows the standard Nygard ADR template and slots naturally into a doc/decisions/ repository. For "no" decisions that don't rise to ADR-tier ceremony, the decision log template handles the same four fields in a lighter format.

The "not forbidden, just already decided" property

The most important property of a "not building this" record is what it isn't: a rule, a prohibition, or a veto.

Teams occasionally resist documenting "no" decisions because they're worried about the cultural signal — that writing it down means the idea is closed, forbidden, bureaucratically unavailable. This concern is real enough to be worth addressing directly, because it's the version of the concern that's technically correct (a poorly written "no" record, with no revisit condition and no named constraint, is effectively a prohibition) but leads to the wrong conclusion (don't write the record).

The right framing is that a "not building this" record is a decision, not a policy. It says: "as of this date, given these constraints, we concluded that building this wasn't the right call. Here's what would have to change for that conclusion to be worth revisiting." That framing makes the record a starting point for the next proposal, not a dead end.

In practice, most re-opened proposals die when they hit the original reasoning — not because the record vetoes them, but because the original reasoning still holds. The engineer proposing sync reads the "no conversion-history API" constraint and updates their proposal accordingly. If their proposal addresses the constraint (a new API has been announced), the record's revisit condition is satisfied and the proposal proceeds. If it doesn't address the constraint (the API still doesn't exist), the record has done its job: it raised the burden of proof to the right level without requiring anyone to argue from memory.

The dynamic that creates politics is the one where engineers don't know why an idea was rejected — they make a proposal, get shot down with "we looked at that," and never know whether the objection still applies or whether the team is just resistant to change. Written "no" records with named constraints turn that dynamic into a productive conversation. They make the reasoning transparent and the revisit condition explicit. Engineers who know what they're arguing against can make a targeted case. Engineers who don't know why something was rejected either avoid proposing it (suppressed ideas) or re-propose without addressing the objection (wasted deliberation).

Two types of "no" decisions: deferred vs. permanent

Not all "not building this" decisions are the same, and the distinction matters for how you write the record.

Deferred "no" decisions are contingent on a constraint that can plausibly change. "Not building SSO until we have ten enterprise accounts" is deferred — the constraint is a business scale threshold, not an architectural invariant. "Not building a mobile app until the web product has 500 active users" is deferred — the constraint is a product prioritization decision. These records should have explicit, evaluable revisit conditions. The revisit condition is the load-bearing part of the record: without it, the decision looks permanent even if it isn't, and the team that encounters the record six months later doesn't know whether to treat it as still operative or outdated.

Permanent "no" decisions are structural. "We don't store raw chat transcripts on the server" is permanent — it's a fundamental product architecture decision, not a temporary constraint. "We don't build features that require API keys from users" is permanent — it's a distribution model constraint that's load-bearing across the entire product. These records should have no revisit condition, or a revisit condition that names a fundamental change in product direction (e.g., "if the product pivots away from the client-side-only model entirely"). Writing "revisit when the cost of server storage decreases" for a decision like this is wrong — it implies the constraint is about economics rather than positioning, which changes how future engineers read it.

The practical test is time horizon. If you can imagine the constraint that produced the "no" going away within 18 months without a major product pivot, write a revisit condition. If the constraint is structural to the architecture, the business model, or the product's core value proposition, leave the revisit condition blank and add a note explaining why. A deferred decision without a revisit condition becomes a permanent ban by default — which is fine intentionally, but frustrating when it's accidental.

The ADR vs. Decision Log vs. RFC post covers the artifact format question: which "no" decisions warrant full ADR ceremony, and which belong in the lighter decision log tier. The short version is that permanent "no" decisions are more likely to warrant ADRs (the constraint is load-bearing indefinitely), and deferred "no" decisions are more likely to belong in the decision log (the constraint is time-bounded, lighter format is appropriate).

How to surface these in the quarterly triage pass

"Not building this" records show up differently in the extractor output than "yes" decisions, and the triage pass needs to account for that.

The extractor's confidence scores tend to be lower on negative decisions than on positive ones. The positive-decision patterns — commit phrases like "going with," "decided on," "we'll use" — are stronger signals than the negative patterns — reversal phrases like "decided against," "not going to implement," "too complex for now." This isn't a bug; it reflects that positive commitment phrases are more distinctive in engineering chat than negative ones. The practical consequence is that "no" records often appear in the middle of the triage output, at medium confidence, without the visual salience of the clearly-extracted high-confidence records at the top.

The quarterly triage workflow described sorting records into Promote / Link / Park / Dismiss buckets. For "not building this" records specifically, the guidance is to lower your Promote threshold slightly. The cost of missing a load-bearing "no" decision in the triage pass is higher than the cost of over-promoting a borderline record — because the missed "no" decision will produce re-litigation, and the over-promoted borderline record just produces one more record in the log.

During the triage pass, scan specifically for records with these title patterns:

Titles beginning with "No" or "Not" — "No real-time sync," "Not implementing auth providers yet"
Titles containing "decided against" or "won't build"
Titles containing "deferred" or "too early"
Records the extractor flagged with a reversal marker in the source conversation

For any record matching these patterns, check the extracted rejected-alternatives field carefully. If the extractor surfaced a rejected alternative (in this case, the "yes, build sync" option), the record is probably substantive. If the rejected-alternatives field is empty, check the source conversation — it may be a false positive from a casual mention, or it may be a genuine "no" decision where the extractor missed the rejected option. Use the source-conversation link in the JSONL output to check; the extraction guide covers how to read the output format and trace a record back to its source.

Finally, pay attention to the reversal markers specifically. Reversal markers fire when the extractor detects a mid-conversation flip — "I was thinking we'd build X, but actually no, the constraint is Y." These are disproportionately likely to be "not building this" records, because reversals in engineering chat happen most often when a close call goes "no." An engineer who's never seriously considered building something doesn't produce a reversal marker. An engineer who spent 30 minutes working toward "yes" and then hit the decisive constraint does.

Run the extractor quarterly and look for the "no" decisions specifically. The open-source extractor surfaces both "yes" and "no" decisions from your ChatGPT export or Claude export. MIT-licensed, ~500 lines, runs locally — nothing sent to a server. During the triage pass, lower your promote threshold for records with reversal markers or negative-construction titles. The "no" decisions are the ones most likely to prevent a re-litigation. Join the waitlist for the hosted version with team sharing, Notion and Linear export, and search across all quarters.