# The Useful Margin — full text

> The Useful Margin is an independent guide to personal decision logs, note review, and lightweight knowledge habits. It is not a software company, productivity service, coaching practice, records custodian, or continuation of any former organization associated with this domain.

# How to Organize a Backlog of Notes Without Losing Context

> Organize an older notes backlog by defining a small collection, recording its original locations and reviewing one bounded batch at a time. Give each item a disposition or an explicit unresolved question, then leave a precise restart point. Separate this catch-up work from current commitments. Preserve originals and follow applicable ownership, access and retention rules; a cleanup is not permission to delete protected records or upload them to another service.

Source: https://wyllis.com/clear-notes-backlog/  
Publisher: The Useful Margin  
Published: 2026-09-10  
Updated: 2026-09-10

## How do you organize a backlog of notes?

Organize an older notes backlog by defining a small collection, recording its original locations and reviewing one bounded batch at a time. Give each item a disposition or an explicit unresolved question, then leave a precise restart point. Separate this catch-up work from current commitments. Preserve originals and follow applicable ownership, access and retention rules; a cleanup is not permission to delete protected records or upload them to another service.

An old notes folder can contain unfinished actions, useful references, abandoned ideas and records that must remain intact. Treating all four as “clutter” makes the first decision too large.

The method below is an original editorial workflow for ordinary notes. Its fictional batch demonstrates accounting and follow-through, not a tested processing speed or a promise that every archive can be cleared in an afternoon.

## Why give the backlog its own session?

Your [weekly notes review](/weekly-notes-review/) keeps current commitments visible. A backlog session answers a different question: what remains worth retrieving or acting on in a defined older collection?

David Allen's [published catch-up transcript](https://gettingthingsdone.com/2020/04/catch-up/) suggests using available time to bring neglected material up to date. We take that limited prompt as a starting point, not evidence for a prescribed timer or productivity result. Our batch ledger is not a reproduction of a GTD checklist.

Keep incoming notes on their usual review route while you work through older material. If an urgent commitment is already known, handle it through the appropriate current process; do not wait for an archive cleanup to reach it.

The backlog list is a boundary around work, not a declaration that everything inside can safely wait.

## What belongs inside the first batch?

Choose a collection you can describe without “everything.” For example: ordinary personal project notes in one folder from a stated month. Avoid starting with a whole shared drive, every device or a mixture of work and private records.

Make a small collection card:

```text
Collection:
Original location:
Included dates or subject:
Excluded material:
Person authorized to organize it:
Applicable storage or retention requirements:
Batch identifiers:
Next item to inspect:
Unresolved questions:
```

Record locations or authorized links rather than copying every document into a new collection. Do not move protected work files into a personal notes app to simplify the view. If ownership is unclear, ask the responsible person before reorganizing.

A batch can be smaller than the whole collection. “Items B01–B12” gives this example a finite boundary; twelve is a teaching choice, not an ideal number.

## What should you preserve before reorganizing?

Keep the original note and its context available. In the review ledger, distinguish the note's date from the date you reviewed it. Preserve a useful source link, attachment relationship or page reference when that is what makes the note understandable.

