> ## Documentation Index > Fetch the complete documentation index at: https://docs.pelion.dev/llms.txt > Use this file to discover all available pages before exploring further. # UNRESOLVABLE and calibration > Why genuinely ambiguous questions need a structural escape valve, not a forced binary resolution. The behavior below is already implemented in `pelion.judgment` and `pelion.validator`. The on-chain path through the adapter is specified but not yet deployed. Real-world questions are not always binary. Some of them cannot be cleanly adjudicated by the evidence available. Forced-binary oracles collapse these into YES or NO anyway. Pelion treats them as a third, structurally distinct outcome. ## Why forced binary fails Consider three scenarios. Each produces a question that has no single correct binary answer. **Ambiguous event timing.** "Did event X happen by midnight UTC on date Y?" If the primary source reports in a different timezone, the answer can flip based on interpretation. **Contradicting primary sources.** Two credible outlets report contradictory facts. Reuters says event happened. AP says it didn't. The resolution criteria don't specify which outlet to prefer. **Edge cases not anticipated by criteria.** The market asked "did X happen." X almost happened, or something that resembles X happened. The resolution criteria didn't anticipate the specific form of the event. A forced-binary oracle must pick YES or NO. Half the market believes the resolution is wrong. Controversy compounds. UMA's historical data on contested markets shows this pattern consistently. Pelion acknowledges the underlying fact. The evidence does not decide. The protocol returns `UNRESOLVABLE`. The requesting contract decides what to do about it. ## The `UNRESOLVABLE` sentinel `UNRESOLVABLE` is a signed integer sentinel with value `-1`. It flows through every layer. **Canonical `Verdict`.** The `outcome` field on the off-chain Verdict schema is a signed integer. `UNRESOLVABLE = -1`, `NO = 0`, `YES = 1`. Multi-outcome markets use values at or above 2. This is documented in the schemas module and locked by the spec. **Bittensor wire (`PelionSynapse`).** The miner returns the same integer on the Synapse outcome field. **Adapter contract state.** `PelionAdapter.sol` preserves the signed integer through submission, challenge, and finalization. The Solidity interface uses `int256 outcome` specifically to accommodate negative sentinels. **Requester callback.** The adapter calls back to the requesting contract with the outcome integer. The requesting contract's callback function interprets `-1` as `UNRESOLVABLE` and handles accordingly. ## What the requester does with `UNRESOLVABLE` Pelion does not dictate the response. The requesting contract chooses. Refund both sides. For a simple prediction market, this is the safest default. Everyone gets their stake back. Escalate. For higher-value markets, the contract can route the question to an independent council (Pelion's own escalation council, for example). Retry with refined criteria. The contract can reissue the question with tighter resolution criteria and let the protocol try again. Apply the contract's own undefined-outcome rules. Some contracts have contract-specific rules for undefined outcomes. Insurance contracts, for example, might have a "disputed claim" path that goes to underwriter review. The protocol's responsibility is to produce a verdict that is true to the evidence. The requesting contract's responsibility is to handle the verdict according to its own logic. Pelion does not impose a single coercion policy. ## Calibration scoring Pelion's scoring mechanism rewards miners for calibrated uncertainty, not just raw accuracy. This is enforced at the validator layer. On questions with available ground truth, validators score miners on three factors. Backtest accuracy (did the verdict match ground truth). Evidence quality (was the evidence diverse, authoritative, recent). Calibration (did the miner return `UNRESOLVABLE` on genuinely inconclusive questions, or did they overcommit to a wrong answer). A miner that always returns YES on ambiguous questions scores well on pure accuracy when the truth turns out to be YES, but poorly on calibration when the truth turns out to be genuinely ambiguous. A miner that always returns `UNRESOLVABLE` scores well on calibration (no wrong commits) but poorly on accuracy (no correct commits either). The scoring function rewards miners who are right when the answer is clear and `UNRESOLVABLE` when it isn't. This is the incentive Pelion needs to produce reliable verdicts without manufactured certainty. v0 of the validator ships with accuracy-only scoring (1.0 for match, 0.0 for miss). The richer calibration-aware scoring lands later in the build sequence against live subnet data. The accuracy-only scoring is intentionally simple so that behavior is predictable while the subnet bootstraps. ## The guardrail. `UNRESOLVABLE` is never an error handler This is the most important design rule around `UNRESOLVABLE`. Infrastructure failures raise errors. They do not silently return `UNRESOLVABLE`. If a miner's frontier model API times out, the miner raises rather than returning `UNRESOLVABLE` with empty reasoning. If a validator's Dendrite call fails, the validator records a null score rather than recording `UNRESOLVABLE` as the miner's answer. If a router's subnet query returns malformed responses, the router retries or fails explicitly rather than synthesizing `UNRESOLVABLE` from the failure. The reason is simple. `UNRESOLVABLE` means "the evidence does not determine the answer." If infrastructure failures silently map to `UNRESOLVABLE`, the outcome label loses information. Every verdict must carry its actual meaning. The failure path and the inconclusive path are different outcomes that deserve different handling. This guardrail is enforced in the reference implementation today. It is documented in each module's README as a hard rule.