Writing & MediaFree
SME Interview Question and Answer List
River answers what it can from your spec, code and ticket history, then leaves you the questions that genuinely need the engineer.
A writer drafting Ashcombe's checkpoint replay pages raised 132 questions. Ninety-five had answers already sitting in the repository. 44 came out of the merged code and the command's own help output, 17 out of the design document, and 12 out of the ticket history. The rest came from support tickets, the pages that already cover the area, and running the build. All of it cost 4.5 hours of reading. What was left needing the engineer was 23 questions, 17% of the list, and the engineer had 15 minutes.
Those 23 need 49 minutes at the rates the classes imply, so the list gets cut by what blocks publication rather than by what is interesting. Nine questions are blocking, they need 12 minutes, and they fit. The other 14 go on the ticket with the writer's provisional answer attached, and 10 came back inside a day. Every question that goes over states the answer the writer already derived and a confidence, so the engineer is confirming or correcting rather than explaining from the beginning.
Standard practice is to read the tickets and test the software first, and the closest anybody comes to a mechanism 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 of your questions you could have answered alone, how many minutes the residue needs against the minutes you were granted, and how many assertions in your own draft rest on nothing anybody said. On this feature the last number was 9 of 214.
A short list gets answered, and the reason it is short is the reason it works
The same team sent 152 questions across three earlier features and got 41 back, a median 6.5 days to the first reply. The fourth list was 23 questions with a derived answer on every row: 19 came back, median 0.9 days. Six times shorter and three times the response rate. An engineer reading a question that already contains a plausible answer can reply in one word, and a question they can answer in one word is a question they answer today.
Which is also why the confidence column matters more than it looks. A question marked high confidence is a yes-or-no. One marked none is the writer saying that no answer exists anywhere in the repository, the design document or the ticket, and those are the only questions that genuinely require somebody's memory. Ashcombe had one: why the checkpoint retention is 24 hours when the write-ahead log keeps 7 days. Nothing written down anywhere answered it.
The third pass is the one nobody runs, because it goes at the draft rather than at the question list. Every assertion 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. Nine of Ashcombe's 214 assertions were in that state, the ones a reader finds first, and keeping that same answer findable once nobody remembers giving it is the internal knowledge base pack.
How it works
Send what you have
The spec, the merged code or help output, the ticket history, and the pages that already cover the area.
Send the questions
Your own list if you have one. River raises the rest from the draft and the sources you sent.
Answer what it can
Each question is tested against your sources first, and the answer arrives with the source named.
Cut to the meeting
The residue is ranked by what blocks publication and sized to the minutes your SME 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 it raises them. Send the draft, or the feature and the sources, and River works through what a reader would need to act correctly: triggers, values, boundaries, failure modes, and what happens on the unhappy path. The list it produces goes through the same triage, so you never see the questions your own repository already answers.
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 list of 23 questions each carrying a plausible answer is a different ask from 132 open ones. Some SMEs 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. Ashcombe published with 4 open and 14 assumptions labelled. That is a publishable position; a page that quietly asserts the 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.
SME Interview Question and Answer List
Fill in the form and your workspace opens with the work already underway.