---
title: "Keep an RFP decision log that preserves what was decided"
description: "Record material bid choices with their evidence, rejected alternatives, authority and conditions. Distinguish approval, application and verified implementation."
canonical: "https://zephior.com/insights/keep-a-decision-log-for-an-rfp"
last-updated: 2026-09-06
---

# Keep an RFP decision log that preserves what was decided

> Record material bid choices with their evidence, rejected alternatives, authority and conditions. Distinguish approval, application and verified implementation.

By [Tony Kim](https://zephior.com/authors/tony-kim). Published 2026-09-06; updated 2026-09-06. 16 minute read.

## Definition

An RFP decision log is a controlled record of material choices made during preparation of a response. Each decision identifies the question, affected scope, alternatives considered, rationale, evidence versions, decision authority, dates, conditions and downstream work. Its history preserves corrections and later changes of decision. A current-state view shows which recorded choices apply to a specified scope and time; it does not grant authority or prove that the response implements them.

## Problem

A meeting ends with agreement on two training cohorts. The minutes say training approved. The method is updated, the price includes two trainer-days, and the schedule still promises one day for all participants. A reviewer cannot tell whether the meeting approved a configuration, accepted its cost, confirmed the room or released the whole offer. One vague line has acquired four incompatible meanings.

## Point of view

Preserve the decision as a specific, evidenced act, then track its effects separately. The fictional Alderfen Controls example follows one conditional choice through approval and partial implementation. This dossier produces the decision record and its current interpretation. It does not establish the organization’s mandates, conduct every options analysis, close the whole issue register or certify draft conformance. Sources were checked on 6 September 2026.

## Record choices that another reviewer must be able to reconstruct

A decision changes what the team is authorized or intends to do within a defined scope. Selecting a delivery configuration, accepting an assumption under stated conditions, declining a proposed deviation or choosing which evidence package to use can merit a durable record. Fixing a spelling error usually belongs in document history. The useful test is the consequence of losing the reasoning, not the length of the meeting.

Keep the unresolved question in the issue register and the work in the action plan. The decision log links them: issue I-6 required a choice; decision D-17 selected an option; actions A-31 to A-33 implement it. These records can share an interface, but their states need separate meanings. Closing a task does not demonstrate that a person with the necessary authority approved the choice.

PM² Guide 3.1, appendix B.10, includes decision details, ownership, decision date, application date, related records and communication recipients. It also permits a reference to meeting minutes. This provides a useful project-record foundation; it does not make everyone present at a bid meeting an authorized approver.

Agree a materiality rule for the bid. Include choices that alter a customer-facing commitment, the approved solution, a significant internal exposure or the basis used by several authors. A decision to retain the existing approach may also be material when a credible alternative was assessed and rejected. Merely writing no change without the question and reason loses the substance.

Assign a custodian who checks completeness and maintains links. The custodian need not own every decision and must not fill missing authority from seniority or familiarity. Where a decision is reported but its approval evidence is unavailable, record that evidential gap. A tidy log with invented certainty is less useful than a clearly bounded reconstruction.

## Make the selected option intelligible without replaying the meeting

Training approved is a topic label, not a decision statement. Identify the bid and lot, the option, the version assessed, what may change and what remains outside the choice. Include conditions in the operative statement, not in an attachment that disappears from search snippets. The reader should be able to distinguish permission to prepare an internal draft from permission to include a commitment in a release candidate.

The AQuA Book’s documentation definitions describe a decisions log containing the choice, when and why it was made, and who decided and signed it off. This analytical guidance supports retaining rationale alongside identity and timing. It does not prescribe the approval chain for a particular supplier’s tender.

Keep the decision’s rationale short enough to inspect and specific enough to challenge. Refer to the underlying analysis for detailed calculations. Name the constraint that ruled an option out and the criterion that distinguished the viable choices. If the decision-maker chose differently from the recommendation, preserve both and record the stated reason. Do not quietly rewrite the recommendation to make the record appear unanimous.

Attach exact evidence references: source identity, version, relevant section and access boundary. An updated document at the same address may no longer show what was known then. Preserve an appropriately controlled version or reliable version reference under the applicable retention rules. Evidence provenance is not permission to publish confidential estimates, personal details or the reasoning of another party.

**Minimum content for a material decision record**

| Record part | What to preserve | Misreading to prevent |
| --- | --- | --- |
| Identity and scope | Stable decision ID, bid, lot, topic and assessed package | A choice for one lot silently applies to another |
| Choice and basis | Selected option, real alternatives, reasons and evidence versions | A topic label stands in for the decision |
| Authority | Required roles, mandate references and approval evidence | The recorder or an attendee becomes the approver |
| Time and conditions | Made, applicable and entered dates; conditions and checker | Recorded or conditionally approved means usable now |
| Effects and history | Action links, implementation evidence and predecessor relations | Approval, completion and supersession share one status |

## Alderfen records why two cohorts were selected

Alderfen Controls is fictional. For its example bid, forty participants must each receive the same one-day training curriculum. The verified buyer instructions allow cohorts on different days. The documented room limit is twenty-four participants. One trainer delivers one cohort per day at an estimated EUR 800 per trainer-day, excluding VAT. These figures cover trainer effort only, not the full offer, room hire or travel.

Analysis T-3 considers one cohort of forty, two cohorts of twenty and four cohorts of ten. The curriculum, available overall delivery window and other technical prerequisites have been checked for the two smaller-cohort designs. Room availability on the selected dates remains to be confirmed. The forty-person option fails the known capacity limit; it is not a cheaper admissible baseline against which the other options must justify themselves.

NASA’s decision-analysis guidance retains options discarded during assessment and distinguishes recommendations from the final decision and rationale. It also captures assumptions and uncertainty. Adapted here, this supports preserving why an option was excluded or not selected without claiming that NASA’s systems-engineering procedure governs procurement approvals.

The team recommends two cohorts. Under Alderfen’s stipulated internal rule, both technical and commercial authorities must approve the same package. They approve D-17: use two cohorts of twenty, with two trainer-days in the estimate, conditional on verified room availability before inclusion in the release candidate. Internal preparation may proceed. The record cites their approvals of T-3 and names the person responsible for checking the condition.

Four cohorts are not rejected as technically invalid. They are a viable design in the assessed context but require four trainer-days without a documented benefit that the decision-makers considered worth the additional trainer cost. That reason belongs in the record. If the buyer later asks for much smaller groups, the changed requirement may justify a different choice without making the earlier record dishonest.

**Fictional T-3 option comparison retained by D-17**

| Option | Trainer-only estimate, excluding VAT | Recorded disposition |
| --- | --- | --- |
| A: one cohort of 40, one trainer-day | 1 × EUR 800 = EUR 800 | Excluded: 40 exceeds the documented room limit of 24 |
| B: two cohorts of 20, two trainer-days | 2 × EUR 800 = EUR 1,600 | Selected conditionally; verify room availability before release-candidate inclusion |
| C: four cohorts of 10, four trainer-days | 4 × EUR 800 = EUR 3,200 | Viable design, not selected: no assessed benefit justifies the extra trainer cost |

## D-17 can be approved while its implementation remains incomplete

Use distinct fields for decision state, applicability and implementation. A proposal awaits a decision. An approved conditional choice has approval evidence but cannot be used beyond its stated boundary until the condition is met. An applicable choice may still be absent from the method or price. A completed implementation action does not settle unrelated release checks. One green status cannot express all of these facts.

After approval, Alderfen obtains documented confirmation that the room is available for the two dates. The named checker records the evidence and confirms that D-17’s stated condition is met. This is condition verification under the original decision, not an invented second commercial approval. If the available room instead has a different capacity, the checker cannot treat a changed design as satisfaction of the old condition.

The method owner updates M-5 to two cohorts of twenty. The estimator updates P-4 to two trainer-days and EUR 1,600 in the trainer-cost component. The schedule owner has not yet corrected S-2, which still shows one day for all forty people. D-17 therefore has two verified implementation actions and one open action. It is neither sixty-seven percent approved nor proof that the offer is ready.

For each action, preserve the affected artifact version, owner, required result and evidence of the check. Reference the broader draft-conformance process for the rest of the response. This log follows the known effects of one choice; it cannot claim that every derivative export or offline draft agrees merely because three named actions were listed.

Communicate the applicable decision and its limits to affected owners through the authorized channel. A receipt confirms receipt, not implementation. If an owner cannot perform an action in time, the decision remains recorded while the unresolved consequence returns to the appropriate control process. Do not erase the approved choice to conceal a delivery problem.

**D-17 after room confirmation, before schedule correction**

| Dimension | Verified state | Remaining boundary |
| --- | --- | --- |
| Decision | Technical and commercial approvals reference T-3 | No approval of the whole bid is implied |
| Condition | Required room availability verified by the named checker | Changed dates or room characteristics require impact review |
| Method action | M-5 checked: two cohorts of 20 | Evidence covers this inspected version |
| Estimate action | P-4 checked: two trainer-days, EUR 1,600 | Trainer component only, not total offer approval |
| Schedule action | S-2 still shows one day for all 40 | Open correction; implementation incomplete |

## Correct the account without pretending the decision changed

Keep when the decision was made, when it became applicable and when the entry was recorded. Include the relevant time zone where time affects interpretation. A decision made yesterday can be entered today with supporting evidence; the entry should not be backdated to disguise the delay. Conversely, today’s entry time does not prove that the decision was unknown to everyone yesterday.

If the recorder typed four cohorts although the authenticated approval clearly says two, append a correction that identifies the prior record, error, evidence, correct value, author and correction time. Preserve the erroneous version for the controlled history. A recording correction does not itself authorize a new service design. If the underlying approval is ambiguous, the custodian needs clarification rather than a confident edit.

W3C PROV-DM describes a revision as a derivation from an earlier entity and supports provenance about records themselves. These concepts help distinguish a revised record from its predecessor. They do not establish that a revised text is substantively correct, approved or legally effective.

A later choice to use four cohorts is different. It needs the applicable decision process and a new decision linked to D-17. State the scope and application point of the replacement. If only the dates change, identify whether the original authority covers that adjustment or a new decision is needed. Do not infer the answer from an edit permission in the document system.

## Retrieve the applicable choice, not the newest row

The history answers what happened; the current view answers what applies to this bid, lot, topic and point in time. Resolve the latter from approved records, their conditions, effective times and explicit replacement relations. A newer draft recommendation is not a replacement. A future-effective approval may belong in the forthcoming view while the earlier choice still governs the current one.

Decisions can have separately replaceable components. A later record might change the cohort dates while leaving the group-size limit intact. Identify the component replaced and retain the surviving constraints. Where two approved records conflict and the scope or precedence is unclear, report the conflict for an authorized determination. Neither recency nor a more senior name is a universal precedence rule.

Historical questions also differ. What did the log contain at yesterday’s checkpoint is a question about the recorded history. What decision applied yesterday, reconstructed from evidence available now is a question about the underlying decision and its application. State which question was answered and which evidence was used. Late evidence must not silently alter an earlier snapshot presented as contemporary.

An agent can extract candidate entries, identify missing fields and calculate a proposed current view. Its output should cite exact records, retain conditional wording and expose unresolved authority or precedence. It may not approve the choice, satisfy a condition by inference, contact a decision-maker or update controlled artifacts without the corresponding authorization. A decision log is an input to action, not a general grant of agency.

## Test whether a new reviewer can explain the choice and its limits

Give a reviewer D-17 without the surrounding conversation. Ask them to identify the selected design, excluded alternative, viable alternative not selected, evidence basis, approval roles, condition and open implementation action. If they cannot, repair the relevant field or link. Adding more meeting notes is useful only when those notes resolve the missing meaning.

Then insert a test proposal recommending four cohorts with a later timestamp. The current view must retain D-17 until an authorized replacement exists. Test a correction to a miscopied date separately from a new date decision. Test an entry for another lot. These cases reveal whether the system understands scope and state or simply displays the latest matching words.

Report completeness with a defined denominator. Five fully evidenced records out of five inspected records is not proof that every material decision has been captured. Reconcile the log with identified issues, approval records and known commitment changes within the review scope. Track unexplained gaps, recording delays and incomplete implementation rather than rewarding a high volume of entries.

The accepted work product is a controlled decision history plus a scoped current-state view, accompanied by its unresolved exceptions. Hand the applicable choices to the baseline and release processes with exact references. Keep protected supporting material behind its access controls. The public method can be fully understandable without exposing a real bidder’s negotiations, internal cost model or individual approvals.

## Useful outcomes

- Material choices distinguished from routine work updates.
- A decision statement that identifies its exact scope and conditions.
- Alternatives retained with the reasons they were not selected.
- Approval evidence separated from the recorder’s account.
- Implementation actions linked without implying completion.
- A current-state view that preserves earlier decisions and corrections.

## Workflow

1. **Identify a material choice.** Select a question whose answer changes a commitment, configuration, accepted exposure or controlled bid direction. Link the originating issue instead of copying its whole history.
2. **Preserve the decision basis.** Record the actual alternatives, evaluation reference, source versions and unresolved assumptions available to the decision-maker. Do not rewrite the rationale using later knowledge.
3. **Verify the decision act.** Separate the recommendation from the choice made. Identify each required authority, the approved package, the evidence of approval and any limits or conditions.
4. **Record dates and effects.** Keep the decision time, application time and entry time distinct. Link required implementation actions, owners, affected artifacts and acceptance evidence.
5. **Control later changes.** Append a supported correction for a recording error. Record a new authorized decision for a changed choice, identifying exactly which earlier component it replaces.
6. **Test the current view.** Retrieve by bid, scope, authority, application time and conditions. Verify that an unapproved newer proposal and an unrelated decision cannot displace the applicable choice.

## Key decisions

- Would losing this choice make the bid’s commitments or reasoning hard to reconstruct?
- Which option was selected, and which alternatives were actually considered?
- What evidence shows that the competent authority made this exact decision?
- Does the choice apply now, later or only after a verified condition?
- Which implementation results remain unverified?
- Is a later entry correcting the account or changing the decision?

## Risks

- The recommended option is reported as approved.
- Attendees are all described as decision-makers.
- A conditional choice becomes an unconditional promise in a summary.
- Rejected alternatives disappear and the rationale cannot be reconstructed.
- A recent proposal overwrites an older applicable decision.
- A completed action is treated as approval of the whole offer.

## Metrics

- Material decisions with complete scope and approval evidence
- Conditional decisions with an identified condition checker
- Elapsed recording delay for verified decisions
- Implementation actions overdue or lacking acceptance evidence
- Current-view conflicts between overlapping decision scopes
- Corrections and supersessions with a preserved predecessor link

## Frequently asked questions

### Does every meeting need a decision-log entry?

No. Record material choices, including a reasoned choice to retain an existing approach. Routine status reports and task updates belong in their own records. A meeting may produce several decisions, none, or only a recommendation awaiting approval.

### Can meeting minutes prove approval?

They can be approval evidence if their authenticity, wording, scope and decision authority are verified under the organization’s rules. Attendance alone is insufficient. Link the exact approved package and preserve any conditions or unresolved dissent.

### Should rejected alternatives remain in the log?

Retain the alternatives actually considered and their dispositions, with a link to detailed analysis where needed. Distinguish an inadmissible option from a viable option not selected. Do not invent alternatives retrospectively to make the choice appear more rigorous.

### Does an approved decision mean implementation is complete?

No. Keep approval, applicability and implementation separate. In Alderfen’s example, the condition is met and two artifacts are updated, but the schedule correction is still open. That is incomplete implementation, not partial approval.

### Can an agent decide which record supersedes another?

It can propose an interpretation from explicit scope, approval, dates, conditions and replacement links. It must expose ambiguity and cite the records. It cannot create authority, resolve disputed precedence or treat a newer unapproved proposal as the operative decision.


## Primary sources

- [PM² Guide 3.1, B.10: Decision Log](https://op.europa.eu/en/publication-detail/-/publication/97cc2f12-c648-11ee-95d9-01aa75ed71a1/language-en), European Commission
- [The AQuA Book: decisions-log documentation](https://www.gov.uk/guidance/the-aqua-book), UK Government
- [Systems Engineering Handbook, 6.8: Decision Analysis](https://www.nasa.gov/reference/6-8-decision-analysis/), NASA
- [PROV-DM, 2.2.2 and 5.2.2: provenance and revision](https://www.w3.org/TR/prov-dm/), W3C


## Related articles

- [Keep every RFP draft on one verified fact baseline](https://zephior.com/insights/keep-every-rfp-draft-on-one-baseline)
- [Set bid escalation rules before the decision window closes](https://zephior.com/insights/define-escalation-rules-for-a-bid)
- [Who can approve a tender contract deviation?](https://zephior.com/insights/approve-tender-contract-deviations)
- [How to close unresolved tender questions before approval](https://zephior.com/insights/close-unresolved-tender-questions-before-release)