A market-data bot is a measurement system, not a money machine. It observes published questions, prices, timestamps, and outcomes, then helps you test whether a research idea survives contact with evidence. A displayed probability can be stale, thinly traded, mechanically wrong, or based on information your dataset never captured. This course therefore builds only a read-only research and paper-execution service. It never connects funds, signs transactions, or submits orders.
Start with four separate objects. A question states what is being resolved. A market rule defines the authoritative outcome and cutoff. A quote records what a venue displayed at one moment. A label records the final result. Confusing them creates false confidence. A quote of 0.70 is not a verified 70% chance, and a resolved label does not prove that buying earlier was sensible.
Uncertainty enters through missing rows, clock differences, revised rules, delayed resolution, changing liquidity, spread, and sampling. Record these as data, not footnotes. Every snapshot should include observed_at_utc, source URL or identifier, market identifier, status, bid, ask, last price, and an explicit missingness field. Preserve the raw response beside normalized fields so later audits can distinguish provider changes from your own parser errors.
Use three promises in the project README:
- The service is paper-only and has no write-capable market client.
- Every conclusion names its dataset version, time window, and exclusions.
- No backtest, score, or chart is presented as expected profit.
These promises shape architecture. If a research hypothesis appears strong, the next action is another paper test on unseen time periods—not adding credentials. If evidence is incomplete, the output is ABSTAIN, not a confident guess. If a market rule changes, create a new version instead of overwriting history.
Worked example
Suppose a dashboard shows 0.62 at noon and the final outcome is Yes. A weak report says, “the model was correct.” A professional report asks: Was 0.62 the bid, ask, midpoint, or last trade? Was the quote fresh? How wide was the spread? What information arrived after noon? How many comparable predictions were evaluated? One correct outcome says almost nothing about calibration. A set of forecasts grouped around 0.60 should resolve positively roughly six times in ten only across a sufficiently large, clearly defined sample; even then, sampling noise remains.
🇵🇰 Pakistan Angle
Pakistan-based learners must not infer legality from a website being reachable. PVARA and SECP guidance can change, and venue rules differ by jurisdiction. This course is education about data engineering and forecast evaluation. It provides no signals, account-opening path, payment workaround, or trading service. Use public data or instructor-provided fixtures and check current official Pakistani guidance before any separate activity.
Hands-On Exercise
Create SAFETY.md. Define the four objects above, list eight uncertainty fields, and write the three project promises. Then inspect one public market-data record and produce a five-line evidence note: source ID, observed time, quote type, known gaps, and ABSTAIN or “eligible for paper analysis.” Do not predict the outcome.
Completion Rubric
- The project states paper-only scope and contains no credential or order path.
- Question, rule, quote, and label are defined separately.
- The evidence note records time, source, quote type, and missingness.
- The conclusion abstains when evidence is incomplete.
- No sentence promises profit, accuracy, or future live use.
Sources
- CFTC overview of prediction markets
- NIST AI Risk Management Framework
- PVARA regulations and guidance
Key takeaway: A professional paper bot measures uncertain evidence honestly; it does not turn a price or backtest into a profit promise.