How do I find out what we decided, and why, months after the meeting?

The answer lives in the meeting notes, but only if each decision was written as a line that can be found again, and the reason was written beside it. Dated notes make the rest mechanical: you ask for every block carrying a decision line, read the table, and open the original block behind any row you want to check.

The reader this is for already writes notes after meetings and now needs one answer back. Someone asks why checkout retries are capped at three, or whether anyone ever settled the refund question, and the notes are in a folder of dates. The search that works depends on a habit of two short lines, and the rest of this post shows the habit, what the app reads from it, and where it stops.

Why a decision is hard to find later

A decision is usually written inside a paragraph of discussion. The paragraph says what was argued, who objected and what the group landed on, and a search for the word "decided" finds every meeting where anyone ever decided anything. You get forty hits, each needing a read, and the reason for the decision is often in a different sentence from the verdict.

The second difficulty is that the decision changes. A cap set in March can be raised in May, and a reader who finds only the May note has the current rule without the history that explains it. The notes hold both, but they are two blocks on two dates, and nothing ties them together unless you ask for them together.

Write the decision and the reason on their own lines

Under each date line, start one line with decided: and another with because:. The parser reads a date on its own line as the date of everything after it, so the meeting is already dated, and the two prefixed lines are plain text that any editor can produce. Here are three meetings written that way, with invented content.

12/03/2026
Checkout sync with @dana. #checkout
decided: cap checkout retries at 3.
because: the retries in INC-9021 stacked up on the payment queue.

02/04/2026
Tunnel review with @dana.
decided: keep the old tunnel config until TICK-1842 closes.
because: the new config dropped twice in one week.

19/05/2026
Checkout sync with @dana. #checkout
decided: raise checkout retries to 5.
to confirm: whether the retry cap applies to refunds.

The third meeting records a decision without a reason, which is the normal state of notes written in a hurry. It also records an open question, which gets its own treatment below.

Ask for the decisions as a table

Write a statement inside double curly braces in any block, and it becomes a live table wherever that block is shown. This one lists every block with a decided: line, newest first, with a column for each line prefix you name.

{{ rows has:decided show decided, because }}

Each row carries the block's date and its first line, plus one cell for every prefix named after show. A cell shows the first line with that prefix in the block, and says "not written" when the block has none, so a missing reason is visible rather than blank. Run over the three meetings above, it produces the table below.

You can bound the table to a window, for example in 2026-01-01..2026-03-31 or in 90d, so the question "what did we decide last quarter" has a direct form. The table lists at most 50 blocks and says "at least" when there are more, so a long history does not quietly lose rows.

Open the original lines behind any row

A table of extracted lines is only as trustworthy as your ability to check it. Every row links to its block, so the reason you were shown can be compared with the meeting as you wrote it, including the sentences around it. The count of matching blocks opens exactly the blocks in the table, which means the number and the list cannot disagree.

The same habit runs through the rest of the app. A count on the recap, quiet and diff pages links to the blocks behind it, and every value an instrument shows links to the exact blocks it was read from. If a table ever looks wrong, you do not argue with it, you open the rows and read the source. Blocks you have locked are the exception: they keep their date and their place in the count, but show neither text nor values.

Follow a decision through later changes

When a later meeting changes an earlier decision, say so with a relation line. A line that begins with addresses:, reverses:, follows: or led to: and carries a ticket reference writes a link from that block, and the target block's page shows the inverse wording, such as "Block 14 LED TO this block". Those words also work as a selector, so {{ rows reverses:* }} lists every block that reversed something.

Relation lines attach to ticket references, not to other decisions, so the chain only exists where a ticket number was written into the note. That fits the example above: the retry cap and the raise both name the checkout, and a ticket reference on each would tie them to the incident that prompted the first one.

Keep the open questions in view

An unanswered question is a loose end. On the Loose ends page you teach the phrases that open something, such as to confirm, and the phrases that close it, such as resolved. A block is listed when it holds an opening phrase and names at least one subject, such as a tag, a ticket or a host. A later block about the same subject that holds a closing phrase closes it, and a closing block written on the same day as the opening one does not count.

In the example, the refund question on 19 May names #checkout, so it is listed with the block that raised it and the number of days with no closing note. Opening that item shows the later mentions of the subject, so you can see whether someone answered it in other words. The page can also be read as of an earlier date, which shows what was open then.

What this does not do

Nothing here finds a decision you did not write as a decision. A paragraph that says "we agreed to leave it" contains no decided: line, so the table skips it, and the app does not guess. Reasons behave alike: a cell is the first line with that prefix, so a reason spread across three sentences is only partly shown, and the original block is where you read the rest.

The Loose ends page is bounded as well. Only the most recent blocks that name a subject are read, and a subject you write about very often can stay listed after you closed it, because each subject is checked for a close in a limited number of later mentions. A cue the app was not taught is invisible to it, so a question phrased in other words reads as nothing at all.

The cheapest improvement is at the moment of writing. Two prefixed lines added while the meeting is fresh are the difference between a table you can read in a minute and a search through forty paragraphs.