An engineering decision record is a durable account of what was decided, why it was decided, who had authority and what follows from the choice. A useful record captures the decision context, affected baseline, criteria, alternatives, assumptions, evidence, uncertainty, recommendation, dissent, final rationale and actions. It complements analysis and meetings; it does not replace the underlying calculations, approved change process or accountable engineering judgement.
What should an engineering decision record accomplish?
The record should let a future engineer reconstruct the decision without pretending that today’s knowledge existed at the time. NASA describes decision analysis as evaluating alternatives against the decision-maker’s priorities and state of knowledge, and stresses documenting assumptions, limitations and uncertainty. Its recommended decision report includes context, intended outcomes, criteria, alternatives, methods, results, recommendation and final rationale. See NASA’s Decision Analysis guidance.
A decision record is most valuable when it separates four things that are often collapsed into one sentence: the evidence available, the team’s interpretation of that evidence, the recommendation, and the authorised decision. A decision-maker may choose an option other than the analytical recommendation; the record should preserve that distinction and the rationale.
What belongs in an engineering decision record template?
The following template is ungated and may be copied into the programme’s controlled working environment. Fields marked “not known” should remain explicit rather than being completed with assumed detail.
| Field | What to record |
|---|---|
| Record identity | Stable ID, title, owner, created date, current state and supersession links |
| Decision statement | The single choice the named authority must make |
| Context and intended outcome | Mission or system context, trigger, problem boundary and desired result |
| Affected baseline | Requirement, interface, architecture, product and configuration versions in scope |
| Decision authority | Named person or board, remit and required contributors |
| Criteria and constraints | Measurable criteria, mandatory constraints, weighting method and acceptance rules |
| Alternatives | Options considered, including retain-current-state where credible, and reasons for exclusions |
| Evidence and provenance | Analyses, tests, models, supplier inputs and source revisions used |
| Assumptions and uncertainty | Unverified premises, ranges, sensitivities and evidence that could change the ranking |
| Evaluation and recommendation | Method, results, tradeoffs and the team’s recommended option |
| Decision and rationale | Selected option, decision date, conditions and why the authority chose it |
| Dissent | Material objections, their disposition and any residual concern |
| Consequences and actions | Changes, risks, verification, owners, deadlines and closure evidence |
NASA’s decision-analysis guidance says the rigour of analysis should be proportionate to the consequence and uncertainty of the decision. The same template can therefore support a short engineering judgement or a formal trade study, while the depth of evidence changes with risk.
How should a team complete the template?
- Write the decision as a choice. “Select the flight-computer cooling approach” is clearer than “thermal issue”.
- Freeze the evaluation frame. Record the requirements, configurations, criteria and source revisions used so later updates do not rewrite history.
- Keep evidence separate from judgement. Link measured or calculated results, then state the engineering interpretation and its confidence.
- Expose uncertainty. Record which uncertain input could reverse the ranking and whether more evidence is worth its cost or schedule effect.
- Name authority. Contributors may prepare analysis, but the record should identify the person or board accountable for the final choice.
- Translate the choice into controlled work. Link affected requirements, changes, risks, verification and actions instead of treating “decided” as “implemented”.
NASA’s process explicitly includes criteria, alternative evaluation, uncertainty and reporting to a decision authority. It also notes that the authority remains free to select an alternative or request further analysis. That is why the recommendation and final decision need separate fields.
What does a completed spacecraft decision record look like?
- Record
- EDR-017, Flight-computer standby thermal control, proposed for Baseline C
- Decision
- Select between a thermostatically controlled survival heater, continuous low-power heating and an operational warm-up procedure.
- Context
- A revised cold-case analysis predicts that the computer could begin recovery below its preferred start temperature after an extended safe-mode period.
- Criteria
- Cold-start margin, energy use during safe mode, single-fault behaviour, operational complexity, integration effort and schedule exposure. The systems team identifies safe recovery as mandatory and treats the remaining criteria as tradeable.
- Evidence
- Thermal model TM-22 Rev C, battery-energy analysis EPS-11 Rev B and breadboard heater test TH-08. Each link records the revision reviewed.
- Assumptions and uncertainty
- The cold-case boundary and heater-to-computer thermal coupling remain uncertain. Sensitivity runs show that either could change the margin, but not the ranking under the team’s stated evaluation ranges.
- Recommendation
- The technical team recommends the controlled survival heater because it meets the mandatory recovery criterion with less operational dependence than the warm-up procedure.
- Decision and rationale
- The chief engineer selects the controlled heater subject to closing electromagnetic compatibility testing before release. The decision accepts additional harness and verification work to reduce operational dependence.
- Dissent
- The power lead records concern about safe-mode energy margin. The board retains the concern as an action to update the energy budget before the change order is approved.
- Consequences
- Open a controlled change, update thermal and electrical interfaces, revise the fault-recovery verification plan and supersede EDR-009 when the new baseline is released.
How is a decision record different from minutes, a change request or a trade study?
| Record | Primary purpose | What it does not prove by itself |
|---|---|---|
| Engineering decision record | Preserve the choice, authority, evidence frame, rationale and consequences | That every resulting change was released or implemented |
| Meeting minutes | Record discussion, attendance, decisions and actions from a meeting | That a complete alternatives analysis or controlled change exists |
| Change request | Propose and assess a change to controlled scope or a baseline | That the preferred technical alternative has been authorised or incorporated |
| Trade study | Evaluate alternatives against defined criteria | Which authority selected an option or what implementation followed |
NASA notes that decisions may appear in meeting minutes but should also be captured in the decision report. The record can link to minutes, calculations and trade matrices without duplicating them or losing their revision context.
How should uncertainty, dissent and supersession be handled?
Uncertainty belongs beside the result it affects. Record the uncertain input, its credible range, whether it could change the ranking and the decision to gather more evidence or proceed. Do not turn a point estimate into false certainty.
Dissent is not a failed approval process. Preserve material technical disagreement, the authority’s response and any condition or monitoring action. If later evidence changes the choice, keep the original record immutable and create a superseding record. NASA’s configuration-management guidance identifies change-request dispositions and their rationale as configuration-management work products; preserving the sequence maintains that history.
Where can Arc support engineering decision records?
Arc can configure a typed decision record inside its connected programme model, relate it to requirements and system context, route a scoped decision through named reviews and attributable approvals, and connect approved consequences to controlled engineering changes.
Arc does not make the engineering decision, certify the evidence or supply the programme’s technical authority. The customer defines the record schema, decision rights, required evidence and retention rules. Models, calculations, drawings and signed contractual directions remain authoritative in the systems assigned by the programme.
What should you read next?
Turn an approved decision into controlled work with the ECR, ECO and ECN guide, prepare decision evidence with the SRR, PDR and CDR readiness checklist, and inspect downstream consequences using the requirements change-impact analysis guide.
What are the frequently asked questions?
What is an engineering decision record?
An engineering decision record is a durable account of a technical choice: its context, options, criteria, evidence, assumptions, uncertainty, selected outcome, authority, rationale and consequences. It helps later reviewers understand why the decision was reasonable at the time.
Is an engineering decision record the same as a trade study?
No. A trade study is an evaluation method or supporting analysis. The decision record identifies the actual decision, authority and outcome and can link to one or more trade studies as evidence.
Should dissent be included in a decision record?
Record material dissent, the concern raised, how it was considered and any resulting condition or action. The record should not imply unanimity when the authorised decision was made despite a documented technical disagreement.
Can an engineering decision record be changed?
Preserve the original decision as historical context. If new evidence changes the outcome, create or link a superseding decision record that explains what changed, which earlier decision it replaces and the new consequences.