HQ /proof is designed to make forecasts easier to inspect rather than asking you to take a model’s word for it. You do not need a statistics background to start. The key is to separate five things: what was predicted, when it was predicted, how confident the system was, what eventually happened, and how the record was preserved.
HQ is the home of Hylaq Quantum, which combines frontier AI with quantum provenance from IBM hardware. That provenance is relevant to how a result was produced and recorded; it is not a guarantee that every forecast will be right. Read the forecast itself first, then use the surrounding evidence to judge what it tells you.
Start with the question, not the percentage
Open a forecast and identify the exact event being predicted. A short title can hide important details. Look for:
- The outcome: What would count as “yes,” “no,” or another result?
- The deadline: By what date or time must the event happen?
- The source or scope: Is the forecast about a public event, a measurable release, a market condition, or something else?
- The status: Has the event been resolved, or is the forecast still open?
A forecast is not meaningful without a precise question and a clear resolution rule. For example, “Will this happen soon?” is difficult to evaluate unless “this” and “soon” are defined. If the event is still open, do not treat it as a win or loss simply because the outcome feels likely.
How to interpret a probability
A probability is a degree of belief expressed at a particular moment. If a forecast shows a high probability, it means the system considered the specified outcome more likely than it would at a lower probability. It does not mean the outcome is certain.
Think of probability as a commitment that can be checked later. A forecast near certainty should be held to a higher standard than a cautious forecast. A low-probability event can still happen; that does not automatically make the forecast bad. Likewise, a high-probability event can fail without proving the entire method useless.
For a quick, non-technical reading, ask: Was the forecast appropriately confident over many comparable cases? One result cannot answer that question.
Check the timestamp and forecast history
The publication time matters because forecasts should be judged using information available when they were made, not information that arrived afterward. A result that looks obvious today may not have been obvious at the original timestamp.
Review the forecast’s history where available. Look for the initial publication, later updates, and the final resolved result. A transparent record should help you distinguish an original prediction from a revision. This is one reason the public signed track record at /proof matters: it provides a way to inspect what was recorded and when, rather than relying only on a current summary.
Signing supports record integrity and provenance. It does not turn a forecast into a fact. Treat the signature as evidence about the record, not as evidence that the prediction must come true.
Read wins, losses, and unresolved results correctly
Once a forecast has a clearly resolved outcome, compare that outcome with the prediction. Then step back and review the broader record. Avoid drawing strong conclusions from a small handful of examples, especially if you selected them because they were surprising.
- Correct: The resolved outcome matched the forecast.
- Incorrect: The resolved outcome did not match the forecast.
- Open or unresolved: There is not yet a fair basis for calling it correct or incorrect.
Also watch for changing question types. A record covering technology, politics, markets, and everyday events may contain useful variety, but those categories can have different levels of uncertainty. Compare like with like whenever possible.
A practical checklist for /proof
Use this five-question checklist each time you inspect an HQ result:
- What exactly is the forecast asking?
- When was it published, and what information was available then?
- What probability or confidence level was recorded?
- Has the event been resolved using a clear rule?
- What does the larger signed record show, including misses and open cases?
If you want to investigate further, record the forecast link, timestamp, question, probability, and final resolution in your own notes. If you are moving a result into another workflow, you can try Loadit, but keep the original HQ /proof page as the reference for provenance.
What HQ /proof can—and cannot—tell you
/proof can help you inspect forecasts as time-stamped, verifiable records rather than isolated claims. It can show how a forecast was stated, preserve its provenance, and make later evaluation more accountable. It cannot eliminate uncertainty, predict every event correctly, or replace your judgment about the question being asked.
The most useful habit is simple: read the event definition, respect the timestamp, interpret probability as uncertainty rather than certainty, and judge performance across a meaningful record. That approach lets you explore HQ’s forecasts without needing advanced statistics—and without asking the evidence to say more than it can.