Lay out the conditions for a yes before you write it

A proposal lands in the channel already wrapped in a preference. “Let’s do Friday’s workshop in the office. In-person always has better energy.” The temptation is to treat that feeling as if it were already a reason to say yes. The cheaper work is earlier, and it is visual: put the conditions that would make a yes legitimate in a row, put a real check next to each one, and leave a preference that is not a condition outside that row, before you write the yes.

This is a different step from unpacking a fog until you can name a question, from lining up options against a checklist, from separating observations from interpretations, from sorting facts, assumptions, and open questions, from keeping a problem away from the fixes already being offered, or from weighing evidence for and against. Here the question is already named. The risk is that a preference, or a condition nobody has actually checked, gets treated as if it were already a reason to go.

Should Friday's workshop be in the office?

Say a small team is arguing about this. Around the proposal, people have already collected things they can point to.

These are the conditions they wrote down for a yes:

• The room is booked Friday 14:00–17:00. Facilities confirmed the booking on Tuesday. The calendar hold is for the main room, 14:00 to 17:00. This is a booking, not a guess that a room will be free.
• Seven of ten people can come in person. The Thursday form closed with seven yes, two who will join remotely, and one person who has not replied. The bar they wrote down was six of ten in the room.
• The projector was tested on Wednesday. Alex plugged a laptop in that afternoon. The picture was fine, and audio came from the room speakers. This is that test, not a hope that the cable will work on Friday.
• A join link for the people who cannot come has been created, and a laptop in the room has been used to test that the room can share audio with them. This one is still open: no link has been created, and no one has run that test.

And then there are two sentences that are not conditions:

• “In-person workshops always have better energy.” That is a preference, and a habit of talking.
• “It would be nice to get lunch together beforehand.” A lunch is optional. It does not make a yes legitimate.

On a BaseHalf canvas, those notes are ordinary Markdown files in one folder. The row of conditions is for your eyes. The preference cards sit off to the side of the question, so they cannot pretend to be a check.

A row is not a connection, and neither is a selection

Sitting in the conditions row does not make a note part of the conclusion. A connection does. In BaseHalf, a line from A to B means A is upstream of B: A's context flows into B, and the list is saved in B, in the frontmatter of a Markdown note. The conclusion on this board is connected to the four condition notes, including the missing join link. That missing check is part of what the conclusion stands on. It is why the answer is not a yes yet.

The two preference cards stay outside the row, without a line. Energy and lunch may still matter to someone. The conclusion does not use them, so they are not declared as its upstream.

You can still point at a slice without changing those lists. A selection is temporary. It is what “this” can refer to if you later ask an agent. It is not written into the conclusion, and it does not force an agent to read only those files. A request that names something else still wins.

Select the slice the conclusion already named

For this decision, the slice is the conclusion and the four condition notes it is connected to. The preference cards stay visible on the board, and they stay out of the selection.

If you then ask Claude Code or Codex, ask about that slice. Not “should we do it in the office because the energy is better.” Ask whether those four notes can support the hold the conclusion names: keep the room, keep the in-person plan for the seven who can come, and do not send the yes until a join link exists and a laptop in the room has been used to test it.

What to keep after you decide

Keep the named question, the conclusion, and the upstream list that says which conditions it rests on. Leave the preferences parked, so they are not mistaken for checks the next time someone opens the folder. When the join link is created and tested, update that condition note, and only then consider writing a yes. Do not connect a preference just because it sat nearby.

Limits

A row of conditions does not make the list complete, or the checks the right ones. If six in the room was never a real bar, or the Wednesday projector test used a different laptop than Friday's speakers will see, you will have a tidy board that still misses the failure. The canvas makes it visible which conditions you chose to stand on, and which one is still open. You still have to run the missing check.

Put the conditions for a yes in a row before you write the yes. Write upstream only for the conditions that conclusion actually uses, including a missing check that blocks it. Select that slice if you want to ask an agent about it.