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: a new readout narrows the guideline, and the label follows. 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. Tracking a claim across revisions tells the two apart.

A single unanticipated coverage restriction or advisory delay can alter the economics of an entire 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 the sources behind a claim into dated, verifiable events. NextConsensus turns them into a dated record of how the claim was worded, supported, and contested at each regulator, guideline body, and payer.
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 around a claim, such as support attaching or qualifiers falling away, 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 the claim signal is being tested on specific claims and patterns.

The test, on nextconsensus.com

My role

Founder and primary builder. I built the registration system, deterministic scoring engine, trajectory-reconstruction pipelines, and public resolution rules on top of Refract, the open-source change-detection engine underneath it.