Give AI a stopping rule for research

You ask AI to compare three scheduling tools for your team. It returns a shortlist, then recommends checking integrations, pricing, reviews, security, support, accessibility, and “future-proofing.” A second prompt produces more criteria. After half an hour, you have a longer answer and still don’t know which details matter for your decision.

Try setting a stopping rule before the research starts: state what you need to know, what evidence would be enough to make the next decision, and what to do when a fact can’t be confirmed. The stopping rule gives the AI a boundary for the task. It also gives you a way to tell whether the answer is ready for your review.

This doesn’t make the search exhaustive or turn the answer into a recommendation you can accept without checking. It helps keep the work focused on a decision you actually need to make.

Set the end point before the search

A broad request such as “research the best scheduling software for us” leaves several choices unstated. Best for which job? For how many users? At what cost? Which required connection or constraint would rule a product out? If the model doesn’t know, it may fill the space with general categories and plausible-sounding detail.

A stopping rule makes those boundaries explicit. For a first-pass comparison, it might say: “Compare these three named products against our two required calendar integrations and a maximum monthly budget of $200. Use current official pricing and integration documentation. Stop when you have checked both requirements for each product. Mark anything you can’t verify as unknown, and give me the source links.”

Now the task has a defined scope, a small set of facts to check, a standard for evidence, and a clear result when the evidence is missing. The AI can help gather and organize information. You can decide whether the checked facts are enough to choose a product, request a trial, or ask a vendor a question.

Google’s prompt design guidance recommends defining the task and its constraints, and describes a trade-off between analyzing everything available and prioritizing speed. Anthropic’s prompting guidance likewise recommends being clear about the desired output and constraints. A stopping rule is one practical way to apply those ideas to a bounded research request. Neither source guarantees that a model will follow the boundary or find every relevant fact.

A short prompt to adapt

Use this structure for a task where a person will review the result before acting:

Help me answer this decision question: [question]. Check only these items: [the specific facts that could change my next step]. Use these sources first: [official documentation, pricing pages, or other sources appropriate to the question]. For each finding, give me the source link and the relevant wording or detail. Stop when you have checked each listed item for [named options or cases]. If you cannot verify an item from an appropriate source, mark it “unknown” and tell me what source or person could resolve it. Don’t infer missing facts or add new research criteria without explaining why they affect the decision. Return a short table with: item, finding, source, and what remains to check. Do not take action or make a purchase.

Change the items and evidence standard to fit your task. If you’re checking an internal process, the appropriate source might be an approved procedure and its owner. If you’re comparing tools, official documentation may establish what a vendor says is supported; a hands-on test may still be needed to establish how it works for your team.

The stopping rule isn’t the number of prompts you send or the amount of text you receive. It’s the point at which the specified checks are complete or their unresolved state is visible. That gives you a useful stopping point even when the answer is “we don’t know yet.”

An illustrative comparison

The following example is hypothetical. It isn’t a report of a real vendor comparison or a tested AI result.

Suppose a team wants to know whether a scheduling tool can connect to its shared calendar and stay within a budget. The team has already named two products to compare and set a ceiling of $200 per month. A broad prompt asks, “Which scheduling tool is best for us?” The answer might discuss the interface, popularity, automated reminders, analytics, and many other features. Some could matter later, but none resolves the two conditions blocking this decision.

A bounded request could say:

Compare Tool A and Tool B for a team of 12. For each tool, check whether the current product documentation lists integration with our shared calendar, and whether the official pricing page shows a plan that covers 12 users for $200 a month or less. Link each source. If the pricing page does not let you calculate the total confidently, say so instead of estimating. Stop after checking those two items for both tools. Return one row per tool and a final list of unresolved questions.

A hypothetical result might look like this:

| Product | Calendar integration | Cost for 12 users | Unresolved question | | ------- | ----------------------------------------------- | -------------------------------------------------------------------------------------------------- | ------------------------------------------------------------- | | Tool A | Listed in official integration documentation | Unknown: pricing page shows a per-user price but not the billing terms needed to confirm the total | Ask whether the displayed price is monthly or annual billing | | Tool B | Not found in the official documentation checked | Under the stated cap according to the listed plan price; confirm applicable taxes and terms | Ask support whether the integration exists under another name |

The table isn’t a product verdict. “Not found in the documentation checked” does not prove an integration is unavailable. “Under the cap” may depend on billing terms, taxes, discounts, or plan limits. The stopping rule helps the model expose those gaps instead of continuing to add unrelated comparisons or quietly filling them in.

The next action is now clearer. The team can ask Tool A about billing terms and Tool B about the calendar connection. If one answer rules out a product, there may be no reason to investigate its analytics or interface yet. If both pass the initial checks, the team can decide what to examine next, such as data access or a trial with a representative calendar.

