> For the complete documentation index, see [llms.txt](https://smily.gitbook.io/smily-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://smily.gitbook.io/smily-docs/the-prediction-system.md).
# The Prediction System
## Question types
Three question types are mixed within a room to create a rich scorecard. All three are scored under one unified rule (Brier), so they combine cleanly into a single total.
**Binary.** A yes or no question. The player assigns a probability to YES.
**Multi-choice.** Several predefined, mutually exclusive answers. The player assigns probabilities across the options, summing to 100%.
**Numeric bucket.** A numeric outcome partitioned into predefined ranges. The player assigns probabilities across the buckets. This unifies numeric prediction under the same proper scoring rule as the categorical types and avoids the incentive problems of pure closest-guess scoring.
An optional fourth type, the **proximity headline**, may be used sparingly for flavor and variance. In a proximity question the player submits a point estimate and is scored by distance to the realized value. Because pure proximity is not incentive-compatible in a multiplayer pot, it is reserved for clearly marked headline questions and is never the backbone of scoring.
## The multi-domain principle
The defining structural property of Smily is that each room mixes several uncorrelated knowledge domains. An insider's edge is domain-specific. Someone with an edge in geopolitics has no edge in football, finance, or culture. If a room spans five independent domains, a single-domain tip moves only a fraction of the scorecard. To win the room, a player must be broadly calibrated across all of it, which is skill, not access.
This is the same mathematics as portfolio diversification: uncorrelated positions dilute any single concentrated edge. It also dilutes luck, because variance averages out across many independent questions. The same design that makes Smily anti-insider makes it anti-coin-flip.
## The domain taxonomy
Each room draws from four to six uncorrelated domains, selected from:
* **Crypto markets.** Major asset prices and on-chain market outcomes.
* **Macro and traditional finance.** Macroeconomic releases, rates, indices.
* **Sports.** Resolvable outcomes from major competitions, settled on official data.
* **Politics and geopolitics.** Resolvable events only, such as election results or central-bank decisions.
* **Culture and entertainment.** Resolvable outcomes, such as box office, charts, awards.
* **On-chain and tech metrics.** Verifiable network and protocol statistics.
Points are distributed roughly equally across domains, and no single domain exceeds approximately 30% of the scorecard. Two highly correlated questions, for example two correlated crypto-price questions, are never counted as independent within the same room.
## Confidence is just the probabilities you declare
Confidence allocation is not a separate mechanic and not a separate budget. It is simply the probabilities the player declares. A higher probability on an outcome is a larger bet of confidence, and the scoring rule rewards calibration directly. The interface presents a probability slider per answer, with one-percent granularity. There is nothing else to manage.
## Where the questions come from
Questions are not arbitrary. They are governed by the [Pool Charter](broken://pages/1b0b84e38bd6b8b926e31d271773060048f4fa66), the set of rules that decides what is allowed into a room, how domains are balanced, and how every outcome is resolved. The charter is the credibility backbone of the product.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://smily.gitbook.io/smily-docs/the-prediction-system.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.