Naly ইঞ্জিনিয়ারিং নোটস: পুনরুৎপাদনযোগ্য বাজার স্ন্যাপশট স্তর হিসেবে Polymarket Gamma

TL;DRPolymarket Gamma ingestion Naly-কে প্রেডিকশন-মার্কেট ইভেন্ট, বাজার, ফলাফল, দাম, ট্যাগ এবং রেজোলিউশন মেটাডেটার একটি প্রকাশ্য, কাঠামোবদ্ধ দৃশ্য দেয়। Naly এই স্তর ব্যবহার করে নিবন্ধ প্রার্থী নির্বাচন করতে, মিসপ্রাইসিং রাউন্ডআপকে ভিত্তি দিতে, KBO পূর্বাভাস গল্পকে সমর্থন করতে, উৎস সাইটেশন সংরক্ষণ করতে এবং পরবর্তী ভেরিফিকেশনের জন্য স্থায়ী বাজার স্ন্যাপশট তৈরি করতে। ইঞ্জিনিয়ারিং দাবি সহজ: সম্পাদকীয় আস্থা শুরু হয় পুনরুৎপাদনযোগ্য বাজার ইনপুট দিয়ে, তৈরি করা গদ্য দিয়ে নয়।

সারসংক্ষেপ

Polymarket Gamma API-কে Naly-র বাজার-আবিষ্কার ও মেটাডেটা উৎস হিসেবে দেখা উচিত, ট্রেডিং ইন্টারফেস হিসেবে নয়। অফিসিয়াল Polymarket ডকুমেন্টেশন Gamma-কে Data ও CLOB API থেকে আলাদা করে: Gamma ইভেন্ট, বাজার, ট্যাগ, সিরিজ, স্পোর্টস মেটাডেটা, সার্চ, মন্তব্য এবং পাবলিক প্রোফাইল কভার করে, আর CLOB অর্ডার বুক, দাম, স্প্রেড এবং অথেন্টিকেটেড ট্রেডিং অপারেশন সামলায়। Naly নিবন্ধের জন্য এই সীমারেখা কার্যকর। বেশিরভাগ সম্পাদকীয় ওয়ার্কফ্লোতে টিক-লেভেল অর্ডার-বুক বিবরণের আগে দরকার প্রশ্নের টেক্সট, বাজারের পরিচয়, ফলাফলের লেবেল, প্রদর্শিত সম্ভাবনা, ক্যাটাগরি ট্যাগ, ডেডলাইন এবং রেজোলিউশন প্রসঙ্গ।

এই নোটের থিসিস হলো Naly-র উচিত Gamma-কে একটি ভার্সনযুক্ত বাজার স্ন্যাপশট স্তরে ingest করা। একটি স্ন্যাপশট সত্য নয়; এটি নির্দিষ্ট সময়ে পর্যবেক্ষিত প্রকাশ্য বাজার অবস্থা, যা উৎস URL-এর সঙ্গে যুক্ত এবং কাঁচা payload সংরক্ষিত। এতে Naly সেটাই প্রকাশ করতে পারে যা অন্যরা লুকায়: বাজারের প্রসঙ্গ, সংকেতের সীমা, এবং কোনো নিবন্ধ তৈরির সময় ব্যবহৃত সুনির্দিষ্ট প্রমাণ।

Naly-তে এর অবস্থান

Gamma ingestion নিবন্ধ তৈরির আগে এবং বাহ্যিক উৎস আবিষ্কারের পরে বসে। Naly-র প্রকাশনা পথে, এটি চারটি downstream ব্যবহারের জন্য evidence bundle-এর প্রেডিকশন-মার্কেট অংশ দেয়:

মিসপ্রাইসিং রাউন্ডআপে বর্তমান ইভেন্ট ও বাজার প্রার্থী দরকার, যথেষ্ট মেটাডেটাসহ যাতে বাজার-ইঙ্গিতিত সম্ভাবনাকে উৎসসমর্থিত যুক্তির সঙ্গে তুলনা করা যায়।
KBO পূর্বাভাস নিবন্ধে স্পোর্টস বাজার, দল বা ইভেন্ট ট্যাগ, ইভেন্ট ডেডলাইন এবং ফলাফল লেবেল দরকার, যা হাতে বাজার প্রসঙ্গ না লিখেও রেন্ডার করা যায়।
উৎস সাইটেশনের জন্য স্থিতিশীল বাজার URL, ইভেন্ট slug এবং market identifier দরকার, যাতে পাঠক অডিট করতে পারেন কেন নিবন্ধটি একটি নির্দিষ্ট contract নিয়ে আলোচনা করেছে।
প্রেডিকশন ভেরিফিকেশনের জন্য ঐতিহাসিক স্ন্যাপশট দরকার, যাতে পরবর্তী রেজোলিউশনকে প্রকাশের সময় Naly বাস্তবে যে সম্ভাবনা দেখেছিল তার বিরুদ্ধে স্কোর করা যায়।

