AI Prediction Markets
0/15 complete

Module 02 · Market Research

Building a Personal Watchlist of Tracked Markets

A research watchlist is a bounded dataset of contracts selected by a written rule. It is not a list of tips. Its purpose is to preserve comparable observations, identify upcoming verification work, and prevent attention from jumping only to dramatic or favorable markets.

// concept

Define Eligibility

Choose a neutral universe: one category, date window, public-data availability, unambiguous resolution source, minimum observation frequency, and ethical exclusions. Exclude markets involving personal harm, nonpublic information, manipulation opportunity, unclear terms, or content you should not amplify.

Record the selection rule before choosing markets. This reduces cherry-picking and survivorship bias. Keep excluded items and reasons.

// concept

Design the Schema

Store:

  • event/market stable identifiers and canonical URL;
  • question, outcomes, category, status, close/resolution dates;
  • resolution source/rules and ambiguity note;
  • observed bid, ask, midpoint, last trade, spread, depth, volume fields as defined;
  • retrieval UTC time, API endpoint/schema version;
  • source-desk state and next verification time;
  • paper forecast, rationale source IDs, and immutable forecast timestamp;
  • resolution/outcome and scoring fields after closure.

Do not overwrite observations. Append time-series rows. Separate raw API data from normalized analytics.

// concept

Choose Responsible Refresh Rules

Use official read-only APIs and current rate-limit guidance. Cache responses, apply backoff, identify failures, and avoid aggressive polling. Refresh frequency should match the research question; a daily calibration study does not need millisecond data.

Detect schema/status changes and missing data. A failed request is not a zero price. Mark stale rows and prevent dashboards from displaying them as current.

// concept

Add Decision Hygiene

Before viewing later outcomes, write a forecast/range and the reasons that could change it. Include a no-view/no-update period if constant price watching harms judgment. Do not send “urgent opportunity” alerts.

Use the watchlist to ask: which contracts are ambiguous, which sources need checking, how calibrated were frozen forecasts, and where did reasoning fail? Do not rank markets by hypothetical profit alone.

// worked_example

Worked Example

A researcher selects every eligible public economic-policy market closing in one quarter, not just three interesting ones. Two are excluded for ambiguous resolution sources. Daily snapshots preserve spread and staleness. At resolution, every included market is scored—even embarrassing forecasts.

This dataset can evaluate calibration. A hand-picked list of successful calls cannot.

// failure_cases

Failure Cases

7 cases to diagnose

  • Selecting only volatile or social-media-popular markets.

  • Overwriting the latest price without history.

  • Treating missing data as zero.

  • Polling more frequently than needed or allowed.

  • Ignoring resolved/invalid/cancelled status.

  • Changing paper forecasts after seeing outcomes.

  • Using watchlist alerts to encourage real-money urgency.

// pakistan_angle

Pakistan Angle

Use UTC as the stored timestamp and display PKT separately. Network interruptions should mark data stale, not trigger rapid retry storms. If a source is blocked or unavailable, respect the restriction and remove it from the study rather than circumventing access.

The watchlist must stay read-only. Do not store wallet keys, account IDs, KYC documents, or deposits. Check PVARA/SECP and platform rules on the access date if research scope changes.

// hands_on

Hands-On Exercise

Create a ten-market watchlist with a prewritten eligibility rule and at least three exclusions. Collect seven daily read-only snapshots, preserve raw/normalized data, mark failures/staleness, and freeze one paper forecast per market. Write a monitoring and retirement policy.

// completion_rubric

Completion Rubric

3 grading bands

  • Complete

    selection is neutral, schema/version/time are explicit, history is append-only, refresh is responsible, and forecasts are frozen.

  • Needs revision

    the table works but bias, staleness, or resolution handling is weak.

  • Not complete

    it functions as a tips list, circumvents controls, or stores trading credentials.

// sources

Sources