Writing & MediaFree
SME Interview Question and Answer List
Paste your draft and attach your sources. River answers what it can from them, then leaves you the few questions that genuinely need the engineer.
Paste your draft and attach the spec, design doc, ticket history or help output you already have, and River tests every open question against those sources before any of it reaches your subject matter expert. Questions your sources answer come back answered, with the source quoted. Questions it can only partly answer become labelled assumptions with a confidence. What is left is a short list that genuinely needs the engineer, each question carrying your best answer so they can confirm or correct it in a word.
Here is an illustrative example. A writer documenting a checkpoint replay feature has 132 questions. Tested against the design document, the ticket history and the command's help output, 95 turn out to be answered already and 14 can be derived well enough to ship as labelled assumptions. That leaves 23 for the engineer, who has 15 minutes. Sized by how long each kind of answer takes, the 9 blocking questions fit; the other 14 go on the ticket with the writer's provisional answer attached.
Standard practice is to read the tickets and test the software first, and the closest anybody comes to a method is a line about how you might be able to fill some gaps in yourself. None of it produces a count. This does: how many questions your sources already answer, how many minutes the rest need against the time you were given, and which sentences in your own draft rest on nothing anybody wrote down.
A short list gets answered, and the reason it is short is the reason it works
A short list with answers already in it is a different request from a long list of open questions. An engineer reading "replay skips records the sink already acknowledged; is that right?" can reply in one word, from a phone, between meetings. The same engineer reading "how does replay handle acknowledged records?" has to explain the system from the beginning, which is exactly the work that gets postponed. Putting your best answer on every question turns an interview into a review, and a review is far easier to fit into someone's day.
That is why the confidence column matters more than it looks. A question marked high confidence is a yes-or-no. One marked none says that no answer exists anywhere in the spec, the design document or the tickets, and those are the only questions that genuinely need someone's memory. In the illustrative example there was one: why checkpoint retention is 24 hours when the write-ahead log keeps 7 days. Nothing written down anywhere answered it, so it went to the top of the list.
The third pass is the one nobody runs, because it goes at the draft rather than at the question list. Every claim the draft makes is traced to a source, an answer, or a labelled assumption, and whatever is left is a sentence somebody wrote from memory. Those never appear on a question list, because nobody knew they were open, and they are the ones a reader trips over first. Keeping those answers findable after the call is what an internal knowledge base pack is for.
How it works
Paste your draft
Say what you are documenting, paste the draft, and note your deadline and how long you have with the expert.
Attach your sources
The spec, design doc, ticket history or help output, plus your own questions if you have any.
Answer what it can
Each question is tested against your sources first, and every answer names and quotes its source.
Cut to the meeting
What is left is ranked by what blocks publication and sized to the time your expert actually has.
What you get
- Every question you raised, labelled by which source you already hold that answers it
- The residue that genuinely needs the engineer, with your derived answer stated on each row
- A confidence on every question, so a yes-or-no is never mixed in with a real unknown
- Minutes each question needs by class, totalled against the minutes you were actually granted
- The blocking cut: the questions a page cannot publish without, sized to fit the meeting
- One register row per open question and per labelled assumption, by SME, with a state
- Every assertion in your draft traced to a source, an answer, or nothing at all
- The questions no source anywhere answers, named, because those are the only real unknowns
Common questions
What if I have no questions written down yet?
Then River raises them. Paste the draft, or describe the feature and attach the sources, and it works through what a reader would need to act correctly: triggers, values, limits, failure modes and what happens when something goes wrong. The list it produces goes through the same triage, so you never see the questions your own sources already answer.
How does it know a source actually answers a question?
It names the source and quotes what it read. A question answered from the help output carries the flag and its stated default; one answered from the ticket history carries the ticket. If the reading is an inference rather than a statement, it comes back as a provisional answer with a low confidence, not as an answer.
My SME never replies at all. Does this change that?
It changes what you send them, which is the part you control. A short list where every question already carries a plausible answer is a much smaller ask than a long list of open ones. Some experts you will never get one-on-one time with, and for those the whole exchange happens on the ticket, which this is built for.
Does it just guess when it cannot find an answer?
The opposite. A question with no answer anywhere is marked as exactly that, and those are the rows worth the SME's time. Anything derived but not stated outright comes back as a provisional answer with a confidence, and it ships as a labelled assumption with an owner rather than as prose.
What do I do with the questions that never get answered?
They go in the register with an owner and a state, and the draft says what it is assuming in their place. A page that publishes with a few open questions and its assumptions clearly labelled is in a sound position; a page that quietly states an assumption as fact is what a documentation audit finds a year later.
How is this different from auditing the pages afterwards?
Different moment and different input. This runs before anything publishes, against a draft and the sources behind it. Checking published pages against the shipped product is the documentation audit, and the review process that lets a draft through is the docs as code workflow pack.
Can it fill the gaps in the spec itself?
It reads a spec as a source and reports what the spec does not say, which is often the answer to why a question survived triage. Making the spec itself complete enough to document from is the OpenAPI gap workup, and it is worth running first when most of your residue traces back to one thin document.
Sources
Built by
Chandler Supple
Co-founder & CEO, River
Chandler has spent the last six years working in AI, building tools for millions of users and Fortune 100 companies. In 2025, he co-founded River to build a new kind of operating system for AI agents.
SME Interview Question and Answer List
Describe what you need, add any files you have, and your workspace opens with the work already underway.