স্থানীয় runtime facts মূলত গঠনগত দিক থেকে গুরুত্বপূর্ণ, নতুনত্বের জন্য নয়। TypeScript 5.9 এবং tsx ingestion scripts-এর জন্য যুক্তিসঙ্গতভাবে উপযোগী; drizzle-orm সঙ্গে @neondatabase/serverless স্বাভাবিকীকৃত records এবং raw JSON persist করতে পারে; Next.js 16 এবং React 19 ফলস্বরূপ article pages render করতে পারে; আর ai এবং Claude SDK packages প্রস্তুত evidence bundle ব্যবহার করতে পারে, তবে ingestion বাজার অবস্থা explicit করার পরেই।

প্রযুক্তিগত প্রক্রিয়া

একটি শক্তিশালী Gamma ingestion loop-এর ছয়টি ধাপ আছে।

Discovery. Naly-র broad active-market discovery দরকার হলে Gamma events ব্যবহার করুন, আর কোনো নিবন্ধ পরিচিত Polymarket URL-এ anchored হলে market বা event slugs ব্যবহার করুন। Polymarket-এর market-data guide complete active discovery-র জন্য events সুপারিশ করে, কারণ events associated markets অন্তর্ভুক্ত করে, ফলে API calls কমে। sports-এর মতো category work-এর জন্য ranking candidates-এর আগে tags এবং sports metadata crawl সংকুচিত করা উচিত।
Pagination. Gamma offset-style endpoints এবং keyset endpoints দুটিই সমর্থন করে। বড় বা repeated crawling-এর জন্য keyset pagination নিরাপদ, কারণ next_cursor continuation token হয়ে যায় এবং offset keyset markets endpoint-এ স্পষ্টভাবে rejected। ছোট targeted article jobs-এর জন্য query window সংকীর্ণ হলে এবং output সঙ্গে সঙ্গে snapshotted হলে offset pagination এখনও গ্রহণযোগ্য হতে পারে।
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 নয়; এটি নিবন্ধের market interpretation উল্টে দেয়।
Snapshotting. normalized columns এবং raw JSON দুটিই সংরক্ষণ করুন। 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 schema drift থেকে Naly-কে সুরক্ষা দেয় এবং verification-কে সুনির্দিষ্ট ingestion artifact replay করতে দেয়।
Candidate scoring. Article jobs-এর উচিত trading execution criteria নয়, editorial criteria ব্যবহার করে markets rank করা: freshness, volume বা liquidity যেখানে available, resolution proximity, source availability, category fit, এবং marketটি clear reader-facing contrast তৈরি করতে পারে কি না। Candidate scoring কখনও ইঙ্গিত করা উচিত নয় যে market price স্বয়ংক্রিয়ভাবে ভুল; বরং এটি একটি market-কে গবেষণাযোগ্য হিসেবে mark করা উচিত।
Publication binding. কোনো generated article যখন market cite করে, article-টির stored snapshot id, Polymarket source URL এবং writer ব্যবহৃত external evidence set-এ link করা উচিত। এটাই একটি page যে শুধু বলে market ছিল 62 percent, আর একটি page যে প্রমাণ করতে পারে valueটি কখন, কোথায় এবং কোন payload থেকে এসেছে, তাদের পার্থক্য।

Rate limits প্রক্রিয়ার অংশ। Polymarket Cloudflare-enforced throttling এবং নির্দিষ্ট Gamma limits document করে /events, /markets, /tags, এবং /public-searchএর জন্য। daily publishing-এর জন্য Naly-র ওই limits-এর কাছাকাছি যাওয়ার দরকার নেই, তাই সঠিক posture conservative: bounded concurrency, jitter সহ retry, idempotency-র জন্য payload hashes, এবং কোনো job throttled, empty বা structurally unexpected responses পেলে alerting।

সাহিত্য কী বলছে

সাম্প্রতিক arXiv কাজ snapshot-first design-কে সমর্থন করে। 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-এর পক্ষে যুক্তি দেন। Naly-র ছোট publishing system-এ একই ধরনের সমস্যা আছে: market metadata একা যথেষ্ট নয়, যদি না পরে তা prices, article claims এবং resolution outcomes-এর সঙ্গে join করা যায়।

Le-এর calibration study article language-এর জন্য সরাসরি প্রাসঙ্গিক। বড় Kalshi ও Polymarket datasets ব্যবহার করে paperটি যুক্তি দেয় যে calibration domain, horizon এবং trade-size effects-এর ওপর নির্ভর করে; যারা prices-কে face-value probabilities হিসেবে ধরে নেয়, তারা systematicভাবে ভুল ব্যাখ্যা করতে পারে। Naly-র জন্য এর অর্থ হলো নিবন্ধে truth নয়, market-implied probability, observed price বা public market signal বলা উচিত। raw market observation-কে Naly-র model বা source-backed reasoning থেকে আলাদা করার পরেই article একটি possible mispricing আলোচনা করতে পারে।

