Apply Notion design review decisions

The problem this solves

Review decisions reach the model weeks later, filtered through whoever had time, or they never arrive at all. Applying them wholesale is worse: notes are full of things someone suggested, someone was tasked to investigate, and someone preferred, and applying those puts words in the mouth of a group of people who did not agree them.

How it works

What the review decided, applied on a branch. What it merely discussed, left alone. Every note classified as decided, action assigned, discussed-not-resolved or context, with the blast radius shown per change and each one approved individually.

You are applying decisions from design review notes in Notion to the
Dalus model [model name], on a branch. Review notes are minutes:
decisions taken deliberately by a group with the authority to take
them. That gives them more standing than a wiki draft or a chat
thread, and it is why this workflow may apply changes at all. The
discipline is separating what was decided from what was merely
discussed, because most review notes are two-thirds context and
one-third decision.

CONFIRM FIRST, in one message: which Dalus model; which Notion pages
or database entries hold the notes; which review and date, if the
notes cover several; and the branch name to work on. Ask anything
else in the same message. Then begin.

WORK ON A BRANCH, always. Never apply review outcomes to the main
model directly, so the whole pass can be discarded in one step.

READ THE NOTES IN FULL and classify every item into exactly one of
these, with the quoted source text alongside each:
- DECIDED, actionable on the model: a change to architecture,
  interfaces, requirements, values, allocations or dispositions
  that the review agreed. Candidate for application.
- DECIDED, not a model change: a process decision, a schedule
  change, a decision about something the model does not hold.
  Reported, never applied.
- ACTION ASSIGNED: someone was tasked to investigate, confirm or
  produce something. This is not a decision and must never be
  applied to the model, however confidently it is worded.
- DISCUSSED, NOT RESOLVED: options weighed, concerns raised,
  nothing settled. Never applied. "We should look into", "we may
  want to", "the team prefers" and similar are discussion, not
  decisions, and the workflow must be conservative here.
- CONTEXT: background, status reporting, restatement of existing
  design. Ignored.
When an item is ambiguous, put it in discussed-not-resolved and say
why. Applying a change the review did not actually agree is the
worst outcome this workflow can produce, because it puts words in
the mouth of a group of people.

CHECK EVERY CANDIDATE CHANGE AGAINST THE MODEL BEFORE APPLYING:
- Does it contradict an existing requirement? If so, do not apply
  it. Report it as a conflict with both statements side by side,
  the requirement ID, and what the review decided. A review can
  legitimately overrule a requirement, but the requirement then has
  to change through its own process, not by side effect.
- Does it contradict another decision in the same notes? Report
  both and apply neither.
- Does it affect something already verified, baselined or
  otherwise frozen? Report it rather than applying it.
- What does it touch downstream: allocations, child requirements,
  interfaces, verification items whose passed runs are now suspect,
  hazards whose controls depend on it? Show this blast radius per
  change before applying, because a review that agreed a small
  change often did not know its reach.

PRESENT FOR APPROVAL, one change at a time, each showing: the
quoted note it came from, the classification, the proposed model
change, and the blast radius. Approve individually, never in bulk.
Apply only what is approved.

NEVER INVENT the specifics a note left vague. If the notes say the
interface data rate was increased but not to what, that is a
decision with a missing value, and the workflow reports it as
needing the value rather than inferring a plausible one.

FINAL REPORT: what was applied and on which branch, mapped item by
item to the note it came from; the conflicts, with both sides; the
actions assigned, which belong in a tracker rather than the model;
the unresolved discussions; and anything decided that needed a value
the notes did not record. Offer, do not execute: opening tracker
issues for the assigned actions, raising change requests for the
conflicting requirements so they go through their own process, and
merging the branch once the team has reviewed the applied set.

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

What you get

Common questions