Project Notes and Decision Memory

By the end of this lesson, you will be able to...

• write a short decision record that preserves context, alternatives, current status, and a revisit condition;

• distinguish a time-bounded project decision from a reusable knowledge note; and

• update or supersede a decision without erasing why the earlier choice was reasonable.

Idea in one sentence: A decision note is useful when it lets a future reader reconstruct what was chosen, why it fit then, what it cost, and what event should make the choice open again.

At the end of her five-day experiment, Mina writes one line in her project notes: “Use quieter notifications during focused work.” The line feels efficient. It records the result and lets her get on with the next task.

Three weeks later, Mina begins a week in which she must respond quickly to a small set of urgent requests. The notification setting now feels unsafe. She remembers that she had compared options, measured task switches, and had a reason for accepting some delay. But the one-line note does not say which messages were allowed through, what the observed cost was, or when she intended to revisit the choice.

Mina is not facing a memory failure alone. She has lost the decision context. To change the setting responsibly, she must recreate a past debate from scraps. A project note earns its maintenance cost when it prevents that reconstruction while remaining small enough to update.

Core Insight

A decision is different from a durable claim. A durable claim says something Mina may reuse across contexts, such as: “A reversible work setting needs its reason and revisit condition.” A project decision says what Mina will do in a particular context: “For this month, use quieter notifications from 09:00 to 11:00, while priority contacts can interrupt.”

The two should link, but they should not collapse into one note. The project record needs dates, constraints, status, alternatives, and a trigger for revision. The durable note needs a general point that can outlive this project. If Mina mixes them, the reusable idea becomes cluttered with expired settings, or the live decision loses the principle that helps her improve it.

Decision memory is the lightweight design that keeps this separation visible. It records enough of the path to support a later revision, not every conversation or thought that preceded it.

The Promise We Need to Keep

Mina needs a notebook that supports change without pretending that its first answer is permanent. When a setting, project convention, or tool choice is revisited, she wants to answer four practical questions:

What did we decide?
What problem and constraint made that choice fit then?
What alternatives and trade-offs did we see?
What event, evidence, or date should make us revisit it?

The word “we” can refer to one person as well as a team. A personal decision can still need memory because future Mina does not automatically inherit the details available to present Mina.

This is not an attempt to create a complete task manager or an organizational knowledge base. The decision record does not schedule every action, capture every meeting, or prove that a choice is correct. It makes the reasoning behind a consequential, revisable choice recoverable.

The Naive Design: Record Only the Outcome

The first design is a log of conclusions:

Decision: quieter notifications during focused work.

This is attractive because it is easy to write and easy to scan. It may be enough for a trivial, irreversible choice whose rationale is obvious and unlikely to change—for example, correcting a typo in a project title.

It breaks for a choice made under competing pressures. Mina's notification setting trades uninterrupted work against responsiveness. The outcome alone cannot tell her whether an urgent request was allowed through, whether the experiment actually measured the risk, or whether the decision was intended as a temporary trial. A later change can therefore look like inconsistency when it is simply a response to new conditions.

The missing boundary is between a result and a decision. A result says what happened. A decision record says what the result meant for a choice, under named constraints.

A Better Boundary: A Small Decision Record

In plain English, a decision record is a short note that makes a choice revisable. In Mina's case, it holds six elements:

status
context and decision to make
options and trade-offs
observations or sources considered
current choice and rationale
revisit condition and links

These are prompts, not a bureaucratic template. Use the smallest amount of detail that lets a future reader answer the four questions above.

• Status tells Mina whether the decision is proposed, active, superseded, or abandoned. It prevents an old experiment from masquerading as current policy.
• Context names the goal and constraint. “Reduce interruptions” is incomplete without “while priority contacts remain visible.”
• Options and trade-offs preserve alternatives that were plausible, not every possibility she could imagine.
• Observations or sources show what informed the choice. They may be synthetic observations from a personal experiment, a source note, a requirement, or an open question. They are not automatic proof.
• Current choice and rationale make the decision legible in one scan.
• Revisit condition and links tell Mina when to reopen it and connect the time-bounded choice to relevant maps, source notes, and durable claims.