Dubach-এর Polymarket microstructure paper মূলত order-book data নিয়ে, কিন্তু এটি ingestion design-এর জন্য একটি দরকারী সতর্কতা দেয়: high-frequency market evidence-এর source-specific error modes, ingestion delays এবং joins আছে, যেগুলো গুরুত্বপূর্ণ। Gamma order-book feeds-এর চেয়ে কম granular, তবু একই principle প্রযোজ্য। কোনো সংখ্যার উৎস দৃশ্যমান হতে হবে। Gamma snapshot, CLOB midpoint এবং on-chain trade record সম্পর্কিত হলেও interchangeable নয়।

Madrigal-Cianci, Monsalve Maya, and Breakey prediction markets-কে Bayesian inverse problems হিসেবে frame করেন, যেখানে observed probability এবং volume histories noisy, endogenous এবং heterogeneous trader types দ্বারা shaped। এটি Naly-র editorial stance-কে শক্তিশালী করে। Ingested market state হলো evidence, verdict নয়। ভালো engineering generation-এর সময় সেই uncertainty মুছে না দিয়ে inspectable করে তোলে।

নকশাগত trade-offs

Gamma versus CLOB প্রথম trade-off। Gamma Naly-কে discoverability, article context এবং metadata দেয়। CLOB দেয় sharper pricing এবং order-book mechanics। দৈনিক engineering articles এবং prediction-market roundups-এর জন্য Gamma-ই default input হওয়া উচিত, কারণ এটি marketটি কী নিয়ে তা উত্তর দেয়। article-টির spread, midpoint বা price-history precision দরকার হলে CLOB যোগ করা যেতে পারে।

Event-first versus market-first ingestion দ্বিতীয় trade-off। broad scans-এর জন্য Event-first সস্তা, কারণ একটি event multiple markets এবং shared metadata ধারণ করতে পারে। verification-এর জন্য Market-first পরিষ্কার, কারণ eventual score একটি specific binary outcome-এর সঙ্গে attach হয়। Naly-র উচিত দুই shape-ই ingest করা, তবে একক outcome evaluate করা হলে article links-কে market-level claim-এর দিকে point করানো।

Raw JSON versus typed schema তৃতীয় trade-off। Raw JSON একা store করা সহজ, কিন্তু safely query করা কঠিন। Typed columns একা 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 Polymarket কোনো market move, close বা resolve করলে নীরবে অর্থ বদলে ফেলতে পারে। Naly-র trust strategy-র জন্য কোনো page dated claim করলে freshness-এর চেয়ে frozen evidence শ্রেয়।

ব্যর্থতার ধরন

সবচেয়ে বিপজ্জনক failure হলো outcome-price misalignment। যদি Yes এবং No labels prices থেকে আলাদাভাবে parse করা হয়, article signal উল্টে দিতে পারে, তবু 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-এ several tradable markets থাকতে পারে। একটি round-up event cite করতে পারে, কিন্তু verification record-কে Naly যে specific market ও outcome evaluate করেছে তা cite করতে হবে।

চতুর্থ 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-এর পার্থক্য বজায় রাখা উচিত।

ষষ্ঠ failure হলো citation loss। article যদি শুধু rendered markdown সংরক্ষণ করে, পরবর্তী verification প্রমাণ করতে পারে না কোন 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-এ normalized।
status: active, closed, archived এবং publishability flags।
raw_payload: full provider response।
payload_hash: idempotency এবং replay-এর জন্য deterministic hash।
parser_version: payload interpret করা code contract।

Article generator-এর উচিত এটিকে loose prompt text নয়, structured evidence হিসেবে গ্রহণ করা। তারপর এটি existing AI stack দিয়ে markdown তৈরি করতে পারে, site pipeline দিয়ে render করতে পারে এবং citations-কে source records-এর সঙ্গে attached রাখতে পারে। একটি verification worker পরে article-এর market snapshot-কে resolution data-এর সঙ্গে join করে published claim ভালোভাবে aged হয়েছে কি না score করতে পারে।

Engineering principle ইচ্ছাকৃতভাবে conservative: ingest, normalize, snapshot, cite, তারপর write। এই order কোনো model-কে market page browse ও summarize করতে বলার চেয়ে ধীর, কিন্তু এটি সেই artifact তৈরি করে যা acquisition এবং retention-এর জন্য Naly-র সত্যিই দরকার: একটি public article যার market evidence result জানা হওয়ার পর replay করা যায়।