The dominant design pattern in risk software is the dashboard. Tiles, widgets, a timeline feed, a geographic heat map, a color-coded risk matrix. The assumption behind this pattern is that the analyst's problem is information presentation: the data exists, it just needs to be organized and visualized so the analyst can understand it faster.
This assumption is wrong in a specific way. The analyst who is trying to decide whether to hedge supply chain exposure against a specific regulatory event does not have a presentation problem. They have a measurement problem: they do not have a number. What is the probability that this event occurs in the next three months? The dashboard cannot answer that question. The dashboard shows the analyst what has happened; it does not produce the probability of what will happen.
This is the design premise of Cade Market. We are building a research instrument. The output of a research instrument is a measurement: in our case, a probability score attached to a defined event, with a confidence interval, and with source attribution showing which signals drove the reading.
What a Research Instrument Requires That a Dashboard Does Not
The distinction between a research instrument and a dashboard is not cosmetic. It changes what the product does at every layer: how it ingests data, how it structures events, how it weights sources, and what it surfaces to the analyst.
A dashboard collects information and displays it. Volume is a feature: more sources, more signals, more coverage area. The analyst is responsible for interpreting the displayed information and drawing conclusions. The dashboard is passive. It shows; the analyst concludes.
A research instrument is different in kind. It is responsible for producing a conclusion: a number with documented uncertainty. Volume is not itself valuable if the additional sources are not calibrated. A poorly calibrated source that adds noise to the scoring reduces measurement quality even if it increases information quantity. Adding a new source category requires demonstrating that it improves calibration on the event types it is supposed to cover, not just that it represents additional monitoring coverage.
This means the product design has to enforce discipline that a dashboard does not need. You cannot add a source because it is available or because someone requests broader coverage. You have to ask: does this source improve calibration on which event categories? If the answer is unclear, the source goes into a testing queue, not into production. The discipline is not rigidity; it is the precondition for the product's core claim that the probability scores mean something.
Event Definition as Product Design
In a research instrument, the event definition is the unit of product. An event that is too vague cannot be scored; a vague probability estimate is not a measurement. An event that is too narrow covers situations no analyst actually needs to track. Getting the event definition right is a product decision with methodological consequences.
An event needs three things to be scorable: a binary resolution condition (it either happened or it did not), a defined timeframe within which the resolution occurs or fails to occur, and a reference to observable facts that determine resolution. "Geopolitical tension in Region X" fails all three tests. "The Altai Passage Framework Agreement enters formal legislative review in Kazakhstan before October 31, 2025" passes all three: binary outcome, defined window, observable resolution via official government publication.
The resolution condition requirement has a consequence that is less obvious: it forces us to think carefully about what the analyst actually cares about, not what is easy to measure. A risk analyst tracking a regulatory process does not care whether there has been news coverage of the regulatory process; they care whether the process produces a formal regulatory action. The event needs to be defined in terms of what the analyst will do if it resolves one way versus the other, not in terms of what is observable in the source data.
We spend more time on event definition than on any other product dimension. The temptation is to define events around available data, which is backwards. You define the event in terms of analytic need, then determine whether the source environment supports scoring it.
Source Architecture: Why We Track Four Categories
The Cade Market source architecture separates news wires, government documents, academic preprints, and field intelligence. This is not an arbitrary taxonomy. Each category has different latency characteristics, different calibration profiles across event types, and different reliability failure modes.
News wires are high-frequency and broad-coverage. They carry the most recency weight in time-sensitive events. But wire coverage is noisy: not every wire report that mentions an event is a meaningful precursor. The scoring system has to distinguish between wire reports that represent new information and wire reports that represent recycled or amplified prior reporting. This requires source-internal filtering that is distinct from cross-source weighting.
Government documents are lower-frequency but higher-fidelity for regulatory and legislative events. A government publication of a formal consultation period opening is a qualitatively different signal than a wire report describing the political background of the same event. The document carries structural information: it establishes a timeline, a set of required procedural steps, and an implied resolution window. This kind of structural calendar intelligence changes the prior probability for events with defined procedural requirements.
Academic preprints function primarily as long-lead indicators. A working paper on the policy case for a regulatory change, published six months before formal action, represents forward signal in a different register than either wires or government documents. The calibration for this category is more uncertain and the weighting is more conservative as a result. But the directional signal, when present, represents a source of intelligence that wire monitoring alone does not capture.
Field intelligence is the most expensive to maintain and the most valuable in specific contexts. For events with thin public-source environments, verified field reporting is the primary signal. We are conservative about what qualifies as field intelligence and how it enters the scoring model, because the quality verification requirements are higher than for the other categories.
Displaying Uncertainty Without Making It Useless
One of the harder product design challenges is how to display confidence intervals in a way that is meaningful to the analyst without making the interface unusable. The instinct in most software design is to simplify: give the analyst a number and hide the uncertainty. But hiding the uncertainty creates false precision that undermines the product's credibility when the interval matters.
We display the probability as a central estimate with a confidence interval bar, and we show the source contribution breakdown alongside it. The source breakdown is not an appendix or an advanced view; it is part of the primary display. An analyst who sees a 61% central estimate with a wide interval driven primarily by field intelligence sources reads that differently than the same estimate with a narrow interval driven by converging wire and government document signals. The interval and the source breakdown are the context that makes the number actionable.
The design principle is that measurement without uncertainty is false precision, but uncertainty without measurement is not useful either. The goal is to give the analyst a number they can act on and the context they need to understand how much to trust it.
What We Are Not Building
We are not building a news aggregator with a probability feature. Cade Market does not try to do everything. We do not provide streaming news monitoring, sentiment analysis across social media, or general geopolitical briefings. If those are the primary needs, there are established products that do them well.
What we produce is a specific analytic output: a calibrated probability estimate for a defined near-term event, with source attribution and uncertainty quantification. The discipline of that definition is what allows the estimate to be trustworthy rather than decorative.