Architecture Decision Records (ADRs) use a similar idea in software: capture an important decision together with context and consequences. Mina can borrow the lightweight reasoning pattern without adopting a corporate process or treating every personal preference as an ADR.

Worked Decision: Mina Chooses a Notification Setting

The following observation table is synthetic teaching data. It illustrates how a decision can be grounded without claiming a general fact about notifications.

The table gives Mina a local observation: in this short trial, fewer unplanned switches coincided with more consistent use of a resume cue, and no urgent message was recorded as delayed. It does not establish that the setting will remain safe in a different role, with different contacts, or in a longer period.

Step 1: State the decision and its context

Mina writes a decision note instead of adding another sentence to the experiment log:

Decision: Use quieter notifications from 09:00 to 11:00 on focused-work days.
Status: active trial.

Context: Mina needs a protected block for research and planning, but a small
set of priority contacts may need a timely response.

The phrase “active trial” matters. It says the choice is currently in use but still subject to evidence and changing conditions.

Step 2: Preserve the meaningful alternatives

Mina records only the options that competed seriously:

Option A: mute all notifications
  Benefit: fewer visible interruptions.
  Cost: could hide an urgent request.

Option B: leave notifications unchanged
  Benefit: no new response risk.
  Cost: unplanned switches continue to fragment the focused block.

Option C: quieter setting with priority-contact exceptions
  Benefit: reduces ordinary interruptions while retaining a route for urgent contact.
  Cost: requires maintaining the exception list and checking whether it still fits.

This is not a formal proof that C is best. It makes Mina's preference inspectable under the stated constraint. If an alternative was never realistic, leave it out; a decision record is not a museum of discarded thoughts.

Step 3: Connect evidence, uncertainty, and choice

Mina then records the evidence she actually has and its limit:

Observed in this five-session trial: 12 unplanned switches before the trial;
4 during it; no recorded delayed urgent message.

Decision: choose Option C for the next two weeks.
Rationale: the trial supports trying a quieter setting, while priority-contact
exceptions keep the main response risk visible.

Uncertainty: five sessions do not show how this works during on-call duty or
when the priority list changes.

The distinction matters. The observations are local and time-bounded. The rationale is Mina's current interpretation of them. The uncertainty names the condition that could make the choice wrong for the next context.

Step 4: Add a revisit condition and links

Finally, Mina gives future Mina a way to reopen the decision:

Revisit when: an urgent message is delayed, Mina starts on-call duty, or the
two-week trial ends.

Links:
- map: Restarting focused work without losing urgent messages
- experiment: Notification settings trial
- durable claim: A reversible work setting needs its reason and revisit condition
- source note: the passage that prompted this decision-record pattern

The links have different jobs. The map explains where the decision fits. The experiment preserves the detailed observations. The durable claim transfers the lesson to a later project. The source note lets Mina inspect where one supporting idea came from. None of these links replaces the decision record's own statement of context and status.

Step 5: Supersede instead of silently overwriting

When Mina begins on-call duty, the revisit condition fires. She changes the setting and writes a new decision record:

Decision: pause the quieter setting during on-call duty.
Status: active.
Supersedes: quieter-notifications trial.
Reason: the previous record identified on-call duty as a condition outside
the five-session trial.

She marks the earlier record superseded; she does not erase it. The former decision documents why a quieter setting was reasonable under a different constraint. The new one records what changed. This small history prevents churn because it distinguishes new evidence from a forgotten old debate.

So far: Mina has not made the notebook decide for her. She has made the decision's state, rationale, alternatives, and revision trigger inspectable. That is enough to support change without filling the project with retrospective prose.

Operational Consequences

Before using decision memory, Mina might store a result in a task list and discover the rationale only after a problem returns. After it, she can treat certain choices as compact objects with a status and a revisit path.

Use a dedicated record when a choice has at least one of these properties:

