Trade study from a Notion option list

The problem this solves

Trade studies get built from whatever columns the spreadsheet happens to have, weighted by whoever built it, and produce a total that looks decisive. A requirement violation becomes a low score and gets outvoted by a good score elsewhere. Nobody can say which criterion the result actually turned on, so the study convinces no one at the review.

How it works

Criteria from the requirements, not the columns, and a sensitivity finding that says how much the ranking is worth. Options that violate a requirement are eliminated before scoring rather than losing on points, and the study is willing to conclude that it cannot yet distinguish the top two.

You are building a trade study in the Dalus model [model name] from
options recorded in a Notion database. The point of this workflow is
honest comparison, not a winner. A trade study that hands back a
ranking without showing how fragile that ranking is has told the
engineer nothing they can defend in a review.

CONFIRM FIRST, in one message: which Dalus model; which Notion
database; what decision the trade study supports and which part or
interface in the model it concerns; whether all rows in the database
are candidates or a filtered subset; and whether an existing trade
study in the model should be updated or a new one created. Ask
anything else in the same message. Then begin.

READ NOTION: every candidate row with all its properties, and note
the property types (number, text, select, relation, rollup). Record
which properties are consistently populated and which are patchy,
because a criterion scored from a half-empty column is a criterion
that will mislead. Capture the Notion page URL for each option.

READ THE MODEL: the part or interface this decision concerns, the
requirements allocated to it, the interfaces it must satisfy, the
budgets it draws on (mass, power, cost, volume, thermal) and their
current margins, and any existing trade study covering the same
decision.

DERIVE THE CRITERIA FROM THE MODEL FIRST, not from the Notion
columns. The requirements allocated to this element are the criteria
that actually matter; the Notion columns are the data available to
score them. Present the criteria as three groups:
- Requirements-derived: each traced to the requirement ID it comes
  from.
- Budget-derived: each traced to the budget it consumes and its
  current margin.
- Practical: lead time, supplier risk, heritage, and anything else
  the team scores that the model does not hold.
Where a requirement cannot be scored because the Notion database
does not carry the data, say so and list it as an unscored
constraint rather than dropping it silently.

HARD FILTERS BEFORE SCORING. Any option that violates a requirement
outright is eliminated and reported before the scoring matrix, with
the requirement ID and the violating value. Never let a
requirements violation become a low score buried in a weighted
total, because a weighted total can be outvoted by a good score
elsewhere and a requirement cannot. If applying the filters leaves
one option or none, stop and report that: the decision is already
made, or the option set is inadequate.

PROPOSE WEIGHTS, never assume them. For each criterion give a
proposed weight and one sentence of rationale grounded in something
real: the tightness of the budget margin, the criticality of the
requirement, the stated priority of the decision. Present the
weights for approval before scoring. If the user wants to change
them, rescore rather than arguing.

SCORE, and be explicit about the basis of every score. For each
option and criterion: the value used, its source (the Notion
property, or the model), and whether it is measured, vendor-claimed,
estimated or missing. Vendor-claimed and measured are not the same
evidence and the matrix should show which is which. Where data is
missing, leave it missing and carry it through as missing rather
than substituting a midpoint, which manufactures a result.

SENSITIVITY, and this is the output that matters most. Show how the
ranking changes as the weights move. Name the criteria the result
actually turns on, and the criteria that could be weighted anywhere
without changing anything. State the margin between the top options
in plain terms. If the top two are within the noise of the data
quality, say the study does not distinguish them and name what
additional information would. A trade study whose answer is "we
cannot tell yet, and here is what would settle it" is a good trade
study, and the workflow must be willing to produce one.

WRITE THE TRADE STUDY into the model, gated: alternatives with their
scores, criteria with weights and their traced sources, the cost and
lead time criteria set to minimise, the Notion page URL cited on
each alternative, the eliminated options with their violated
requirements, and the sensitivity finding recorded alongside the
result. Show the full structure for approval before writing.

FINAL REPORT: the eliminated options, the ranking, the sensitivity
finding, the unscored constraints, the criteria whose data was
patchy, and a plain statement of how much confidence the result
deserves. Offer, do not execute: allocating the selected option into
the model as a part, updating the budgets from its values, and
re-running the study when the Notion data improves.

Replace the [bracketed] placeholders with your model and project names.

What you get

Common questions