NextConsensus

Why guideline and coverage changes catch teams off guard

A claim that held when someone wrote the payer deck can be out of date by the meeting where they use it, if a new readout has changed a guideline, a label, or a coverage policy in between. Once a policy is out, the next chance to challenge it is usually a cycle away.

A probability for a named body, action, and deadline helps a team prepare for each outcome.

A safety signal that persists across revisions means something different from a brief spike, yet keyword searches treat them identically. NextConsensus keeps a dated record of each claim, which shows which one a team is looking at. Whether that movement signals a coming decision is still under test, and the estimates do not rest on it.

How it works

1. 01 #

   Reconstruct

   Refract replays the public revision history of a claim’s sources, such as its Wikipedia article, into dated, verifiable events. NextConsensus adds the regulator’s own record, from FDA filings to NICE schedules, and turns both into a dated record of how people worded, supported, and contested the claim.

2. 02 #

   Estimate

   Each forecast names a body, an action, and a deadline. Its probability comes from inputs frozen at a cutoff: the evidence behind the claim, where the body’s own review stands, how that body has acted in reviews like this one, and the constraints that cut the other way.

3. 03 #

   Register

   I publish the proposition, the cutoff, the probability, three baselines, and the rule that settles the outcome before the body acts. Nobody can edit them afterward.

4. 04 #

   Score

   When the deadline passes, the outcome is resolved against the frozen rule and scored against its baselines, right or wrong. A miss stays on the record beside the reasoning that produced it.

The estimate is about how a body has acted under conditions like these. It does not say whether the evidence is good. A question without a named body, a defined action and a deadline is not registered, because there is no outcome to score.

It does not recommend an action: the decision to brief, escalate or wait stays with the team that owns it.

What it rests on

Refract, the open-source engine (AGPL-3.0), reconstructs a claim’s history from source revisions. The same source produces the same events on every run. Each release includes a test set of recorded edits that anyone can regenerate byte for byte.

Agents can inspect the dated events and source links or rerun the reconstruction to check its output.

Refract on GitHub

What the first test changed

I started from the idea that revision activity, such as support attaching to a claim or qualifiers falling away from it, would show which decisions were coming. An early proof cycle seemed to confirm it and turned out to be invalid. Rebuilt correctly, the cycle showed no lift from general revision activity. The forecasts now rest on each decision’s own review record, and I’m testing the claim signal on specific claims and patterns.

The test, on nextconsensus.com

My role

Founder and sole builder. I built the registration system, the public resolution rules and the tools that apply them, and the trajectory-reconstruction pipelines on top of Refract, my open-source change-detection engine.