Naly इंजीनियरिंग नोट्स: Polymarket Gamma एक पुनरुत्पादनीय मार्केट स्नैपशॉट लेयर के रूप में

TL;DRPolymarket Gamma ingestion Naly को prediction-market events, markets, outcomes, prices, tags, और resolution metadata का सार्वजनिक, structured view देता है। Naly इस layer का उपयोग article candidates चुनने, mispricing roundups को anchor करने, KBO prediction stories को support करने, source citations को preserve करने, और बाद की verification के लिए durable market snapshots बनाने में करता है। Engineering claim सरल है: editorial trust generated prose से नहीं, reproducible market input से शुरू होता है।

सार

Polymarket Gamma API को Naly के market-discovery और metadata source के रूप में देखा जाना चाहिए, trading interface के रूप में नहीं। Official Polymarket documentation Gamma को Data और CLOB APIs से अलग करता है: Gamma events, markets, tags, series, sports metadata, search, comments, और public profiles को cover करता है, जबकि CLOB order books, prices, spreads, और authenticated trading operations संभालता है। Naly articles के लिए यह boundary उपयोगी है। अधिकांश editorial workflows को tick-level order-book detail की जरूरत पड़ने से पहले question text, market identity, outcome labels, displayed probabilities, category tags, deadlines, और resolution context चाहिए होते हैं।

इस note की thesis यह है कि Naly को Gamma को versioned market snapshot layer में ingest करना चाहिए। Snapshot सत्य नहीं है; यह source URLs से जुड़ी और preserved raw payloads के साथ किसी specific time पर observed public market state है। इससे Naly वह publish कर सकता है जो दूसरे छिपाते हैं: market context, signal की limits, और article generate करते समय इस्तेमाल किया गया exact evidence.

यह Naly में कहां बैठता है

Gamma ingestion article generation से पहले और external source discovery के बाद आता है। Naly के publishing path में, यह चार downstream uses के लिए evidence bundle का prediction-market side देता है:

Mispricing roundups को current event और market candidates चाहिए होते हैं, पर्याप्त metadata के साथ ताकि market-implied probabilities की तुलना source-backed reasoning से की जा सके।
KBO prediction articles को sports markets, team या event tags, event deadlines, और outcome labels चाहिए होते हैं जिन्हें hand-entered market context के बिना render किया जा सके।
Source citations को stable market URLs, event slugs, और market identifiers चाहिए होते हैं ताकि reader audit कर सके कि article ने किसी specific contract पर चर्चा क्यों की।
Prediction verification को historical snapshots चाहिए होते हैं ताकि बाद का resolution उस probability के against score किया जा सके जिसे Naly ने publish time पर वास्तव में देखा था।

Local runtime facts novelty के बजाय मुख्यतः shape के लिए मायने रखते हैं। TypeScript 5.9 और tsx ingestion scripts के लिए उचित fit हैं; drizzle-orm के साथ @neondatabase/serverless normalized records और raw JSON को persist कर सकता है; Next.js 16 और React 19 resulting article pages render कर सकते हैं; the ai और Claude SDK packages prepared evidence bundle को तभी consume कर सकते हैं जब ingestion ने market state को explicit बना दिया हो।

Technical mechanism

एक robust Gamma ingestion loop के छह stages होते हैं।

