What a page can ask that a document cannot
Every document ends with the same question: any objections? The answer is almost always no, and it tells you very little.
Fields that depend on getting judgment right stopped asking that question long ago. They ask narrower ones, and they ask in a particular way: separately, before discussion, with something concrete to react to. Each of those practices is awkward in a document and natural on a page that can take answers. These are the ones we think matter most now that Inputs is open to everyone.
Estimate before you hear anyone else's number
Norman Dalkey and Olaf Helmer of RAND described the Delphi method in 1963: experts answer questionnaires separately, see controlled feedback on the group's answers, and answer again. Planning poker, studied on software projects, applies the idea to effort estimates by having everyone reveal a number at once, so the first voice cannot anchor the rest. On a page this is one number per question and a report that shows the spread rather than the average. A wide spread is the finding. It means people are estimating different things.
Explain it back
Medicine calls it teach-back: the clinician asks the patient to explain the plan in their own words. It is rarely done. In a 2003 study of diabetes visits, physicians checked recall or comprehension for 12% of the new concepts they introduced, and patients whose physicians did check were more likely to have their blood sugar under control. A design doc, an onboarding guide or a postmortem can end the same way, with one question asking the reader what changes for them. The answers show which paragraph nobody understood.
Rehearse the bad day
Google's SRE teams run disaster role plays, described in the SRE book as the Wheel of Misfortune: someone narrates an outage and a newer engineer says what they would do next. A launch plan can do this without the meeting. The page sets a scenario (latency doubles at a 20% rollout, say) and each reader chooses continue, pause or roll back, and why. Our launch rehearsal example works this way. It saves the scenario each person set up next to their answer, so two people who both chose continue can be seen to have assumed different things.
Put a number on it
The forecasting tournament work led by Philip Tetlock's group found that training, teaming and tracking forecasters improved both calibration and resolution. Calibration only exists when people commit to a probability that can be scored later. Asked per person as a percentage, "will this ship by March?" gives a team something to check in March. Asked out loud in a meeting, it gives them a mood.
Choose, with a reason
Design reviews tend to end in a preference vote between two directions. The vote is the least interesting part. A page that lets each reviewer try both flows, then asks which one and at which step it broke for them, returns a list of friction points instead of a tally. That is how our design review example is built.
Then let the agent read the answers
The new part is what happens next. Answers are data an agent can read. It can find where the estimates diverge, which assumption came up most, or which section the teach-back answers got wrong, then revise the page and publish a new version. Readers see a diff of what changed since they answered, and the next round is recorded against the new version. Each answer is marked as given in the page or sent by an agent, so a summary can leave the agents out.
What it cannot do
Delphi relies on anonymity between participants. Inputs keeps answers hidden from other readers, but the publisher sees every name, and that changes what some people will write. Readers must sign in. None of these formats work if nobody answers, and thing does not chase people for you.