Separate observations from interpretations before you ask the agent

A weekend of search tickets lands in the channel: “search is broken,” a screenshot of an empty panel, a query that later finds three notes. The temptation is to paste the pile into Claude Code or Codex and ask what is wrong with search. The model will treat every guess in that pile as if it were a fact. The cheaper work is earlier, and it is visual: put what you actually observed on one side of the board, and what the team thinks those observations mean on the other, before you ask anyone to jump.

This is a different step from unpacking a fog until you can name a question, and different from lining up options. Here the question is already half-formed. The risk is that a leap has already been smuggled in as if it were part of the evidence.

A weekend of empty search

Say the product is a local-first desktop notes app. Over the weekend you collected:

• A support quote: someone typed yesterday’s note title, got nothing back, and still opened the file from the sidebar.
• A Sunday screenshot of the search panel: query invoice Q3, blank space underneath, no “0 results,” no hint, no spinner in the crop.
• A Monday debug log after reopen: the same query returned 0 hits in 1840 ms, then 3 hits in 62 ms, with no error line between them.
• Stopwatch timing: about 1.8 seconds for the first search after opening the folder; 40–80 ms for later searches in the same session.

Those are observations. They do not yet say why. Next to them, the team already has leaps:

• The index is stale: an empty first result and a slow first search mean the index was not ready after reopen.
• The query parser drops the title: invoice Q3 is split or scored so a remembered title does not match.
• The empty state is too quiet: people said “search is broken” because they could not tell a slow first search from a true empty set or a hung panel.

The stale-index story is tidy. It may also be wrong. A quiet panel can produce the same tickets without anything being wrong with the index.

Two piles, not one blob

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

• context.md: the weekend of tickets, and nothing more.
• Observations: obs-support-quote.md, obs-empty-results-screenshot-note.md, obs-query-log.md, obs-timing.md. Facts and quotes only. No “so the index is stale” on these cards.
• Interpretations: interp-index-stale.md, interp-query-parser.md, interp-ui-too-quiet.md. Each is explicitly a leap.
• pressure-test.md: the ask you are finally willing to make, for example: “Does an empty first result plus a slow first search after reopen actually imply a stale index? Or could a quiet empty-state UI explain the tickets on their own?”

Drag them the way you would scraps on a whiteboard. Context at the top. Observations in a pile on the left. Interpretations in a pile on the right. The pressure-test at the bottom, under the facts that might support or undo the leap. 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 piles around without turning a seating plan into a merge conflict.

Your eyes can now see what a pasted prompt hides: three interpretations across from four facts, and only some of those facts even speak to the first leap.

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 right. BaseHalf does not sort observations from interpretations for you. You move them until the two kinds of sentence stop occupying the same space.

Draw a line only when A should keep feeding B. Once pressure-test.md exists, connect the empty-panel note and the timing note into it if that evidence should travel with the ask next week. A Markdown note stores that list in its frontmatter, under upstream:. Leave the support quote and the query-parser leap unconnected if they are not what this pressure-test is about. Sitting in the left pile is a hunch that they are observations. A line is a claim that context flows.

Select the leap, not the whole board

You are not asking “what is wrong with search.” You are asking whether two observations (empty first results and a slow first search after reopen) actually imply a stale index, or whether a quiet empty state could explain the tickets by itself.

Select that pressure-test card plus the observation cards that belong to it. If you want the agent to attack a specific leap, add that one interpretation (the stale-index note) and leave the query-parser guess out. 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 “diagnose search.” Ask the model to pressure-test that leap against those observations.

What to keep after the answer

Keep the named pressure-test, the observations that actually mattered, and a short note on whether the leap held. If they should keep traveling together, leave or adjust the upstream list. An interpretation that collapsed can stay as a warning, or you can delete it. 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 observations true. If the screenshot hid a “0 results” line that was actually there, or the timing was a slow disk rather than search, you will pressure-test a neat wrong leap and the model will answer it fluently. The canvas makes the jump visible. You still decide whether to believe the landing.

Put observations on one side and interpretations on the other before you ask. Write upstream only for evidence that should stick to the named test. Select that slice, and then ask the agent.