The following method is used to take a business question, build an evidence base, and turn it into insights the customer can act on, clear about where the evidence is solid and where it is thin, across days of work and many sessions.
Research is useful when the customer trusts the sources it rests on, helped shape the framework behind it, and trusts that a solid process was used to collect and analyze the data. A proprietary platform built for research with large language models carries the work, holding the analysis steady across days and many sessions and pulling from hundreds of sources across more than one tool. The analyst supplies the plan and the judgment. The platform supplies the reach. The result is meant to hold up when the customer builds a decision on it.
The method starts by building a shared understanding of the work before any data is pulled. That artifact is the problem statement.
The problem statement is not a brief written once and filed. It is worked from the top down and the bottom up, and revisited as the work teaches the analyst something new. It has eight parts, shown in Diagram 1. One of them, the customer's goal, anchors the other seven; domain, scope, assumptions, and the rest are set in service of it.
Diagram 1. The practice at a glance. The problem statement across the top, with the customer's goal as the part the others serve. Below it, the three areas of engagement work.
Several of the eight parts earn their weight by naming edges early. Expected limitations tell the customer where the evidence is likely to be thin before time is spent chasing it. Scope and boundaries do the same from the other side, and the clearest boundary is often what the work will not do. In an analysis of the physician value equation, for instance, the analyst can set at the start that the work will not compute ROI. Sources and synthesis settles what kind of evidence will drive the direction. Naming these early is what lets the analyst and the customer agree on what a good result will look like.
A research plan addresses three questions, shown as the three columns of Diagram 1: who is involved, what gets done, and what the customer walks away with.
Who's in the Loop sets ownership. The customer owns the goal and the reality check. The analyst owns sequencing and judgment. The tools are licensed and used within a set scope.
What Gets Done is the shape of the work: frame the goal, break the problem into parts and design the effort, then build evidence, analyze, and deliver. What Gets Delivered is the tangible result: the shared understanding and research plan, the base research and any applied modules, and the cross-section synthesis that turns evidence into insights the customer can use.
Two things run through the three areas rather than sitting inside any one of them. Diagram 1 places them as bands beneath the columns: the analyst's judgment and the platform.
A capable model will answer almost any question put to it. The value of the work is not in the answering. It is in deciding what to ask, in what order, and whether the results make sense. That decision is the analyst's, and it shows up at five points that carry the engagement:
These are judgments, not requests a tool fills on its own. A model can read and reconcile sources faster than any person. It cannot decide, on the customer's behalf, which disagreement between two sources changes the decision on the table. That call is the work the customer is paying for. The platform makes the work faster and wider; it does not remove it.
The platform is what lets one analyst work at the scale of a team and stay confident in the result as it grows. It is built for research with large language models over days and many sessions, and it does four things a general chat window does not.
Pulling from many sources and more than one tool surfaces disagreements between them. Reconciling those disagreements, filling the gaps, and settling the conflicts is the verification work described in Section 7; the platform gathers the material, and the verification loop is where it earns confidence.
The work keeps an audit trail of each step, each edit, each version. The analyst and the customer can trust the work as it accumulates, because how each finding was reached stays visible.
An engagement runs the same three steps twice: set the goal for understanding, settle the dimensions to explore, then collect and validate the evidence. The first pass builds the evidence base; the second turns it into what the customer needs to decide. Diagram 2 shows the two layers.
Diagram 2. Structure applied twice. The problem statement anchors both layers. Layer 1 builds the foundational research; Layer 2 turns it into the customer's insights. Each layer runs the same three steps, and the two right-hand boxes, collection in Layer 1 and analysis in Layer 2, are where most of the effort concentrates.
Layer 1 is foundational research. Its work is to build data shaped for the fullest understanding of each part of the domain, made to serve many analyses rather than one. Each part starts from a goal for understanding rather than a question list, set against the problem statement. The analyst then settles the dimensions to explore. A dimension is a lens for organizing the domain, not a question about it. For example a physician can be a dimension; beneath it sit sub-dimensions such as the online tools a physician uses, then the types of those tools, and a measure such as the value each one carries. Setting these dimensions first is deliberate; naming sub-questions too early narrows the collection and misses what was not yet thought to ask. The third step collects, reconciles, and validates the evidence for each part; building these base data sets is the deepest work in Layer 1. The base is not fixed once built. When a later question needs more, it is extended with the same rigor as the first build, not patched.
Layer 2 is final analysis and narrative. The same three steps run again, with the emphasis shifted. The goal for understanding is now set by what the customer needs in order to decide or act. The dimensions become analytical: fit, tension, risk, and the shape of a recommendation. The third step develops the insights within that frame and validates them with the customer. What Layer 2 produces is the set of insights the customer needs to make the decision, with the low-confidence areas and the thin spots called out rather than hidden.
The link between the two layers is the point worth stating plainly. The base evidence built at the end of Layer 1 is what the analysis in Layer 2 draws on. A consistent set of trusted foundational data is the material the customer's insights are built from. Building that base is the single largest block of effort in the engagement, and the Layer 2 analysis is a close second; together the two are more than half the work. A thin base produces confident-sounding findings that cannot bear weight. A strong base is what lets the analysis stand.
A finding is not final because the model returned it. It is final once it has earned confidence. Verification is three sections of work, shown in Diagram 3: collect, analyze, and refine. They run as a loop rather than a straight line, and the loop is what separates this from a tool that runs from prompt to result in one pass.
Diagram 3. Verification. Collect, analyze, and refine run as a cycle. A finding passes through the loop until it earns confidence, or until a gap is named as one that cannot be closed. The heavier dashed line on the left is the return path from refine back to collect.
The loop has a smaller version of itself at the very start, before collection proper begins. The problem statement itself is built in the platform, and the platform is then used to build the first prompts for the collection work. That is the same collect-analyze-refine pattern, applied in miniature. This matters because it shows the structure is not a wrapper added after the analysis; it shapes the work from the first move.
Collect pulls from three kinds of source so findings can triangulate: public web, an academic corpus, and the customer's own library. Analyze compares them, reconciles the conflicts, and names what is agreed, what is contested, and what is missing; a review with the customer runs alongside as a reality-check on accuracy and missed context. Refine ranks the weak spots by how much each affects the goal, sets the next pull, and returns to Collect.
Iteration is the design, not a fallback. When a gap cannot be closed, the honest move is to name it as unresolved and flag it in the deliverable rather than smooth it over.
Parts of an engagement differ in the depth they need, and treating them as the same puts effort where it is not needed. The analyst sets the depth per part, against how much the customer will need to trust that part.
| Mode | Effort | What it is for |
|---|---|---|
| Fast single-read pass | Four to eight hours | Orientation and early insight. Useful for direction; not something to bank on. |
| Full standing treatment | Multiple days per major part | Work the customer will rely on; depth matched to the weight the finding has to carry. |
The gap between the two is real. A fast pass can be a single read of a background document to get oriented. A full standing treatment on one major part can run past eight hours on that part alone. The skill is not in going deep by default. It is in knowing which parts earn it.
When depth is warranted, a major part gets three beats:
The second beat is where the judgment matters most. Finding the one question whose wrong answer would sink the rest, and spending real effort there, is the difference between a standing treatment and a summary.
The method works on evidence that is public or can be supplied as text. Three categories feed it. Public web sources are deep enough for most questions when the boundaries are set well and each source's credibility is graded as it comes in. The academic corpus is peer-reviewed and citation-locked, for the questions where that standard of proof is what the customer needs. The customer library is proprietary content unique to the customer, owned by them and firewalled by the platform, folded in when the customer can provide it as text.
The limit matters as much as the reach. Knowledge that lives only in people's heads, or in databases and PDFs the platform cannot read, is out of range. When the evidence that matters is out of range, the method says so rather than quietly substituting something weaker.
One distinction matters for a customer weighing the value. If the foundational research is built on public sources alone, the customer does not own that base unless they supplied the inputs. When the customer provides proprietary material, it is folded into the work and stays theirs.
Here is what the customer receives. A shared understanding of the problem, written as the eight-part problem statement, so the work and the goal stay aligned as things change. A foundational evidence base, built part by part and reusable on the next question rather than spent on this one. Applied modules on the questions that carried disproportionate weight. And a cross-section synthesis that turns the base into insights shaped for the decision at hand.
The insights come with their sources attached, and the method is explicit about where confidence is low and where good data was lacking. Each finding shows what it rests on, and the gaps that could not be closed are named rather than buried. Sometimes the honest finding is that the public evidence is thin, or that what is available stands in for the data the customer wishes it had. That is worth more than a confident result that will not hold.
With this in hand, the customer can make decisions and see how far to trust each one. The analyst's judgment runs through the whole of it; the platform is what lets that judgment work across hundreds of sources and many sessions.