AI Adoption GuideResearchShallow Assess
Sensitivity-driven research scoper
Ranks which inputs would most reduce decision uncertainty
Research processScopeSourceTriageShallow AssessDeep AssessDecideHand Over
By Don, DoneThat’s AI coach · updated
The output is a ranked list of questions worth answering next
The scarce thing in a first-pass review is not information. It is reviewer time. This job produces a ranked list of inputs, ordered by how much resolving each one would change the decision in front of the team. The top of the list is where the next two weeks of work should go.
The ranking is about the decision, not about the topic. An input can be fascinating, poorly understood, and irrelevant to a choice between two options, because both behave the same way across its plausible range. It belongs at the bottom of the list even though everybody wants to discuss it.
The list is not an answer to any of the questions, not a probability that a candidate succeeds, and not a recommendation. A row reads as: this input, this plausible range, this is where the preferred option would flip, this is what it would cost to narrow it.
Teams that cannot state the decision precisely often find the round was never stuck on a shortage of evidence.
Nothing runs until the decision, the options, and the rule are written down
Four things have to be on the page before any ranking is meaningful.
The decision, as an action somebody takes on a date. Progress this site to full feasibility, fund this trial, or stop. A topic is not a decision. Ranking inputs against "understand the market better" produces a list that reorders itself every time the phrasing changes.
The options, as a closed set. Sensitivity is a statement about the gap between alternatives. With one option on the table, every input looks important, because there is nothing for it to change.
The decision rule, stated in advance. Which quantity or condition determines the choice, and at what level the answer switches. A rule written after the evidence arrives is not a rule, and the ranking cannot be computed against it. If the criteria are shaky, run them through the critique of proposed criteria for gameability and gaps first.
The uncertain inputs, each with a plausible range and its provenance. This is the part that gets faked most often, and a fabricated range corrupts the whole ordering.
When any of the four is missing, the correct output is nothing, with a note naming the gap. A ranked list built on an unstated decision rule still looks convincing, and it sends a team to research the wrong thing with unusual confidence.
Rank by whether resolving an input would change the choice, not by how uncertain it feels
The ordering follows one test: move each input across its plausible range, hold the others at their central values, and record whether the preferred option changes. Inputs that flip the choice rank above inputs that only move a number.
Report the switching point, not just the rank. A row saying the choice flips when a value crosses a stated threshold is usable, because the team can often say from memory whether the real value sits near it. A row saying an input is highly influential is not.
Separate two properties that get blended into one score. How wide the uncertainty is, and how much the decision cares. An input can be badly known and irrelevant, or tightly known and decisive at the margin. Two columns show which kind of row a reader has.
Add the cost of resolution as a third column. An input that would flip the decision but needs an eighteen-month field study does not belong at the top of a two-week list. The useful ranking weighs influence against the cost of narrowing the range.
Mark correlated inputs as a group. When two assumptions move together, resolving one alone shifts less than the single-input test suggests, and the list will otherwise recommend the same work twice. Where the analysis is a model rather than a spreadsheet, the sturdier test is the re-run of the actual model under alternative parameterisations.
Scope the next two weeks on a grid-scale storage site
The site, the fund, and every number below are invented. An appraisal analyst at an infrastructure fund is deciding whether to progress a grid-scale battery site to full feasibility, or progress a second site instead. The investment committee's rule is a threshold on modeled lifetime return, and the two sites sit close together.
Five uncertain inputs go in, each with a range and a stated source. Grid connection date, between 30 and 54 months out, from the developer's disclosed queue positions. Annual curtailment hours, from a regional operator publication. Cell degradation rate, from vendor warranty terms and test reports. Balancing market revenue, from a broker forecast. Land lease escalation, from the draft heads of terms.
The ranking returns connection date first. Moving it from 30 to 54 months flips the preference to the second site, with the switching point at roughly 41 months. That sits close enough to the middle of the range to matter.
Degradation rate ranks second but does not flip anything on its own. Across its full range the preference holds, and the row records that.
Balancing revenue ranks third, grouped with curtailment hours because the two move together. Land lease escalation ranks last, moving the return by less than the gap between the sites.
The outcome: two weeks on the queue position and the operator's connection timetable, not the degradation debate engineering had prepared for. Nobody has decided anything about the site.
Ranges invented by a model will reorder the whole list
Ranges are the easiest thing in this workflow to produce without evidence.
A model asked for a plausible range will supply one. It will look reasonable and have no provenance. Require a source on every range, and treat a sourceless range as a blocker. One wide invented range at the top of the list sends a team to research a question nobody needed answered.
Symmetric ranges hide skew. Permitting timelines, recruitment rates, and delivery schedules overrun far more often than they underrun. A range centered on the plan understates the input that most often breaks the case.
Local sensitivity misses interactions. Varying one input while holding the rest fixed will not find a combination where two moderate deviations together flip the decision. State that limit on the artifact, and test the combinations the team already worries about.
A ranking becomes stale the moment the decision rule changes. Any change to the options, the threshold, or the timeline invalidates the order. Date the list and re-run it rather than editing rows.
The subtle failure is treating a low rank as a verdict on importance. An input can be irrelevant to this choice and central to the next one. Write the scope on the artifact so a later reader does not mistake a scoping list for a judgment about the subject.
The analyst owns the ranges, and the decision maker owns the rule
Ranges are evidence claims and need an owner. An analyst signs each one: what it rests on, when it was set, and how confident they are in the bounds. The signature makes a row challengeable in a meeting.
The decision rule stays with whoever will make the call. A committee may change the threshold after seeing the ranking, and that triggers a re-run. What is not legitimate is adjusting the rule so the work somebody already wanted arrives at the top.
The list recommends effort, never conclusions. A high rank means an input is worth resolving. It does not mean the input is unfavorable, and no row is evidence about the candidate.
Turn the top rows into work somebody can pick up. Each becomes a scoped brief with a question, a method, and a stopping condition, in the shape the packager that turns open uncertainties into actionable briefs produces. Where the answer sits with a named specialist, surfacing relevant named experts beats another literature pass.
When the round closes, record which inputs were resolved, which were not, and how the call was made. That record belongs with the decision captured as a distribution rather than a binary, because the honest version of most calls is that two of the top three questions were still open.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other. This one is rated high effort to implement, so the baseline matters more than usual.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first