Lay out what you know, what you assume, and what you still need before you ask

A decision lands in the channel with a mix of hard facts, things everyone is already treating as true, and questions nobody has answered. The temptation is to paste the pile into Claude Code or Codex and ask what you should do. The model will treat a guess the same way it treats a booking on the calendar. The cheaper work is earlier, and it is visual: put what you actually know in one pile, what you are only assuming in another, and what you still need to find out in a third, before you ask anyone to choose.

This is a different step from unpacking a fog until you can name a question, and different from lining up options or separating a quote from a leap. Here the question is already on the table. The risk is that an assumption has already been filed as if it were a fact, and an open gap has already been skipped.

A public API this quarter

Say a local-first desktop notes app is deciding whether to ship a public API before the quarter ends. On the table you already have:

• Two enterprise leads asked for API access last month, both in writing. One wants to pull notes into a dashboard. The other wants to create notes from an internal form.
• The only official way out of the app today is a manual CSV export. There is no documented HTTP API, and no official SDK.
• A four-week performance sprint starts next Monday. It was committed in the last planning meeting.

Those are knowns. They do not yet say you should build an API, or that you can. Next to them, the team is already treating some things as true:

• The two leads are a pattern: more customers will want the same thing, even though no one has asked the rest of the list, or counted how many people already script the CSV export.
• A thin API (list folders, read a note, create a note) fits in two weeks after the sprint, including docs and auth. That number has not been estimated against the current codebase.
• Current support headcount can absorb v1 tickets, key resets, and “why is my token 401.” No one has looked at last quarter’s ticket load with an API in the mix.

And some questions are still open:

• How many customers would actually call a v1 API in the first 90 days?
• Do both leads need a general public API, or would a narrower export or inbound hook be enough?
• If work starts now, does the performance sprint slip a month, lose a week, or split the team?

The “two weeks after the sprint” story is tidy. It may also be the assumption that, if false, should shrink the decision before anyone writes a route.

Three piles, not one brief

Open the project folder in BaseHalf. Each file becomes a card. Write short notes, one idea each:

• context.md: the decision on the table, and nothing more: not a yes, and not a plan.
• Known: know-two-leads.md, know-csv-only.md, know-perf-sprint.md. Facts you can point to. No “so we should ship an API” on these cards.
• Assumptions: assume-leads-are-pattern.md, assume-two-weeks.md, assume-support-ok.md. Each is explicitly a thing you are treating as true without having checked it.
• Still need: need-90-day-demand.md, need-smallest-surface.md, need-sprint-cost.md. Questions, not answers.
• ask.md: the question you are finally willing to put to an agent, for example: “Which of these assumptions, if false, would kill or shrink a public API this quarter? What is the cheapest way to test the two highest-risk ones before we touch the performance sprint?”

Drag them the way you would scraps on a whiteboard. Context at the top. Known in a pile on the left, assumptions in the middle, open questions on the right. The ask at the bottom, under the facts and assumptions that might actually change it. A short label card at the head of each pile helps your eyes keep the three kinds of sentence apart. That arrangement is for your eyes. Card places and sizes live under .bh/ and stay out of git through BaseHalf's own ignore file (it never touches your .gitignore), so you can keep sliding the piles around without turning a seating plan into a merge conflict.

Your eyes can now see what a pasted prompt hides: three assumptions sitting between three facts and three open questions, and only some of those cards even speak to the first decision.

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

Once the board looks like a diagram, three moves are easy to mix up.

Sitting together is a way to look. It is not a semantic relation, and not a claim that every card in the left pile proves every card in the middle. BaseHalf does not sort knowns from assumptions for you. You move them until the three kinds of sentence stop occupying the same space.

Draw a line only when A should keep feeding B. Once ask.md exists, connect the two-leads note, the performance-sprint note, and the two assumptions you want to pressure-test, if that context should travel with the question next week. A Markdown note stores that list in its frontmatter, under upstream:. Leave the support-headcount assumption and the “smallest surface” question unconnected if they are not what this ask is about. Sitting in the middle pile is a hunch that a card is an assumption. A line is a claim that context flows.

Select the slice, not the whole board

You are not asking “should we ship a public API.” You are asking which assumptions, if false, would kill or shrink that work this quarter, and how to test the riskiest ones cheaply before the sprint moves.

Select that ask card plus the assumption cards that belong to it. If the two-leads note is the fact those assumptions rest on, add it; leave the open questions and the support-headcount guess out of this pass if they are not what you want judged yet. A dragged box or a Shift-click builds the set; the rest of the board can stay visible without being poured into the prompt. Selection is what Claude Code or Codex can see for this ask in the Agent Area. BaseHalf is not itself an agent.

Then ask. Not “write the API plan.” Ask the model to name which of those assumptions would actually change the decision if they fell over, and what would be enough to check them.

What to keep after the answer

Keep the named ask, the assumptions that turned out to matter, and a short note on whether each one held, was downgraded, or still needs a check. If they should keep traveling together, leave or adjust the upstream list. An assumption that collapsed can move into Known as a corrected fact, or stay in place as a warning. Do not promote the whole left pile into permanent links just because the facts sat near each other.

Limits

Separating the piles does not make the knowns complete, or the assumptions the right ones to test. If the two leads were already told “yes,” or the sprint was never as locked as the note claims, you will pressure-test a neat wrong frame and the model will answer it fluently. The canvas makes the missing check visible. You still have to run the check.

Put what you know, what you assume, and what you still need in different piles before you ask. Write upstream only for the slice that should stick to the named question. Select that slice, and then ask the agent.