Resolve contradictory sources in AI trading by comparing the exact instrument, metric definition, units and observation window before combining their claims. Convert only quantities with a documented relationship, keep different measurements separate, and mark any remaining disagreement unresolved. A majority vote or an average cannot repair evidence that answers different questions.
An assistant reports that BTC is up 10% and down 2.94% “today.” Neither number necessarily contains an arithmetic error. The word “today” may have erased two different starting times. The useful task is to recover the questions behind the numbers before asking the model for a conclusion.
Define what would count as a contradiction
Two claims genuinely conflict when they assert incompatible values for the same measurement under the same conditions. Matching the asset name is insufficient. A spot last trade, a perpetual mark price and an index can all reference BTC while measuring different things.
Bybit's derivatives ticker schema exposes lastPrice, markPrice and indexPrice as separate fields. It also separates open-interest size from open-interest value. Those distinctions should survive an AI summary rather than collapse into “price” or “positioning.” Bybit ticker field definitions.
Before reconciling values, fill out a measurement signature:
| Dimension | Record explicitly | Example of a false contradiction |
|---|---|---|
| Market | Venue, exact symbol, spot or derivative, expiry if relevant | Spot BTCUSDT versus a BTC perpetual |
| Meaning | Raw field and calculation definition | Last trade versus mark price |
| Unit | Quote asset, scale, contract multiplier and counting convention | Decimal return versus percent return |
| Window | Start, end, timezone and inclusion rule | Rolling 24 hours versus the current UTC day |
| Observation state | Source as-of time, arrival time and provisional or final status | An earlier snapshot versus a later update |
| Coverage | Single market, selected venues or stated universe | One venue versus a market-wide aggregate |
Use the data-provenance guide to retain where each observation came from. This signature addresses a separate decision: whether two traceable observations are comparable. Authentic, well-recorded sources can still describe different measurements.
Reconcile opposite return signs without choosing a winner
The following figures are hypothetical teaching data for one spot BTCUSDT market, not downloaded prices. Both summaries are received at 12:00 UTC on October 23 and use the same current price of 66,000 USDT per BTC.
| Summary | Starting observation | Starting price | Ending price at 12:00 UTC | Calculation | Result |
|---|---|---|---|---|---|
| A: “up over 24 hours” | October 22, 12:00 UTC | 60,000 | 66,000 | (66,000 / 60,000 − 1) × 100 | +10.00% |
| B: “down today” | October 23, 00:00 UTC | 68,000 | 66,000 | (66,000 / 68,000 − 1) × 100 | −2.94% |
Both calculations are correct within their stated windows. The contradiction appeared when the assistant called both “today's return.” The reconciliation is to restore the start times, not to blend the percentages. Their simple average, about +3.53%, is neither of the defined returns.
This distinction exists in real interfaces: Binance documents /api/v3/ticker/24hr as a rolling 24-hour statistic and provides a separate Trading Day Ticker with a timezone parameter. Inspect actual window fields and request settings; an endpoint's label is not a substitute for them. Binance Spot market-data documentation.
Suppose a hypothetical research rule requires a rolling 24-hour return above 5%. Under that declared definition, A supplies the relevant observation; B does not invalidate it because B measures another window. If the rule instead requires a positive UTC-day return, B supplies the relevant observation and the condition fails. These are example eligibility checks, not tested trading signals.
Choose the rule's window before inspecting which version gives a favorable result. Otherwise “reconciliation” becomes a way to switch definitions after seeing the answer. If the starting price is zero or missing, do not compute the percentage; the required comparison remains unavailable.
Normalize units without erasing meaning
A decimal return of 0.001, a percentage return of 0.1% and a return of 10 basis points represent the same change. A schema that identifies the scale permits that conversion. A bare value of 0.1 does not reveal whether its author meant a decimal or a percentage.
Record the original value and unit beside the converted value. Check that a previous processing stage has not already converted it. Multiplying a percent field by 100 again creates a confident error with a plausible label.
Currency conversions require more than renaming a column. USDT and USD are distinct units; converting a price between them requires a dated exchange rate and a declared direction. Likewise, converting a quantity into notional value requires an appropriate valuation price. A value change can include revaluation effects, so retain the quantity series separately. The open-interest comparison covers that specific quantity/value boundary.
Some differences should remain separate. A last trade and a mark price are not interchangeable observations that a unit conversion can reconcile. A global aggregate is not directly comparable to one venue unless its coverage and aggregation method support the comparison.
Handle the disagreement that survives normalization
Now suppose two hypothetical records both claim the same venue, instrument, last-trade definition and exact source time. One says 66,000 USDT and the other 66,300. The difference relative to 66,000 is about 45.45 basis points: 300 / 66,000 × 10,000.
An illustrative review policy allows a discrepancy of at most 5 basis points. This pair fails that policy. The tolerance is a chosen investigation threshold, not a universal market-data standard or permission to trade on smaller discrepancies.
Inspect the original fields and timestamp precision. Did one source round seconds while the other retained milliseconds? Did a parser select another symbol? Did a vendor revise an earlier observation? If those checks do not explain the difference, preserve both records and mark the relevant claim unresolved. Do not manufacture a 66,150 “consensus” price that neither record observed.
Avoid calling a source wrong merely because another source is official. A venue is authoritative about the fields it publishes, but a retrieved response can be stale, parsed incorrectly or outside the question's scope. For disputed event claims rather than measurements, follow the separate news-verification process.
Give the AI an explicit reconciliation result
Ask the assistant to return the original claims, measurement signatures, permitted conversions, resulting status and remaining gap. Useful statuses are equivalent after conversion, different scope, reconciled by window, and unresolved under the declared comparison policy. Require it to explain which input supports each consequential sentence.
Keep unresolved material in the evidence bundle. Dropping the conflicting observation to save space makes the next summary appear more certain than the research supports. The context-window evidence guide explains how to retain material qualifications when packing inputs.
A corrected feed can also arrive through the same delivery path as the original. Preserve the correction as a linked revision and define its occurrence identity before requesting another analysis; trigger deduplication handles that separate run-identity problem. Repeated delivery should not make one corrected observation look like several independent confirmations.
The reconciliation record is ready when another reader can identify what disagreed, which definition resolved it, and what remains uncertain. It can support a review; it cannot establish a forecast or override account-action rules. This AI-assisted article follows the editorial policy. Its examples and worksheet are original educational constructions, and they do not claim that KLINEO provides an automatic source-reconciliation feature.