Find Unknowns

Find what neither the user nor you have noticed yet: the hidden problems, goals, constraints, and considerations that would change the result, and what is achievable that the user may not know about. Work from the assumption that at least one consequential unknown exists, and look for it with the field's breadth of cases and expert practice rather than only the material in view. Then give your own view first, ask the user the consequential questions together and early, and carry on with the work already authorized.

The pass applies to any subject, technical or not. It runs either as a quick standalone pass the user asks for, without an interview, or as a lens inside other work, such as a plan, a design, a review, or delegated work; design-exploration and interview apply it this way. Inside other work, put the result where that work keeps its findings and open questions instead of producing a separate document. interview runs this lens before its first round and again when answers open new territory, so a user who wants sustained questioning until something is clear should use interview rather than repeated passes.

In the four-quadrant terms this pass follows: known knowns are what the user has told you; known unknowns are what the user knows they have not worked out; unknown knowns are criteria so obvious to the user that they would never write them down, though they recognize them on sight; unknown unknowns are what the user has not considered at all, including what is achievable. The pass targets unknown unknowns, on your side as well as the user's. The known unknowns it meets become questions or investigation items, and an unknown known is shown rather than asked, with the recognition tools in discovery tools.

Method

1. Inspect before asking

Read what is available before forming questions: the conversation, named files and artifacts, the repository or data involved, prior decisions, and the sources the request points to. A fact that inspection or a quick search can settle is your job, never a question. Note what the request takes for granted and what it leaves unsaid; the scan starts from those gaps.

2. Scan broadly with field knowledge

Name the field and the class of effort the work belongs to, then reason from how efforts of that class usually go:

• Recall how comparable efforts went, including how they failed and what they cost.
• Ask what an experienced practitioner in this field checks first, which pitfalls are standard, and which terms of art a practitioner would use that the request does not.
• Run a premortem: assume the result later failed or disappointed, and name the most plausible reasons.
• List the assumptions behind the request and behind your own reading of it, and ask what changes if each one is false.

When the field is unfamiliar to you or the stakes are high, search for comparable cases, practitioner guidance, standards, or rules where search is available and within the task's authority.

Sweep every dimension below before concluding that nothing consequential is hidden. Dismiss a dimension quickly when it plainly does not apply, but do not skip one because the request looks narrow or the first checks came back clean. Most of the sweep is reasoning from field knowledge and costs little; spend inspection and search where cost, irreversibility, or unfamiliarity is high.

• Goal: what the user is actually trying to achieve, what success means and who judges it, and what would make a correct-looking result useless.
• Hidden constraints: rules, deadlines, budgets, access, compatibility, policies, and norms the request does not state.
• Affected people: who else uses, approves, maintains, pays for, or bears the consequences of the result, and whose incentives differ from the user's.
• Failure and worst case: how the work goes wrong, how bad the worst plausible outcome is, and how comparable efforts failed.
• Cost, irreversibility, and timing: what is expensive or impossible to undo, which windows or deadlines apply, and where the order of steps matters.
• Second-order effects: what the result changes downstream and what it makes harder later.
• Shared assumptions: what both the user and you take for granted, and what evidence would contradict it.
• Practitioner's first checks: the checks and quality bars someone experienced in the field applies before anything else.
• What is achievable: options, tools, or results the user may not know exist, and limits that put an expected result out of reach.

The dimensions guide the sweep. They are not an output template.

3. Sort each finding

Keep only findings that could change the result, then sort each one:

• Resolve by looking: inspection, search, or a quick read settles it. Do it now and report the answer.
• Needs a measurement or trial: only new evidence settles it. Propose the cheapest check that would, such as a sample, a small run, a quote, or a prototype. Run it now when it is cheap and within the current grant; otherwise list it as an investigation item with what its result would change. It is not a question for the user.
• User's decision: it turns on a goal, preference, priority, risk tolerance, or authority that only the user holds. Ask it.

4. Lead with your view

Open with what you think matters most and why: your read of the situation, the finding most likely to change the result, and the direction you would take. Then give the few other findings that matter, each with its evidence or reasoning, and what you resolved by looking. Scan broadly and present briefly: show the findings that change the result, not an inventory of what you checked, so that an unneeded pass costs the user one paragraph to skip. Explain how the field works only as far as a finding needs it, and define any term of art you introduce when the user's familiarity is unclear.

5. Ask the consequential questions together and early

Ask every user decision in one batch, before the work it affects, with the hardest to reverse first. Give each question why its answer changes the result, concrete options, and a recommended default worded so that agreeing is easy.

An unanswered question stays open with a decide-later rule: the point by which it must be decided and what happens until then, such as proceeding with the default on reversible parts or holding the parts that depend on it. Silence or "I don't know" is never consent to a consequential or irreversible step. Ask a question that depends on an earlier answer in a later round, once its premise is settled. When the user's choices need sustained back-and-forth, offer interview and let the user choose it.

6. Continue authorized work

The pass informs the work and does not block it. Continue the authorized work that does not depend on open answers, and hold only the parts that do. The pass grants no new authority: ask before changing direction, exceeding resources or access, taking a new external action, or starting a long new activity.

The pass is complete when the user has your view, the findings that change the result with their evidence, the checks you ran or propose, and one batch of questions with defaults, and the authorized work is moving.

Scope and Optional Tools

Skip an unrequested pass for small or mechanical edits, well-specified work, and requests to proceed without discussion. An explicit request for blind spots runs the pass even on specified work, since a specification does not establish that its assumptions hold. A request to be interviewed or questioned until something is clear belongs to interview, which applies this pass inside its rounds. When a domain-specific skill owns the task, follow it and apply this pass to what it does not cover.

Read discovery tools when the scan shows that the dominant unknown is one direct questions handle poorly: an unsettled direction (option map), an unknown known the user can recognize but not describe (throwaway variants or a reference request), or dependent choices that need a short follow-up exchange (mini-interview). The same file covers the comprehension check, which runs only when the user cannot verify the result directly and wants one.

Results and Records

Return the result in chat by default. Write a launch brief only when the user asks for one or the work is being handed to another session, agent, or plan; adapt the template and drop the parts that do not apply. When the user asks for a plan, use work-plan with these findings instead of another discovery round. To transfer the session itself, use session-handoff. Record findings in a file or in the project's existing records only when the user asks or the task already maintains them.

Gotchas

• Narrowing while scanning. A request that looks well defined invites stopping after a few clean checks, and the unnoticed unknown usually sits in a dimension nobody looked at. Finish the sweep, quickly where a dimension plainly does not apply.
• Teaching instead of finding. A tour of how the field works reads as useful but changes nothing. Each finding names what it changes in this work.
• Presenting the inventory. Listing every dimension checked buries the one finding that matters. Report the scan's results, not its coverage.
• Defaults becoming decisions. A recommended default the user did not accept stays an open item with its decide-later rule.

Source

The four kinds of unknowns, the blind-spot pass for unknown unknowns, and the option maps, variants, and references for unknown knowns adapt Thariq Shihipar, "A field guide to Claude Fable 5: Finding your unknowns" (Anthropic, 2026-07-06), rewritten here. This version leads with its own view, and where the article interviews one question at a time, it asks the consequential questions together in one batch.