A name with possibilities.

A decision sheet you can revisit

This original worksheet uses a few explicit gates instead of an overall score. It is intended for ordinary software selection discussions, not certification or security assurance. The fictional example below demonstrates how an unresolved requirement can change the next action even when one candidate appears more attractive.

Define gates and evidence states

Make a row for each required workflow outcome. Add columns for required or preferred, candidate, evidence source, checked date, result and next action. Use results supported, unsupported or unknown. Supported means the evidence applies to the stated configuration; it is not a promise about all versions. A candidate remains unresolved if any required row is unknown. A preferred row can distinguish otherwise suitable candidates, but should not compensate for a required capability that is absent. Name the person responsible for resolving each unknown.

Work a fictional handoff case

A fictional studio needs file export and reassignment of open requests. It prefers a compact calendar. Candidate Cedar has documented export, but reassignment has not been checked. Candidate Reed supports both required outcomes in the fictional notes, while its calendar is less compact. Cedar is unresolved, not automatically better because its interface is preferred. Reed can proceed to the next review under these assumptions. The next task for Cedar is a reassignment check using a sample request; there is no basis for filling that cell with a guess.

Close the record without erasing it

Record the selected candidate, the version or plan considered, the decision date and the reason. Add a reconsideration trigger such as a changed export requirement or a plan restriction. Preserve the earlier evidence when a later review changes the conclusion. The sheet should explain a decision to someone who was absent from the meeting, including what the team chose not to investigate. That makes future migration discussions more concrete and reduces the chance that a temporary preference is remembered as a permanent technical necessity.

Two gates before a preference — Illustrative reference for SoftwareHawk. The example is fictional. Scroll the diagram horizontally on smaller screens.