A Business Decision Record (BDR) is a note that says why a business made a call. Not what was decided — the reasoning behind it, so that N months later nobody has to guess.

It is the missing business-side twin of the ADR (Architecture Decision Record), which does the same job for technical choices. Without a BDR, decisions look arbitrary. With one, the why survives even if the decision turns out wrong.

Why not the “what”

The what is already visible. It is sitting in the budget, the contract, the org chart, the product that shipped. What disappears is “why we picked this over the other options” — the part nobody can reconstruct later by looking at the outcome, glorious or disastrous.

Where it belongs

A BDR is a Business domain artifact. It is written by the roles who made the call, and it lives in the Business domain repository, like every other Business deliverable.

IMPORTANT
A BDR is what a BPT Exception lands on when it reaches Business. It is the reason the cascade can name a true origin instead of stopping at an unexplained decision.

What a BDR is not

  • Not the Strategy & Motivation deliverable. That DBJ ADM document holds the standing position of one wheel: the constraints and non-negotiables that govern it. A BDR holds one decision, dated and attributable, with the reasoning that produced it.
  • Not a requirement. Requirements Management chains REQ to REQ. Where a REQ originates in a business call, it references the BDR — the BDR is what the chain points at, never a second chain running beside it.

The record

BUSINESS DECISION RECORD (BDR)
--------------------------------
ID:          BDR-YYYY-NNN
Date:
Authors:     (Who has decided)
Taxonomy:    (Taxonomy layer/domain, e.g. Conceptual/Business)
Status:      proposed | accepted | superseded
--------------------------------
Document sections
--------------------------------
Decision:    (what was decided)
Why:         (reasoning / drivers)
--------------------------------

The Taxonomy field positions the record in the organization’s information space, using the DBJ Taxonomy — the same coordinates as any other deliverable.

Status is the whole lifecycle: a decision is proposed, accepted, and eventually superseded by another BDR. Superseded records are never deleted. The superseded reasoning is exactly what a later exception needs to read.