Discovery. जब Naly को broad active-market discovery चाहिए हो तो Gamma events का उपयोग करें, और जब कोई article किसी known Polymarket URL से anchored हो तो market या event slugs का उपयोग करें। Polymarket की market-data guide complete active discovery के लिए events की recommendation करती है क्योंकि events associated markets शामिल करते हैं, जिससे API calls कम होती हैं। Sports जैसे category work के लिए, tags और sports metadata को candidates rank करने से पहले crawl को narrow करना चाहिए।
Pagination. Gamma offset-style endpoints और keyset endpoints दोनों support करता है। Large या repeated crawling के लिए, keyset pagination ज्यादा सुरक्षित है क्योंकि next_cursor continuation token बन जाता है और offset keyset markets endpoint पर explicit रूप से rejected है। Smaller targeted article jobs के लिए, offset pagination तब भी acceptable हो सकता है जब query window narrow हो और output तुरंत snapshotted हो।
Normalization. मुख्य normalization rule यह है कि outcome labels और outcome prices को position से map किया जाना चाहिए। Polymarket का market-data overview outcomes और outcomePrices arrays को one-to-one arrays के रूप में document करता है, इसलिए index discipline मायने रखता है। Swapped array cosmetic bug नहीं है; यह article की market interpretation को उलट देता है।
Snapshotting. Normalized columns और raw JSON दोनों store करें। Normalized columns में provider, fetched timestamp, event id या slug, market id या slug, question text, मौजूद होने पर condition id, मौजूद होने पर token identifiers, outcome labels, outcome prices, active और closed flags, end time, tags, source URL, और payload hash शामिल होने चाहिए। Raw JSON Naly को schema drift से बचाता है और verification को exact ingestion artifact replay करने देता है।
Candidate scoring. Article jobs को markets को editorial criteria के आधार पर rank करना चाहिए, trading execution criteria के आधार पर नहीं: freshness, उपलब्ध होने पर volume या liquidity, resolution proximity, source availability, category fit, और क्या market एक clear reader-facing contrast पैदा कर सकता है। Candidate scoring को कभी यह imply नहीं करना चाहिए कि market price अपने आप गलत है; उसे market को research के लायक mark करना चाहिए।
Publication binding. जब generated article किसी market को cite करता है, तो article को stored snapshot id, Polymarket source URL, और writer द्वारा इस्तेमाल किए गए external evidence set से link करना चाहिए। यही उस page के बीच अंतर है जो कहता है कि market 62 percent था और उस page के बीच जो prove कर सकता है कि वह value कब, कहां, और किस payload से आई।

Rate limits mechanism का हिस्सा हैं। Polymarket Cloudflare-enforced throttling और specific Gamma limits document करता है for /events, /markets, /tags, और /public-search. Naly को daily publishing के लिए उन limits के करीब जाने की जरूरत नहीं है, इसलिए सही posture conservative है: bounded concurrency, jitter के साथ retry, idempotency के लिए payload hashes, और job को throttled, empty, या structurally unexpected responses मिलने पर alerting.

Literature क्या कहता है

Recent arXiv work snapshot-first design को support करता है। Jia et al. decentralized prediction-market data को off-chain metadata, fill-level trading records, और oracle-resolution events में fragmented बताते हैं, फिर identifier resolution, incremental updates, और consistency mechanisms वाले unified relational system के पक्ष में argument करते हैं। Naly के छोटे publishing system में भी समस्या का यही class है: market metadata अकेला पर्याप्त नहीं है जब तक उसे बाद में prices, article claims, और resolution outcomes से join न किया जा सके।

Le की calibration study article language के लिए सीधे relevant है। Large Kalshi और Polymarket datasets का उपयोग करते हुए, paper argue करता है कि calibration domain, horizon, और trade-size effects पर depend करती है; जो consumers prices को face-value probabilities मानते हैं वे उन्हें systematically misinterpret कर सकते हैं। Naly के लिए इसका मतलब है कि article को market-implied probability, observed price, या public market signal कहना चाहिए, truth नहीं। Article raw market observation को Naly के model या source-backed reasoning से अलग करने के बाद ही possible mispricing पर चर्चा कर सकता है।

Dubach का Polymarket microstructure paper मुख्यतः order-book data के बारे में है, लेकिन यह ingestion design के लिए उपयोगी warning देता है: high-frequency market evidence में source-specific error modes, ingestion delays, और joins होते हैं जो मायने रखते हैं। Gamma order-book feeds से कम granular है, फिर भी वही principle लागू होता है। किसी number का source visible होना चाहिए। Gamma snapshot, CLOB midpoint, और on-chain trade record related हैं लेकिन interchangeable नहीं।

Madrigal-Cianci, Monsalve Maya, और Breakey prediction markets को Bayesian inverse problems के रूप में frame करते हैं, जहां observed probability और volume histories noisy, endogenous, और heterogeneous trader types से shaped होती हैं। यह Naly के editorial stance को reinforce करता है। Ingested market state evidence है, verdict नहीं। अच्छी engineering उस uncertainty को generation के दौरान wash out करने के बजाय inspectable बनाती है।

Design trade-offs

Gamma versus CLOB पहला trade-off है। Gamma Naly को discoverability, article context, और metadata देता है। CLOB sharper pricing और order-book mechanics देता है। Daily engineering articles और prediction-market roundups के लिए, Gamma default input होना चाहिए क्योंकि यह बताता है कि market किस बारे में है। CLOB तब जोड़ा जा सकता है जब article को spread, midpoint, या price-history precision चाहिए हो।