• it is difficult to reverse or costly to revisit;
• it trades one valued outcome against another;
• it depends on evidence, a source, or an assumption that could change;
• it needs to remain intelligible after a project pause or handoff; or
• it establishes a temporary convention that could become stale.

Do not create one for every task. “Send the draft Tuesday” belongs in an action system, not a decision record. “Use this source for an argument” may belong in a literature note unless choosing it constrains a project in a way that later needs explanation. The form follows the cost of reconstructing the decision, not the charm of the template.

Trade-offs, Limits, and Signals

Decision memory improves continuity and makes a reversal easier to explain. It costs time at the moment of choice, and it creates an obligation to update status when conditions change. A dense template can create false rigor: a full page of sections does not make a weak choice well supported.

This design helps when a project contains decisions whose rationale will matter later. It does not replace source evaluation, project planning, collaboration agreements, or writing for an external reader. It also cannot guarantee that Mina notices every changed condition.

Watch these signals:

• Outcome without rationale: the note says what happened but not why the choice fit its constraints. Add the decision context and trade-off.
• Active decision with expired assumptions: a known trigger occurred, but the record still says active. Revisit or supersede it.
• A durable note full of dates and settings: project history has leaked into a reusable claim. Move the time-bounded details into the project record and link them.
• A record with every possible option: documentation is crowding out use. Keep only alternatives that genuinely competed.

The important trade-off is between fidelity and maintenance. More context makes a decision easier to reconstruct, but too much context makes records expensive to create and read. The right amount is enough to justify the choice and identify its revision trigger.

Check Your Understanding

Check: Mina writes, “Turn notifications off during focused work.” Which missing field most directly prevents the note from becoming stale when her role changes?

A. A larger list of tags.

B. A revisit condition such as on-call duty, a delayed urgent message, or the end of a trial.

C. A daily flashcard that asks Mina to repeat the setting.

D. A paragraph describing every notification she received that month.

Think first, then reveal.

Answer: B. A revisit condition names an event that should reopen the choice. Tags help grouping, flashcards help certain recall tasks, and exhaustive history adds cost without necessarily defining when the setting no longer fits.

Check: Which item belongs in Mina's durable knowledge note rather than only in the project decision record?

Think first, then reveal.

Answer: “A reversible work setting needs its reason and revisit condition.” It can guide future decisions. “Use quieter notifications from 09:00 to 11:00 for the next two weeks” is a time-bounded project choice and should stay in the decision record, linked to the durable claim.

Practice: Record One Reversible Choice

Choose one real or fictional reversible choice: a study routine, a project convention, a travel plan, or a work setting. Write a decision record with:

status
context and constraint
two or three serious options with a trade-off
observations, sources, or assumptions considered
current choice and rationale
one revisit condition
one link to a durable claim, source, map, or experiment

A good record should make a future reader able to see why the choice fit at the time, what could make it stale, and which note to open next. It should not try to prove the choice was universally correct or capture every action around it.

For a self-check, imagine the original constraint changes tomorrow. Can you tell whether to keep, revise, or supersede the decision without reopening the entire project history? If not, add the missing context, alternative, or revision trigger.

Resources

• [ARTICLE] MADR: Markdown Architectural Decision Records — Focus: Examine how a lightweight record separates status, context, options, decision, and consequences; adapt only the parts your decision needs.
• [ARTICLE] Architecture Decision Record examples — Focus: Compare consequential decisions with small, temporary, or already-covered choices that may not need a separate record.
• [ARTICLE] Andy Matuschak: Evergreen notes — Focus: Compare a reusable claim with a project-specific decision that should link to, rather than overwrite, the claim.

Key Takeaways

• A project decision records a time-bounded choice; a durable note records a reusable point. Link them, but do not merge their jobs.
• A compact decision record needs status, context, serious alternatives, supporting material, rationale, and a revisit condition.
• Local observations can inform a decision without proving a general rule; name their scope and uncertainty.
• Superseding an old decision preserves why it once fit and makes later change intelligible.
• More documentation is not automatically better. Keep enough context to reconstruct and revise the choice, then stop.