The [Library of Congress guide to personal digital records](https://digitalpreservation.gov/personalarchiving/records.html) points out that drafts can contain details absent from final versions. It also recommends describing an organized collection. That supports asking what a version contributes rather than assuming the newest document contains everything.

For your own ordinary files, check that appropriate backups exist before making authorized changes. For organizational records, follow the approved process instead of creating an extra personal copy. This article does not prescribe a backup configuration or certify a storage service.

An archive label changes how you find something. It does not establish that the material is backed up, legally disposable or safe to expose.

## Which questions should you ask about each note?

Read enough to decide what the item requires, not enough to complete the project described inside it. Use these original routing questions:

| Question | Possible disposition | What to record |
|---|---|---|
| Does this contain a current commitment? | Route a next action | Owner, actual next step and source reference |
| Does it explain a choice worth retaining? | Link to a decision record | Which choice and what context it adds |
| Is it useful reference without current work? | Give it a retrieval destination | Topic, location and reason to retain |
| Is it no longer active but still needed? | Retain outside the active view | Reason and applicable review or retention rule |
| Is ownership, meaning or retention unclear? | Mark unresolved | Exact question and responsible person |

Do not force every item into the first row. A reference article is not automatically a task to read; an idea is not automatically a commitment.

Likewise, “done” is too vague for the ledger. An item can be reviewed and routed while the underlying task remains unfinished. Name the disposition so a future review does not mistake organization for execution.

## How does the twelve-note example work?

Everything in this example is fictional. The identifiers represent twelve ordinary notes in their original locations, not files that we accessed or changed.

At the end of a first pass, the ledger shows:

| IDs | Count | Review result |
|---|---:|---|
| B01–B04 | 4 | Current actions identified and routed with source references |
| B05–B07 | 3 | Reference destinations recorded |
| B08–B09 | 2 | Retention or ownership clarification needed |
| B10–B12 | 3 | Not yet examined |

The accounting is 4 + 3 + 2 + 3 = 12. Nine notes have been examined; seven have a resolved routing decision. Two examined notes remain blocked, and three have not been read.

Those are different progress measures. Saying “nine cleared” would hide the two unresolved questions. Saying “four tasks completed” would also be wrong: the table records routing, not task completion.

The restart note says: “Begin with B10. Separately await the owner clarification for B08 and B09.” That is more useful than “continue cleanup.”

## What happens in the next pass?

Suppose the next session examines B10–B12:

- B10 contains a current action and receives an owner and source pointer.
- B11 is reference material and receives a destination.
- B12 requires an ownership check before any change.

The updated ledger has five action routes, four reference routes, three unresolved items and no unread items. The sum is 5 + 4 + 3 = 12.

Now all twelve have been examined, but only nine have resolved dispositions. The three unresolved items are B08, B09 and B12. Their originals remain unchanged.

Do not manufacture completion by moving those three into an “archive” folder. Ask the named owner the specific question. Keep the batch open until the questions are resolved, or transfer responsibility through an acknowledged handoff that preserves their unresolved status.

## What should you do with apparent duplicates?

Compare purpose and context before treating files as interchangeable. Similar titles do not establish identical contents. Identical text does not establish identical obligations.

The [U.S. National Archives' Records Basics guidance](https://www.archives.gov/records-mgmt/scheduling/basics) explains that, in federal records management, a copy may itself be a record because of its use and purpose. That is a federal context, not a universal rule for every personal notebook. It illustrates why “copy” alone is an inadequate disposal decision.

For ordinary notes you own, record a candidate duplicate and the maintained reference before considering removal. Check attachments, annotations and links. Where retention, evidence or ownership is uncertain, preserve the item and ask the appropriate records owner or adviser.

Do not apply an age cutoff or a bulk-delete rule from this article. It supplies no disposal schedule. A folder that looks redundant can still carry information that another authorized person needs.

## How do you stop without losing your place?

Leave both a location and a status. A useful stopping note names the next unread item, the unresolved items and the actions already routed elsewhere.

For our example:

```text
Batch: B01–B12
Examined: 12
Resolved routing decisions: 9
Unresolved: B08, B09, B12
Next step: obtain the recorded ownership/retention clarifications
Originals: unchanged
Underlying tasks: tracked separately; not marked complete here
```

This is a proposed record, not evidence that a real cleanup happened. It avoids a common ambiguity: an empty unread column does not necessarily mean the batch is finished.

If you choose a time limit, treat it as your own scheduling boundary. There is no need to claim that a particular number of minutes suits every note. Stop earlier if resolving one item would require authority, specialist advice or access you do not have.

## What is the final retrieval check?

Before closing a resolved batch, try to locate one routed action's supporting note, one retained reference and any decision context that was linked. Use only material you are authorized to access.

If an action depends on a choice, connect the explanation to the [decision-log method](/keep-useful-decision-log/). Keep new filenames and elaborate tagging outside this session unless a specific retrieval problem requires attention.

Add the next bounded batch to your [weekly-review planning](/weekly-review/), while leaving current commitments visible in their normal system. Do not let the backlog ledger become a second hidden task manager.

The useful result is not fewer files at any cost. It is a collection whose retained items can be found, whose actions have somewhere to surface, and whose unanswered questions remain honestly unanswered.

## Sources

- [David Allen Company: Catch Up transcript](https://gettingthingsdone.com/2020/04/catch-up/) — the limited catch-up prompt, published in 2020.
- [Library of Congress: Keeping Personal Digital Records](https://digitalpreservation.gov/personalarchiving/records.html) — value of drafts and collection description.
- [National Archives: Records Basics](https://www.archives.gov/records-mgmt/scheduling/basics) — copies and record purpose in the expressly federal context.

Primary pages opened and read September 8, 2026. Batch identifiers, counts, routing tables and stopping notes are original fictional examples, not a reported trial.

## Frequently asked questions

**Should I clear all my old notes during the weekly review?**

Give older catch-up work a separate boundary so it does not displace current commitments. Select a defined collection and leave a restart point when you stop. Known urgent obligations still need their appropriate current process. The backlog method is not a reason to postpone them until an entire archive has been examined.

**Does reviewing a note mean the task inside it is complete?**

No. The ledger distinguishes examining a note, resolving its destination and completing any underlying action. Routing an action to an owner is not evidence that the owner performed it. Keep the work in the actual task system and preserve a reference to the note that explains its context.

**Can I delete older copies once I find a final version?**

Not automatically. Compare contents, attachments, annotations, purpose and applicable retention or ownership requirements. A draft can retain information absent from a final version. This guide supplies no disposal schedule. Preserve uncertain material and ask the responsible owner or qualified adviser rather than treating age or a filename as permission to delete.

**What should a backlog stopping note include?**

Identify the batch, the next unread item, any unresolved questions and the person responsible for each clarification. Distinguish resolved routing from task completion. If every item has been examined but questions remain, state that plainly. A restart note should preserve the work's status, not make an unfinished batch appear closed.

**Should I move everything into one app before sorting?**

Not as a prerequisite. Start with an inventory of original locations and authorized references. Moving shared or protected records may require permission and can affect access or links. Follow the controlling storage and retention process. A general cleanup does not authorize uploads, personal copies, bulk moves or changes to another person's records.


---

# File Naming Conventions for Notes: A Practical Guide

> A useful naming convention for notes puts a meaningful subject, a clearly defined date and any necessary version in a consistent order. Choose the first field according to how you expect to find the note: by time or by topic. Keep file extensions intact and document your abbreviations. For shared or protected records, follow the responsible owner's rules; do not bulk-rename files or assume existing links will survive.

Source: https://wyllis.com/file-naming-conventions-for-notes/  
Publisher: The Useful Margin  
Published: 2026-09-09  
Updated: 2026-09-09

## What makes a useful file-naming convention for notes?

A useful naming convention for notes puts a meaningful subject, a clearly defined date and any necessary version in a consistent order. Choose the first field according to how you expect to find the note: by time or by topic. Keep file extensions intact and document your abbreviations. For shared or protected records, follow the responsible owner's rules; do not bulk-rename files or assume existing links will survive.

The purpose is recognition, not a perfectly uniform archive. A filename should help you distinguish the note you need from a nearby note that sounds almost the same. It does not have to summarise the document.

The method below is an original, tool-neutral planning exercise for ordinary notes. It draws on institutional file-organisation guidance without turning those institutions' local rules into universal requirements. No reader files were renamed, and no notes app was tested.

## Should the subject or the date come first?

Begin with a retrieval question, not a punctuation rule. Will you remember the week when you wrote something, the project it concerned, or the type of record?

[MIT Libraries' research-data guidance](https://libraries.mit.edu/data-management/store/organize/) recommends planning names and folders around later retrieval and considering sorting when choosing the first filename element. That is research-data guidance; our examples adapt the principle to personal notes.

| What you expect to ask later | Possible naming order | Main limitation |
|---|---|---|
| What did I record that day? | Date, subject, note type | Notes on the same subject can be separated by other subjects. |
| What have I recorded about this project? | Subject, date, note type | A whole-week view may require a separate search or index. |
| Which record did the other note reference? | Stable identifier, short subject | The identifier needs an index or enough accompanying context to be understandable. |

Choose one principal route for a small collection. A meeting notebook and a research archive need not use identical names if they answer different questions. Write down the distinction rather than letting each new note establish its own rule.

## What does the order change in a concrete example?

Here are six fictional filenames, shown in ascending lexical order. Cedar and Orbit are invented project labels, not actual organisations. The suffix v01 is simply the initial revision label in this example.

A date-first collection looks like this:

```text
2026-09-08-orbit-meeting-v01.txt
2026-09-08-orbit-research-v01.txt
2026-09-09-cedar-meeting-v01.txt
2026-09-10-orbit-meeting-v01.txt
2026-09-11-cedar-research-v01.txt
2026-09-12-orbit-research-v01.txt
```

Put the subject first and the same six records sort this way:

```text
cedar-2026-09-09-meeting-v01.txt
cedar-2026-09-11-research-v01.txt
orbit-2026-09-08-meeting-v01.txt
orbit-2026-09-08-research-v01.txt
orbit-2026-09-10-meeting-v01.txt
orbit-2026-09-12-research-v01.txt
```

The first arrangement groups the two September 8 notes together. The second groups the two Cedar notes together and the four Orbit notes together. Neither creates more information: both contain six records, with the same subjects, dates and types.

We checked this ordering by sorting the illustrative strings in memory. That verifies this lexical example, not how a particular app displays notes. A program may instead be showing modified dates, pinned items or another selected order. Inspect its actual view before expecting the filename's first field to control it.

## Which date belongs in the name?

Define the date before choosing its format. A meeting date, writing date and period covered can all be useful, but they answer different questions.

For example, a note written on September 10 about a September 8 meeting could use September 8 if the convention means “event date.” Record the writing date inside the note when it matters. Do not switch to September 10 merely because the note was typed later.

[MIT Records Management](https://libraries.mit.edu/records-management/tips-best-practices/file-creation/) recommends year-month-day dates and numbered draft versions in its file-naming guidance. A consistent date representation is useful here, but it cannot resolve an unknown date. Do not invent a day to make a filename fit the pattern.

For a weekly summary, define whether the date means the week's starting date or the review date. Put the covered interval inside the note. If you routinely need both, use an index with separate fields instead of forcing every date into the filename.

A date in a name is a label chosen under your convention. It is not independent evidence that an event happened, an approval was given or a record became effective then.

## How much context belongs in a filename?

The [Smithsonian Institution Archives' electronic-file guidance](https://siarchives.si.edu/what-we-do/setting-electronic-files) explains how meaningful folder names can supply context while individual names identify particular files. It also discusses consistent vocabulary and abbreviations. These are organisational principles, not a requirement to copy Smithsonian storage arrangements.

Ask what context would disappear if someone encountered the note outside its usual folder. A filename such as `meeting-v01.txt` may be clear in one location and ambiguous in a mixed search result. A short subject label can preserve the missing distinction.

Use terms you would actually search. If your notes alternate between “launch,” “release” and “go-live” for the same project, decide whether those mean the same thing. Document the chosen term or record the alternatives in an index. Do not quietly combine terms that represent different events.

Keep confidential information out of filenames and broad indexes. A descriptive title does not need a diagnosis, private account number or another person's sensitive details. Use approved systems and access arrangements for protected material; naming consistency is not a privacy control.

## How do versions differ from stable identifiers?

A version label distinguishes revisions within a chosen scheme. A stable identifier points to a particular record. Decide which job you need.

In our example, `v01` does not mean approved, implemented or legally authoritative. Adding `v02` would not establish any of those facts either. Record status and approval in the appropriate place rather than trying to make a higher number do that work.

A stable identifier such as N014 can remain attached to a note even if its short descriptive title changes. Write that convention down, and do not reuse the identifier for an unrelated note. It is a local reference label, not evidence of a universal numbering system.

For the reasoning behind a choice, keep the actual explanation in a [decision log](/keep-useful-decision-log/). The filename can identify that record; it cannot replace its assumptions, evidence or authorised status.

## What should a one-page naming rule contain?

Use this original convention card before applying a scheme:

```text
Collection: ordinary project notes
Primary retrieval question: what happened on this date?
Order: event-date, project-label, note-type, revision
Date meaning: event date; unknown dates stay unresolved
Project vocabulary: cedar; orbit
Note types: meeting; research
Revision meaning: numbered draft revision, not approval
Extension: retain the file's actual extension
Exceptions: record why an item does not fit
Owner: person authorised to maintain this collection
```

This is a fictional example card, not a prescription for every collection. Replace the fields with your actual needs in an appropriate private record. Keep the explanation short enough to consult when creating the next note.

A useful exception explains why a file differs. It does not require immediate renaming. A received attachment, externally supplied record or document managed by another system may have naming requirements you do not control.

## How can you adopt a convention without reorganising everything?

Start with new notes you are authorised to create. Sketch a few candidate names before touching existing records. Ask whether they distinguish the event, subject and record type without needing private context.

For existing material, avoid bulk renaming as a first step. Check the application's documented rename behaviour and the consequences for links, references and collaborators. If a small manual change is appropriate, verify the affected references afterwards. Do not assume an old path or link continues to work.

Leave extensions alone during a naming cleanup. [Microsoft's Windows guidance](https://support.microsoft.com/en-us/windows/experience/storage-filemanagement/common-file-name-extensions-in-windows) states that changing an extension does not convert the underlying file format. The fictional names represent text files; they are not instructions to turn other documents into text by renaming them.

A naming review is not authority to delete originals, move shared records or override retention obligations. Ask the responsible owner when an item is governed by organisational, legal or other formal requirements.

## How do you know whether the convention is useful?

During your next [weekly notes review](/weekly-notes-review/), try three ordinary retrieval questions: find a note from a known date, find two notes on the same subject, and identify which record a reference points to. Use non-sensitive material and your actual tool.

Record any ambiguity rather than inventing a performance score. Perhaps “research” is too broad, or the chosen date means different things in different files. Change the rule only where that observation justifies it.

Keep this bounded within your [weekly-review routine](/weekly-review/). The goal is a name you can understand when memory is unavailable, not an archive whose consistency becomes another unfinished project.

## Sources

- [MIT Libraries: Organize your files](https://libraries.mit.edu/data-management/store/organize/) — retrieval-oriented organisation and naming order.
- [MIT Records Management: File creation](https://libraries.mit.edu/records-management/tips-best-practices/file-creation/) — its date and draft-version conventions.
- [Smithsonian Institution Archives: Setting Up Electronic Files](https://siarchives.si.edu/what-we-do/setting-electronic-files) — meaningful context, vocabulary and naming.
- [Microsoft Support: Common file name extensions in Windows](https://support.microsoft.com/en-us/windows/experience/storage-filemanagement/common-file-name-extensions-in-windows) — extension changes are not format conversion.

## Frequently asked questions

**Should a note filename start with the date or the subject?**

Choose according to the question you expect to ask later. Date-first names support a date-oriented lexical listing, while subject-first names group matching subject labels in that listing. Your app may display another sort order, so check its actual view. Neither convention is universally better or a substitute for a useful title.

**Which date should I use when I write notes after a meeting?**

Define what the filename date means. If your collection uses event dates, a note written later can retain the meeting date, with the writing date recorded inside when relevant. Do not invent an unknown date or switch meanings silently. A filename date is not proof of approval, implementation or legal effect.

**Does a higher version number mean the note is approved?**

No. In the proposed scheme, a version number identifies a revision; it does not establish approval, authority or implementation. Record those facts through the appropriate process. A stable record identifier has a different job: it points to the same record even when its descriptive title changes under an authorised convention.

**Should I rename all my old notes to match?**

Not as a starting point. Apply the convention to new notes you are authorised to create, then consider existing material separately. Check the app's documented rename behaviour, shared ownership and reference implications before any small manual change. Do not bulk-rename, delete or move protected records under the guise of tidying filenames.

**Can I change the extension to make all my notes the same format?**

No. Renaming an extension is not format conversion, and a naming convention should retain the file's actual extension. Use the appropriate application and authorised process if a format change is genuinely needed. This guide supplies neither conversion instructions nor permission to alter shared records, originals or files subject to retention requirements.


---

# How to Keep a Decision Log You Will Reuse

> Keep a useful decision log by recording the decision date, context, alternatives, choice, reasons, assumptions, expected result, owner, and a review date. Write the choice as a bounded action rather than an aspiration, link to supporting evidence instead of pasting an archive, and name an early warning or stop condition. At review, record the outcome, surprises, assumptions that held, and whether to keep, change, or stop. Judge the reasoning available at the time as well as the result, because luck can reward weak process and uncertainty can punish sound choices.

Source: https://wyllis.com/keep-useful-decision-log/  
Publisher: The Useful Margin  
Published: 2026-07-19  
Updated: 2026-08-26

## Record the decision before hindsight redecorates it

A useful decision log captures what you chose, why, which alternatives you considered, what you expected, and when you will review the result. Keep each entry short enough to complete while the reasoning is fresh. The purpose is not to prove that Past You was brilliant. It is to give Future You an honest record before the outcome starts pretending it was inevitable.

Use a decision log for choices you may revisit, repeat, explain, delegate, or learn from. Do not log every sandwich. Unless lunch has acquired a budget, a committee, and measurable downside, memory may handle it.

## Choose one searchable home

Keep the log in a place you already open: a notebook, spreadsheet, notes app, text file, or database. The tool needs reliable search, dates, backup, and access appropriate to the information. Fancy relationships and colorful properties are optional.

Use one consistent title pattern:

`YYYY-MM-DD — decision — short subject`

Examples include `2026-08-26 — choose — workshop venue` or `2026-08-26 — stop — monthly newsletter`. An ISO-style date sorts cleanly and removes the international suspense of whether 08/09 means August or September.

Do not place passwords, recovery codes, confidential health information, protected work data, or another person's sensitive details in a casual log. Use an approved secure system for records that require one.

## Use a nine-line template

Copy this structure:

```text
Decision:
Date:
Context:
Options considered:
Choice:
Reasons:
Assumptions:
Expected result:
Review date:
```

Add an owner when the decision belongs to a team, and a link to supporting material when needed. Keep the supporting document separate rather than pasting an entire research archive into the entry. A decision log should point to evidence, not swallow the library.

## Make the decision sentence testable

Write the choice as an action with a boundary. “Improve communication” is an aspiration. “Send one project update every Thursday for four weeks, then review replies and missed questions” is a decision.

Include what you are not deciding. A trial of one meeting format does not settle every future meeting. Choosing one vendor for a pilot does not authorize unlimited renewal. Boundaries prevent a small choice from quietly acquiring an empire.

If the decision has money, safety, legal, medical, employment, privacy, or contractual consequences, use the qualified advice and formal approval process the situation requires. A personal log can document professional advice; it cannot replace it.

## Preserve alternatives without writing a novel

List the serious options and one sentence on why each was declined. Include “do nothing yet” when delay is genuinely available. You are preserving the decision landscape, not writing a defense brief against imaginary critics.

For each option, record the same few criteria: cost, time, reversibility, risk, effort, fit, or another relevant measure. Define subjective terms. “Simpler” might mean fewer weekly steps, less training, one owner, or no new software; those are different promises wearing the same adjective.

## State assumptions and expectations

Assumptions are facts you are acting as though true: the venue can hold the group, the software export contains attachments, the weather permits the route, or the collaborator has two hours available. Mark what has been verified and what remains uncertain.

Then write the expected result in observable language. Use a range or condition when precision would be invented. “Most invited participants can complete registration without staff help” is more honest than a confidence-heavy percentage pulled from the atmosphere.

Name an early warning sign and a stop condition. A reversible decision becomes expensive when nobody agrees what would trigger reversal.

## Pick a review date that matches the decision

Review after enough evidence can exist but before the consequence becomes difficult to change. A one-week process trial may need review next Friday; a seasonal choice may need the end of the season. Avoid “someday,” a date with an excellent record of nonattendance.

Put the review in the same system that surfaces other commitments. Link the log entry. During a [weekly notes review](/weekly-notes-review/), check whether any decision has reached its review point or lost an owner.

## Review the reasoning, not only the outcome

At review, add:

```text
Outcome:
What surprised us:
Which assumptions held:
Keep, change, or stop:
Next review:
```

A good outcome can follow weak reasoning or luck. A poor outcome can follow a sensible choice under uncertainty. Ask whether the information, criteria, and process were reasonable at the time—not whether the result made you look clever afterward.

Browse [decision records](/decision-records/) for more templates. Over time, look for repeated assumptions, delays, blind spots, and successful small tests. The log becomes valuable when it changes the next decision, not when it grows large enough to frighten the search bar.

## Frequently asked questions

**What decisions belong in a decision log?**

Log choices you may repeat, revisit, explain, delegate, audit, or learn from—especially when alternatives, assumptions, money, time, risk, or several people are involved. Skip trivial choices unless a pattern matters. High-stakes legal, medical, financial, safety, employment, privacy, or contractual decisions still require qualified advice and formal procedures; the log records reasoning and sources but does not replace professional judgment or authorization.

**How long should a decision-log entry be?**

Use the shortest entry that preserves the choice, context, credible alternatives, reasons, assumptions, expected result, owner, and review date. Many ordinary entries can fit in several lines; complex decisions may link to separate analysis. If completing the log becomes burdensome, reduce prose before removing the review date or assumptions. A decision record must be easy enough to write while the reasoning is still fresh.

**What is the difference between a decision log and journal?**

A decision log is structured around a choice and later review, while a journal may capture broader experience, feelings, events, or reflection. They can coexist or share a tool. The log benefits from consistent fields and searchable dates; the journal can remain more open. Do not force sensitive personal reflection into a shared decision system merely because the two formats overlap.

**When should I review a decision?**

Review after enough evidence can exist but before the consequences become unnecessarily difficult to change. Match the date to the decision: a short process trial may need days or weeks, while a seasonal choice needs a full cycle. Add an earlier warning or stop condition for safety, cost, or performance. Put the review in a calendar or task system that will surface it reliably.

**How do I avoid hindsight bias in a decision log?**

Write assumptions, uncertainty, rejected options, and expected outcomes before results arrive. Preserve the information sources and dates available at the time. During review, separate process quality from outcome quality: luck can rescue weak reasoning, and a reasonable choice can fail under uncertainty. Ask which signal was missed, which assumption changed, and what rule should influence the next similar decision without pretending the result was obvious.


---

# How to Write a Project Closeout Note

> A project closeout note should record the intended result, actual result, important variance, reusable lessons, final artifact locations and any open work with an owner and date. Write it before the team disperses, link to evidence instead of copying it, and express each lesson as a condition and action. Add a review trigger so the note returns when a similar project begins.

Source: https://wyllis.com/project-closeout-note/  
Publisher: The Useful Margin  
Published: 2026-09-05  
Updated: 2026-09-07

## What belongs in a project closeout note?

A useful project closeout note records the intended outcome, the actual outcome, what changed, the few lessons worth reusing, where the final artifacts live, and any work that remains open. Write it while the evidence is still easy to find. Keep it short enough to scan, but specific enough that a future colleague can act without reconstructing the whole project.

The note is not a ceremonial summary. It is the last piece of working infrastructure a project produces.

NASA's project-closeout guidance is written for missions, not ordinary office work, but its core list travels well: document and capture lessons, establish a final report, and archive the data. Its current [lessons-learned framework](https://www.nasa.gov/learning-resources/for-professionals/appel-lessons-learned/) goes one step further. A lesson has to be collected, recorded, shared and eventually applied. A closeout note that merely exists has completed only part of that journey.

## How is a closeout note different from a status update?

A status update helps people steer work that is still moving. A closeout note helps someone reuse knowledge after the work has stopped.

That distinction changes what deserves space:

| Record | Main question | Best contents |
|---|---|---|
| Status update | Where are we now? | Progress, current risks, next actions |
| Decision log | Why did we choose this? | Options, criteria, decision, assumptions |
| Closeout note | What should survive this project? | Outcome, variance, lessons, artifacts, open loops |

Do not paste a sequence of weekly updates into a final document. Chronology is rarely the most useful organizing principle six months later. Compress the history into decisions, evidence and reusable instructions. If a choice needs its own reasoning trail, link to a [decision log](/keep-useful-decision-log/) instead of retelling it badly.

## When should you write it?

Draft the note before the team disperses and before shared folders become archaeology. The practical moment is usually after the final outcome is known but before the last handoff meeting.

For a long project, do not wait until the end to remember everything. Keep a small running section called "closeout candidates" in the working notes. Add a sentence whenever a constraint changes, an experiment settles a question, or a workaround becomes worth repeating. At closeout, promote only the items that still matter.

This is consistent with NASA's broader approach: lessons can be collected through individual write-ups, team discussions, or pause-and-learn sessions, then recorded in a suitable repository. The format is flexible; retrieval and application are the point.

## A project closeout note template

Use the following as a page, not a form that must be filled at any cost. Delete sections that have nothing useful to say.

```text
Project — concise name
Closed — date
Owner — person who can clarify this record
Outcome — complete, stopped, handed off, or superseded

INTENDED RESULT
One or two measurable sentences about what the project set out to change.

ACTUAL RESULT
What happened, including the date or measurement window and a link to evidence.

VARIANCE
What differed from the plan, and the best-supported reason why.

REUSE
When this situation appears again, do this because this evidence showed that.

DECISIONS TO PRESERVE
Links to the decisions whose reasoning will matter later.

FINAL ARTIFACTS
Canonical link — what it contains — access owner

OPEN LOOPS
Action — owner — due or review date

RETIRE OR DELETE
Drafts, duplicate files, temporary access, and obsolete instructions to remove.

REVIEW TRIGGER
The event or date that should bring this note back into view.
```

The labels make omissions visible. If "actual result" has no evidence link, the project may not yet have a settled result. If an open loop has no owner, it is not handed off. If the final artifact has no canonical location, the next person will find five nearly identical versions and choose by filename vibes.

## How do you write the outcome without polishing the history?

Put the intended and actual results beside each other. Use the same unit and time window where possible.

Consider a hypothetical four-week email cleanup project:

- Intended: reduce the average response time for support email from 30 hours to 18 hours during the four weeks after launch.
- Actual: average response time was 21 hours during that window, according to the linked support export.
- Variance: three hours above target. Weekend messages continued to enter the weekday queue because the routing rule did not separate them.

That is more useful than "response times improved, although the team encountered some routing challenges." The precise version shows what improved, what missed, the evidence window and the mechanism worth checking next time.

Be equally exact when a project stops. "Stopped after legal review identified an unresolved licensing condition" is a result. "Paused for strategic reasons" is fog unless those reasons are recorded somewhere accessible.

## What makes a lesson reusable?

A reusable lesson joins a condition to an action and gives the reason. A compact pattern is:

> When this condition appears, take this action, because this evidence showed that consequence.

For example:

> When a campaign depends on a partner's mailing list, confirm the final segment count before approving creative, because the usable audience in this project was smaller than the planning export.

Contrast that with "communicate earlier." Earlier about what, with whom, and to prevent which failure? General wisdom feels agreeable while asking nothing of the next project.

Keep facts separate from interpretation. "The final export contained 2,400 eligible records" is an observation. "The eligibility rule was misunderstood" is an explanation, and it may need evidence or a confidence label. Write "likely explanation" when that is genuinely all the record supports. Do not upgrade a plausible story into a fact simply because the project is ending.

## Which artifacts should the note link to?

Link the smallest set that lets someone verify the result or restart the work:

- the approved final deliverable;
- the source data or measurement export;
- the final brief or scope;
- decisions with assumptions that could expire;
- operating instructions for anything that remains live;
- the owner or location for credentials, without copying credentials into the note.

NASA describes archiving technical information and data as part of formal [project closeout](https://www.nasa.gov/reference/3-9-project-phase-f-closeout/). A small team's archive is simpler, but it needs the same basic discipline: identify the authoritative material and leave it somewhere another authorized person can retrieve it.

Avoid dumping every intermediate file into the closeout note. Link a canonical folder, then name the few files that matter. Mark superseded versions clearly or remove them under the team's retention policy. Keeping everything is not the same as preserving knowledge.

## How should open loops be handled?

Closeout does not make unfinished work disappear. Give every remaining action an owner and a date. If the date is uncertain, set a review date or a concrete trigger such as "after the first monthly billing cycle."

Move those actions into the system where work is actually tracked. The closeout note is the record; it should not become a hidden second task list. If your review practice is the place where loose ends surface, add the actions to the next [weekly notes review](/weekly-notes-review/) and link back to the closeout record.

An unresolved risk also needs plain language. State what could happen, what has already been done, who owns the next decision and where the supporting material lives. "Monitor" is not an action unless it includes what signal to watch and what response that signal triggers.

## How long should a closeout note be?

For a small project, one or two pages is usually enough. Let complexity, not prestige, earn more space. A six-month project may still close cleanly in three pages if its evidence and decisions are linked rather than duplicated.

A useful editing test is to ask what a new owner could do with each paragraph. The paragraph should help them verify an outcome, repeat a successful method, avoid a known failure, find an artifact or pick up an obligation. If it does none of those, cut it.

Use a predictable filename such as `2026-09-05-project-name-closeout`. Put the closeout note where future work on the same subject will begin, not in a private folder that happened to be convenient on the final day.

## A 15-minute closeout routine

If the project is small and the evidence is ready, use this sequence:

1. **Three minutes: gather.** Open the original brief, final result, measurement source and current task list.
2. **Four minutes: compare.** Write intended result, actual result and variance in matching terms.
3. **Four minutes: extract.** Record no more than three condition-action lessons and link any consequential decisions.
4. **Two minutes: hand off.** Assign each open loop and copy it into the team's task system.
5. **Two minutes: file.** Link canonical artifacts, mark obsolete material and set a review trigger.

Fifteen minutes is not enough to discover missing evidence or settle a disputed interpretation. In those cases, create the skeleton, assign the gaps and finish the record when the facts are available. Brevity is useful only after the important questions have answers.

## What should you check before closing the note?

Read it once as someone who did not attend the project:

- Can they tell what was attempted and what actually happened?
- Can they verify the result from a linked source?
- Can they distinguish facts from explanations?
- Does each lesson say when and how to apply it?
- Is there one authoritative location for final artifacts?
- Does every open loop have an owner and date or trigger?
- Are obsolete drafts and temporary access accounted for?
- Is there a reason this note will surface when it becomes relevant?

The last question matters most. NASA's lessons framework names application as the crucial step: recorded knowledge has to enter checklists, processes, handbooks or other working practice. For a small team, that might mean adding one line to a launch checklist, linking the note from the next brief, or scheduling a review before a seasonal project repeats.

A closeout note earns its keep when the next project starts a little less naively.

## Frequently asked questions

**What is a project closeout note?**

It is a short final record of what a project intended, what happened, what should be reused, where authoritative artifacts live and which obligations remain open.

**How is a closeout note different from a status report?**

A status report helps steer active work. A closeout note preserves the outcome, evidence and lessons that someone will need after the work has ended.

**When should a project closeout note be written?**

Write it after the outcome is known but before the final handoff and team dispersal. Collect candidate lessons during longer projects so closeout does not depend on memory.

**How long should a closeout note be?**

One or two pages is often enough for a small project. Add length only when it helps a future reader verify a result, reuse a method, find an artifact or assume an obligation.

**What makes a lesson learned useful?**

State the condition, the action to take and the evidence-based reason. Specific guidance such as when X occurs, do Y because Z is more reusable than advice such as communicate better.

**Where should unfinished actions go?**

Record each open action with an owner and date or trigger, then copy it into the team's real task system. The closeout note should preserve the handoff, not become a hidden task list.


---

# How to Update a Decision Log Without Losing History

> Update a decision log by distinguishing a factual correction, an outcome note, and a changed decision. Date the addition and explain what changed. For a replacement decision, give the new record its own identifier, link it to the earlier record, and show which choice currently applies. Keep proposed changes separate from approved ones. Use your organization's authorized correction, access, and retention processes for protected records.

Source: https://wyllis.com/update-decision-log/  
Publisher: The Useful Margin  
Published: 2026-09-09  
Updated: 2026-09-09

## How do you update a decision log?

Update a decision log by distinguishing a factual correction, an outcome note, and a changed decision. Date the addition and explain what changed. For a replacement decision, give the new record its own identifier, link it to the earlier record, and show which choice currently applies. Keep proposed changes separate from approved ones. Use your organization's authorized correction, access, and retention processes for protected records.

A log is most useful when you can read it without reconstructing a conversation. The question is not simply whether the note is up to date. It is whether you can tell what was believed then, what became known later, and what you are meant to do now.

This is a lightweight editorial method for ordinary personal and project notes. It is not a substitute for formal approvals, regulated records management, or professional advice. Start with the [basic decision log](/keep-useful-decision-log/) if you have not yet recorded the original choice.

## Where does the replacement-record idea come from?

Architectural decision records, or ADRs, document significant software-design choices. AWS describes an accepted ADR as fixed: a changed decision goes through a new proposal and acceptance process, after which the earlier record is marked superseded. That is a software-team workflow, not a rule governing every personal notebook. [AWS's ADR process](https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/adr-process.html) supplies the useful distinction between revisiting a choice and quietly rewriting it.

Microsoft likewise recommends a linked replacement when an accepted architectural decision changes. Its guidance includes status labels and keeping the reasons alongside the outcome. [Microsoft's architecture-record guidance](https://learn.microsoft.com/en-us/azure/well-architected/architect-role/architecture-decision-record) is specifically about workload architecture.

The worksheet below adapts that narrow idea. Its dates, labels, and examples are our editorial design, not a tested productivity intervention or a prescribed AWS or Microsoft personal-review system.

## Is this a correction, an observation, or a new choice?

Use the smallest change that accurately describes what happened. In this proposed method, three kinds of update have different jobs.

| What happened | Suitable note | What it must not imply |
|---|---|---|
| You typed the wrong meeting date | Dated correction identifying the error and its verified replacement | That the original date was always recorded correctly |
| You learned how the choice worked out | Outcome addition with the observation date | That a new approach has already been chosen |
| You chose a different approach | Separate replacement record, with its approval and effective status | That merely discussing the alternative made it current |

A correction needs evidence. If you cannot establish which of two dates is right, record the discrepancy and the next verification step. Do not choose the one that makes the chronology look neater.

An outcome can be disappointing without requiring a replacement decision. “The summary arrived late” is an observation. “We will use a different summary format” is a choice. Keeping those statements separate leaves room to consider the cause instead of treating the first inconvenience as a verdict.

## What belongs in the new record?

For a changed decision, make a short record containing:

- A stable identifier and a descriptive title.
- The earlier record's identifier or link.
- The date the replacement was proposed.
- The new information or changed constraint prompting review.
- The alternatives now being considered.
- The choice, its reason, and the tradeoff being accepted.
- Who may approve it, and whether that approval has happened.
- When the choice is intended to take effect.
- A later check that can establish whether implementation happened.

A stable identifier can be as plain as D-014. It is a reference, not a ranking. Keep it attached to the same decision even if you improve the title.

For an individual note, you may be the decision-maker. For shared work, do not infer approval from being the person who maintains the log. Identify the responsible person or process. Leave a missing approval marked unresolved.

Keep sensitive details out of a general-purpose worksheet. Use authorized storage and appropriate access restrictions. If a record contains information that should not be there, follow the applicable correction or incident process; do not create another unrestricted copy in the name of preserving history.

## What would two connected records look like?

Here is a fictional example about an internal project-summary format. The identifiers, dates, observations, and decisions are invented to demonstrate the method.

**D-014 — Use a paragraph for the project summary**

The original choice was accepted on September 1, 2026. Its reason was to keep the weekly summary readable in one short passage. The note expected readers to find the current action within that paragraph.

On September 8, the writer adds an outcome note: the paragraph describes progress, but the current action is not consistently distinguished from background information. That observation does not itself change the agreed format.

**D-021 — Separate the current action from background**

The replacement is proposed on September 8. It would use two labeled fields: “Current action” and “Background.” The alternative is to retain the paragraph and put the action first. The proposed reason for choosing fields is to make the distinction explicit, accepting a more repetitive layout.

The example's authorized owner accepts D-021 on September 9, with an effective date of September 14. Until that effective date, D-014 remains the applicable format in this fictional workflow.

The date sequence is:

| Date in the example | What the record can honestly say |
|---|---|
| September 8 | A replacement is proposed; it is not approved |
| September 9 | The replacement is approved for September 14; it is not yet current |
| September 14 | The replacement takes effect under the recorded arrangement; implementation still needs checking |
| September 15 | A dated follow-up can record whether the new fields were actually used |

Approval, applicability, and implementation are three different facts. A September 9 approval does not prove that anyone used the new layout on September 14. If the effective date changes, record that change through the appropriate process rather than leaving the table to contradict current instructions.

## How should the old record point to the new one?

Add a clearly dated status annotation where a reader will notice it. For the example, the September 9 annotation could read:

“D-021 accepted on September 9; scheduled to replace this format from September 14. D-014 remains current until then.”

When the replacement takes effect, the annotation can state:

“Superseded from September 14 by D-021. The original reasoning below describes the earlier choice.”

The replacement points back to D-014. The old record points forward to D-021. In a paper notebook, page references can do the same job. Check both directions; a reference to a renamed or inaccessible file is not useful simply because it is underlined.

Do not label the old record “wrong” merely because circumstances changed. A choice made for an earlier constraint may explain the work perfectly well. Its historical usefulness and its current applicability are different questions.

## What if a replacement is rejected or only partly accepted?

A rejected proposal is not a replacement. In your note, record that it was not adopted and explain the unresolved concern. Do not change the current record's status to superseded just because you spent time drafting an alternative.

For a partial change, name the boundary. In the fictional example, the owner might accept the two-field layout only for one project while retaining paragraphs elsewhere. The replacement note should identify that limited scope, not announce a universal new format.

If two records appear current and conflict, flag the conflict for the responsible decision-maker. Do not silently select the newest file timestamp. That timestamp could reflect a typo correction rather than an authorized decision.

## How do you keep the history usable?

Add the new record to the same index as the old one, with its status and the decision it replaces. Put unresolved approval or implementation checks into your [weekly notes review](/weekly-notes-review/). A review reminder is a prompt to look, not evidence that the change has occurred.

When a project finishes, link its current decision chain from the [project closeout note](/project-closeout-note/). Keep detailed records in their canonical location rather than pasting slightly different versions into every summary.

Before finishing an update, ask:

- Can a reader identify the currently applicable choice?
- Can they distinguish proposal, approval, effective date, and observed implementation?
- Does each correction explain its basis?
- Can they find the previous reasoning without mistaking it for current instructions?
- Have access, correction, and retention requirements been respected?

You do not need a biography of the decision. You need enough of its history to change course honestly and enough clarity that the next reader knows where the course now leads.

## Sources

- [AWS Prescriptive Guidance: Architectural decision record process](https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/adr-process.html), read September 8, 2026. Software-specific acceptance and supersession process.
- [Microsoft Learn: Maintain an architecture decision record](https://learn.microsoft.com/en-us/azure/well-architected/architect-role/architecture-decision-record), updated April 13, 2026; read September 8, 2026. Linked replacement records and architectural decision context.

## Frequently asked questions

**Should I edit an old decision log entry?**

Distinguish a factual correction from a changed decision. A correction should identify the error, its verified replacement, and when you recorded it. A changed choice can have a separate linked record so the original reasoning remains understandable. For protected or organizational records, follow authorized correction and retention processes rather than treating this personal-note method as permission to edit.

**What does superseded mean in a decision log?**

In this method, superseded means that another recorded choice has replaced the earlier one within a stated scope. It does not mean the old reasoning was necessarily mistaken. Identify the replacement and when it applies. A proposal that has not been approved, or an approved change scheduled for later, needs a status that preserves those distinctions.

**Is an approved decision already implemented?**

Not necessarily. Approval records acceptance by the responsible person or process; an effective date says when the choice is intended to apply. Implementation requires separate evidence that the change actually happened. Keep an unresolved implementation check visible instead of treating an approval date, calendar reminder, or updated document as proof that the work was completed.

**Do I need a new record for every disappointing outcome?**

No. An outcome note records what you observed and when. It can prompt reconsideration without claiming that you have already chosen a replacement. Explain the observation and any uncertainty, then record a new decision only when there is a distinct choice to document. Do not rewrite the original prediction to make it match the result.

**What if two decision records contradict each other?**

Mark the conflict and ask the responsible decision-maker which record applies and to what scope. Do not assume that the most recently edited file is authoritative: its timestamp might reflect a wording correction. Record the clarification through the appropriate process and connect the affected notes so readers can find it without repeating the same investigation.


---

# A 30-Minute Weekly Notes Review

> A useful weekly note turns the past seven days into decisions for the next seven. Spend five minutes collecting loose notes, ten classifying them, ten connecting and updating active material, and five scheduling follow-ups and clearing debris. Record what changed, actions with owners, waiting items with follow-up dates, decisions with reasons, and one visible starting point for next week. Stop after 30 minutes and handle any backlog separately.

Source: https://wyllis.com/weekly-notes-review/  
Publisher: The Useful Margin  
Published: 2026-07-19  
Updated: 2026-09-07

## What should a weekly note contain?

A useful weekly note is one page that turns the past seven days into decisions for the next seven. Give it 30 minutes: five minutes to collect loose notes, ten to classify them, ten to connect and update active material, and five to schedule follow-ups and clear debris. The finished note should show what changed, what needs action, what is waiting, and where next week’s review begins.

This works on paper or in a digital app. The labels may differ, but the decisions are the same: keep, act, connect, defer, archive, or delete. The weekly note is the review surface, not a second copy of everything you already captured.

## Copy this weekly note template

Use the same small structure each week so the review begins with decisions rather than page design.

```text
Week of:
Review date:

CHANGED
- New facts, outcomes, or assumptions:

ACT
- [Owner] Next visible step — due date or no date

WAITING
- Expected item — from whom — follow-up date

DECISIONS
- Choice — reason — assumption — review date

REFERENCE TO CONNECT
- Note or source — useful link or destination

ARCHIVE OR DELETE
- Item — reason it can leave the active view

NEXT REVIEW STARTS WITH
- One visible first move
```

“Changed” prevents the page from becoming only a task list. “Waiting” separates work you control from work someone else owes. “Decisions” preserves reasons that memory may smooth over later. The final line supplies a starting point if the timer interrupts you.

The template is deliberately tool-neutral. A heading can be a paper divider, a page section, or a saved template in an app. Do not add a field unless it repeatedly changes what you do.

## Before the timer: choose one review surface

Open the places where notes actually arrive: inbox, daily page, notebook, voice-memo list, downloads, screenshots, meeting notes, and saved messages. Do not begin reading all of them yet. Make one short collection list or place physical items together.

Close unrelated tabs and silence alerts for 30 minutes. Keep a calendar and task list nearby, because a note describing an action belongs in a trusted action system rather than hiding inside prose.

If work records, health data, legal material, financial details, or another person’s private information appears, handle it under the applicable retention, security, and organizational rules. A weekly cleanup is not authorization to move protected material into a personal app.

## Minutes 0–5: collect the loose edges

Gather notes created since the last review. Rename only files whose current title prevents recognition. A useful title names the subject and, where helpful, a date or project: `supplier questions — August` beats `New Note 47`, though the competition is not fierce.

Move screenshots containing actionable information into the review list. Transcribe a voice memo only when it contains something worth keeping. Do not tidy old archives during collection. The first five minutes are a sweep, not a documentary excavation.

At minute five, stop gathering. A forgotten note can wait until next week; expanding the search to every device is how a review becomes a migration project.

## Minutes 5–15: decide what each note is

Process the collection one item at a time and choose:

- **Act:** create a specific task with an owner and next visible step.
- **Calendar:** assign a real date or time when timing is fixed.
- **Reference:** keep information that is likely to be used again.
- **Decision:** capture a choice, reasons, assumptions, and review date.
- **Waiting:** record what is expected, from whom, and when to follow up.
- **Archive:** retain for a defined reason without keeping it active.
- **Delete:** remove information with no remaining use or obligation.

Do not duplicate the full note into every destination. Put the action in the task list and link back to supporting material. One maintained source with several pointers ages better than four copies holding a disagreement.

Use [how to keep a decision log](/keep-useful-decision-log/) when a note contains a choice that may later need explanation or review. The [decision-records section](/decision-records/) has the broader method without turning this weekly pass into a second project.

## Turn a loose note into a useful record

Suppose Friday’s capture says: `Supplier sample may arrive next week; Mina needs to approve the finish.` It contains at least three different things. The weekly review separates them:

| Destination | Useful record |
|---|---|
| Waiting | Sample from supplier; follow up Thursday if no confirmation arrives |
| Act | Mina: review finish after the sample arrives |
| Decision | Finish remains open; sample review is the decision point |
| Reference | Link to the supplier message and current specification |

Nothing new was invented. The change is structural: an ambiguous sentence becomes a follow-up, an owner, a decision boundary, and supporting context. If the sample date is not fixed, it does not belong on the calendar. If Thursday is the chosen follow-up date, that follow-up does.

This is also a useful test for the template. If a field merely repeats the original capture, it is decoration. If it changes where the information lives or what happens next, it earns its place.

## Minutes 15–25: connect and update

Review active project or topic notes. Add links only where a future reader would genuinely benefit. A connection should answer one of three questions: What supports this? What depends on this? What should be read next?

Merge duplicate fragments when doing so takes less than a minute. Preserve source and date when they matter. If two notes conflict, do not quietly overwrite one; mark the discrepancy and create an action to resolve it.

Update status lines, owners, next steps, and deadlines. Remove completed actions from active lists only after recording any result that matters. A checked box can disappear; the decision it produced may need to remain.

For a physical notebook, add page numbers to an index or project list. For digital notes, use a small stable set of labels. A tag used once is often a tiny folder wearing a novelty hat.

## Minutes 25–30: surface reviews and close

Scan waiting items, decision review dates, deadlines, and scheduled follow-ups. Place time-specific commitments on the calendar and flexible actions in the task system. Move no-date aspirations out of the urgent view.

Then archive or delete obvious debris: duplicate downloads, empty notes, outdated event logistics, and screenshots whose information has been captured. Follow retention requirements and make sure deletion is appropriate; records subject to legal hold, policy, tax, contract, safety, or audit duties are not weekly clutter.

End by writing one line: `Next review starts with ___`. This gives next week’s session a visible first move and preserves anything the timer interrupted.

The arithmetic is 5 + 10 + 10 + 5 = 30 minutes. If the inbox remains large, schedule a separate backlog session rather than extending the routine indefinitely.

## Diagnose the review when it keeps failing

| What happens | Likely cause | Next review’s adjustment |
|---|---|---|
| Collection consumes the whole timer | The search boundary is undefined | List the capture points before starting and stop gathering at minute five |
| Every note becomes a task | Reference, decisions, and waiting items are being collapsed into action | Classify first; create a task only when a visible action exists |
| The same item returns each week | It lacks an owner, trigger, date, or decision | Add the missing field or archive it as a no-date possibility |
| The weekly note grows indefinitely | It stores source material instead of pointing to it | Keep the decision or action and link to the maintained source |
| You avoid the review | The routine has become backlog cleanup | Keep the 30-minute stop and schedule backlog work separately |

Change one part at a time. A shorter capture list, a clearer waiting field, or a firmer stopping rule produces evidence you can use next week. Replacing the entire system produces a fresh system and no diagnosis.

## What not to do during review

Do not redesign the entire folder structure, test six new apps, reread every journal entry, rewrite finished notes for style, or begin the tasks you are identifying unless they take seconds. Capture the next action and continue.

Do not use link count as proof of knowledge. A note connected to 12 vague pages may be less useful than one attached to a clear decision and current source.

Browse [weekly review](/weekly-review/) for backlog and project variants. The review succeeds when important actions and decisions surface, useful reference remains findable, and dead material leaves the active view. Perfect tidiness is optional; a system you trust next Tuesday is not.

## Frequently asked questions

**What should a weekly note contain?**

Include the week and review date, what changed, actions with owners, waiting items with follow-up dates, decisions with reasons and review dates, reference notes worth connecting, material to archive or delete, and one line naming where the next review begins. The page should route information rather than copy every source note into a new container.

**What should I review every week?**

Check note inboxes, recent daily or meeting notes, useful voice memos, screenshots with information, active project pages, waiting items, decision review dates, deadlines, and follow-ups. Include only systems you actually use. Protected work, legal, health, financial, or personal records must remain in approved storage and follow applicable retention and security rules.

**What if 30 minutes is not enough?**

Stop at the planned finish and write where the next review should resume. If a genuine backlog remains, schedule a separate, bounded cleanup session rather than turning every weekly review into an open-ended project. Prioritize recent notes, commitments, safety or money implications, and time-sensitive decisions. Older reference material can wait unless it blocks current work.

**Should tasks stay inside my notes?**

Supporting details can remain in notes, but a clear next action should also appear in the task system you regularly review. Include an owner, visible verb, and link back to context. Fixed appointments and deadlines belong on a calendar. Avoid duplicating full text across tools because copies diverge; maintain one source and dependable pointers.

**How many tags should a note have?**

Use only tags that support repeated retrieval or a real workflow. A small stable set, such as active, waiting, reference, or a durable topic, usually works better than a new label for every nuance. Before adding one, ask when you will browse or filter it. Search, links, titles, and project lists may already solve the need.

**What should I delete during a weekly review?**

Delete empty notes, true duplicates, obsolete logistics, and screenshots whose useful information has been captured, provided no retention or evidence need remains. Archive items kept for a defined reason but no longer active. Do not delete records under legal hold or needed for tax, contract, employment, safety, audit, healthcare, or organizational policy; check the controlling rule when uncertain.


---

# Weighted Decision Matrix Example: Show Your Tradeoffs

> A weighted decision matrix compares options against defined preferences: give each criterion an importance weight, rate each eligible option, multiply ratings by weights, and add the results. Keep mandatory requirements outside the tradeoff score. The total summarizes your inputs; it does not establish an objectively correct choice. Record evidence, uncertainties and who can decide. Use qualified advice and required approvals for consequential legal, financial, medical, employment or safety decisions.

Source: https://wyllis.com/weighted-decision-matrix-example/  
Publisher: The Useful Margin  
Published: 2026-09-10  
Updated: 2026-09-10

## How does a weighted decision matrix work?

A weighted decision matrix compares options against defined preferences: give each criterion an importance weight, rate each eligible option, multiply ratings by weights, and add the results. Keep mandatory requirements outside the tradeoff score. The total summarizes your inputs; it does not establish an objectively correct choice. Record evidence, uncertainties and who can decide. Use qualified advice and required approvals for consequential legal, financial, medical, employment or safety decisions.

A matrix is useful when “I prefer this one” needs a little more explanation. It gives the disagreement somewhere to live: perhaps you value a criterion differently, perhaps the evidence is incomplete, or perhaps the options solve different problems.

This guide uses an entirely fictional, low-stakes choice between three formats for an ordinary project summary. No software, team performance or actual project was tested.

## What question are you actually deciding?

Write a bounded decision before drawing the table. Our fictional question is: “Which format should we consider for a short internal summary: a paragraph, a labeled card or a table?”

That is narrower than “How should we communicate?” It does not decide the frequency of updates, who must approve them or where confidential information belongs. Those questions would need their own context.

[ASQ's decision-matrix guide](https://asq.org/quality-resources/decision-matrix) explains the weighted calculation and cautions against treating the highest score as an automatic choice. The particular criteria, weights and ratings below are our original design.

## Which requirements should not become preferences?

Before scoring, identify conditions an option must meet. In this example, every candidate must fit within the existing approved summary system and support the required text. We stipulate that all three pass; we have not evaluated a real system.

If an option could not meet a genuine requirement, a pleasing layout score would not repair that failure. Record it as ineligible or unresolved rather than letting unrelated advantages compensate for it.

[NASA's systems-engineering guidance](https://www.nasa.gov/reference/6-0-crosscutting-technical-management/), section 6.8.1.2.1, distinguishes mandatory criteria from enhancing ones and excludes alternatives that fail mandatory criteria. That is engineering guidance, not a certification of this personal worksheet.

For real shared work, ask the responsible owner which requirements apply. Do not invent permission to use a new service, transfer protected notes or alter an approval process. An unresolved access or retention requirement stays unresolved.

## How should you define the ratings?

Our example uses three preferences. Each has a deliberately simple three-point scale, with larger numbers meaning more desirable performance under that preference.

| Preference | Rating 1 | Rating 2 | Rating 3 |
|---|---|---|---|
| Action visibility | Action is mixed into background | Action has a distinct opening line | Action has a separately labeled location |
| Context capacity | Only a short fragment fits the chosen layout | A brief explanation fits | A fuller paragraph fits |
| Preparation ease | Several fields need separate entries | Two parts need separate entries | One continuous entry is sufficient |

These are fictional layout definitions, not measured usability findings. A reader may reasonably choose different definitions. What matters is making them explicit before comparing candidates.

Keep every scale pointing toward preference: in this example, 3 is preferable to 1, including for preparation ease.

Keep the scoring note beside the table. A bare 3 tells a future reader less than “separate action field, under the scale defined above.” Do not silently change what a rating means halfway down the column.

## What weights are we using?

The fictional decision-maker assigns action visibility a weight of 5, context capacity 3 and preparation ease 2. They sum to 10.

This expresses the example's priorities: action visibility receives more weight than either other preference. It does not mean visibility is scientifically five units important. The weights are judgments, not observations about a product.

Use the same weights for every option. If one candidate receives a special set of weights, its total no longer represents the same comparison.

Keep a short reason for the allocation: “The summary's main job is to expose the current action; background and preparation effort still matter.” If the people affected disagree with that purpose, settle the question rather than hiding it inside arithmetic.

## What does the worked example calculate?

The following ratings are invented editorial inputs consistent with the example's layout assumptions. They are not results from testing real summaries.

| Format | Visibility rating, weight 5 | Context rating, weight 3 | Ease rating, weight 2 | Weighted total |
|---|---:|---:|---:|---:|
| Paragraph | 1 | 3 | 3 | 20 |
| Labeled card | 3 | 2 | 2 | 25 |
| Table | 3 | 1 | 1 | 20 |

The calculations are:

- Paragraph: (1 × 5) + (3 × 3) + (3 × 2) = 5 + 9 + 6 = 20.
- Labeled card: (3 × 5) + (2 × 3) + (2 × 2) = 15 + 6 + 4 = 25.
- Table: (3 × 5) + (1 × 3) + (1 × 2) = 15 + 3 + 2 = 20.

Under these inputs, the card leads by 5 points. That is the complete numerical conclusion. It does not establish that a card is faster to read, more accessible or better for every team.

The largest possible total on this chosen scale is 3 × (5 + 3 + 2) = 30. A score of 25 is not a 25-in-30 chance of success. It is a weighted preference total.

## What happens if the priorities change?

Keep the ratings fixed and try a second explicitly labeled scenario: visibility weight 3, context weight 4 and ease weight 3. The weights still total 10.

| Format | Recalculation under 3, 4, 3 weights | New total |
|---|---|---:|
| Paragraph | (1 × 3) + (3 × 4) + (3 × 3) | 24 |
| Labeled card | (3 × 3) + (2 × 4) + (2 × 3) | 23 |
| Table | (3 × 3) + (1 × 4) + (1 × 3) | 16 |

The paragraph now leads the card by 1 point. No format changed. Only the priorities changed.

This is a small sensitivity illustration, not a reliability test. It shows why a ranking without its weights is incomplete. Retain both scenarios and their reasons; do not replace the first table simply because the second gives a preferred answer.

NASA's decision-analysis section also calls for examining assumptions, uncertainty and whether those uncertainties could change a recommendation. Our two calculations demonstrate only a change in chosen weights, not an analysis of every possible uncertainty.

## What if a rating is unknown?

Do not quietly enter the middle score. “Unknown” and “moderate” mean different things.

Leave the rating unresolved and name the evidence needed. In ordinary notes, that might be a sample layout or confirmation of what a required field must contain. Do not describe an unobserved result as a measurement.

If you use alternative assumed ratings to explore possibilities, label each scenario. An assumed rating does not become evidence because the arithmetic is correct.

Likewise, avoid averaging disagreement into apparent consensus. Ask whether people used the same definition, evaluated the same option and had the same information. Sometimes the most useful output is the precise question that prevents a responsible decision.

## What should you keep with the final choice?

Use this original record card:

```text
Decision and scope:
Eligible options and unresolved requirements:
Criteria and rating definitions:
Weights and reasons:
Evidence behind each rating:
Original calculation:
Alternative scenario and what changed:
Authorized choice and reason:
Remaining uncertainty:
Review date or evidence trigger:
```

Attach it to your [decision log](/keep-useful-decision-log/). Put an outstanding evidence request into your [weekly notes review](/weekly-notes-review/) rather than leaving it as an invisible footnote.

Record the actual choice separately from the leading score. If a decision-maker chooses differently, preserve the reason. A matrix supports explanation; it does not supply authorization.

The [decision-records collection](/decision-records/) covers the wider record. Here, success means another reader can reconstruct the comparison, identify the assumptions and understand the limits. The table need not settle every disagreement to make the next conversation more precise.

## Sources

- [ASQ: What Is a Decision Matrix?](https://asq.org/quality-resources/decision-matrix) — weighted comparison procedure and rating direction.
- [NASA: Crosscutting Technical Management, section 6.8](https://www.nasa.gov/reference/6-0-crosscutting-technical-management/) — engineering decision criteria, mandatory requirements and uncertainty.

Primary pages read September 8, 2026. All format ratings, weights, tables and example conclusions are original fictional teaching material. Only their arithmetic was checked; no actual performance was measured.

## Frequently asked questions

**Does the highest weighted score tell me what to choose?**

It identifies the leading option under the recorded ratings and weights, not an objectively correct choice. Check requirements, evidence and uncertainty before deciding. Keep the authorized choice and its reason separate from the score. Use appropriate qualified advice and formal approvals for consequential decisions; this worksheet cannot replace them.

**What is the difference between a rating and a weight?**

A rating describes how an option performs under a defined criterion and scale. A weight expresses how much that criterion matters within the particular comparison. Use the same scale and weight consistently across the options. Both need an explanation; neither becomes objective evidence merely because it appears as a number.

**Should an unknown rating receive the middle score?**

No. The middle score describes a defined level on your scale, while unknown means the supporting information is missing. Mark the gap and identify what could resolve it. You can explore clearly labeled assumed scenarios, but do not present their totals as measurements or evidence that the option meets a requirement.

**What does it mean when changing weights changes the winner?**

It means the ranking depends on those chosen priorities. In the fictional example, one weighting favors the card and another favors the paragraph. Keep both calculations and explain why each scenario matters. This does not prove either format's real performance or the reliability of a decision under all possible conditions.

**Can a high score compensate for a mandatory requirement?**

Not in this proposed method. Check mandatory requirements separately before scoring preferences; a failure remains a failure, and an unresolved requirement remains unresolved. Ask the responsible owner what actually applies. Do not use an attractive total to authorize protected-data transfers, bypass formal approval or override applicable safety and professional requirements.


---