Join for free

Turn research findings into a decision recommendation with limitations

Author: AILesson9 min setupTested with:ChatGPTReviewed: 2026-08-28

Quick answer

Connect research evidence to a bounded recommendation, alternatives, risks, conditions, and next validation without overstating certainty. Provide: Decision and options, Research findings and evidence, Limitations and decision context. Expected result: A decision memo with evidence chain, recommendation scope, alternatives, limitations, dissent, triggers, and verification plan.

1

Add your context

Your text stays in this browser. AILesson Prompts does not send it to a model or server.

2

Your prompt

Unfilled fields remain visible as placeholders, so you can still copy and edit the prompt

Write a decision recommendation from the supplied research without exceeding its evidence.

Decision and options:
[decision]

Findings and evidence:
[findings]

Limitations and context:
[limits]

Build an explicit chain from decision criterion to relevant finding, source evidence, confidence, implication, and residual uncertainty. Separate observed finding, interpretation, recommendation, business assumption, feasibility input, and decision. State what populations, contexts, behaviors, and outcomes the research does and does not support. Evaluate each supplied option, including status quo, against the same criteria; retain counterevidence, minority needs, harms, dependencies, and dissent. Do not convert qualitative counts into prevalence, prototype behavior into production outcomes, stated preference into actual behavior, correlation into cause, or research into decision authority. Recommend a bounded, reversible action when supported, or recommend more evidence when a material uncertainty could reverse the choice. Include conditions, guardrails, owner placeholders, success and stop signals, next validation, and a decision log.
Private by defaultPrompt assembly happens locally in your browser. Avoid placing confidential information into any AI service unless your organization allows it.

From input to outcome

A worked example

See how concrete context turns this recipe into a usable result

Actual input

Decision and options
By 20 September, the GM must choose: A build membership pause for all monthly members now; B run a limited beta; C keep cancel-only and do more research. Goal is reduce avoidable cancellations without creating billing harm or unmanageable support. Capacity allows a four-week beta, not a full hardened release. Success for beta: at least 80% of eligible pause attempts complete without support, billing-error rate zero in verified transactions, and support contacts no more than 8 per 100 attempts. Any real incorrect charge stops beta. GM decides; research recommends only. Annual plans and involuntary payment failures are out of scope.
Research findings and evidence
F1 interviews: 18/24 current monthly members described wanting a temporary break; purposeful sample of people who had considered cancellation, so not prevalence. F2 analytics: 420 monthly cancellations in July; 96 selected ‘temporary financial or schedule reason,’ but reason field is optional and self-reported. F3 prototype test: 8 participants; 5/8 completed pause task unaided with all terms correct, 2/8 partial, 1/8 chose cancel; confusion involved next-cycle start and automatic resume. F4 support-ticket review: 27 of 310 July cancellation contacts asked about temporary suspension; coding checked by two researchers. F5 counterevidence: 4 interviewees preferred a clean cancel and later rejoin; support warns timezone and refund questions could increase load. No experiment measures whether pause reduces cancellation or revenue loss.
Limitations and decision context
Purposeful interview and usability samples; July only; cancellation-reason selection may be biased; support tickets omit customers who did not contact support. Prototype had no real billing, email, accessibility semantics, analytics, or backend. Engineering estimate 3–5 weeks and notification dependency unresolved. Legal and finance have not approved terms. Accessibility review required. Beta can use 10% of eligible monthly members, exclude accounts with credits or pending refunds, and use manual daily reconciliation. Product manager, engineering, support, finance, legal, and accessibility owners are not yet named in the record.

Example output

Decision recommendation — choose a guarded beta, subject to readiness gates

Recommendation: Option B, a reversible 10% beta for eligible monthly members, is better supported than a full release or indefinite status quo. This recommends learning safely; it does not claim pause will reduce cancellations. Capacity supports a beta but not a hardened release. GM retains the decision.

Evidence chain: The need criterion has medium confidence: repeated interview accounts (18/24 in a selected sample), 96 optional cancellation reasons, and 27/310 cancellation contacts all indicate a temporary-break use case, but none estimates population demand. Usability readiness is low-medium: 5/8 prototype participants completed unaided with correct terms, while three had material friction, including one choosing cancel. Billing safety is unknown because the prototype had no backend. Support sustainability is unknown and may be harmed by timezone and refund questions. Outcome impact on cancellation or revenue is completely unmeasured.

Option A fails current readiness: no real billing evidence, unresolved terms, accessibility, notification dependency, and a 3–5 week estimate against four-week capacity. Option C avoids immediate billing risk but leaves convergent need signals untested and cannot answer behavioral impact. Option B can test behavior with bounded exposure if mandatory gates pass. Four interviewees' preference for cancel must remain available; pause must not obstruct cancellation.

Readiness gates before beta: Finance and Legal approve terms and test cases; Engineering resolves notification dependency; accessibility review passes; support scripts and escalation exist; analytics distinguish view, start, complete, cancel, contact, and error; named owners approve daily reconciliation; accounts with credits or pending refunds are excluded. Missing owner names are blockers, not assignments.

Success/stop: evaluate the supplied 80% unaided completion and 8 contacts per 100 attempts with explicit denominators; require zero verified billing errors. Stop immediately for any incorrect charge, misleading term, failed reconciliation, or inaccessible critical path. Do not interpret beta selection as retention impact. Next decision requires completion, error, contact, cancellation-after-pause, and qualitative issue evidence, plus costs and minority harms. Log GM choice, exceptions, owners, dates, evidence, and the condition for broader release.

Why this works

  1. 1

    An evidence-to-criterion chain makes the recommendation auditable instead of rhetorically persuasive

  2. 2

    Reversal conditions reveal which uncertainties matter enough to change the decision

Check the result

  • Does every recommendation claim trace to a finding that can support that scope and outcome?

  • Are alternatives, status quo, counterevidence, minority needs, harms, and residual uncertainty visible?

  • Are decision authority, guardrails, success signals, stop signals, and evidence that could reverse the choice explicit?

Use it with confidence

Frequently asked questions

Practical answers about when to use this recipe, what to provide, and where human review still matters

What should I prepare before using “Turn research findings into a decision recommendation with limitations”?

For “Turn research findings into a decision recommendation with limitations,” prepare Decision and options, Research findings and evidence, and Limitations and decision context. Replace placeholders only with information you can verify. If a detail is unknown, preserve that uncertainty explicitly instead of asking the model to infer it.

When is the “Turn research findings into a decision recommendation with limitations” result not ready to use?

The result is not ready if it does not yet deliver the stated outcome—A decision memo with evidence chain, recommendation scope, alternatives, limitations, dissent, triggers, and verification plan—from the supplied evidence, or if it relies on unresolved assumptions, missing approvals, or invented details. Use the checks as release gates: revise the source inputs or assign a named, authorized reviewer instead of polishing an unsupported output.

Which AI tools have recorded tests for “Turn research findings into a decision recommendation with limitations”?

The published test record for “Turn research findings into a decision recommendation with limitations” lists ChatGPT as of 2026-08-28. This confirms recorded runs, not guaranteed compatibility or identical results in later product versions. For another tool or version, keep every constraint visible and repeat the result checks before use.

More ways to explore

Where this recipe fits

Text promptsProduct & user researchFor managers

Keep the work moving