Choose checks that can change the next step

A stopping rule is only useful if the checks connect to the decision. Before writing the prompt, ask yourself: “If I knew this fact, could it change what I do next?” If the answer is no, it probably doesn’t belong in the first pass.

For example, when choosing a tool, the number of available themes might be interesting, but it won’t matter if the tool can’t meet a required data-handling rule. When preparing a meeting, a long history of an account may be less useful than confirming the next meeting date and the customer’s open question. When reviewing a proposed process, a polished summary matters less than knowing who must approve an exception.

This doesn’t mean you should never investigate secondary details. It means you should be able to say what would make them relevant. If the initial check shows two products meet the required conditions, a comparison of support options may become the next useful question. You can set a new boundary for that question rather than letting the first request grow without limit.

Keep the first pass small enough that you can inspect it. A useful stopping rule might cover three products and two requirements; another might cover one document and one specific question. There isn’t a universal number of sources or criteria that makes research complete. The right boundary depends on what the decision requires and what the cost of an error would be.

Check the stop, not just the answer

When the AI returns a result, review the rule you gave it before reading the recommendation. Did it check each requested item? Did it stop at the stated boundary? Did it introduce a new criterion that may matter, or simply add detail? Did it label missing information, or turn a gap into an assumption?

Then check the sources against the claims. A source link should lead to material that supports the finding, not merely to a company’s home page. Make sure it refers to the product, plan, region, or version you asked about. A vendor’s documentation is evidence of what the vendor currently documents; it may not establish how the feature behaves in your particular account or configuration.

For pricing, check the billing period, seat count, usage limits, and any required add-ons that affect the comparison. For an internal procedure, check that you have the current version and that it governs the situation you’re handling. For a technical integration, a documented connection may still require configuration or permissions. The model’s summary is a guide to what you should inspect, not a substitute for reading the relevant material.

If the answer includes an unsupported claim, ask for the specific source and detail behind it. If no appropriate evidence appears, keep the item marked unknown. Don’t let a plausible explanation become a fact just because it fills a blank in the table.

When the rule needs to change

A result can reveal that the original boundary was too narrow. Maybe the official pricing page shows that a product requires an add-on, making the number of integrations relevant. Maybe a policy refers to a separate approval procedure. It’s reasonable to add a check when new evidence shows it could change the decision.

Make that change explicit. Write down which finding led you to add the new item and why it matters. Then check it separately, using the same standard of evidence. This helps distinguish useful scope adjustment from an open-ended search where every new detail creates another branch.

If the AI proposes an additional criterion, ask what decision it could change and what evidence would resolve it. It may have spotted a real issue, such as a required export format or a data-retention term. It may also be offering a generic suggestion that isn’t relevant to your situation. You decide whether to add it; a model-generated checklist is not automatically your organization’s policy.

Sometimes the right stopping point is a handoff. If the missing fact belongs to a vendor, ask the vendor. If an internal rule is unclear, ask the process owner. If the choice depends on your team’s priorities, agree on those priorities with the people responsible. AI can help frame the unanswered question, but it can’t create authority or evidence that isn’t there.

Where a stopping rule stops helping

A clear boundary can make a task easier to review, but it cannot guarantee a correct answer. The model may use the wrong source, overlook a limitation, misunderstand a requirement, or present stale material as current. A concise answer can still be wrong. That’s why you should inspect the sources and confirm the details that can affect the decision.

A stopping rule also doesn’t make a high-stakes decision safe to delegate. If a result could affect someone’s employment, access, health, finances, legal rights, or a significant customer commitment, use the qualified review process for that decision. An AI-generated table can organize questions; it isn’t authorization to act.

And sometimes there is no short research pass that can answer the question. A product’s documentation may not specify how a feature works with your setup. A vendor may need to confirm a contract term. An internal document may be outdated or conflict with another instruction. In those cases, the useful output is a clear list of what remains unresolved and who can answer it.

Try it on one decision

Pick a small research task you already have: a tool comparison, a procedure question, or a decision about what to ask a supplier. Write one sentence naming the decision. List only the facts that could change your next step. Say which sources count, what the AI should return, and when it should stop. Ask it to mark anything it cannot verify as unknown.

When the response comes back, check whether it followed the boundary and whether the sources support the findings. Note anything it missed, assumed, or added. If the result gives you enough to choose a next step, use that step. If it exposes an unanswered question, send that question to the person or source that can resolve it.

The habit is simple: decide what “enough for this step” means before asking AI to research. That keeps the work tied to your decision and makes uncertainty easier to see. It doesn’t tell you what the final answer should be; it helps you know when the next useful action belongs with you.

Sources: Google’s prompt design strategies and Anthropic’s prompting best practices.