NextConsensus

Why guideline and coverage changes catch teams off guard

A claim that held when a payer deck was written can be out of date by the meeting where it is used, if a new readout has changed a guideline, a label, or a coverage policy in between. Once a policy publishes, the chance to contest it usually waits for the next cycle.

A safety signal that persists across revisions carries different weight from a transient spike, yet keyword searches treat them identically. The dated claim record 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.

One coverage restriction or advisory delay that nobody saw coming can change the economics of a whole portfolio. A probability for the body, the action, and the date a team is working to tells it how much to prepare for each outcome.

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 the claim was worded, supported, and contested.
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 The proposition, the cutoff, the probability, three baselines, and the rule that settles the outcome are published before the body acts. None can be edited afterward.
4. 04
   Score When the deadline passes, the outcome is adjudicated and the forecast is 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, not whether the evidence is good.

What it is built 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 use the dated events and source links to inspect a claim’s history. They can also rerun the reconstruction to check its output.

Refract on GitHub

What it does not do

• It does not judge what is medically true. A claim can be well supported and still not be adopted by the date a team needs.
• No registered forecast has resolved yet, so there is no accuracy record to report.
• It registers only questions with a named body, a defined action, and a deadline. Without all three, there is no outcome to score.
• It does not recommend an action. The resulting decision to brief, escalate, or wait stays with the team that owns it.

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.