Event-first versus market-first ingestion दूसरा trade-off है। Event-first broad scans के लिए cheaper है क्योंकि एक event में multiple markets और shared metadata हो सकते हैं। Market-first verification के लिए cleaner है क्योंकि eventual score एक specific binary outcome से attach होता है। Naly को दोनों shapes ingest करने चाहिए, लेकिन जब single outcome evaluate किया जा रहा हो तो article links को market-level claim की ओर point कराना चाहिए।

Raw JSON versus typed schema तीसरा trade-off है। Raw JSON alone store करना आसान है लेकिन safely query करना कठिन। Typed columns alone query करना आसान है लेकिन provider fields evolve होने पर brittle हो जाते हैं। Durable pattern दोनों है: ranking, rendering, और joins के लिए typed fields; audit, replay, और migration के लिए raw payloads.

Live render versus frozen render चौथा trade-off है। Live market widget उपयोगी हो सकता है, लेकिन article claims को publish-time snapshot से bind होना चाहिए। वरना पुराना article तब चुपचाप meaning बदल सकता है जब Polymarket market को move, close, या resolve करता है। Naly की trust strategy के लिए, जब page dated claim करता है तो frozen evidence freshness से बेहतर है।

Failure modes

सबसे खतरनाक failure outcome-price misalignment है। अगर Yes और No labels को prices से separately parse किया जाता है, तो article signal को invert कर सकता है और फिर भी plausible दिख सकता है।

दूसरी failure stale market reuse है। कोई market discovery के दौरान active हो सकता है और publish time तक closed हो सकता है। प्रत्येक article job को snapshot bind करने से तुरंत पहले active, closed, archived, और end-time fields revalidate करने चाहिए।

तीसरी failure multi-market ambiguity है। Polymarket event में कई tradable markets हो सकते हैं। Round-up event को cite कर सकता है, लेकिन verification record को उस specific market और outcome को cite करना चाहिए जिसे Naly ने evaluate किया था।

चौथी failure schema drift है। Public APIs field names, defaults, और nested relations बदलते हैं। Snapshot storage में payload hashes, parser version, provider URL, और validation errors शामिल होने चाहिए ताकि drift observable रहे।

पांचवीं failure calibration को overclaim करना है। Market price एक उपयोगी public signal है, लेकिन literature सभी domains और horizons में इसे clean probability मानने के खिलाफ चेतावनी देता है। Naly की copy को market-implied probability, Naly estimate, और realized outcome के बीच फर्क preserve करना चाहिए।

छठी failure citation loss है। अगर article सिर्फ rendered markdown store करता है, तो later verification prove नहीं कर सकती कि किस market page और payload ने claim को support किया था। Article-market joins first-class records होने चाहिए, embedded prose नहीं।

Implementation notes

एक practical Naly implementation ingestion contract को छोटा रख सकता है:

provider: polymarket-gamma.
provider_url: discovery के लिए इस्तेमाल किया गया exact Gamma endpoint या public market URL.
fetched_at: UTC में server timestamp.
event_key और market_key: stable provider identifiers या slugs.
question: canonical market question text.
outcomes: ordered labels.
outcome_prices: ordered decimal strings जिन्हें validation के बाद ही numeric values में normalize किया गया हो।
status: active, closed, archived, और publishability flags.
raw_payload: full provider response.
payload_hash: idempotency और replay के लिए deterministic hash.
parser_version: code contract जिसने payload को interpret किया।

Article generator को यह structured evidence के रूप में मिलना चाहिए, loose prompt text के रूप में नहीं। इसके बाद यह existing AI stack के माध्यम से markdown produce कर सकता है, site pipeline के साथ render कर सकता है, और citations को source records से attached रख सकता है। Verification worker बाद में article के market snapshot को resolution data से join कर सकता है और score कर सकता है कि published claim समय के साथ कितना सही रहा।

Engineering principle जानबूझकर conservative है: ingest, normalize, snapshot, cite, फिर write। यह order किसी model से market page browse और summarize कराने से धीमा है, लेकिन यह वह artifact बनाता है जिसकी Naly को acquisition और retention के लिए वास्तव में जरूरत है: एक public article जिसकी market evidence result ज्ञात होने के बाद replay की जा सकती है।