Mit próbáltunk — a teljes kísérleti térkép

Konszolidált rendszer- és kísérleti kézikönyv. Állapot: 2026-08-01.

0. Hogyan épül fel ez a lap

0.1 Négy könyv

Az első váz egyetlen lapos listát használt. Az hibás volt: négy különböző kérdéstípust mostam össze, és emiatt három téma egyáltalán nem fért bele.

A D könyvet a legkönnyebb kihagyni és a leginkább megbánni. Ez a projekt fele arról szólt, hogy rossz mércével mértünk — az a tudás sehol nincs leírva a méréseken kívül.

0.2 A végfelhasználó egy hangalapú chatbot

Valaki felteszi, hogy „mi a helyzet a ratinggel?", és a bot ebből válaszol. Öt kötelező szabály:

1. Önhordó. Tilos „lásd a T51-et" a szám nélkül. A hivatkozás kiegészítés, nem helyettesítés.
2. Első mondat = a válasz. Minden bejegyzés Válasz egy mondatban mezővel kezd.
3. A szám a szövegben van. „+0,0177 logloss, n=755", nem „lásd a táblát".
4. Minden szakasz definiálja a saját szavait. Hangban nincs visszalapozás.
5. Stabil számozás. B4.1 örökre B4.1. Kiürült bejegyzés [visszavonva] jelöléssel marad.

0.3 Terjedelem

Ez a teljes, tömör változat: nem egy előre kitűzött oldalszámot tölt ki, hanem minden felsorolt kérdést lezárt vagy végrehajthatóan nyitott állapotba hoz. A B könyv 106 számozott kérdéséhez, a nyolc rosterforráshoz és a hét C-méréshez tartozik önhordó válasz. A rövid bejegyzések is megtartják mind a nyolc kötelező mezőt; a részletes nyers táblák és hash-ek az F-ben megadott riportokban maradnak. Az F.6 és F.7 teljes fájljegyzéke miatt egyetlen gyökérszintű Markdown-dokumentum és egyetlen analysis-modul sem marad név nélkül; a jelenlét azonban nem jelent automatikusan érvényes bizonyítékot, azt továbbra is a D.2 és a registry státusza dönti el.

A. A rendszer, ahogy ma működik

A bot enélkül nem tud kontextusban válaszolni — nem tudja, hogy amiről beszélünk, az nincs élesben.

A.1 Mit csinál a rendszer?

A rendszer egy League of Legends-meccsekhez épített, meccs előtti döntéstámogató és papír- fogadási rendszer. Összegyűjti a történeti eredményeket, az ismert vagy becsült felállást és a piaci ajánlatokat; ezekből megbecsüli a sorozat és a pályák kimeneteleinek valószínűségét; végül összeveti a saját árat a Tippmix vagy a Polymarket elérhető árával. A board jelenlegi célja nem az, hogy egy modellteszt minden belső részletét megmutassa, hanem hogy egy fogadó egyértelműen lássa: melyik esemény, melyik piac, melyik oldal, milyen elérhető odds mellett, mikor keletkezett vagy változott, és mekkora tétet javasol a ma aktív policy.

A rendszer két külön dolgot tud kiírni. A fogadható tipphez konkrét venue és végrehajtható quote kell. A modell-tipp venue nélkül is megmutatja, melyik irányt választaná a modell, de nincs hozzá kitalált odds és tét; ez kutatási jel, nem végrehajtható fogadás. A boardon a három engedélyezett nem-moneyline család a map_winner, a map_handicap és a total_maps. A series_winner a háttérben szükséges alapár, de nem negyedik board-kategória.

A rendszer nem automatikus pénzfogadó robot. A jelenlegi út árakat és papír-téteket számol, naplóz és megjelenít; a shadow ágak pedig új modelleket hasonlítanak össze anélkül, hogy a production artifactot lecserélnék. 2026-07-31-én nincs bizonyított, végrehajtható árakon mért pozitív edge: a korábbi kedvező CLV-állítást a seed/mid belépőár, a hiányzó díj és a mutálható replay érvénytelenítette. Emiatt minden új modell- vagy profitállítás kutatási hipotézis addig, amíg az időhelyes forward kapuk át nem mennek.

A.2 Az adatlánc végig

A lánc három külön rétege az adat, az ármodell és a döntés; attól, hogy az első kettő számot ad, még nem keletkezik fogadható tipp. A történeti igazságforrás az Oracle's Elixir: ebből tudjuk utólag, ki játszott és mi lett az eredmény. Az előre ismert roszter elsődleges programozható forrása az authentikált Leaguepedia Cargo. A menetrend és a formátum a LoL Esports-registryből, az odds a Tippmix- és Polymarket-gyűjtőkből érkezik. A név- és eseményfeloldás mindegyik forrást azonos csapat-, esemény- és piacazonosságra hozza; bizonytalan feloldásnál a helyes viselkedés a látható kiesés, nem a néma fuzzy találat.

A múltbeli meccsekből a models/fit_pandaskill_ratings.py időpont előtti játékos-, csapat- és régiórating-snapshotokat épít. A features/player_feature_builder.py és a kapcsolódó builderek csak a meccs cutoffja előtt ismert sorokból képeznek team-, seat-, forma- és kontextusmezőket. Ezekből a jelenlegi production models/fit_oracle_match_level_model.py egy közvetlen sorozatgyőztesi pontárat tanul. A shadow package ettől külön, team-alap + per-seat korrekció + opcionális reziduál szerkezetben dolgozik. A modell artifactja nemcsak súly: hozzá tartozik a feature-lista, a kalibrátor, az inputok és a kód azonosítója is.

A friss scorer az upcoming registryt, a döntéskor elérhető felállást és a befagyasztott artifactot egyesíti. A moneyline-pontárból egy közös, terminális sorozateredmény-eloszlás képezi a koherens map_winner, map_handicap és total_maps árakat. Ezután jön a döntési réteg: venue-quote illesztés, edge-küszöb, tétforma, kockázati korlát, majd append-only döntéskori napló. Végül a tips/render_current_board.py a JSON/CSV állapotból HTML-boardot renderel. A processed/ az adattár és futási output helye, gépenként eltérhet és nincs Gitben; ezért egy friss HTML-mtime önmagában nem bizonyít friss bemenetet.

A.3 Mi fut ténylegesen 2026-07-31-én?

A tényleges pontár továbbra is a 2026-06-16-i, 79 feature-ös joint match-XGBoost; az azóta elkészült rating-, lineup- és context-kutatásból semmi nincs productionbe promótálva. Az artifact szimmetrikus csapatpárt pontoz, majd Platt-kalibrációt használ; a production dokumentáció szerint az élő artifactban interceptes kalibrátor maradt. A tétet a legacy, oddsot nem használó 0,143 + 1,286·p egységképlet adja. A fejlesztői ág közös UNIT_USD értéke jelenleg 100 dollár, a 2026-07-18-i Linux-visszaállítás 10 dolláros bázissal fut; ezért dollárösszeget csak a futó gép konfigurációjával együtt szabad idézni.

Két állapotot külön kell mondani. A fejlesztői munkafa 2026-07-31-én a board-modell-odds-3types ág c0b8ca1 pontján áll, rajta sok, még nem commitolt kutatási anyaggal. A Linux box a konzervatív box-restore-20260718 ágon fut; erre egyetlen elkülönített board-backport került (b944aee). Ez a commit stabil érkezési sorszámot ad, minden modellezhető meccshez létrehozza a venue nélküli non-ML modell-tippet, csak a három engedélyezett piacot mutatja, idő- és rosterállapotot jelenít meg, valamint eltávolítja a fogadónak felesleges modellzsargont. Ez felületi és kiválasztási backport, nem modellpromóció.

A 2026-07-31-i ellenőrzési pillanatban a box 36 modellezett meccset látott, ebből 15-höz volt Tippmix-illesztés és 23-hoz Polymarket-esemény; a 21 Tippmix-moneyline nélküli meccs is kapott modell-tippet. Ezek pillanatnyi számlálók, nem tesztminta és nem rendszerállandók. A boxon a friss bemenetek miatt a mai tippek nem a július 18-i tippek másolatai: csak a kód- és modellviselkedés maradt július 18-i alapú.

A.4 Mi van árnyékban?

Árnyékban több, a productionnél ígéretesebb részmegoldás van, de egyiknek sincs promotion-joga. A tiszta PandaSkill-rácsban a strict raw-winner változat ötéves rolling-originon javított; a D365 decay a súlyozatlan változatot 5/5 évben verte. A tiszta K8 futásban a T10 team-alap a T5 előtt végzett, és a szokásos ötöshöz mért seat25 A lineup-korrekció mindkét baselinet 5/5 évben javította. Az átlag-σ jobb aggregátornak látszik az RMS-σ-nál, de a σ pontárban betöltött szerepe még nincs döntéselméletileg lezárva.

A modellcsaládok közül a LOGIT3/PS4 a rating és a szórás szerkezetét bontja ki; a PS7_CONTEXT, RED23 és rich-context ágak a feature-tér szűkítését vagy kontextussal bővítését vizsgálják; az M12 per-seat package és az M13 twin tower a team-alap és a felálláskorrekció szétválasztására készült. A common-PMF ág koherens nem-moneyline árakat állít elő, a forward v3 logger pedig döntéskori információállapotot gyűjt. Ezek eredményeinek egy része erős fejlesztési jel, de történeti, fejlesztésre már felhasznált szeleteken született.

Az „árnyék” itt konkrét biztonsági állapot: külön artifact és output, bet_allowed=false vagy shadow_not_submitted, változatlan M1–M11 kontroll és változatlan production artifact. A shadow eredmény csak jelöltet nevezhet meg. Promotionhoz külön, előre rögzített szabály, valódi döntéskori adat, végrehajtható quote, költség utáni eredmény és elegendő független esemény kell.

A.5 A futási ciklus

A box körülbelül 15 percenként újraolvassa a friss piacot és eseményeket, de nem minden adatforrás és nem minden modell frissül 15 percenként. A loop sorban frissíti vagy ellenőrzi a roster-, Oracle-, uncertainty-, tipp-, forward-ledger-, replay-, board- és papír-P&L outputokat. A Leaguepedia hálózati lekérés 24 órás throttle-t használ; a loop minden körben meghívhatja, de friss snapshotnál nem kérdezi újra az API-t. Az Oracle-frissítés, a sheet-írás és egyes külső tokenes lépések gép- és hitelesítésfüggők. A statikus webszerver csak a már elkészült fájlokat szolgálja ki.

A 15 perces ciklus scoring és naplózás, nem automatikus modelltréning. A PandaSkill-rácsok, rolling-origin kísérletek, package-retrainek, kalibrátorválasztások és promotion-döntések kézi, reprodukálható futások. Artifacthiánynál vagy feature-eltérésnél a régi scorer képes volt csendben újratanítani; ez ismert veszély, nem kívánt funkció. Auditált működésben az ilyen helyzet hard fail, és csak explicit --allow-train engedéllyel lehetne új artifactot létrehozni.

Egy ciklus sikerét nem az output fájl módosítási ideje bizonyítja. Ellenőrizni kell a bemenet max(snapshot_time_utc) értékét, a roster-scrape idejét, az Oracle utolsó tényleges eseményét, a piaci quote korát, az artifact hashét, a feloldási coverage-et és azt, hogy minden kiírt döntésnek van-e stabil event/market kulcsa. A Google Sheet külön Mac-folyamat; a Linux board attól még renderelhet, hogy a Sheet vagy valamely grader áll.

A.6 Az öt production-kapu

Az öt rendszerkapu a helyes működést bizonyítja, nem a nyereséget; 2026-07-31-én egyik sincs teljesen zöld. Ezeket nem szabad összekeverni az M12/M13 négy gépi promotion-gate-jével (unseen holdout, real-missing lineup coverage, information-state logging, net forward ROI). Az alábbi öt a teljes production út end-to-end szerződése:

1. Időhelyes, reprodukálható igazságforrás. Append-only vagy as-of olvasható bemenet,

content-hash-es manifest, explicit fallback reason és strict audit kell. Hiányzó adat nem jelenthető „sikeres, nincs változás” állapotnak.

1. Teljes lineup-állapotgép és bizonytalanságalapú tét. Az exact-five, a történeti roster és a

ténylegesen beárazott ötös külön mező. A rolling stat és a PandaSkill csak ugyanarra a role→player mapre, atomikusan válthat.

1. Időhelyes oksági lánc az ártól a fillig. Stabil event/team/market kulcs, döntéskori

végrehajtható quote és likviditás, valamint submitted/accepted/fill, díj és csúszás kell; a ledger-accountingnak 100%-osnak kell lennie.

1. A production-populációt mérő validáció. Külön kell riportálni a teljes univerzumot, a

candidate, eligible, fired és executed halmazt, mindegyiknél coverage-dzsel és kizárási okkal. Egy szűk, szép holdout nem helyettesíti ezt.

1. Üzemeltetési szerződés és automatikus őrség. Verziózott séma, end-to-end golden fixture,

health summary, riasztás, idempotens újrafutás és rollback szükséges. Technikai invariáns hibájánál fail-closed állapot kell.

Ha mind az öt zöld, akkor lehet egy döntési szabályt előre befagyasztani és azon nettó CLV-t, kalibrációt és ROI-t mérni. A profitállítás ehhez képest egy következő kapu, nem az ötödik kapu szinonimája.

A.7 Szótár

Oracle's Elixir — nyilvános, történeti LoL-adatkészlet a ténylegesen lejátszott meccsekről és játékosokról. Utólag jó igazságforrás arra, ki játszott és mi lett az eredmény, de önmagában nem mondja meg, hogy a fogadás pillanatában kit jelentettek be kezdőnek. → B1.A1, B0.

Leaguepedia Cargo — a Leaguepedia/Fandom strukturált MediaWiki-lekérdezési felülete. Az authentikált TournamentPlayers–Tournaments join bejelentett torna-kereteket ad, de közösségi forrás, késhet, és a keret nem azonos az exact kezdő ötössel. → B1.A2, B2.

LoL Esports registry — a Riot esemény- és menetrendforrása, amelyből a kezdési idő, a résztvevők, a sorozatformátum és a hivatalos eseményazonosító jöhet. Különösen a döntetlenre képes Bo2 és a kétkimenetelű moneyline szétválasztásánál biztonsági forrás. → B0.4, B13.

Tippmix — fogadóirodai venue, ahonnan konkrét pre-match piac és odds érkezhet. A Tippmix hiánya nem jelenti azt, hogy a modell nem tud árat mondani; csak azt, hogy ott nincs hozzá fogadható quote. → B9, B10, B13.

Polymarket — prediction-market venue, ahol a piaci ár, a spread és a likviditás együtt határozza meg a végrehajtható belépőt. Seed vagy mid ár nem automatikusan kereskedhető ár; az askot, díjat és csúszást külön kell naplózni. → B9, B13.

roszter — egy csapathoz valamely forrásban hozzárendelt játékoskeret. Lehet nevezési keret, történeti keret vagy pillanatnyi becslés; egyik sem azonos automatikusan azzal az öt játékossal, aki ténylegesen kezd. → B1, B2, C.2.

exact-five — mindkét oldalon szereppel együtt ismert és egyértelmű öt kezdő játékos. A 10/10 exact-five a legerősebb lineup-állapot, de csak akkor időhelyes, ha az információ a döntési cutoff előtt tényleg elérhető volt. → B2, A.6/2.

szokásos ötös / reference_five — a csapat és szerep múltbeli, cutoff előtti mintájából képzett referenciafelállás; a mai kód tipikusan az utolsó 20 meccs modális szereplőit használja. A seat-korrekció ehhez viszonyít, ezért a referenciaötösnél egzakt nullának kell lennie. → B4.1, B4.12.

lineup information state — egy döntési pillanat teljes felállásismerete: hány játékos ismert, mely jelöltötösök lehetségesek, miből származik az információ és mikori. Ugyanaz a meccs több különböző information state-et kaphat, ahogy új hír érkezik. → B2, B12, B14.

cutoff és as-of lookup — a cutoff az a legkésőbbi időpont, ameddig egy predikció adatot láthat. Az as-of lookup minden entitáshoz a cutoff előtti utolsó érvényes állapotot választja; nem egyszerűen a fájl legutolsó sorát. → B6, D.3.

snapshot — egy forrás vagy modell állapotának időbélyegzett pillanatfelvétele. A snapshot csak akkor auditálható, ha a megfigyelési idő, a tartalom és az azonosító együtt megmarad; a fájl mtime-ja nem elég. → B1, B14.

append-only ledger — olyan napló, amely a már rögzített döntéskori sort nem írja át egy későbbi refit vagy új quote miatt. Új információ új sort kap; e nélkül a „forward” eredményt a jelenből visszamenőleg át lehetne írni. → B13, B14.

leakage — jövőbeli vagy döntéskor még nem ismert információ bejutása a tanításba, feature-be, kalibrációba vagy értékelésbe. A 2026-07-30-i ns/us időegységhiba ilyen jövőbeli ratinget választott, ezért több korábbi futást érvényteleníteni kellett. → B6, D.2.a.

célváltozó / target — az a kimenet, amelyre a modell veszteséget minimalizál: például a sorozat győztese vagy egy térkép győztese. A célváltozó megválasztása meghatározza a mintát, a függőségeket és azt is, mely piacok árazhatók közvetlenül. → B0.

series és best-of (Bo) — a series több mapből álló mérkőzés; a Bo3 első két mapet nyerő, a Bo5 első három mapet nyerő csapata nyer. A Bo2 döntetlennel is zárulhat, ezért nem kezelhető vakon kétkimenetelű moneyline-ként. → B0.4, B10.

moneyline (ML) — közvetlen fogadás a teljes sorozat győztesére. A production modell ezt a valószínűséget közvetlen joint XGBoostból adja; ezért az ML és a nem-ML ár nem ugyanannak a fejnek a kimenete. → B5, B9.

non-moneyline (non-ML) — minden nem közvetlen sorozatgyőztes piac; a boardon jelenleg map_winner, map_handicap és total_maps. Ezeket közös sorozateredmény-eloszlásból kell képezni, hogy egymással koherensek legyenek. → B10.

terminális score PMF — valószínűségi tömegfüggvény az összes lehetséges végső sorozateredményen, például Bo3-ban 2–0, 2–1, 1–2, 0–2. Ugyanebből összegezhető a győztes, a handicap és a lejátszott mapek száma. → B10, B5.9.

pontár, fair probability, fair odds — a pontár a modell egyetlen becsült valószínűsége; a fair odds ennek reciproka, 1/p. Egyik sem piaci ajánlat, és egyik sem tartalmaz automatikusan bizonytalansági sávot, díjat vagy végrehajtási kockázatot. → B5, B12.

quote / végrehajtható ár — időbélyegzett ajánlat, amelyen a szükséges méret elvileg megköthető. Mid, utolsó kötés vagy seed ár csak referencia; fogadási állításhoz oldal, odds, likviditás, díj és csúszás is kell. → B9, B13.

de-vigging — a bookmaker marginjának eltávolítása a két vagy több kimenetel implicit valószínűségéből. Nélküle a piac „valószínűségei” összege nagyobb lehet 100%-nál, ezért a modellel való összevetés torz. → B9.

edge és EV — az edge a modell és a kínált ár közti előny; egyszerű decimális oddsnál EV = p·odds − 1. Pozitív modell-EV csak akkor jelent gazdasági előnyt, ha a p helyes, az odds végrehajtható, és a költségeket levontuk. → B12, B13.

CLV — closing-line value, vagyis mennyivel jobb vagy rosszabb a belépőár a záróárnál. Hasznos korai jel, de csak azonos piacon, irányban és végrehajtható belépővel; a pozitív CLV önmagában nem bizonyít nettó profitot. → B13, B14.

P&L és ROI — a P&L a fogadások pénzbeli nyeresége/vesztesége, a ROI ennek a feltett tőkéhez viszonyított aránya. Mindkettőt nettó díjjal, csúszással, voiddal és elfogadott fill-lel kell számolni; papír-replayből nem lesz automatikusan realizálható eredmény. → B11, B13.

unit és stake — a unit relatív tétmérték, a stake a tényleges pénzösszeg. Ugyanaz a legacy_units(p) képlet 10 és 100 dolláros UNIT_USD mellett tízszeres dollárkockázatot jelent, ezért a két fogalmat tilos összemosni. → A.3, B12.

Kelly / fractional Kelly — a Kelly-frakció egy ismertnek feltételezett valószínűség és odds mellett a hosszú távú log-bankrollt maximalizáló tétarány. Becsült p, korrelált fogadások és model uncertainty mellett a teljes Kelly túl agresszív; a fractional Kelly ennek csökkentett változata. → B11, B12.

market_reliability és lineup_reliability — két külön haircut. Az első azt mondja meg, mennyire végrehajtható és megbízható a venue-quote; a második azt, mennyire ismerjük azt az ötöst, amelyre az árat számoltuk. → B12.A.

production — a tényleges boardot és döntést kiszolgáló, verziózott és rollbackelhető kód-, adat- és modellút. A „legjobb történeti logloss” nem azonos a production státusszal. → A.3, A.6.

shadow — production mellett futó, de valódi döntést nem vezérlő jelölt vagy kísérlet. Saját artifactot és outputot kap, a production kontrollt nem írja felül, és eredménye promotion nélkül nem nevezhető élő modellnek. → A.4.

artifact, manifest, fingerprint — az artifact az illesztett modell és kalibrátor; a manifest leírja a kódot, inputokat, cutoffot, feature-listát és konfigurációt; a fingerprint vagy hash ellenőrzi, hogy tényleg ugyanarról a tartalomról beszélünk. Azonos mezőnév eltérő rating-generációból nem azonos feature. → B14, D.3.

feature — a modell egy bemeneti változója, amelyet csak cutoff előtti adatokból szabad képezni. A feature lehet erőjel, bizonytalansági jel, kontextus vagy technikai állapot; a neve önmagában nem mondja meg, melyik. → B4.

A-csatorna — azok a mezők, amelyek közvetlenül a várható csapaterőt és ezért a pontárat módosíthatják: például a szokásos ötöshöz mért seat-μ és teljesítménystatisztika. A tiszta ötéves futásban a seat25 A 5/5 évben javított. → B4.1, B5.2.

B-csatorna — azok a mezők, amelyek elsősorban azt mérik, mennyit tudunk a csapatról: rating-σ, meccsszám és coverage. A befagyasztott elvi szerződés ezeket intervallumhoz és téthez kötötte, de a σ 4/5 évben pontárjelként is javított; ezért a „soha az árba” szabály már nem tekinthető empirikus ténynek. → B4.4, B8, B12.3.

team-level — a csapat múltbeli eredményeiből és aggregált állapotából képzett alapréteg. Mivel a múltbeli csapaterő már a szokásos játékosokat is tükrözi, abszolút player-erőt ráadni dupla számolás lenne. → B4, B5.2.

per-seat / seat delta — szerepenként a tényleges játékos és a csapat szokásos szereplőjének különbsége. Ez lineup-változáskor korrigál, a referenciaötösnél pedig egzakt nullát kell adnia. → B4.1, C.1.

PandaSkill / OpenSkill — Bayes-i jellegű ratingrendszer, amely minden játékoshoz vagy régióhoz erőközepet és bizonytalanságot tart fenn, majd eredmények után frissít. A projekt PandaSkillnek nevezi a saját OpenSkill-alapú, időhelyes snapshot-útját. → B3.

μ (mű) — a PandaSkill becsült erőközepe. Külön játékos-, csapat- és régió-μ létezhet; összehasonlítani csak azonos ladderből, generációból és cutoffból származó értékeket szabad. → B3, B4.

σ (szigma) — a rating vagy a becsült ár bizonytalanságának skálája, nem a bináris kimenet p(1−p) szórása. Lehet hasznos irányjel, intervallum- vagy tétjel; ezek külön hipotézisek, nem felcserélhető szerepek. → B8, B12.3.

beta és tau — OpenSkill-hiperparaméterek: a beta a teljesítményzaj skálájához, a tau az erő időbeli változásához kapcsolódik. A játékos- és régióladder azonos defaultja kényelmi döntés, nem validált szükségszerűség. → B3.2–B3.4.

régióladder — a ligák vagy régiók közti erőkülönbséget becslő ratingréteg. Akkor számít, amikor ritkán találkozó régiók csapatai játszanak; a kevés kereszt-régiós eredmény miatt prior- és hiperparaméter-érzékeny. → B3.4, B3.6.

kalibráció és Platt — a kalibráció a nyers score-t úgy alakítja valószínűséggé, hogy a 70%-osnak mondott események hosszú távon körülbelül 70%-ban történjenek meg. A Platt-logisztika slope-ot és opcionálisan interceptet illeszt; az intercept side-order bias-t vihet a boardba. → B7, C.5.

blue-oriented értékelés — minden történeti sort a tényleges blue oldal felől tájol. Ez érvényes offline diagnosztika, de csak akkor döntéshelyes live mérce, ha a blue/red oldal a fogadás pillanatában ismert és a feed csapatsorrendjéhez biztosan hozzárendelhető. A jelenlegi odds-feedben ez nem teljesül (live_left_order_is_not_blue). → B7.1, C.5.

side-neutral tükörértékelés — ugyanazt a meccset mindkét csapatsorrendben értékeli, így a puszta left/right vagy feed-order előny kiátlagolódik. Ezt kell használni, amikor a live út nem tud valódi blue/red oldalt. → B7.1, B7.2, C.5.

identity kalibráció — a nyers szimmetrikus modellár változatlan átengedése: nincs sem intercept-, sem slope-refit. Nem azt jelenti, hogy a modell tökéletesen kalibrált, hanem azt, hogy a kalibrátor nem írja át az árat. → B7.2, C.5.

logloss — proper scoring rule, amely különösen erősen bünteti a magabiztos tévedést; kisebb érték jobb. Modellárak összevetésére alkalmas, de nem tartalmaz oddsot, költséget vagy tétet, ezért nem pénzügyi célfüggvény. → B5, D.4.

Brier-score — a valószínűség és a 0/1 kimenet négyzetes hibájának átlaga; kisebb jobb. A loglosshoz képest kevésbé bünteti a szélsőséges tévedést, ezért a két proper score együtt erősebb bizonyíték. → B5, D.2.

AUC és ECE — az AUC a rangsorolást méri: milyen gyakran kerül a győztes a vesztes fölé; nem mondja meg, hogy a 70% valóban 70%-e. Az ECE kalibrációs hibát foglal bin-ekbe, de binválasztás- érzékeny, ezért diagnosztika, nem egyedüli döntési mérce. → B7, C.5.

rolling-origin — időrendi validáció, amely több egymást követő évben mindig csak a múltból tanít és a következő időszakon értékel. Az öt évből 5/5 azonos irány erősebb stabilitási jel, mint egyetlen 755 soros holdout. → D.2, B4.1.

holdout és gate — a holdout modellválasztáskor érintetlenül hagyott értékelő időszak; a gate előre rögzített elfogadási feltétel. Ha ugyanazt a holdoutot új ötletek kiválasztására többször felhasználjuk, fejlesztési mintává válik és elveszíti promotion-erejét. → D.2, D.3.

OOF (out-of-fold) — olyan tréningpredikció, amelynél minden sorra egy azt nem látó fold modellje ad score-t. Többlépcsős modellben ez akadályozza meg, hogy a második lépcső az első lépcső tanítási túlillesztését tanulja meg. → B5.2, D.3.

bootstrap-CI — újramintázással becsült konfidenciaintervallum egy metrika vagy két kar különbsége körül. Meccs- vagy eseményszinten kell mintázni, ha ugyanazon series piacai korrelálnak; a nullát nem fedő intervallum sem javít ki rossz cutoffot vagy post-hoc karválasztást. → D.2, B11.

fail-closed — bizonytalan technikai állapotban a rendszer nem gyárt megbízhatónak látszó tippet, hanem látható okkal letilt vagy széles, nem robust állapotba vált. A legitim lineup- bizonytalanság nem mindig technikai hiba; azt kisebb tét és intervallum kezelheti. → A.6, B14.

promotion — explicit döntés, amellyel egy fagyasztott shadow jelölt a production kontroll helyére kerül. Ehhez nem elég jobb történeti logloss: teljes provenance, diszjunkt időholdout, valódi missingness, append-only forward minta és költség utáni eredmény kell. → A.4, A.6.

A.8 Fájltérkép

B. A lánc — megpróbáltuk-e?

B.0 A gerinc — 15 lépcső

Az első váz 12-t használt. Három lépcső hiányzott belőle, és mind döntő lehet:

B0  CÉLVÁLTOZÓ  ← mit jósolunk egyáltalán?
 │
 ├─ B1 adatforrás → B2 roszter → B3 RATING → B4 feature → B5 pontár → B6 idő → B7 kalibráció
 │                                                                                    ↓
 │  B14 üzemeltetés ← B13 végrehajtás ← B12 döntés ← B11 KOCKÁZAT ← B10 nem-ML ←──────┤
 │                                            ↑            ↑                          │
 │                                            └── B9 PIACI ÁR           B8 bizonytalanság

A táblázat maga az eredmény. A B4/B5 sok történeti mérést kapott; a célváltozó, piac, kockázat, döntés és végrehajtás kérdései dokumentáltak, de nagyrészt empirikusan nyitottak.

B.00 A bejegyzés-sablon — MINDEN bejegyzés így néz ki

### Bx.y  A kérdés önhordó címe

**Fok:** A / B / C / D / X / ?

**Válasz egy mondatban:** A rövid, kimondható válasz, feltétellel együtt.

**Miért kérdeztük.** 2–4 mondat arról, mely döntést változtatná meg a válasz.

**Mit futtattunk.** Karok, split, elemszám és cutoff-szerződés. Ha nem futott: — (nem futott).

**A szám.** Konkrét eredmény mértékegységgel és elemszámmal. Ha nem futott: — (nem futott).

**Mi cáfolná.** Az az előre rögzíthető eredmény, amely megfordítaná a választ.

**Kapcsolódik.** A közvetlen előzmény, következmény és az esetleges konfliktus.

**Forrás.** Script · artifact · riport/párbeszéd-azonosító.

Kötelező mezők: Fok · Válasz egy mondatban · Miért kérdeztük · Mit futtattunk · A szám · Mi cáfolná · Kapcsolódik · Forrás. Hiányzó mező = a bejegyzés nincs kész. ?-fokozatnál a Mit futtattunk és A szám helyére — (nem futott) kerül, de a Miért kérdeztük és a Mi cáfolná akkor is kötelező. A fokot kizárólag a D.2 bizonyítékszabály és az érvényes, hivatkozott futás határozza meg.

B0 — Célváltozó

Soha nem tettük fel külön kísérletként a kérdést, hogy mit jósoljunk. A series-győztest jósoljuk, mert az volt kéznél. A map-szintű célváltozó 2,5–3× mintát adna, és a nem-ML fejeknek amúgy is kell — de a pályák nem függetlenek (HOLDOUT_RHO), tehát nem ingyen.

B0.1 Jobb-e a map-szintű célváltozó a series-célnál?

Fok: ? ·

Válasz egy mondatban: Az első tiszta score-diagnosztika döntetlent adott, de a production szempontjából fontos, format-aware map→series PMF összevetés továbbra sem készült el.

Miért kérdeztük: a map-target körülbelül 2,5–3-szor több címkét adna és közvetlenebb alap lenne a non-ML piacokhoz.

A célváltozó megválasztása az egész downstream láncot meghatározza: más a megfigyelési egység, a függőség, a kalibráció és az, hogy mely piacok vezethetők le közvetlenül. Egy több sort adó target önmagában nem jobb, ha ugyanazon series mapjei miatt az effektív minta jóval kisebb, vagy ha a címke nem egyezik a fogadási szerződéssel. A válaszhoz ezért azonos információt, series-csoportos idősplitet és piacszintű értékelést kell tartani.

Mit futtattunk: E47-ben azonos tíz döntéskori rolling feature-rel két logisztikus modellt tanítottunk. A series-kar az első map állapotából a series-kimenetet tanulta; a map-kar minden mapet látott, series-enként összesen egy súllyal, majd az első-map score-ját ugyanazon series- kimeneten értékeltük 2022–2026 rolling-origin években.

A szám: 22 461 közös tesztseriesen a map−series logloss-különbség −0,000004, a series-bootstrap 95%-os CI [−0,000362; +0,000354]; a map-kar csak 2/5 évben jobb. Ez valódi döntetlen, nem a map-target veresége. A történeti döntéskori Bo3/Bo5 formátum hiánya miatt a map-score-t nem alakítottuk series-valószínűséggé, ezért a fő kérdés fokozata marad ?.

Mi cáfolná: előre rögzített, series szerint csoportosított rolling-origin összevetés azonos inputinformációval, logloss/Brier mellett market-family kalibrációval.

A kérdőjel nem azt jelenti, hogy nincs implementáció vagy nincs vélemény, hanem azt, hogy a jelenlegi artifactok nem különítik el a versengő magyarázatokat érvényes mintán. A lezáró futás előtt rögzíteni kell a kontrollt, az elsődleges metrikát, a minimum független elemszámot, a cutoff-szerződést és a döntési küszöböt. Addig a rendszer fail-closed vagy shadow állapotban marad; terv, kód, nyers coverage vagy utólag kiválasztott legjobb kar nem emeli a fokot.

Kapcsolódik: B0.2, B5.9, B10.

Forrás: E47; run_target_granularity_experiment.py; ARCHITECTURE.md §9–§12.

B0.2 Mennyit ér a nagyobb map-minta a sorozaton belüli korreláció mellett?

Fok: ? ·

Válasz egy mondatban: A névleges 2,5–3-szoros sorszám nem jelent ugyanekkora effektív mintát, mert egy series mapjei függők.

Miért kérdeztük: mapenkénti random split leakage-et és túl szűk CI-t adhat.

A célváltozó megválasztása az egész downstream láncot meghatározza: más a megfigyelési egység, a függőség, a kalibráció és az, hogy mely piacok vezethetők le közvetlenül. Egy több sort adó target önmagában nem jobb, ha ugyanazon series mapjei miatt az effektív minta jóval kisebb, vagy ha a címke nem egyezik a fogadási szerződéssel. A válaszhoz ezért azonos információt, series-csoportos idősplitet és piacszintű értékelést kell tartani.

Mit futtattunk: — (nem futott).

A szám: — (nem futott).

Mi cáfolná: series-clusterelt bootstrap és group rolling-origin, amely kiírja a design effectet és az effektív mintanagyságot.

A kérdőjel nem azt jelenti, hogy nincs implementáció vagy nincs vélemény, hanem azt, hogy a jelenlegi artifactok nem különítik el a versengő magyarázatokat érvényes mintán. A lezáró futás előtt rögzíteni kell a kontrollt, az elsődleges metrikát, a minimum független elemszámot, a cutoff-szerződést és a döntési küszöböt. Addig a rendszer fail-closed vagy shadow állapotban marad; terv, kód, nyers coverage vagy utólag kiválasztott legjobb kar nem emeli a fokot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B0.1, B10.3, B11.3.

Forrás: ODDS_COHERENCE.md; nincs lezárt célváltozó-kísérlet.

B0.3 Közös toronyra kötve tanuljon-e a map- és series-target?

Fok: ? ·

Válasz egy mondatban: Nem tudjuk, hogy a közös reprezentáció segít-e vagy a series-labellel visszaszivárogtatja ugyanazt a hibát.

Miért kérdeztük: a két target közös csapaterőt lát, de eltérő zajt és kalibrációt.

A célváltozó megválasztása az egész downstream láncot meghatározza: más a megfigyelési egység, a függőség, a kalibráció és az, hogy mely piacok vezethetők le közvetlenül. Egy több sort adó target önmagában nem jobb, ha ugyanazon series mapjei miatt az effektív minta jóval kisebb, vagy ha a címke nem egyezik a fogadási szerződéssel. A válaszhoz ezért azonos információt, series-csoportos idősplitet és piacszintű értékelést kell tartani.

Mit futtattunk: — (nem futott).

A szám: — (nem futott).

Mi cáfolná: háromkarú, időrendi teszt: külön map-modell, külön series-modell, közös torony két fejjel; azonos paraméterbudget és series-szintű értékelés.

A kérdőjel nem azt jelenti, hogy nincs implementáció vagy nincs vélemény, hanem azt, hogy a jelenlegi artifactok nem különítik el a versengő magyarázatokat érvényes mintán. A lezáró futás előtt rögzíteni kell a kontrollt, az elsődleges metrikát, a minimum független elemszámot, a cutoff-szerződést és a döntési küszöböt. Addig a rendszer fail-closed vagy shadow állapotban marad; terv, kód, nyers coverage vagy utólag kiválasztott legjobb kar nem emeli a fokot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B5.3, B5.9, B10.3.

Forrás: közvetlen artifact nincs.

B0.4 Helyes-e a Bo2 fail-closed?

Fok: C ·

Válasz egy mondatban: Igen: draw-capable formátumon kétkimenetelű moneyline-t kiadni kategóriahiba, ezért ismeretlen vagy Bo2 formátumnál a kétutas ár tiltása biztonságos.

Miért kérdeztük: a 1–1 kimenetel valós, miközben a production target bináris.

A célváltozó megválasztása az egész downstream láncot meghatározza: más a megfigyelési egység, a függőség, a kalibráció és az, hogy mely piacok vezethetők le közvetlenül. Egy több sort adó target önmagában nem jobb, ha ugyanazon series mapjei miatt az effektív minta jóval kisebb, vagy ha a címke nem egyezik a fogadási szerződéssel. A válaszhoz ezért azonos információt, series-csoportos idősplitet és piacszintű értékelést kell tartani.

Mit futtattunk: a LoL Esports-registry formátumkapuját és a result-label egyezést fixture-ökön és 271 hivatalos eredményen ellenőriztük.

A szám: 271/271 label-egyezés; draw-capable seriesre nincs kétutas tipp.

Mi cáfolná: olyan venue-piac, amelynek szerződése explicit döntetlen kezelést vagy draw-no-bet elszámolást ad, és ezt a market schema megőrzi.

A C fok határa egyetlen előre értelmezhető fejlesztési szelet vagy strukturált diagnosztika. Ez elegendő az irány dokumentálására és a következő teszt megtervezésére, de nem általánosítható automatikusan más évre, ligára vagy fogadási piacra. A következő mérésnek előre fagyasztott kontraszttal több időfoldot vagy elegendő forward mintát kell adnia, ugyanazon proper score- és invariánskapukkal; csak ekkor emelhető a fok.

Kapcsolódik: B10, B13.

Forrás: STATE_OF_PLAY.md; LoL Esports registry tesztek.

B1 — Adatforrás

Az eredmény-adat utólag mondja meg, ki játszott; a felállás-hír előre próbálja megmondani, ki fog játszani. A modell tanítása az elsőből él, a fogadás a másodikból. Minden forrást cutoff, coverage, hibatípus és hiánykezelés szerint kell olvasni; a latest snapshot nem helyettesíti az append-only döntéskori történetet.

B1.A A roszter-források leltára

A táblázat gyorskereső; alatta minden forrás önálló bejegyzést kap.

Amit minden bejegyzésnek tartalmaznia kell: mikori az adat (cutoff-helyes-e), mekkora a lefedettség, hogyan hibázik (némán vagy hangosan), és mi történik, ha hiányzik.

B1.A2 Leaguepedia Cargo — authentikált roster-forrás

Fok: nem alkalmazható — forrásleltár; a megbízhatósági kérdés külön B1.2.

Válasz egy mondatban: A Leaguepedia Cargo ma az elsődleges programozható előzetes roster-forrás, de torna-keretet ad, nem garantált kezdő ötöst.

Miért kérdeztük. Az Oracle csak utólag mondja meg, ki játszott, a boardnak viszont a döntés előtt kell felállást választania. A korábbi gol.gg út bizonyítottan rossz csapathoz is rendelhetett keretet, ezért kellett gyors, lekérdezhető és időbélyegezhető alternatíva.

Mit futtattunk. Az operatív collect_leaguepedia_rosters.py authentikált Cargo-kéréssel a TournamentPlayers=TP,Tournaments=T joinból kér Team, Player, Role, Tournament és DateStart mezőket. Az aktuális, illetve még futó tornákat bevonja, a staff-szerepeket kiszűri, majd torna×csapat szinten keretté aggregál; a loop legfeljebb 24 óránként kér új snapshotot, és a változásokat append-only fájlba írja.

A szám. A 2026-07-31 12:14 +0200-kor írt lokális roster_snapshot_latest.csv 2 489 csapat–torna sort, 1 286 külön csapatnevet és 260 tornát tartalmaz. A korábbi „774 csapat” állapotjelentés egy régebbi adatvintage volt; nem maradhat időbélyeg nélküli állandóként.

Mi cáfolná. Egy cutoff-helyes, kézzel ellenőrzött upcoming-minta, amelyen a Cargo rosszabb exact-starter vagy csapatazonossági fedést ad, mint egy másik előzetes forrás; illetve bármely olyan eset, amikor staff vagy régi torna-keret némán átmegy kezdőötösként.

Kapcsolódik. B1.2 (jobb-e az authentikált Leaguepedia?) · B2.3 (bejelentett vs modális) · C.2 (kezdőötös-jósolhatóság) · A.6/1 (igazságforrás).

Forrás: src/lolbet/collect/collect_leaguepedia_cargo.py · src/lolbet/collect/collect_leaguepedia_rosters.py · processed/leaguepedia/rosters/roster_snapshot_latest.csv.

B1.A1 Oracle's Elixir — történeti igazságforrás

Fok: nem alkalmazható ·

Válasz egy mondatban: Az Oracle a ténylegesen lejátszott játékos–map sorok és eredmények tanítási igazságforrása, de előzetes lineup-hírként nem használható.

Miért kérdeztük: a label és a döntéskor ismert információ más időpontból származik. Az Oracle erőssége éppen az, hogy a mérkőzés után rögzíti, kik játszottak és mi történt; ugyanezért veszélyes lenne upcoming forrásként kezelni. Ha a később megismert exact ötös visszaszivárog a döntéskori feature-be, a rosterfeloldás mesterségesen hibátlanná válik. Külön kellett rögzíteni, hogy az Oracle a tanítás label- és retrospektív auditoldala, nem a live információs állapot része.

Mit futtattunk: a training build szerep-, csapat-, idő- és winner-mezőit hivatalos eredményekkel ellenőriztük. Az as-of rosterprofilok minden célmeccsnél csak a korábbi Oracle-sorokat láthatták; a célmeccs tényleges játékosait kizárólag utólagos kiértékeléshez használtuk. A result-audit külön ellenőrizte a győztes oldalt, nehogy csapatsorrend-csere labelhibát rejtsen el.

A szám: az auditált result-mintán 271/271 egyezés; a friss retrospektív adat 2026-07-28-nál véget ér. Ez a 271-es ellenőrzés a vizsgált mintát igazolja, nem az Oracle minden évét és ligáját; a dátum pedig adatvintage, nem a forrás örök frissességi ígérete.

Mi cáfolná: hivatalos forrással ellentmondó label, duplikált map eltérő kimenettel vagy cutoff előtti lineupként kezelt utólagos sor. Már egy ilyen időirány-hiba érvénytelenítené az érintett roster- és modellmérést; az őr ezért max timestampet és célmeccs-ID-t is ellenőrizzen.

Kapcsolódik: B0, B6, B14.

Forrás: Oracle CSV-k, STATE_OF_PLAY.md, ARCHITECTURE.md.

B1.A3 Leaguepedia roster-wrapper

Fok: nem alkalmazható ·

Válasz egy mondatban: Ez nem második forrás, hanem a Cargo-adat operatív lekérője, normalizálója és változásnaplózója.

Miért kérdeztük: a forrást és az azt feldolgozó útvonalat külön kell látni. A Cargo válasza lehet helyes, miközben a wrapper rossz időablakot kér, staffot játékosnak hagy, aliasokat összevon vagy a latest fájllal eltünteti a korábbi állapotot. Korábban a „Leaguepedia működik” állítás ezeket egyetlen dobozzá mosta össze. Auditnál külön kell tudni támadni a távoli tartalmat, a queryt, a normalizálást és a tárolási szerződést.

Mit futtattunk: 120 napos és még futó tornák lekérése, staff-szűrés, 24 órás throttle, latest snapshot és append-only history. A wrapper a normalizált sort időbélyeggel írja a historyba, miközben a latest csak kényelmi nézet. Az ismételt lekérésnek azonos távoli tartalom mellett nem szabad új, tartalmilag duplikált változást gyártania.

A szám: a lokális history 88 422 adatsort tartalmazott 2026-07-31-én. Ez fizikai sorszám, nem 88 422 független rosteresemény: ugyanaz a csapat–torna több snapshotban is szerepelhet. Coverage-et ezért a latest egyedi entitásain, változást pedig a history egymást követő állapotain kell mérni.

Mi cáfolná: ugyanazon scrape ismétlése új történeti sort vagy eltérő normalizált rostert adna; ugyanígy bukás, ha egy valódi forrásváltozás nem kap új history-sort. Golden fixture-ben azonos inputnak byte-stabil latestet, módosított inputnak pontosan egy új állapotot kell adnia.

Kapcsolódik: B1.A2, B1.4, B14.8.

Forrás: collect_leaguepedia_rosters.py, roster_snapshot_history.csv.

B1.A4 gol.gg rosterforrás

Fok: nem alkalmazható; státusz: nyugdíjazva ·

Válasz egy mondatban: A gol.gg nem maradhat elsődleges rosterforrás, mert rossz entitáshoz is rendelt látszólag érvényes keretet.

Miért kérdeztük: a néma rossz roster veszélyesebb a hiánynál. Hiánynál a rendszer tud fallbacket, kisebb reliabilityt vagy fail-closed állapotot választani; egy öt névvel kitöltött, de más csapathoz tartozó keret teljes bizonyosság látszatát kelti. Az ilyen hiba nemcsak a badge-et, hanem a seat-deltát, a PandaSkill-aggregációt és végül a tippet is rossz entitásból számolja.

Mit futtattunk: kézi esetellenőrzést és Leaguepedia-összevetést a gyanús upcoming sorokon. A vizsgálat a csapatnevet, a ligát, a játékosokat és a forrásoldal tényleges entitását együtt nézte, nem csak azt, hogy öt nem üres név érkezett-e. A collector kódját is átnéztük abból a szempontból, hogy stabil ID helyett hol támaszkodik név- vagy keresési találatra.

A szám: legalább egy bizonyított súlyos esetben a Kits koreai kamu- rostert kapott. Ez nem prevalenciabecslés: egy eset nem mondja meg, hány százalék hibás. A forrás-alkalmasságot mégis megdönti, mert az út némán, teljesnek látszó rosterként engedte át.

Mi cáfolná: csak egy új, stabil entitásazonosítós API és nagy, cutoff-helyes kézi minta állíthatná vissza. Előre rögzített upcoming eseményeken legalább 95%-os helyes csapat- és starterfeloldás, nulla bizonyított cross-team tévesztés és látható fail-closed ok kellene.

Kapcsolódik: B1.1, B2, B14.3.

Forrás: STATE_OF_PLAY.md, collect_golgg_rosters.py.

B1.A5 LoL Esports API

Fok: nem alkalmazható; státusz: részben bekötött jelöltforrás ·

Válasz egy mondatban: A Riot forrás jó esemény- és formátumazonosító, de a roster-résztvevői lefedése önmagában nem elég teljes elsődleges lineupforrásnak.

Miért kérdeztük: hivatalos azonosító és párhuzamos rosterjel kell. A közösségi rosterforrások alias- és frissességi hibáját egy független hivatalos út képes lehet észlelni, a Bo2/Bo3/Bo5 formátum pedig közvetlenül meghatározza, mely piacok értelmezhetők. Ugyanakkor a Riot schedule eseménylétezést bizonyít, nem automatikusan döntés előtt ismert kezdő ötöst; ezt a két szerepet nem szabad összecsúsztatni.

Mit futtattunk: upcoming schedule- és game-participant-gyűjtést, majd feloldási auditot. A collector a hivatalos eseményazonosítót, kezdési időt, csapatokat és sorozatformátumot külön artifactba írja; a participant rekordokat csak akkor lehet rosterjelként használni, ha timestampjük a döntési cutoff előtt van. A hiányzó résztvevő nem kap modális névvel kitöltött „hivatalos” státuszt.

A szám: a korábbi riport körülbelül 73% résztvevői fedést adott. Ez hasznos keresztjel, de túl alacsony ahhoz, hogy egyedüli starterforrás legyen; a coverage nem azonos a megtalált sorok pontosságával sem.

Mi cáfolná: stabil, legalább 95%-os cutoff-helyes upcoming starter coverage, kézzel auditált helyességgel és külön missing-reasonnel. A státusz csak akkor emelhető, ha több liga és legalább 100 upcoming series mintáján a Riot-jel nem későbbi, mint a board döntése.

Kapcsolódik: B0.4, B1.3, B13.

Forrás: collect_riot_fresh_sources.py, lolesports_game_participants.csv.

B1.A6 Liquipedia roster-idővonal

Fok: nem alkalmazható; státusz: kísérleti ·

Válasz egy mondatban: A Liquipedia hasznos szöveges roster-idővonal lehet, de jelenleg nincs production feloldási útba kötve.

Miért kérdeztük: a join/leave dátumok kiegészíthetik a torna-keretet. A Cargo többnyire azt mondja meg, kit neveztek egy tornára; a timeline azt is jelezheti, mikor csatlakozott, távozott vagy vált inaktívvá egy játékos. Ez roster-csere időpontjához és a döntéskori jelöltpool szűkítéséhez értékes lehet, de csak akkor, ha a szöveges dátum és az aliasfeloldás megbízható.

Mit futtattunk: kísérleti timeline-kinyerést külön artifactba; a nyers választ is megőriztük. A prototípus játékos-, csapat- és időmezőket normalizált, de nem kapott teljes cutoff-, duplikáció- és cross-source auditot. Nem került a production resolver prioritási sorrendjébe, így a mai board árát és tippjét nem módosítja.

A szám: 210 soros artifact készült. A sorszám nem coverage: nem tudjuk belőle, az upcoming csapatok mekkora részéhez van friss esemény, hány sor valódi változás, és hány aliasduplikáció. Ezért ebből sem minőségi fok, sem inkrementális modellérték nem következik.

Mi cáfolná: a jelenlegi kísérleti státuszt egy Leaguepedia melletti cutoff-, alias- és coverage-audit változtatná meg. Legalább 100 időbélyegzett rostereseményen kell mérni, hogy a Liquipedia korábban és helyesebben jelzi-e a változást; későbbi vagy ellentmondó sor fail-closed ok.

Kapcsolódik: B1.6, B2.5.

Forrás: liquipedia_roster_timeline.csv.

B1.A7 Modális ötös

Fok: nem alkalmazható; státusz: production fallback ·

Válasz egy mondatban: A modális ötös az utolsó 20 meccs leggyakoribb szereplője szerepenként, ezért múltból becsül és nem bejelentést olvas.

Miért kérdeztük: exact lineup nélkül is kell reprodukálható referencia. A team-level modell már a csapat szokásos erejét hordozza; a seat-korrekciónak ezért nem egy abszolút játékosötöst, hanem az ettől való eltérést kell leírnia. A múltbeli módusz egyszerű, cutoff-helyes és minden csapatra ugyanazzal a szabállyal képezhető, de gyakori csere, szerepcsere vagy kevés előzmény esetén könnyen hamis bizonyosságot ad.

Mit futtattunk: past-only roster-profile buildet minden célmeccs előtt legfeljebb az előző 20 meccsből. Szerepenként külön móduszt választottunk, majd a később ténylegesen lejátszott ötössel exact-five és seat-szinten hasonlítottuk össze. A célmeccs saját rosterét a profil nem láthatta.

A szám: az exact ötös csapatszintű medián találata 52,0%, szék-szinten 71,8%; 37 csapat 20% alatt, 24 legalább 80%-on volt. Az átlag mögötti heterogenitás miatt a fallback reliabilityje nem lehet minden csapatra azonos.

Mi cáfolná: egy előzetes forrás ugyanazon upcoming populáción tartósan jobb starterpontosságot ad, vagy más múltablak több rolling évben veri a 20 meccset. Legalább 100 cutoff-helyes series, csapat/tier bontás és exact- valamint seat-metrika kell; a javulás ne csak stabil rosterekről jöjjön.

Kapcsolódik: B2.1, B2.3, C.2.

Forrás: player_feature_builder.reference_five(), build_roster_profiles.py.

B1.A8 PandaSkill team snapshot

Fok: nem alkalmazható; státusz: production featureforrás ·

Válasz egy mondatban: A team snapshot cutoff előtti csapat-μ/σ-t és a hozzá tartozó játékoslistát adja, de csak a rating artifact azonosságával együtt értelmezhető.

Miért kérdeztük: azonos nevű mező két rating-generációból eltérhet. A production snapshot és a szerepfeloldott shadow út korábban ugyanazt a ps_team_mu_diff nevet használta, noha más generációból vagy más aggregációból jöhetett. Ha a név alapján összekeverjük őket, egy modell látszólag ugyanazt a feature-t kapja, miközben valójában a teljes ratingtörténet megváltozott.

Mit futtattunk: kézi provenance-t és F9 dekompozíciót. Minden megtartott match-side soron a snapshot team-μ/σ értékét újraszámoltuk a hozzá tartozó öt játékos atomikus állapotából, azonos cutoffal. A manifest külön rögzítette a player- és match-rating artifact hashét, hogy a két út ne csak numerikusan, hanem származásában is azonosítható legyen.

A szám: 45 312/45 331 exact-five sor egyezett 1e-9 tolerancián belül; 19 azonos timestampű sor fail-closed kiesett. Az egyezés a vizsgált atomikus generáció belső konzisztenciáját bizonyítja; nem igazolja önmagában az OpenSkill-paramétereket vagy a roster helyességét.

Mi cáfolná: bármely megtartott sor μ- vagy σ-eltérése a tíz játékos aggregátumától, artifacthash nélküli újragenerálás vagy timestamp-tie önkényes feloldása. Az őr minden buildben bitközeli F9-egyezést és explicit kiesési okot követel.

Kapcsolódik: B1.5, B3.7, B14.3.

Forrás: PANDASKILL_F9_DECAY_K8_ROLLING_REPORT_2026-07-30.md.

B1.B A kérdések

B1.1 Megbízható-e a gol.gg rosterforrás?

Fok: X ·

Válasz egy mondatban: Nem; bizonyítottan tudott rossz csapatidentitásból hihetőnek látszó rostert adni.

Miért kérdeztük: a modell nem feltétlenül jelzi, ha öt valós játékos a rossz csapathoz tartozik. A korábbi feltételezés az volt, hogy egy rosterforrás hibája legfeljebb hiányzó sort okoz, amit a fallback láthatóan kezel. A Kits-eset megmutatta az ellenkező, veszélyesebb hibát: teljesnek és típushelyesnek látszó ötös érkezhet más entitásból, így a downstream feature-, ár- és bizonytalanságút zölden fut tovább. Emiatt itt nem átlagos coverage-ről, hanem néma súlyos hiba kizárásáról döntünk.

Mit futtattunk: esetvizsgálat Leaguepedia-kontrollal.

A szám: a Kits-eset súlyos, kézzel igazolt ellenpélda; általános hibaarány nincs mérve.

Mi cáfolná: új, ID-alapú gol.gg út legalább 100 upcoming csapatos vak auditon nulla súlyos eltéréssel. A minta előre fagyasztott upcoming csapatokat használjon, és külön számolja az exact starter-, team-identity- és staff-szennyezési hibát. A forrás csak akkor kaphatna újra szerepet, ha a 95%-os felső konfidenciahatár is a Leaguepedia hibaaránya alatt maradna, és egyetlen main↔feeder entitáscsere sem fordulna elő.

Az X a kipróbált megvalósítást és a fenti, szűk állítást vonja vissza; nem bizonyítja, hogy az egész ötletcsalád minden lehetséges formája értéktelen. Új változat csak a leírt cáfolati protokollal, előre fagyasztott karon és érintetlen időszakon nyitható ki. Ugyanannak az elhasznált szeletnek új paraméterrel történő ismételt megnyitása nem számít új bizonyítéknak.

Kapcsolódik: B1.A4, B14.3.

Forrás: STATE_OF_PLAY.md.

B1.2 Jobb-e az authentikált Leaguepedia?

Fok: B ·

Válasz egy mondatban: Operatív forrásként igen: nagyobb és frissebb strukturált keretet ad, de exact-starter fölényét még nem mértük vak mintán.

Miért kérdeztük: az anonim Cargo rate-limitelt, a gol.gg pedig hibázott.

Forráskérdésnél a nagyobb sor- vagy coverage-szám nem azonos a jobb döntéskori információval. Külön kell mérni az entitáshelyességet, az exact starter pontosságát, a forrás késését és azt, hogy a hiány hangosan vagy némán jelentkezik-e. A retrospektív Oracle ground truth csak a későbbi értékeléshez használható; a jelölt forrás minden mezőjének a tipprecord létrejötte előtt rögzített állapotból kell származnia.

Mit futtattunk: bot-password login, dátumablakos Cargo join és kézi ismert-esetek.

A szám: 2 489 csapat–torna sor, 1 286 csapat a 2026-07-31-i snapshotban.

Mi cáfolná: upcoming exact-lineup mintán rosszabb coverage vagy pontosság egy alternatív forrásnál.

A B fok azt jelzi, hogy a jel több szeletből vagy független reprodukcióból ismétlődött, de a teljes production és pénzügyi lánc még nem feltétlenül zöld. Az állítás csak a megnevezett targetre, populációra és metrikára vihető át. Promotion előtt külön forward adat, döntéskori provenance, kalibráció és végrehajtási ellenőrzés kell; egy új, ellentétes és érvényes adatvintage a fokot visszanyithatja.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B1.A2, B2.3.

Forrás: Cargo snapshot és collector.

B1.3 Ér-e valamit a LoL Esports API párhuzamos rosterjelként?

Fok: ? ·

Válasz egy mondatban: Nem tudjuk; eseményazonosításra hasznos, de inkrementális starterértékét nem mértük.

Miért kérdeztük: független hivatalos jel kiszúrhatja a közösségi forrás késését.

Forráskérdésnél a nagyobb sor- vagy coverage-szám nem azonos a jobb döntéskori információval. Külön kell mérni az entitáshelyességet, az exact starter pontosságát, a forrás késését és azt, hogy a hiány hangosan vagy némán jelentkezik-e. A retrospektív Oracle ground truth csak a későbbi értékeléshez használható; a jelölt forrás minden mezőjének a tipprecord létrejötte előtt rögzített állapotból kell származnia.

Mit futtattunk: — (nem futott összehasonlító kar).

A szám: — (nincs inkrementális mérés; a nyers coverage körülbelül 73%).

Mi cáfolná: cutoff-helyes Leaguepedia, Riot és kombinált kar ugyanazon upcoming ground truth-on.

A kérdőjel nem azt jelenti, hogy nincs implementáció vagy nincs vélemény, hanem azt, hogy a jelenlegi artifactok nem különítik el a versengő magyarázatokat érvényes mintán. A lezáró futás előtt rögzíteni kell a kontrollt, az elsődleges metrikát, a minimum független elemszámot, a cutoff-szerződést és a döntési küszöböt. Addig a rendszer fail-closed vagy shadow állapotban marad; terv, kód, nyers coverage vagy utólag kiválasztott legjobb kar nem emeli a fokot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B1.A5, B2.3.

Forrás: collect_riot_fresh_sources.py.

B1.4 Valódi idősor-e a rosteradat?

Fok: X ·

Válasz egy mondatban: A latest fájl nem idősor, de az új history és changes napló append-only; a régi visszamenőleges állítások ezért nem állíthatók helyre.

Miért kérdeztük: replace-in-place adatból nem rekonstruálható, mit tudtunk a döntéskor. Régebben a latest snapshotot úgy kezeltük, mintha a mai tartalma a múltbeli döntéskor is ismert lett volna. Ez look-aheadot okozhat a rosterfeloldásban, és egy új scrape utólag megváltoztathatja ugyanannak a fogadásnak a magyarázatát. A kérdés ezért nem pusztán tárolási preferencia: a forward eredmények auditálhatósága és a modell tényleges információs halmaza múlik rajta.

Mit futtattunk: idempotencia- és history-séma ellenőrzés.

A szám: a jelenlegi history 88 422 adatsor; ez nem pótolja a bevezetése előtti múltat.

Mi cáfolná: korábbi snapshotok content-hash-es archívuma. A cáfolathoz nem elég egy új history fájl: minden döntéshez feloldható, döntés előtt írt snapshot-ID, tartalmi hash és source timestamp kellene, majd egy rerunban byte-azonos roster- és tipprekord. A bevezetés előtti időszak csak külső, változatlan archívumból állítható helyre; enélkül az X történeti része végleges.

Az X a kipróbált megvalósítást és a fenti, szűk állítást vonja vissza; nem bizonyítja, hogy az egész ötletcsalád minden lehetséges formája értéktelen. Új változat csak a leírt cáfolati protokollal, előre fagyasztott karon és érintetlen időszakon nyitható ki. Ugyanannak az elhasznált szeletnek új paraméterrel történő ismételt megnyitása nem számít új bizonyítéknak.

Kapcsolódik: B14.8, B12.3.

Forrás: roster snapshot fájlok.

B1.5 Melyik ps_team_mu_diff a helyes?

Fok: B ·

Válasz egy mondatban: Ugyanazon cutoff, roster és rating-generáció mellett a team snapshotnak és a tíz játékos aggregátumának egyeznie kell; a korábbi eltérés adatút-hiba volt.

Miért kérdeztük: azonos név alatt corr=0,690 és 0% egzakt egyezés jelent meg.

Forráskérdésnél a nagyobb sor- vagy coverage-szám nem azonos a jobb döntéskori információval. Külön kell mérni az entitáshelyességet, az exact starter pontosságát, a forrás késését és azt, hogy a hiány hangosan vagy némán jelentkezik-e. A retrospektív Oracle ground truth csak a későbbi értékeléshez használható; a jelölt forrás minden mezőjének a tipprecord létrejötte előtt rögzített állapotból kell származnia.

Mit futtattunk: kézi Giants–Fnatic provenance és teljes F9 dekompozíció.

A szám: 45 312 megtartott soron max μ-eltérés 2,13e−14, max σ-eltérés 2,66e−15.

Mi cáfolná: új hashpáron bármely >1e-9 eltérés.

A B fok azt jelzi, hogy a jel több szeletből vagy független reprodukcióból ismétlődött, de a teljes production és pénzügyi lánc még nem feltétlenül zöld. Az állítás csak a megnevezett targetre, populációra és metrikára vihető át. Promotion előtt külön forward adat, döntéskori provenance, kalibráció és végrehajtási ellenőrzés kell; egy új, ellentétes és érvényes adatvintage a fokot visszanyithatja.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B1.A8, B14.3.

Forrás: PandaSkill F9 riport.

B1.6 Mennyit ad a Liquipedia a Leaguepedia fölött?

Fok: ? ·

Válasz egy mondatban: Nem tudjuk; csak 210 soros kísérleti timeline van, közös upcoming értékelés nincs.

Miért kérdeztük: a join/leave esemény gyorsabb lehet a tornaoldal frissítésénél.

Forráskérdésnél a nagyobb sor- vagy coverage-szám nem azonos a jobb döntéskori információval. Külön kell mérni az entitáshelyességet, az exact starter pontosságát, a forrás késését és azt, hogy a hiány hangosan vagy némán jelentkezik-e. A retrospektív Oracle ground truth csak a későbbi értékeléshez használható; a jelölt forrás minden mezőjének a tipprecord létrejötte előtt rögzített állapotból kell származnia.

Mit futtattunk: — (nem futott összehasonlító mérés).

A szám: — (a 210 sor nem teljesítménymetrika).

Mi cáfolná: időbélyegzett forrásablation starter accuracyvel, coverage-dzsel és késési eloszlással.

A kérdőjel nem azt jelenti, hogy nincs implementáció vagy nincs vélemény, hanem azt, hogy a jelenlegi artifactok nem különítik el a versengő magyarázatokat érvényes mintán. A lezáró futás előtt rögzíteni kell a kontrollt, az elsődleges metrikát, a minimum független elemszámot, a cutoff-szerződést és a döntési küszöböt. Addig a rendszer fail-closed vagy shadow állapotban marad; terv, kód, nyers coverage vagy utólag kiválasztott legjobb kar nem emeli a fokot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B1.A6, B2.5.

Forrás: Liquipedia timeline artifact.

B1.8 Ugyanaz-e az acad és a cl, vagy külön rétegzés kell?

Fok: ?

Válasz egy mondatban: Az entitásfeloldás ma megkülönbözteti az acad és cl címkét, de a modellezési és értékelési út mindkettőt academy réteggé vonja össze; nem mértük, hogy ez veszteséges összevonás-e.

Miért kérdeztük. A két címke nem feltétlenül ugyanazt a versenykörnyezetet jelenti. Az akadémiai csapat egy szervezet fejlesztő kerete lehet, a challenger címke viszont ligaszintet vagy második divíziót is takarhat; eltérhet a játékosszint, a feljutási rendszer, a mérkőzésszám és a rosterfluktuáció. Eddig csak a főcsapattal való összekeverést akartuk megakadályozni, ezért minden feeder-jellegű csapatot közös guard mögé tettünk, és nem vizsgáltuk a két alréteg különbségét.

Mit futtattunk. Forrás- és kódauditot, nem prediktív összevetést. A központi classifier három értéket tart meg (main, acad, cl), míg a team_identity_tier() és több downstream audit az acad|cl → academy leképezést használja.

A szám. A 2026-os összesítésben 34 acad és 7 cl csapat szerepel. A frissebb first-batch tier-audit forrásoldalon 79 acad és 78 cl egyedi, kontextussal azonosított entitást lát, de ez nem közös, outcome-os teljesítményminta.

Mi cáfolná. Előre rögzített, időrendi értékelés ugyanazon modellel, külön main, acad és cl rétegeken. Külön rétegzés akkor indokolt, ha mindkét feeder-réteg eléri legalább az n=100 független series kaput, és a köztük mért logloss-, kalibráció- vagy rosterhibakülönbség CI-je kizárja a nullát; enélkül a külön bontás kis mintás zaj lehet.

Kapcsolódik. C.6, B7.5, B8.9.

Forrás: src/lolbet/common/teams.py, src/lolbet/models/lineup_skill.py, processed/odds/fresh_watch/shadow_models/first_batch/team_tiers/team_tier_summary.csv.

B2 — Roszter-feloldás

A bejelentett keret egy forrás állítása, a modális és referenciaötös múltból képzett becslés, az exact-five pedig az öt tényleges kezdő szereppel együtt. Ezeket a rendszer nem kezelheti szinonimaként.

B2.1 Mennyire jósolható a kezdő ötös?

Fok: B ·

Válasz egy mondatban: Közepesen: a past-only modális ötös medián 52,0%-ban találja el mind az öt kezdőt, egy-egy széket 71,8%-ban.

Miért kérdeztük: exact lineup nélkül erre épül a referencia és a lineup-posterior.

A rosterfeloldásnál a technikai coverage és az információ prediktív értéke külön kérdés. Egy teljesnek látszó keret lehet bő, későn frissített vagy rossz szerepsorrendű, miközben a múltbeli fallback reprodukálható, de elavult. A vizsgálatnak ugyanazon upcoming eseményeken kell fagyasztania minden forrás állapotát, majd csak a meccs után szabad az exact ötössel összevetnie; különben a jobb feloldás könnyen look-ahead eredménye.

Mit futtattunk: 20 meccses, csak múltat látó rosterprofil 2026-os csapatokon.

A szám: exact-five átlag 49,5%, medián 52,0%; 37 csapat 20% alatt, 24 legalább 80%-on.

Mi cáfolná: új időszakban lényegesen eltérő találati eloszlás.

A B fok azt jelzi, hogy a jel több szeletből vagy független reprodukcióból ismétlődött, de a teljes production és pénzügyi lánc még nem feltétlenül zöld. Az állítás csak a megnevezett targetre, populációra és metrikára vihető át. Promotion előtt külön forward adat, döntéskori provenance, kalibráció és végrehajtási ellenőrzés kell; egy új, ellentétes és érvényes adatvintage a fokot visszanyithatja.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B1.A7, B8.1, C.2.

Forrás: build_roster_profiles.py, E23.

E53 kiegészítő leíró mérés. A 2026-os Oracle 13 700 pályáján, 386 csapatra a leggyakoribb ötös súlyozott aránya 68,4%; 206 csapat 70%, 96 csapat 50% alatt van. Ez megmutatja, hogy a felállásbizonytalanság erősen csapatfüggő, ezért az élő boardon hasznosabb figyelmeztetés, mint a ≤3 napos rosteresemény, amely a vizsgált 17 tippből 16-on jelzett. Az E53 azonban teljes éves, utólagos koncentrációs leírás: nem cutoff-helyes előrejelzési teszt, és történeti feature-ként csak időpontonként újraépítve használható. Az E23 52,0%-os exact-five eredményét nem írja felül; a K11 feladata ugyanazokat a rosterverdikteket előre rögzítve, stabilitási rétegenként újramérni.

Forrás: src/lolbet/features/build_lineup_stability_index.py, E53.

E54 rétegzett audit. Az E23 és E53 közös 273 csapatán a történeti stabilitás valóban együtt jár a modális ötös jósolhatóságával: az exact-five medián <50% stabilitásnál 34,40%, 50–70% között 51,25%, 70–90% között 55,10%, ≥90%-nál 71,60%; a folytonos korreláció +0,592348. Ez azonban forecastability, nem döntési érték. Az E22 ellenpontár-táblát is hozzákapcsolva (224 csapat) a medián árspan rendre 22,81, 16,63, 14,61 és 20,25 pp: a stabil rétegben nem nulla. A korábbi 0,00 pp abból a körkörös állításból jött, hogy ahol csak egy megfigyelt ötös volt, ott nincs megfigyelt második ötös. Ebből nem következik, hogy egy tényleges csere hatástalan lenne, és tétpolicy sem következik; ahhoz előre rögzített forward P&L- és drawdown-kar kell.

Forrás: python -m lolbet.analysis.run_lineup_stability_strata, E54.

B2.2 Számít-e a szerepsorrend feloldása?

Fok: B ·

Válasz egy mondatban: Az exact-five esetben ritkán; a mért kétértelműség 0,59%, a valódi nehézség a 6–9 fős keretből a kezdők kiválasztása.

Miért kérdeztük: szerepcsere és startercsere más hibaforrás.

A rosterfeloldásnál a technikai coverage és az információ prediktív értéke külön kérdés. Egy teljesnek látszó keret lehet bő, későn frissített vagy rossz szerepsorrendű, miközben a múltbeli fallback reprodukálható, de elavult. A vizsgálatnak ugyanazon upcoming eseményeken kell fagyasztania minden forrás állapotát, majd csak a meccs után szabad az exact ötössel összevetnie; különben a jobb feloldás könnyen look-ahead eredménye.

Mit futtattunk: role-assignment audit 2026-os exact ötösökön és nagy kereteken.

A szám: exact-five ambiguity 0,59%, large-squad starter ambiguity 37,54%.

Mi cáfolná: új liga/időszak, ahol a role ambiguity gyakori és érdemben mozgatja az árat.

A B fok azt jelzi, hogy a jel több szeletből vagy független reprodukcióból ismétlődött, de a teljes production és pénzügyi lánc még nem feltétlenül zöld. Az állítás csak a megnevezett targetre, populációra és metrikára vihető át. Promotion előtt külön forward adat, döntéskori provenance, kalibráció és végrehajtási ellenőrzés kell; egy új, ellentétes és érvényes adatvintage a fokot visszanyithatja.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B2.3, B4.1.

Forrás: T17 role-assignment artifact.

B2.3 Jobb-e a bejelentett felállás a modálisnál?

Fok: ? ·

Válasz egy mondatban: Valószínű, de nincs ugyanazon upcoming mintán mért, cutoff-helyes összevetés.

Miért kérdeztük: a bejelentett keret frissebb, de lehet bő, késő vagy staffal szennyezett.

A rosterfeloldásnál a technikai coverage és az információ prediktív értéke külön kérdés. Egy teljesnek látszó keret lehet bő, későn frissített vagy rossz szerepsorrendű, miközben a múltbeli fallback reprodukálható, de elavult. A vizsgálatnak ugyanazon upcoming eseményeken kell fagyasztania minden forrás állapotát, majd csak a meccs után szabad az exact ötössel összevetnie; különben a jobb feloldás könnyen look-ahead eredménye.

Mit futtattunk: — (nem futott).

A szám: — (nem futott).

Mi cáfolná: előre naplózott Leaguepedia/Riot announced kar és modális kontroll, későbbi Oracle exact starterrel értékelve.

A kérdőjel nem azt jelenti, hogy nincs implementáció vagy nincs vélemény, hanem azt, hogy a jelenlegi artifactok nem különítik el a versengő magyarázatokat érvényes mintán. A lezáró futás előtt rögzíteni kell a kontrollt, az elsődleges metrikát, a minimum független elemszámot, a cutoff-szerződést és a döntési küszöböt. Addig a rendszer fail-closed vagy shadow állapotban marad; terv, kód, nyers coverage vagy utólag kiválasztott legjobb kar nem emeli a fokot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B1.A2, B2.1, B8.1.

Forrás: nincs érvényes összehasonlító artifact.

B2.4 Mennyit ér a felállás-ismeret?

Fok: D ·

Válasz egy mondatban: Van pozitív fejlesztési felső korlát: a tényleges ötöst használó D kar igazoltan jobb a team-only B-nél, de egyik előzetes fallback-policy sem promótálható.

Miért kérdeztük: meg kell különböztetni az információ értékét a rosterjóslás minőségétől.

A rosterfeloldásnál a technikai coverage és az információ prediktív értéke külön kérdés. Egy teljesnek látszó keret lehet bő, későn frissített vagy rossz szerepsorrendű, miközben a múltbeli fallback reprodukálható, de elavult. A vizsgálatnak ugyanazon upcoming eseményeken kell fagyasztania minden forrás állapotát, majd csak a meccs után szabad az exact ötössel összevetnie; különben a jobb feloldás könnyen look-ahead eredménye.

Mit futtattunk: A/B/C/D karok 690-es fejlesztési holdouton.

A szám: D−B +0,01512 [0,00302;0,02725]; C−B +0,00899, A−B +0,00810, utóbbi CI-k nullát fednek.

Mi cáfolná: független forward minta, ahol exact lineup sem javít.

A D fok tudatos figyelmeztetés: a szám elhasznált holdoutból, utólag nyitott karból vagy retrospektív replayből jön. Leírhatja, miért született egy hipotézis és melyik irányt érdemes újramérni, de confirmatory állításra, modellválasztásra vagy promotionre nem hivatkozható. A fokot ugyanazon szelet új paraméterezése nem javítja; csak előre regisztrált, érintetlen naptári minta és változatlan döntési szabály adhat új bizonyítékot.

Kapcsolódik: B5.2, C.7.

Forrás: K6/§24/T30.

B2.5 Megfigyelhető-e döntéskor a rosterváltozás?

Fok: A ·

Válasz egy mondatban: Technikailag igen az új snapshot-history és változásnapló bevezetése óta; a korábbi időszakra nem rekonstruálható.

Miért kérdeztük: a változás ideje kell a badge-hez és az oksági feature-höz. Korábban csak a jelenlegi és a referenciaötös eltérését láttuk, ezért nem tudtuk elválasztani a valódi új hírt a régen megtörtént, már beárazott rosterhelyzettől. A boardon ugyanaz a jelzés jelent meg friss bejelentésre és többhetes állapotra. Időbélyeg nélkül sem a felhasználónak szóló magyarázat, sem a változás körüli ármozgás oksági vizsgálata nem lehetséges.

Mit futtattunk: idempotens Leaguepedia scrape, snapshot-diff és information-state linkelés.

A szám: az auditált első forward batchben 60/60 shadow order érvényes information-state linket kapott; a history jelenleg 88 422 sor.

Mi cáfolná: bejelentett változás, amely nem generál új state-et, vagy későbbi adat írja át a régit. A következő ellenőrzés legalább 100, később exact lineup-pal lezárt upcoming eseményt kövessen, és minden tényleges változásnál kérje számon az első észlelés idejét, a forrást és az előző hash-t. Már egy olyan súlyos eset visszavonná az A technikai állítást, ahol a history változatlan marad, de a döntéshez használt ötös utólag csendben módosul.

Az A fok itt kizárólag a fenti, szűken megfogalmazott és a megadott mércén vizsgált állításra vonatkozik. Nem jelent automatikus production promotiont, bizonyított pénzügyi edge-et, más targetre való átvihetőséget vagy a teljes modellcsalád általános győzelmét. Ezekhez a kapcsolódó adat-, kalibrációs, végrehajtási és forward kapuknak külön, döntéskor rögzített bizonyítékot kell adniuk.

Kapcsolódik: B14.8, C.7.

Forrás: forward shadow report, roster collector.

B2.6 Jó-e a ±12 órás outcome-join ablak?

Fok: C ·

Válasz egy mondatban: Működő fallback, de az időablak önmagában nem elégséges azonosító és nincs széles körben optimalizálva.

Miért kérdeztük: azonos csapatpár rövid időn belül többször is játszhat.

A rosterfeloldásnál a technikai coverage és az információ prediktív értéke külön kérdés. Egy teljesnek látszó keret lehet bő, későn frissített vagy rossz szerepsorrendű, miközben a múltbeli fallback reprodukálható, de elavult. A vizsgálatnak ugyanazon upcoming eseményeken kell fagyasztania minden forrás állapotát, majd csak a meccs után szabad az exact ötössel összevetnie; különben a jobb feloldás könnyen look-ahead eredménye.

Mit futtattunk: exact pair+time Riot join és exact event+pair+time market-konszenzus, fuzzy fallback nélkül.

A szám: az első, 2026-07-30-i auditban 13 Riot- és 8 market-log eredmény ment át; ez a join működésének történeti fixture-je, nem élő kapuszámláló. Az E42 későbbi, rögzített auditja 66 graded soron bontotta fel a D_actual=0 okát: 33 legacy sor nem építhető vissza, 33 új sor pedig Oracle exact-five igazságra várt. A folyamatosan változó snapshot/graded/pending/párosítatlan darabszám kizárólag a forward_grading_report.json health reportban él.

Mi cáfolná: egyértelmű event-ID mellett téves vagy többszörös ±12 órás találat.

A C fok határa egyetlen előre értelmezhető fejlesztési szelet vagy strukturált diagnosztika. Ez elegendő az irány dokumentálására és a következő teszt megtervezésére, de nem általánosítható automatikusan más évre, ligára vagy fogadási piacra. A következő mérésnek előre fagyasztott kontraszttal több időfoldot vagy elegendő forward mintát kell adnia, ugyanazon proper score- és invariánskapukkal; csak ekkor emelhető a fok.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B13.4, B14.8.

Forrás: konszolidáció §5.1.

B3 — Rating (PandaSkill)

B3.A Mi ez, és honnan jön

A PandaSkill nem külső komponens — a mi implementációnk. Egy szakcikk ötletét (arXiv:2501.10049) vettük át, a repójukat nem vendoroltuk, a számaikat nem használtuk. Amit örököltünk, az az elgondolás; a kód és minden szám a mienk, Oracle's Elixir adatból, openskill.models.PlackettLuce motorral.

Ennek egyetlen, súlyos következménye van: a láncban nincs egyetlen külsőleg validált konstans sem. Minden szám vagy könyvtári default, vagy valaki egyszer beírta.

Négy lépcső: perf-score (öt szerep-logisztikus becsli, ki játszott jól) → OpenSkill free-for-all (a 10 játékos tíz egyfős csapatként, perf_score szerint rangsorolva — így egy vesztes meccsen jól játszó is nyer ratinget) → régió-ladder (második, független ladder régiók fölött, kizárólag régióközi meccsekből) → kombinálás.

B3.B A bedrótozott számok leltára

Tizenegy bedrótozott döntésből négyet közvetlenül mértünk: player-beta, player-tau, régióparaméterek és aggregáció. A kezdőprior, kappa, balance/limit_sigma és a perf-score belső hiperparaméterei továbbra is nyitottak.

B3.C A két ladder paraméterrácsa

player_model = PlackettLuce(**(player_model_params or {}))   # sosem adunk at parametert
region_model = PlackettLuce(**(region_model_params or {}))   # ugyanaz a default

A játékos-ladder ~99 302 mapen frissül. A régió-ladder kizárólag régióközi nemzetközi meccseken — azok ritkák. Emiatt a két ladder defaultazonosságát külön rács támadta.

És ez nem apróság: a LOGIT3-ban a régió-együttható 0,0467 a μ 0,0793-jához képest — a régió a csapaterő ~59%-át éri, 2026-ra 0,709-re nő az arány.

Az ötéves eredmény szerint a player-beta felezése és a player-tau emelése stabil, nagyobb irány. A régió-beta felezése ugyan 5/5 évben jobb, a régió-tau duplázása csak 3/5-ben, és mindkettő hatása kicsi. Ezért a „külön dinamika kell” hipotézis részben alátámasztott, a végleges régió- paraméter nincs lezárva.

B3.D Miért volt mérhető

Korábban 79–288 mezős XGBoostokban mértünk, ahol egy 0,003-as rating-javulás elveszett a zajban. A LOGIT3 három paraméter — egy rating-változás hatása közvetlenül és zajmentesen látszik. Minden kar ugyanazt a LOGIT3+D365 downstream fejet kapta.

B3.E A végrehajtott mérés

Egy rácspont a teljes történeti láncot újraszámolta, majd azonos LOGIT3 fejet értékelt öt rolling évben. Összesen 21 kar futott; karonként 23 025 out-of-year series-predikció készült.

A protokoll, kötelezően:

1. Egyszerre egy konstans. A tau–beta interakciót külön kell mérni, nem egy rácsban.
2. Rolling-origin, öt év — egyetlen szelet itt sem hivatkozható.
3. A célfüggvény a LOGIT3 logloss, nem a rating belső illeszkedése. A rating nem

önmagáért jó, hanem mert utána jobb árat ad.

1. Külön namespace. A pandaskill_ratings.csv és a snapshotok élő fájlok — a rácsnak

saját könyvtárba kell írnia, különben a production alól cserélünk adatot.

1. Leakage-őr minden rácsponton. A *_pre konstrukció (a rating csak korábbi meccseket lát)

újra ellenőrizendő, nem feltételezhető.

A lefutott fő tengelyek:

player beta       × {0,25; 0,5; 0,75; 1; 2}·alap
player tau        × {0; 1; 2; 4}·alap
region beta       × {0,5; 1; 2}·alap
region tau        × {0; 1; 2}·alap
frissítési mód    × {performance-only; outcome-only; winner-first+performance}
strict kontroll  × {későbbi Plattos perf; expanding-window raw perf}

A numerikus győztes BETA_HALF_TAU_DOUBLE_WINNER_PERF, LL 0,579617. A szigorú időhelyes kontroll STRICT_RAW_BETA_HALF_TAU_DOUBLE_WINNER_PERF, LL 0,579713, saját strict baseline-jához +0,007050 [0,006088;0,008053], 5/5 év. A kombinált kar a stage-1 beta-rács széle után nyílt, ezért erős fejlesztési jel, de új időszak nélkül nem promotion-bizonyíték. A perf-score C és foldszám nem futott: az külön B3.5 marad.

B3.F A kérdések

A rating-belső rács 21 kart futtatott újra öt rolling évben. A player-beta/tau és frissítési sorrend iránya mérve van; a perf-score modell belseje, a hiányzó játékos prior és a végleges régiódinamika továbbra is nyitott. Külső validáció egyik konstansra sincs.

B3.1 Jó-e a region_weight=0,35?

Fok: X ·

Válasz egy mondatban: Nem igazolható külön konstansként; a LOGIT3 a régiójelet külön együtthatóval tanulja, ezért a kézi 0,35 tárgytalan.

Miért kérdeztük: a régióközi erő kevés mérkőzésből jön. A kézi 0,35 azt feltételezte, hogy a régiójel minden időszakban ugyanúgy aránylik a csapatjelhez, noha a nemzetközi találkozók ritkák és évenként más mezőnyt kapcsolnak össze. Ha ez a konstans rossz, minden régióközi meccsen azonos irányú torzítást okoz. A LOGIT3 bevezetésével először vált külön mérhetővé, hogy maga a régiójel hasznos-e, és mekkora súlyt kér a downstream célváltozó.

Mit futtattunk: minimal-model rolling-origin és implicit súlykiolvasás.

A szám: az implicit régiós súly foldonként körülbelül 0,28–0,71; egyetlen 0,35 nem stabil.

Mi cáfolná: új, előre rögzített rács, ahol a fix 0,35 több évben veri a tanult súlyt. Az összevetésnek kizárólag cross-region eseményeken is ki kell írnia a loglosst és a kalibrációt, legalább négy külön évvel. A fix konstans csak akkor térhetne vissza, ha pozitív CI-vel jobb vagy azonos, és közben kisebb foldközi ingadozást adna, mint a külön tanult együttható.

Az X a kipróbált megvalósítást és a fenti, szűk állítást vonja vissza; nem bizonyítja, hogy az egész ötletcsalád minden lehetséges formája értéktelen. Új változat csak a leírt cáfolati protokollal, előre fagyasztott karon és érintetlen időszakon nyitható ki. Ugyanannak az elhasznált szeletnek új paraméterrel történő ismételt megnyitása nem számít új bizonyítéknak.

Kapcsolódik: B3.4, B5.1.

Forrás: E17, rating riportok.

B3.2 Jó-e az OpenSkill beta?

Fok: A az irányra, nem a végső optimumra ·

Válasz egy mondatban: A játékos-beta felezése stabilan jobb a defaultnál; a negyedelés már feltételes exploráció.

Miért kérdeztük: a beta a teljesítményzaj skáláját és minden ratingfrissítést befolyásol. A könyvtári defaultot korábban külső igazolás nélkül örököltük, pedig a LoL mapek teljesítményzaja nem szükségképpen egyezik azzal a sporttal vagy szimulációval, amelyre a defaultot választották. Túl nagy beta elmossa a valódi különbséget, túl kicsi beta túlreagálhat egyetlen mapet; a hiba az egész későbbi ratingtörténetet megváltoztatja, nem csak egy regressziós együtthatót.

Mit futtattunk: minden karban teljes rating-rebuild, azonos LOGIT3+D365 fejjel, 2022–2026 rolling-originban.

A szám: PLAYER_BETA_HALF LL 0,582959 és 5/5 baseline-győzelem; default 0,585872; beta-double 0,593948 és 0/5. A fél-β az első rács alsó széle volt, ezért megnyitottuk a második hullámot: a β/4 kar nem hiányzik, LL-je 0,583590 és csak 4/5 évben nyert, tehát rosszabb a β/2-nél. A végső optimum ettől még nincs független időszakon lezárva, mert a második hullám feltételesen nyílt ki.

Mi cáfolná: új években a half-beta előnyének eltűnése, vagy egy előre rögzített, β/2 körüli finomrács más, foldok között stabil belső optimuma.

Kapcsolódik: B3.3, B3.6.

Forrás: RATING_INTERNAL_ROLLING_ORIGIN_REPORT.md.

B3.3 Jó-e a tau a játékosladderen?

Fok: A az emelés első hullámos irányára; az E40 tau×6 optimuma D ·

Válasz egy mondatban: A defaultnál nagyobb player-tau jobb, és a kibővített rácson a tau×6 belső optimum: jobb a négyszeresnél, a nyolcszoros viszont már egyértelműen ront.

Miért kérdeztük: túl kis tau befagyaszt, túl nagy tau zajossá tesz. Korábban a könyvtári defaultot azért hagytuk érintetlenül, mert kényelmes és numerikusan stabil volt, nem azért, mert LoL-adaton nyert. A játékoserő meta-, csapat- és szerepváltozásokkal gyorsan mozdulhat; a túl lassú ladder hónapokig őrzi a régi állapotot, a túl gyors viszont minden map után szétesik. Ezért az irányt több időéven kellett ellenőrizni.

Mit futtattunk: tau-zero, double, quadruple, sextuple és octuple teljes rating-láncban, ugyanazon öt rolling éven és közös 23 023 OOF soron.

A szám: tau-double LL 0,584610, tau-quadruple 0,582733, tau-sextuple 0,582277, tau-octuple 0,583544, baseline 0,585872. A tau×6 javulása tau×4 fölött +0,000399 [+0,000058; +0,000743]; a tau×8 változása tau×6 fölött −0,001267 [−0,001620; −0,000906].

Mi cáfolná: új időszakban az emelt tau stabil hátránya, vagy egy előre rögzített finomrácson a 4×–8× tartomány más, foldok között stabil optimuma. Az A irányt akkor vonnánk vissza, ha legalább három új évben a default nyerne, vagy az emelt tau előnye a szigorú raw-performance kontrollon eltűnne. A mai rács már mindkét oldalon zárt; ez belső optimumot, nem production promotiont jelent.

Kapcsolódik: B3.2, B6.2.

Forrás: RATING_INTERNAL_ROLLING_ORIGIN_REPORT.md, E34/E40. Az optimum D, mert a második hullám a korábbi rácsszél láttán nyílt meg ugyanazon éveken.

B3.4 Jó-e ugyanaz a tau a régióladderen?

Fok: C ·

Válasz egy mondatban: Nincs azonosított régió-hiperparaméter-hatás: a mért eltérések gyakorlatilag nullák, ezért sem az azonos default, sem egy eltérő régiódinamika nem igazolt.

Miért kérdeztük: a régiók sokkal ritkábban találkoznak, mint a játékosok.

A rating belső választása nem lokális hiperparaméter: minden korábbi frissítést, így a célmeccs előtti teljes állapotot megváltoztatja. Egy részleges vagy egyholdoutos próbából ezért nem lehet biztonságosan következtetni. Érvényes összevetéshez minden kart külön namespace-ben, teljes történeti rebuilddel, azonos downstream fejjel és több rolling évvel kell futtatni, miközben a teljesítményjel, a cutoff és a hiányzó játékos priorja változatlan.

Mit futtattunk: region tau-zero/double és region beta half/double teljes rating-rebuildben.

A szám: region-tau-double LL 0,585743, 3/5 év; baseline 0,585872; tau-zero 0,586128. A region-beta-half ugyan 5/5 évben nyert, de csak +0,000130 [−0,0000224; +0,000288] ΔLL-lel: a CI súrolja/fedi a nullát, ezért az 5/5 itt nem gyakorlati irány, hanem apró, zajszintű egyezés.

Mi cáfolná: cross-region fókuszú új időszak stabil, érdemi más tau optimuma.

A C fok határa egyetlen előre értelmezhető fejlesztési szelet vagy strukturált diagnosztika. Ez elegendő az irány dokumentálására és a következő teszt megtervezésére, de nem általánosítható automatikusan más évre, ligára vagy fogadási piacra. A következő mérésnek előre fagyasztott kontraszttal több időfoldot vagy elegendő forward mintát kell adnia, ugyanazon proper score- és invariánskapukkal; csak ekkor emelhető a fok.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B3.1, B3.3.

Forrás: rating-internal rolling report.

B3.5 Jó-e a perf-score modell?

Fok: ? ·

Válasz egy mondatban: Nem tudjuk; a C=0,5, nyolcfoldos szerepmodell teljes változtatása nem volt ablatálva.

Miért kérdeztük: ez rendezi a tíz játékost, tehát hibája végig megy a ratingen.

A rating belső választása nem lokális hiperparaméter: minden korábbi frissítést, így a célmeccs előtti teljes állapotot megváltoztatja. Egy részleges vagy egyholdoutos próbából ezért nem lehet biztonságosan következtetni. Érvényes összevetéshez minden kart külön namespace-ben, teljes történeti rebuilddel, azonos downstream fejjel és több rolling évvel kell futtatni, miközben a teljesítményjel, a cutoff és a hiányzó játékos priorja változatlan.

Mit futtattunk: — (nincs alternatív C/fold/target teljes láncfutás).

A szám: — (nem futott).

Mi cáfolná: előre rögzített C-rács és outcome-alapú kontroll teljes rating-rebuilddel.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B3.6, B3.2.

Forrás: fit_pandaskill_ratings.py.

B3.6 Jó-e a free-for-all perf-score rangsor?

Fok: B ·

Válasz egy mondatban: A tiszta irány a winner-first, azon belül raw performance tie-break; a performance-only baseline nem a legjobb.

Miért kérdeztük: performance-only mellett egy vesztes meccs jól játszó tagja ratinget nyerhet.

A rating belső választása nem lokális hiperparaméter: minden korábbi frissítést, így a célmeccs előtti teljes állapotot megváltoztatja. Egy részleges vagy egyholdoutos próbából ezért nem lehet biztonságosan következtetni. Érvényes összevetéshez minden kart külön namespace-ben, teljes történeti rebuilddel, azonos downstream fejjel és több rolling évvel kell futtatni, miközben a teljesítményjel, a cutoff és a hiányzó játékos priorja változatlan.

Mit futtattunk: performance-only, outcome-only, winner-then-performance és strict raw változatok, teljes ötéves rating-rebuilddel.

A szám: baseline 0,585872; outcome-only 0,585703; winner-then-perf 0,584448. A strict kombinált half-beta+double-tau+winner-perf 0,579713 vs strict baseline 0,586764, +0,007050 [0,006088;0,008053], 5/5, de feltételes exploráció.

Mi cáfolná: új időszakban a winner-first előny eltűnése.

A B fok azt jelzi, hogy a jel több szeletből vagy független reprodukcióból ismétlődött, de a teljes production és pénzügyi lánc még nem feltétlenül zöld. Az állítás csak a megnevezett targetre, populációra és metrikára vihető át. Promotion előtt külön forward adat, döntéskori provenance, kalibráció és végrehajtási ellenőrzés kell; egy új, ellentétes és érvényes adatvintage a fokot visszanyithatja.

Kapcsolódik: B3.2, B3.5.

Forrás: rating-internal rolling report.

B3.7 Jó-e az átlag-μ és RMS-σ aggregáció?

Fok: X a teljes párra ·

Válasz egy mondatban: Az átlag-μ tartható, de a tiszta újrafutásban az átlag-σ 5/5 évben verte az RMS-σ-t, ezért a régi páros specifikáció megdőlt.

Miért kérdeztük: a tíz játékosból csapatszintű state kell. Az RMS-σ intuitívan bünteti az egyetlen nagyon bizonytalan játékost, ezért sokáig természetes aggregátumnak tűnt. Ugyanakkor a downstream modell signed csapatkülönbséget lát, és az RMS más skálát, valamint erősebb szélsőérték-hatást ad, mint a μ egyszerű átlaga. A kérdés azért load-bearing, mert ugyanaz a roster két aggregációval eltérő árat és bizonytalansági állapotot kap.

Mit futtattunk: atomikus aggregációs rolling-origin 22 414 soron.

A szám: mean-σ vs RMS-σ ΔLL +0,000503 [0,000257;0,000743], 5/5 év; max-σ −0,006130.

Mi cáfolná: új független években az RMS stabil fölénye. A visszafordításhoz ugyanazon cutoff-helyes játékosstate-ekből épített mean- és RMS-kar kell legalább négy új rolling évben, előre rögzített LOGIT3 fejjel. RMS csak akkor térhet vissza, ha a pooled LL-CI pozitív, legalább 3/4 évben nyer, és a ritka, magas-σ játékosok rétegében sem romlik a kalibráció.

Az X a kipróbált megvalósítást és a fenti, szűk állítást vonja vissza; nem bizonyítja, hogy az egész ötletcsalád minden lehetséges formája értéktelen. Új változat csak a leírt cáfolati protokollal, előre fagyasztott karon és érintetlen időszakon nyitható ki. Ugyanannak az elhasznált szeletnek új paraméterrel történő ismételt megnyitása nem számít új bizonyítéknak.

Kapcsolódik: B4.3, B8.9.

Forrás: atomic aggregation riport.

B3.8 Jó-e a hiányzó játékos μ=25 priorja?

Fok: ? ·

Válasz egy mondatban: Nem tudjuk; a default prior érzékenységét és újonc-populációs kalibrációját nem mértük.

Miért kérdeztük: ismeretlen játékosnál ez közvetlenül árat mozdít.

A rating belső választása nem lokális hiperparaméter: minden korábbi frissítést, így a célmeccs előtti teljes állapotot megváltoztatja. Egy részleges vagy egyholdoutos próbából ezért nem lehet biztonságosan következtetni. Érvényes összevetéshez minden kart külön namespace-ben, teljes történeti rebuilddel, azonos downstream fejjel és több rolling évvel kell futtatni, miközben a teljesítményjel, a cutoff és a hiányzó játékos priorja változatlan.

Mit futtattunk: — (nem futott).

A szám: — (nem futott).

Mi cáfolná: hierarchikus liga/role prior és fix 25 összevetése új játékosokon, past-only rolling-originban.

A kérdőjel nem azt jelenti, hogy nincs implementáció vagy nincs vélemény, hanem azt, hogy a jelenlegi artifactok nem különítik el a versengő magyarázatokat érvényes mintán. A lezáró futás előtt rögzíteni kell a kontrollt, az elsődleges metrikát, a minimum független elemszámot, a cutoff-szerződést és a döntési küszöböt. Addig a rendszer fail-closed vagy shadow állapotban marad; terv, kód, nyers coverage vagy utólag kiválasztott legjobb kar nem emeli a fokot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B8.9, C.6.

Forrás: PandaSkill konfiguráció.

B4 — Feature-építés

A team-level blokk a csapatmúltat, a per-seat a referenciaötöshöz mért lineup-eltérést, a context a liga/patch/időrezsimet, a meta pedig a gördülő játékkörnyezetet írja le. Az A-csatorna erőjelet, a B-csatorna elsősorban tudás- és coverage-jelet hordoz.

B4.1 Kell-e szerepenkénti bontás a játékos-metrikákban?

Fok: A; a régi E18 érvénytelen, a fokot a tiszta ötéves rolling futás adja.

Válasz egy mondatban: A szerepenkénti bontás a szokásos ötöshöz mért lineup-korrekcióban igen, abszolút csapataggregációként viszont nincs külön igazolva.

Miért kérdeztük. A top, jungle, mid, bot és support nem felcserélhető szerep, ezért egy lineup-csere hatása elveszhet egyetlen csapatátlagban. Ugyanakkor az abszolút játékoserő ráadása a team-alapra dupla számolás lenne; csak a referenciaüléshez mért eltérésnek van tiszta jelentése.

Mit futtattunk. A kijavított, atomikus PandaSkill-inputon öt rolling-origin évet, összesen 22 414 out-of-year sort mértünk. A T10 és T5 team-only karokat ugyanazon, OOF team-marginra illesztett seat25 A réteggel hasonlítottuk össze; a szokásos ötös változatlanságát külön fixture ellenőrizte. A régi E18 run_role_vs_aggregate_logit futás érvénytelen, száma nem bizonyíték.

A szám. A T10 + seat25 A pooled loglossa 0,588950, a T10 team-onlyé 0,599722: ΔLL = +0,010772 [0,008886; 0,012617], és a seat-kar 5/5 évben nyert. A pooled Brier 0,207041 → 0,202401; a szokásos ötösnél a globális max|Δp| = 0. A T5 fölötti nyereség is 5/5 év, ΔLL = +0,010228 [0,008234; 0,012208].

Mi cáfolná. Egy előre lezárt, a fejlesztési szeletektől független időablak, amelyen az atomikus per-seat korrekció egyik proper score-on sem veri a team-only kontrollt, vagy ahol a referenciaötösnél nem egzakt nulla; az is gyengítené az általános állítást, ha egy szerep nélküli, azonos kapacitású lineup-summary ugyanazt a javulást adná.

Kapcsolódik. B4.12 (pinning) · B5.2 (kétlépcsős modell) · C.1 (lineup-érzékenység) · D.2.a (érvénytelen E18).

Forrás: src/lolbet/analysis/run_k8_rolling_origin_validation.py · PANDASKILL_F9_DECAY_K8_ROLLING_REPORT_2026-07-30.md §4 · processed/odds/fresh_watch/k8_rolling_origin/ · [E18 érvénytelen — T59 ns-bug].

B4.2 Kell-e 12 játékosmetrika az 5 helyett?

Fok: X ·

Válasz egy mondatban: Nem igazolt; a további hét metrika szerepenként nem adott kimutatható többletet.

Miért kérdeztük: a gazdagabb lane- és combat statok növelhetik a lineup- jel részletességét, de zajt és hiányt is hoznak. Az előzetes intuíció az volt, hogy öt alapmetrika nem tudja szétválasztani például a lane-erőt, az erőforrás-felvételt és a csapatharc-hatást. A további hét mező azonban ugyanabból a kevés játékosmeccsből készül, erősen korrelált, és minden szerepre külön paramétert kér. Így a gazdagítás könnyen varianciát növel valódi új információ nélkül, különösen debütálóknál és ritka rosterkombinációknál.

Mit futtattunk: seat12_delta és seat12_both a K8 azonos holdoutján.

A szám: +0,000879 [−0,002665;0,004281], illetve +0,001756 [−0,005225;0,008382]; mindkettő CI-je fedi a nullát.

Mi cáfolná: új rolling évek többségében mindkét proper score-on pozitív többlet. A tiszta teszt ugyanazon T10 baseline és seat-A konstrukció mellett csak az öt versus tizenkét metrikát változtassa, legalább négy új időfolddal. A döntést akkor fordítanánk vissza, ha a pooled LL- és Brier-CI egyaránt pozitív, legalább 3/4 év nyer, és a gyenge coverage-rétegben sem nő a hiba.

Az X a kipróbált megvalósítást és a fenti, szűk állítást vonja vissza; nem bizonyítja, hogy az egész ötletcsalád minden lehetséges formája értéktelen. Új változat csak a leírt cáfolati protokollal, előre fagyasztott karon és érintetlen időszakon nyitható ki. Ugyanannak az elhasznált szeletnek új paraméterrel történő ismételt megnyitása nem számít új bizonyítéknak.

Kapcsolódik: B4.1, B4.14.

Forrás: T35b/K8.

B4.3 Kellenek-e min/max/medián/székszámláló aggregátumok?

Fok: A ·

Válasz egy mondatban: Nem; a tiszta aggregációs rácsban nem adtak stabil többletet az egyszerű közép- és szórásmezők fölött.

Miért kérdeztük: az átlag elfedheti az egyetlen gyenge vagy kiugró játékost. A minimum-μ, spread és medián ezért kézenfekvő módon írhatná le a „leggyengébb láncszemet” vagy a kiegyensúlyozatlan rostert. Korábban egyetlen, később érvénytelenített inputon adtunk ezeknek túl magas fokot. A tiszta audit azt kérdezte, marad-e inkrementális jel az átlag és az aggregált σ mellett, nem azt, hogy az extra mezők önmagukban korrelálnak-e a győzelemmel.

Mit futtattunk: atomikus, ötéves rolling-origin aggregációs rács 22 414 soron.

A szám: minimum-μ +0,000195 [−0,000080;0,000471], spread +0,000165 [−0,000030;0,000358], szerepsúly −0,000258 [−0,000524;0,000009]; egyik sem stabil javulás.

Mi cáfolná: előre rögzített aggregátum 3/5 évben pozitív CI mindkét score-on. Ugyanazon 22 ezres vagy újabb rolling konstrukcióban egyetlen előre kiválasztott aggregátumot kell az alaphoz adni, a többi rácspont megnyitása nélkül. A verdikt akkor változna, ha pooled szinten a CI kizárná a nullát, legalább három év azonos irányú lenne, és a javulás nem csak egyetlen tierből vagy extrém rosterből származna.

Az A fok itt kizárólag a fenti, szűken megfogalmazott és a megadott mércén vizsgált állításra vonatkozik. Nem jelent automatikus production promotiont, bizonyított pénzügyi edge-et, más targetre való átvihetőséget vagy a teljes modellcsalád általános győzelmét. Ezekhez a kapcsolódó adat-, kalibrációs, végrehajtási és forward kapuknak külön, döntéskor rögzített bizonyítékot kell adniuk.

Kapcsolódik: B3.7.

Forrás: atomic aggregation riport; E19 érvénytelen és nem idézendő.

B4.4 Kell-e a σ a pontárban?

Fok: A ·

Válasz egy mondatban: Prediktív irányjelként igen: a signed σ 4/5 rolling évben szignifikánsan javított, de ettől a döntési/P&L szerepe még nyitott.

Miért kérdeztük: az eredeti szerződés csak uncertainty-mezőként engedte volna. Az intuíció szerint a nagy σ kevesebb tudást jelent, ezért nem volna szabad a győztes oldal irányát mozgatnia. A signed különbség azonban azt is hordozza, melyik csapat ratingje bizonytalanabb, ami tier-, tapasztalat- és matchup-információval korrelálhat. Emiatt külön kellett választani a prediktív irányjelet a kalibrált uncertainty-intervallumtól és a tétméretezéstől.

Mit futtattunk: LOGIT2 kontra LOGIT3 öt out-of-year foldon.

A szám: 2022–2025 LL-javulás rendre 0,0138; 0,0092; 0,0105; 0,0194, mind szignifikáns; 2026 −0,0018, nem szignifikáns. A korábbi T50-verdikt két már elhasznált szeleten állt: a σ kivétele gate_1391-en csak +0,00133 [−0,00894; +0,01167], legacy_755-ön +0,00887 [−0,00691; +0,02476] volt, mindkét CI fedte a nullát. Az E16 öt éve ezért nem a σ-ról, hanem a T50 szeletéről mondott ellent: nem a σ volt rossz, a szelet volt rossz.

Mi cáfolná: új független években az irány eltűnése, vagy a B12.3 negatív nettó P&L. A point-model állítást négy új rolling foldon azonos LOGIT2/LOGIT3 kontraszt fordítaná vissza, ha a signed σ legfeljebb 1/4 évben nyerne vagy a pooled CI nullát fedne. A fogadási használat külön bukhat: azonos quote-okon futó, fee-net forward σ-on/off kar negatív log-growthja nem törölné a prediktív jelet, csak alkalmazását.

Az A fok itt kizárólag a fenti, szűken megfogalmazott és a megadott mércén vizsgált állításra vonatkozik. Nem jelent automatikus production promotiont, bizonyított pénzügyi edge-et, más targetre való átvihetőséget vagy a teljes modellcsalád általános győzelmét. Ezekhez a kapcsolódó adat-, kalibrációs, végrehajtási és forward kapuknak külön, döntéskor rögzített bizonyítékot kell adniuk.

Kapcsolódik: B4.5, B8, B12.3.

Forrás: run_rolling_origin_sigma.py, E16.

B4.5 Működik-e a σ zsugorításként?

Fok: A ·

Válasz egy mondatban: A pontos, előre megnevezett μ×|σ_mean| interakció tiszta atomikus inputon 4/5 rolling évben javít, és 5/5 évben a nagyobb σ 50% felé zsugorít; más shrink alakok korábbi bukása ettől nem tűnik el.

Miért kérdeztük: nagy bizonytalanságnál intuitívnak tűnik óvatosabb árat adni. Ezt az intuíciót korábban összemostuk a jó kalibrációval: azt feltételeztük, hogy az episztemikusan bizonytalan sor igaz valószínűsége automatikusan közelebb van 0,5-höz. Ez nem következik a bizonytalanságból; a posterior szélesedhet változatlan középpont mellett. A shrink ráadásul épp a legbiztosabban féloldalas meccsek árát ronthatja, ha a σ főleg tier- vagy coverage-proxy.

Mit futtattunk: a K3b g(n,Σσ) és a D2 kétoldalas eloszlás beta-rácsa mellett az E20 pontos μ×|σ_mean| karját újrafuttattuk a javított atomikus inputon, öt rolling évben, előre rögzített M1 elsődleges karral és bemeneti hashsel.

A szám: a tiszta M1 logloss-nyeresége évenként +0,000439, +0,000216, −0,000199, +0,000384, +0,000491; a modulációs együttható mind az öt évben negatív (−0,0507…−0,0907). K3b továbbra is −0,004379 [−0,009540;0,000901], D2 0/5 év és β=∞ optimum. A régi E20 „20/20” száma ns-hibás és érvénytelen marad; az E39 az érvényes pár.

Mi cáfolná: új években az M1 előjelének megfordulása, a negatív interakció eltűnése, vagy az, hogy a javulás σ-missingness/coverage kontroll után megszűnik. A pontos kar A-foka nem terjed ki a K3b és D2 alakokra, és nem ad sizing- vagy P&L-jogot; ezt a B12 forward karjának kell eldöntenie.

Az A fok kizárólag az előre megnevezett M1 interakció ötéves irányára vonatkozik. Nem jelent automatikus production promotiont, pénzügyi edge-et vagy helyes tétméretet; ezek külön kapuk.

Kapcsolódik: B5.4, B12.1.

Forrás: E39, processed/odds/fresh_watch/sigma_modulation/manifest.json; K3b, E21; [E20 régi futása érvénytelen — T59 ns-bug].

B4.6 Kell-e külön a ps_delta és a ps_combined_diff?

Fok: A ·

Válasz egy mondatban: Nem; a production artifactban bitre azonos aliasok, így külön feature-ként hamis fontosságot és duplikációt okoznak.

Miért kérdeztük: a feature- importance mindkettőt jelként mutatta. Ha két azonos oszlop külön néven kerül a fába, a split-gain véletlenszerűen oszlik meg köztük, és a családablation kétszer számolhatja ugyanazt az információt. Korábban ezt két egymást megerősítő PandaSkill-jelként olvastuk. Az alias-audit célja ezért nem modellválasztás, hanem a feature-szerződés azonosságának bizonyítása és a félrevezető fontosság megszüntetése volt.

Mit futtattunk: oszlopazonosság- és alias-audit.

A szám: maximális eltérés 0; a két mező együtt +0,00515 nullázási hatást mutatott, de ez nem két független jel.

Mi cáfolná: verziózott definícióban nem nulla eltérés és külön OOF inkrementum. Ehhez előbb szemantikailag külön definíció és schema-verzió kellene, majd olyan golden fixture, ahol a két mező szándékosan eltér. Csak ezután értelmezhető külön rolling ablation; a jelenlegi artifacton már egyetlen >1e-12 soronkénti eltérés adatút-regresszió lenne, nem a duplikált feature megtartásának bizonyítéka.

Az A fok itt kizárólag a fenti, szűken megfogalmazott és a megadott mércén vizsgált állításra vonatkozik. Nem jelent automatikus production promotiont, bizonyított pénzügyi edge-et, más targetre való átvihetőséget vagy a teljes modellcsalád általános győzelmét. Ezekhez a kapcsolódó adat-, kalibrációs, végrehajtási és forward kapuknak külön, döntéskor rögzített bizonyítékot kell adniuk.

Kapcsolódik: B14.3, D.6.1.

Forrás: E3/T39, F2 rangvizsgálat.

B4.7 Kell-e liga/patch/split context?

Fok: D ·

Válasz egy mondatban: Erős fejlesztési jel, de az értékelő gate már használt, ezért promotion-állítás nem tehető.

Miért kérdeztük: a rating az idő- és versenykörnyezetet nem feltétlenül nyeli el.

Feature-kérdésnél a nyers korreláció és a fa fontossága nem bizonyít inkrementális jelet. Az új mező lehet alias, coverage- vagy tier-proxy, illetve a baseline-ban már szereplő információ második példánya. Ezért az értelmezéshez atomikus hozzáadás vagy elvétel, azonos OOF alapmodell, időrendi foldok és előre kijelölt elsődleges score kell; a használt holdouton kiválasztott legjobb kombináció csak fejlesztési diagnózis.

Mit futtattunk: PS7 és rich modell decision-time contexttel a 1 415-ös gate-en, majd diagnosztikusan a 755-ön.

A szám: PS7 0,504585→0,492606, ΔLL +0,011979 [0,006896;0,016782]; a 755-ön +0,011798.

Mi cáfolná: új forward időszakban a gain eltűnése.

A D fok tudatos figyelmeztetés: a szám elhasznált holdoutból, utólag nyitott karból vagy retrospektív replayből jön. Leírhatja, miért született egy hipotézis és melyik irányt érdemes újramérni, de confirmatory állításra, modellválasztásra vagy promotionre nem hivatkozható. A fokot ugyanazon szelet új paraméterezése nem javítja; csak előre regisztrált, érintetlen naptári minta és változatlan döntési szabály adhat új bizonyítékot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B5.5, C.3.

Forrás: E11/E12.

B4.8 Kell-e coverage-mező az árban?

Fok: D ·

Válasz egy mondatban: Állapot- és uncertainty-mezőként biztosan kell; közvetlen árjelként nincs elkülönítve.

Miért kérdeztük: kevés meccses roster magasabb modellhibát okozhat, de a mező tierrel és σ-val korrelál.

Feature-kérdésnél a nyers korreláció és a fa fontossága nem bizonyít inkrementális jelet. Az új mező lehet alias, coverage- vagy tier-proxy, illetve a baseline-ban már szereplő információ második példánya. Ezért az értelmezéshez atomikus hozzáadás vagy elvétel, azonos OOF alapmodell, időrendi foldok és előre kijelölt elsődleges score kell; a használt holdouton kiválasztott legjobb kombináció csak fejlesztési diagnózis.

Mit futtattunk: proxy-dekompozíció és A/B csatorna-ablation, majd az ns-javítás utáni E36 atomikus v2 kontrollt 702 klaszteren, 21 karral. A usual-five fixture mind a 21 karon egzakt nullát adott, tehát a seat-inkrementum csak rostereltérésnél aktiválódott.

A szám: corr(σ_diff,games_before_diff)=−0,746. E36-ban a tiszta seat25_all_A +0,017902 LL-t nyert [+0,005515; +0,030850], míg az A mellé adott sigma_B csak +0,015552-t: a B-mező rontott a tiszta A karhoz képest. A B_only diagnosztika +0,003847 [−0,006336; +0,013670] volt, CI-je fedte a nullát. Ez közvetlenül támogatja, hogy coverage/σ állapotként maradjon, de a pontárba ne kapjon automatikus irányjogot.

Mi cáfolná: coverage hozzáadása új rolling foldokon önálló score-javulást adna a σ és tier mellett.

A D fok tudatos figyelmeztetés: a szám elhasznált holdoutból, utólag nyitott karból vagy retrospektív replayből jön. Leírhatja, miért született egy hipotézis és melyik irányt érdemes újramérni, de confirmatory állításra, modellválasztásra vagy promotionre nem hivatkozható. A fokot ugyanazon szelet új paraméterezése nem javítja; csak előre regisztrált, érintetlen naptári minta és változatlan döntési szabály adhat új bizonyítékot.

A következő futás manifestje rögzítse az inputhash-t, időhatárt, eseményszámot és kizárási okokat.

Kapcsolódik: B4.11, B8.9.

Forrás: E14, K3, E36; evaluate_ab_channel_ablation.py atomikus v2 output.

B4.9 Ér-e valamit a szinergiaréteg?

Fok: X ·

Válasz egy mondatban: Nem; a staged gate kizárta, és az OOF páros reziduál nem mutatott használható jelet.

Miért kérdeztük: az együtt játszó párosok ereje nem feltétlenül additív. A hosszú közös múlt és a jó eredmény között valóban látszott nyers kapcsolat, ezért felmerült, hogy a seat-delták után külön párosréteg kell. A nyers együttmozgás azonban összekeveri a csapaterőt, a stabil rostert és a játékosok egyéni minőségét a valódi interakcióval. Csak a cutoff-helyes pontmodell OOF-reziduáljában maradó jel igazolhatna külön szinergiaparamétert.

Mit futtattunk: T18 stage-gate és T28/1a series/game pair-residual audit.

A szám: series r=0,0418 (0,54σ), game r=0,0435 (0,73σ); a korábbi +0,174 co-movement volt.

Mi cáfolná: előre rögzített párosjel új időszakon stabil reziduál- és score-javulást adna. Az új tesztnek minimum közös meccsszámot, regularizációt és ismeretlen páros priort kell előre rögzítenie, series szerint csoportosított rolling foldokon. A verdikt akkor változna, ha a reziduálkorreláció CI-je kizárná a nullát, a downstream LL/Brier is javulna, és a hatás új csapatba kerülő párosoknál is fennmaradna.

Az X a kipróbált megvalósítást és a fenti, szűk állítást vonja vissza; nem bizonyítja, hogy az egész ötletcsalád minden lehetséges formája értéktelen. Új változat csak a leírt cáfolati protokollal, előre fagyasztott karon és érintetlen időszakon nyitható ki. Ugyanannak az elhasznált szeletnek új paraméterrel történő ismételt megnyitása nem számít új bizonyítéknak.

Kapcsolódik: B4.13, B5.6.

Forrás: T18, T28.

B4.10 Ér-e valamit a h2h, meta és gördülő csapatstatisztika?

Fok: B ·

Válasz egy mondatban: A productionben marginális; a PandaSkill-családon kívül egyik csoport nullázási hatása sem haladta meg a 0,0004 loglosst.

Miért kérdeztük: ezek adják a 79 feature nagy részét.

Feature-kérdésnél a nyers korreláció és a fa fontossága nem bizonyít inkrementális jelet. Az új mező lehet alias, coverage- vagy tier-proxy, illetve a baseline-ban már szereplő információ második példánya. Ezért az értelmezéshez atomikus hozzáadás vagy elvétel, azonos OOF alapmodell, időrendi foldok és előre kijelölt elsődleges score kell; a használt holdouton kiválasztott legjobb kombináció csak fejlesztési diagnózis.

Mit futtattunk: családonkénti nullázás és 79→7 feature retrain.

A szám: PandaSkill hatása +0,03348; minden más család ≤+0,0004, miközben PS7 pontbecslésben verte FULL79-et.

Mi cáfolná: atomikus, többéves ablation önálló pozitív CI-vel.

A B fok azt jelzi, hogy a jel több szeletből vagy független reprodukcióból ismétlődött, de a teljes production és pénzügyi lánc még nem feltétlenül zöld. Az állítás csak a megnevezett targetre, populációra és metrikára vihető át. Promotion előtt külön forward adat, döntéskori provenance, kalibráció és végrehajtási ellenőrzés kell; egy új, ellentétes és érvényes adatvintage a fokot visszanyithatja.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B4.14, B5.1.

Forrás: E2/E5.

B4.11 Kell-e a games_before a pontárban?

Fok: X ·

Válasz egy mondatban: Közvetlen seat-árjelként nem igazolt; inkább coverage- és uncertainty-proxy.

Miért kérdeztük: új játékosnál kevésbé megbízható a rating. Emiatt csábító volt a games_before számot közvetlen győzelmi jelként a seat-fejbe tenni: a modell majd megtanulja, mennyit ér a kevés előélet. A mező azonban egyszerre mér coverage-et, ligát, debütáló státuszt és a PandaSkill σ-jának részét. Ha pontárként használjuk, könnyen kétszer árazzuk ugyanazt a bizonytalanságot és strukturálisan büntetjük az új játékosokat.

Mit futtattunk: atomikus A/B inkrementum és proxy-audit.

A szám: a games_before B-inkrementum −0,000661 [−0,005298;0,003748]; σ-val r=−0,746.

Mi cáfolná: σ, tier és rosterállapot mellett új rolling időszakon stabil point-score gain. Az atomikus kar csak a games_before mezőt adhatja a már σ-t és tiert tartalmazó kontrollhoz, előre rögzített monotonicitás nélkül. Legalább négy új fold, pozitív pooled LL/Brier CI és külön debütáló-rétegű kalibráció kellene; puszta korreláció vagy feature gain nem változtatná meg az X fokot.

Az X a kipróbált megvalósítást és a fenti, szűk állítást vonja vissza; nem bizonyítja, hogy az egész ötletcsalád minden lehetséges formája értéktelen. Új változat csak a leírt cáfolati protokollal, előre fagyasztott karon és érintetlen időszakon nyitható ki. Ugyanannak az elhasznált szeletnek új paraméterrel történő ismételt megnyitása nem számít új bizonyítéknak.

Kapcsolódik: B4.8, B8.9.

Forrás: atomic A/B report, E14.

B4.12 Számít-e a pinning?

Fok: X ·

Válasz egy mondatban: A mostani pinning nem megoldás: megszünteti a dupla számolást, de túlzott attenuációval pontosságot veszít.

Miért kérdeztük: a team-alap már tartalmazza a szokásos játékosokat.

Mit futtattunk: T5/T5-pinned rolling és végpont-fixture.

A szám: T5-pinned−T5 +0,003569 LL veszteség az engedett 0,002 fölött; teljes cserénél a két végpont átlag 4,29 pp-re, maximum 18,22 pp-re tér el.

Mi cáfolná: közösen illesztett vagy EIV- korrigált pinning független javulása.

Az X a kipróbált megvalósítást és a fenti, szűk állítást vonja vissza; nem bizonyítja, hogy az egész ötletcsalád minden lehetséges formája értéktelen. Új változat csak a leírt cáfolati protokollal, előre fagyasztott karon és érintetlen időszakon nyitható ki. Ugyanannak az elhasznált szeletnek új paraméterrel történő ismételt megnyitása nem számít új bizonyítéknak.

Kapcsolódik: B5.2, D.6.5.

Forrás: final K8 report, E9.

A történeti sorrend fontos: ugyanazon team-baseline kérdésben előbb a T5-pinned, utána a sima T5, végül a tiszta rolling-originban a T10 lett a numerikus győztes. Ez nem három egymást követő biztos optimum, hanem annak bizonyítéka, hogy a team-baseline a sokszor használt holdouton nem volt azonosítva. A stabil állítás a seat-A inkrementum; az mind T5, mind T10 fölött 5/5 évben javított. A baseline kiválasztását ezért külön kell tartani a pinning strukturális bukásától.

B4.13 Van-e játékospár-szinergia?

Fok: X ·

Válasz egy mondatban: A production OOF-reziduálban nincs elkülöníthető párjel.

Miért kérdeztük: a roster együtt töltött ideje látszólag erős korrelációt adott. Az eredeti feltevés az volt, hogy bizonyos jungle–mid vagy bot–support párok közös értéke nagyobb az egyéni ratingek összegénél. A nyers korreláció viszont automatikusan nagy ott, ahol ugyanaz az erős csapat sokáig együtt marad. Ezért a kérdés csak a már ismert csapaterő, seat-jel és meccskörnyezet levonása után értelmes; enélkül a „szinergia” a stabilitás másik neve.

Mit futtattunk: series- és game-szintű conditional residual audit, nulla co-movernél kontrollal.

A szám: r=0,0418 és 0,0435, mindkettő egy szigma alatt; nulla co-movernél r=−0,0127.

Mi cáfolná: új, időhelyes párosmodell pozitív out-of-fold és forward gainnel. A párok statisztikája csak cutoff előtti közös meccsekből készülhet, minimumsupporttal és hierarchikus priorral az új párokra. Az X akkor fordulna, ha legalább négy rolling foldon a reziduáljel és a proper score egyszerre javulna, majd ugyanez egy érintetlen roster-change forward mintán is azonos irányban megmaradna.

Az X a kipróbált megvalósítást és a fenti, szűk állítást vonja vissza; nem bizonyítja, hogy az egész ötletcsalád minden lehetséges formája értéktelen. Új változat csak a leírt cáfolati protokollal, előre fagyasztott karon és érintetlen időszakon nyitható ki. Ugyanannak az elhasznált szeletnek új paraméterrel történő ismételt megnyitása nem számít új bizonyítéknak.

Kapcsolódik: B4.9, B5.6.

Forrás: T28/1a.

B4.14 Hány feature kell?

Fok: B ·

Válasz egy mondatban: A 79 biztosan nem szükséges, de nem a darabszám dönt: E37-ben négy jól választott mező elég volt, hét rosszul választott pedig sokkal gyengébb.

Miért kérdeztük: sok mező növeli a driftet és az artifact-kockázatot.

Feature-kérdésnél a nyers korreláció és a fa fontossága nem bizonyít inkrementális jelet. Az új mező lehet alias, coverage- vagy tier-proxy, illetve a baseline-ban már szereplő információ második példánya. Ezért az értelmezéshez atomikus hozzáadás vagy elvétel, azonos OOF alapmodell, időrendi foldok és előre kijelölt elsődleges score kell; a használt holdouton kiválasztott legjobb kombináció csak fejlesztési diagnózis.

Mit futtattunk: FULL79/F76/RED26/RED23/PS7, atomic rich-121 és context benchmark, majd E37-ben a team-baseline T1/T4/T5/T7/T10 ablationját 45 972 soron, 2024-08-26 utáni holdouttal.

A szám: PS7 0,573025 vs FULL79 0,585869; atomikusan PS7 0,544908 vs rich-121 0,546020. E37-ben T10 LL 0,591082; T5 különbsége csak +0,000642 [−0,000979; +0,002262], T4-é +0,001388 [−0,000791; +0,003450], tehát mindkettő megkülönböztethetetlen volt. A T7 viszont +0,028347 [+0,024864; +0,031798] értékkel rosszabb: ez a T5–T10 teljes résének mintegy 44-szerese. A „hány feature” ezért önmagában rossz kérdés; minden táblának azt is ki kell írnia, melyik mező maradt ki.

Mi cáfolná: új forward populáción a gazdag modell stabil nettó fölénye.

A B fok azt jelzi, hogy a jel több szeletből vagy független reprodukcióból ismétlődött, de a teljes production és pénzügyi lánc még nem feltétlenül zöld. Az állítás csak a megnevezett targetre, populációra és metrikára vihető át. Promotion előtt külön forward adat, döntéskori provenance, kalibráció és végrehajtási ellenőrzés kell; egy új, ellentétes és érvényes adatvintage a fokot visszanyithatja.

A következő futás manifestje rögzítse a pontos mezőlistát, inputhash-t, időhatárt és kizárásokat.

Kapcsolódik: B4.10, B5.1.

Forrás: E5, E10–E12, E37; measure_team_baseline_ablation.py.

B5 — Pontár-modell

A három vizsgált architektúra a differencia + swap, a közös súlyú kétoldalas torony és a két eloszlás → integrál forma. Productionben továbbra is a joint XGBoost fut; az új formák shadow állapotúak.

B5.4 Jobb-e a kétoldalas eloszlásos pontár-alak?

Fok: X — a próbált eloszlásos alak megdőlt.

Válasz egy mondatban: Nem — a próbált Φ(Δμ/√(σ_A²+σ_B²+β²)) alak mind az öt évben rosszabb volt a sima különbségalakú LOGIT3-nál, és az optimum a zsugorítás kikapcsolásához futott.

Miért kérdeztük. A PandaSkill két csapathoz nemcsak erőközepet, hanem σ-t is ad, ezért kézenfekvőnek tűnt két látens eloszlás összehasonlításából számolni a győzelmi valószínűséget. Ha ez helyes volna, a nagy össz-bizonytalanság automatikusan 50% felé húzná az árat.

Mit futtattunk. A tiszta rolling-origin táblán 2022–2026 között négy funkcionális formát hasonlítottunk össze: D0 különbség-LOGIT3, D1 interakció az össz-σ-szinttel, D2 tiszta kétoldalas eloszlás, D3 eloszlás + lineáris σ. A D2-ben szabad beta-illesztés futott; a 2026-os foldon ezen felül előre megadott β={1,3,5,7,10,20,50,∞} érzékenységi rács készült.

A szám. A D2 a D0-hoz képest 0/5 évben nyert; az éves logloss-különbségek mind negatívak és a 95%-os bootstrap-CI-k mind nulla alatt vannak: 2022 −0,015079, 2023 −0,008220, 2024 −0,005487, 2025 −0,020086, 2026 −0,013166. A 2026-os beta-rács monoton javult a zsugorítás csökkentésével: β=1: 0,563557 → β=50: 0,556805 → β=∞: 0,556714; a szabad illesztés β≈10¹⁶-ra futott.

Mi cáfolná. Egy előre specifikált, numerikusan stabil eloszlásos család, amely új, független rolling évek többségében mind loglossban, mind Brierben veri az azonos információt használó különbségmodellt, és véges, foldok közt stabil belső optimumot ad.

Kapcsolódik. B4.4 (σ az árban) · B4.5 (σ mint zsugorítás) · B8 (episztemikus szórás) · B12.3 (pontár kontra fogadási eredmény).

Forrás: src/lolbet/analysis/run_two_sided_distributional.py · processed/odds/fresh_watch/two_sided_distributional/metrics.csv · contrasts.json · E21/T58.

B5.1 Kell-e XGBoost, vagy elég egy GLM?

Fok: A ·

Válasz egy mondatban: A jelenlegi jelhez elég a kicsi GLM; a 450 fás XGBoost nem adott stabil többletet.

Miért kérdeztük: a production komplexitása csak akkor indokolt, ha out-of-year javít. A 450 fa több interakciót és nemlinearitást képes megtanulni, de ugyanakkor nagyobb a drift-, verzió- és magyarázhatósági kockázata. Korábban a production státusz önmagában tekintélyt adott az XGBoostnak, noha a jel döntő része néhány PandaSkill-különbségben van. Az összevetés azt kérdezi, hogy azonos információból a komplex forma ad-e ismételhető többletet, nem azt, hogy egyetlen holdouton melyik szám kisebb.

Mit futtattunk: minimal-model rolling-origin 2022–2026, LOGIT2/LOGIT3 és XGB4 karokkal.

A szám: XGB4 csak 1/5 évben verte LOGIT2-t; három évben a GLM szignifikánsan jobb, LOGIT3 3/5 évben a legjobb kar.

Mi cáfolná: előre rögzített XGB több új évben pozitív CI-vel nyer. Azonos feature-készlet, decay, kalibráció és hiperparaméterbudget mellett legalább négy új rolling fold kellene; az XGB-nek 3/4 évben, pooled LL-ben és Brierben is pozitív CI-vel kellene vernie a GLM-et. A választás előtti rácsot fagyasztani kell, és a győzelem nem származhat egyetlen ligából vagy extrém valószínűségi sávból.

Az A fok itt kizárólag a fenti, szűken megfogalmazott és a megadott mércén vizsgált állításra vonatkozik. Nem jelent automatikus production promotiont, bizonyított pénzügyi edge-et, más targetre való átvihetőséget vagy a teljes modellcsalád általános győzelmét. Ezekhez a kapcsolódó adat-, kalibrációs, végrehajtási és forward kapuknak külön, döntéskor rögzített bizonyítékot kell adniuk.

Kapcsolódik: B4.14, B5.7.

Forrás: run_minimal_model_rolling_origin.py, E17.

B5.2 Jobb-e a team+seat kétlépcsős modell?

Fok: A ·

Válasz egy mondatban: A referenciaötöshöz mért seat-A réteg igen, mind T10, mind T5 team-alapot 5/5 évben javított.

Miért kérdeztük: a team-múlt és az aktuális lineup eltérő információ. A team-rating a történeti szervezetet és annak szokásos ötösét már magába sűríti; egy abszolút játékoserő-réteg ezért könnyen duplán számol. Ugyanakkor a tényleges kezdő eltérhet a referenciától, és ezt a team-only ár nem látja. A kétlépcsős konstrukció csak akkor tiszta, ha a seat-réteg OOF team-marginra illeszkedik, és a referenciaötösnél pontosan nulla korrekciót ad.

Mit futtattunk: OOF team-marginra illesztett seat25-A, öt rolling év, 22 414 sor.

A szám: T10 fölött +0,010772 [0,008886;0,012617], T5 fölött +0,010228 [0,008234;0,012208]; reference fixture max|Δp|=0.

Mi cáfolná: független forward időszakon nulla vagy negatív gain. A tesztnek ugyanazon döntéskori lineup-source állapotból kell T10 és T5 team-only, illetve seat-A karokat előállítania, legalább négy új időfolddal vagy n≥100 lezárt forward sorral. Az állítást akkor vonnánk vissza, ha a seat inkrementum pooled CI-je nullát fedne, vagy a referenciaötös fixture bármely soron nem nulla árváltozást adna.

Kapcsolódik: B4.1, B4.12.

Forrás: final K8 rolling report.

Ez az eredmény nem azonosítja a team-baseline végső alakját. A baseline-rangsor háromszor fordult (T5-pinned → T5 → T10), ahogy az adatút és az értékelési szelet változott; a tiszta ötéves futásban T10 nyert, miközben az egyholdoutos K8 még T5-öt választaná. Amit a két baseline közös kontrollja azonosít, az a lineup-korrekció hozzáadott értéke, nem T10 örök optimuma.

B5.3 Jobb-e az M13 kétoldalas torony?

Fok: B ·

Válasz egy mondatban: Nincs egyértelmű fölénye az egyszerűbb M12-vel szemben.

Miért kérdeztük: a két oldal közös súlyú reprezentációja természetesen swap-szimmetrikus és nemlinearitást tanulhat.

Modellforma összevetésekor azonos információbudgetet, targetet, idősplitet és kalibrációt kell tartani. A rugalmasabb modell több kart és seedet nyit meg, ezért a legjobb pontbecslése önmagában optimista lehet, különösen a sokszor használt 755-ös szeleten. A releváns kérdés nem az, hogy található-e egy jobb sor, hanem hogy az előre rögzített forma több időfoldon, stabil proper score-ral és változatlan invariánsokkal nyer-e.

Mit futtattunk: 47 per-side feature, három seed, közös holdout és package benchmark.

A szám: a legacy 755-ön M13 rating 0,574852, residual 0,574898; a reziduál hatása −0,000045, és M12 ellen nincs stabil győztes.

Mi cáfolná: új időholdouton több seedből stabil M13-fölény.

A B fok azt jelzi, hogy a jel több szeletből vagy független reprodukcióból ismétlődött, de a teljes production és pénzügyi lánc még nem feltétlenül zöld. Az állítás csak a megnevezett targetre, populációra és metrikára vihető át. Promotion előtt külön forward adat, döntéskori provenance, kalibráció és végrehajtási ellenőrzés kell; egy új, ellentétes és érvényes adatvintage a fokot visszanyithatja.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B5.2, B5.7.

Forrás: T15/M13, E12.

B5.5 Kell-e külön context-lépcső?

Fok: X ·

Válasz egy mondatban: A staged team+seat modell harmadik reziduáljaként nem ment át a kapun; ez nem cáfolja, hogy context a team pontárban hasznos.

Miért kérdeztük: a réteg helye és a jel létezése két külön kérdés. A liga-, patch- és időjel valóban hordozhat információt, de nem következik ebből, hogy egy már illesztett team- és seat-modell maradékára harmadik reziduálként kell rátenni. Ebben a helyzetben a context könnyen csak a korábbi lépcsők hibáját tanulja, erősen szeletfüggő együtthatókkal. A kérdés a staged architektúráról szól, nem a context teljes elutasításáról.

Mit futtattunk: T18 stage gate, majd külön PS7_CONTEXT.

A szám: T18-ban team 0,56289→seat 0,55434, synergy/context kiesett; külön PS7_CONTEXT +0,011979 LL-t adott a használt gate-en.

Mi cáfolná: új diszjunkt stage-gate-en a context- reziduál seat fölött stabilan nyer. A team és seat lépcsőket előre be kell fagyasztani, majd csak egyetlen, előre megadott context-blokk nyitható ki egy érintetlen időszakon. A verdikt akkor fordulna, ha a harmadik lépcső pozitív LL/Brier CI-t, legalább három időfoldban azonos irányt és forwardban stabil kalibrációt adna; a context team-fejben mért javulása ehhez nem elég.

Az X a kipróbált megvalósítást és a fenti, szűk állítást vonja vissza; nem bizonyítja, hogy az egész ötletcsalád minden lehetséges formája értéktelen. Új változat csak a leírt cáfolati protokollal, előre fagyasztott karon és érintetlen időszakon nyitható ki. Ugyanannak az elhasznált szeletnek új paraméterrel történő ismételt megnyitása nem számít új bizonyítéknak.

Kapcsolódik: B4.7, B5.2.

Forrás: T18, E11.

B5.6 Kell-e szinergia-lépcső?

Fok: X ·

Válasz egy mondatban: Nem; sem a staged gate, sem a páros OOF-reziduál nem igazolta.

Miért kérdeztük: nemadditív játékospárok maradhatnak a seat-delták után. Különösen a jungle–mid és bot–support kapcsolatnál hihető, hogy két játékos közös értéke nem az egyéni eltérések összege. A párosok száma azonban gyorsan nő, a legtöbb kevés meccset lát, és a stabil csapaterő erősen konfundálja a közös múltat. Ezért csak a team- és seat-jel levonása után maradó, időhelyes reziduál igazolhat külön lépcsőt.

Mit futtattunk: T18 és T28/1a.

A szám: synergy KI; pair residual korreláció 0,0418/0,0435, egy szigma alatt.

Mi cáfolná: előre regisztrált, regularizált párosréteg új időszakon pozitív score-gainnel. Előre kell rögzíteni a minimum közös meccsszámot, a shrinkage-priort és az ismeretlen párok kezelését, majd series-csoportos rolling foldokon mérni. A lépcső csak akkor térhetne vissza, ha legalább 3/4 új foldon javítana, pooled proper-score CI-je pozitív lenne, és a roster-cserés forward rétegen is fennmaradna a hatás.

Az X a kipróbált megvalósítást és a fenti, szűk állítást vonja vissza; nem bizonyítja, hogy az egész ötletcsalád minden lehetséges formája értéktelen. Új változat csak a leírt cáfolati protokollal, előre fagyasztott karon és érintetlen időszakon nyitható ki. Ugyanannak az elhasznált szeletnek új paraméterrel történő ismételt megnyitása nem számít új bizonyítéknak.

Kapcsolódik: B4.9, B4.13.

Forrás: T18/T28.

B5.7 Számít-e a hiperparaméter-választás?

Fok: D ·

Válasz egy mondatban: Igen, de a jelenlegi holdout túlhasznált, ezért a látható rangsor-instabilitás nem jogosít új post-hoc választásra.

Miért kérdeztük: T5, T10, pinning és feature-karok sorrendje szeletfüggő.

Modellforma összevetésekor azonos információbudgetet, targetet, idősplitet és kalibrációt kell tartani. A rugalmasabb modell több kart és seedet nyit meg, ezért a legjobb pontbecslése önmagában optimista lehet, különösen a sokszor használt 755-ös szeleten. A releváns kérdés nem az, hogy található-e egy jobb sor, hanem hogy az előre rögzített forma több időfoldon, stabil proper score-ral és változatlan invariánsokkal nyer-e.

Mit futtattunk: a 755-ös holdout kettévágása és 70 név/60 predikcióvektor közös benchmarkja.

A szám: pinned−T10 +0,00353 a teljes 755-ön, −0,00242 a friss 315-ön; a rangsor felborult.

Mi cáfolná: több diszjunkt rolling fold azonos optimuma.

A D fok tudatos figyelmeztetés: a szám elhasznált holdoutból, utólag nyitott karból vagy retrospektív replayből jön. Leírhatja, miért született egy hipotézis és melyik irányt érdemes újramérni, de confirmatory állításra, modellválasztásra vagy promotionre nem hivatkozható. A fokot ugyanazon szelet új paraméterezése nem javítja; csak előre regisztrált, érintetlen naptári minta és változatlan döntési szabály adhat új bizonyítékot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B14.4, D.3.

Forrás: E4/E12.

B5.8 Ér-e valamit a bootstrap-ensemble?

Fok: B ·

Válasz egy mondatban: Uncertainty-becslésre hasznos, pontárjavulásként nem igazolt.

Miért kérdeztük: a modellek átlaga csökkentheti a varianciát, széthúzása pedig episztemikus jelet adhat.

Modellforma összevetésekor azonos információbudgetet, targetet, idősplitet és kalibrációt kell tartani. A rugalmasabb modell több kart és seedet nyit meg, ezért a legjobb pontbecslése önmagában optimista lehet, különösen a sokszor használt 755-ös szeleten. A releváns kérdés nem az, hogy található-e egy jobb sor, hanem hogy az előre rögzített forma több időfoldon, stabil proper score-ral és változatlan invariánsokkal nyer-e.

Mit futtattunk: 100 újrafitből álló base ensemble és legacy benchmark.

A szám: a logit-σ a p-n túl hibajel volt (partial r≈0,21, permutation p=0,0002, 445 OOS), de az ensemble pontár promotiont nem nyert.

Mi cáfolná: új forward mintán az ensemble azonos kalibráció mellett score- és nettó előnyt ad.

A B fok azt jelzi, hogy a jel több szeletből vagy független reprodukcióból ismétlődött, de a teljes production és pénzügyi lánc még nem feltétlenül zöld. Az állítás csak a megnevezett targetre, populációra és metrikára vihető át. Promotion előtt külön forward adat, döntéskori provenance, kalibráció és végrehajtási ellenőrzés kell; egy új, ellentétes és érvényes adatvintage a fokot visszanyithatja.

Kapcsolódik: B8.3, B12.1.

Forrás: bootstrap_uncertainty.py, STATE_OF_PLAY §uncertainty.

B5.9 Ér-e valamit a pred-dist map→series PMF?

Fok: D ·

Válasz egy mondatban: Koherens non-ML piacokhoz szerkezetileg szükséges, de moneyline pontárként nincs promótálva.

Miért kérdeztük: egy közös PMF kizárja az egymásnak ellentmondó handicap/total/winner árakat.

Modellforma összevetésekor azonos információbudgetet, targetet, idősplitet és kalibrációt kell tartani. A rugalmasabb modell több kart és seedet nyit meg, ezért a legjobb pontbecslése önmagában optimista lehet, különösen a sokszor használt 755-ös szeleten. A releváns kérdés nem az, hogy található-e egy jobb sor, hanem hogy az előre rögzített forma több időfoldon, stabil proper score-ral és változatlan invariánsokkal nyer-e.

Mit futtattunk: pred-dist scorer, blend és közös benchmark.

A szám: a 755-ön pred-dist 0,576841, M2 blend 0,577430, production 0,586639; a régi Poly CLV nem döntő.

Mi cáfolná: PMF-koherencia hiba vagy új market-family gate-en rosszabb kalibráció a külön fejeknél.

A D fok tudatos figyelmeztetés: a szám elhasznált holdoutból, utólag nyitott karból vagy retrospektív replayből jön. Leírhatja, miért született egy hipotézis és melyik irányt érdemes újramérni, de confirmatory állításra, modellválasztásra vagy promotionre nem hivatkozható. A fokot ugyanazon szelet új paraméterezése nem javítja; csak előre regisztrált, érintetlen naptári minta és változatlan döntési szabály adhat új bizonyítékot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B0, B10.

Forrás: E12, T24.

B6 — Idő-kezelés

B6.1 Segít-e a naptárév feature?

Fok: X ·

Válasz egy mondatban: Fejlesztési szeleten jelez időrezsimet, de abszolút naptárévként telítődik és jövőbe nem extrapolálható, ezért production feature-ként elutasított.

Miért kérdeztük: az adat és a meta időben változik. Az abszolút évszám egyszerű proxy volt arra, hogy a játékstílus, az adatlefedettség és a rating skálája rezsimenként eltér. Fában azonban csak múltbeli küszöbökre lehet hasítani: ha a legnagyobb tanult küszöb 2025, minden 2026 utáni sor ugyanabba a levélbe esik. A fejlesztési gain ezért nem bizonyít jövőbe extrapoláló időjelet, csak azt, hogy a régi szeletek különböztek.

Mit futtattunk: context-year ablation és küszöbaudit.

A szám: év nélkül a gate LL 0,492606→0,503700, Δ=−0,011093 [−0,015041;−0,006904]; ugyanakkor minden fa-küszöb ≤2025, tehát 2026+ telített.

Mi cáfolná: relatív, extrapolálható időfeature új forward javulása. Ilyen lehet a cutoffhoz viszonyított adatalag, gördülő rezsimindex vagy past-only driftstatisztika, de a definíciót a teszt előtt rögzíteni kell. Az X csak akkor változna, ha az új feature legalább négy gördülő foldon javítana pozitív pooled CI-vel, és a következő naptári évben nem telítődne ugyanúgy.

Az X a kipróbált megvalósítást és a fenti, szűk állítást vonja vissza; nem bizonyítja, hogy az egész ötletcsalád minden lehetséges formája értéktelen. Új változat csak a leírt cáfolati protokollal, előre fagyasztott karon és érintetlen időszakon nyitható ki. Ugyanannak az elhasznált szeletnek új paraméterrel történő ismételt megnyitása nem számít új bizonyítéknak.

Kapcsolódik: B4.7, C.4.

Forrás: PS7 context year ablation, F6 audit.

B6.2 Segít-e a frissesség-súlyozás?

Fok: A ·

Válasz egy mondatban: Igen; az előre rögzített egyéves felezésű decay 5/5 évben verte a súlyozatlan kontrollt.

Miért kérdeztük: régi meccsek kevésbé reprezentálják a mai erőt. A roster, patch és versenyszint változása miatt azonos súllyal használni egy többéves és egy friss meccset implicit stacionaritási feltevés. A túl agresszív felejtés viszont kevés effektív mintát hagy, főleg ritka csapatoknál. Ezért az irányt nem egyetlen év vagy kézzel választott ablak, hanem normalizált súlyú, teljes rolling lánc alapján kellett eldönteni.

Mit futtattunk: D0/D180/D365/D730/D1095 rolling-origin, 22 414 out-of-year sor.

A szám: D365−D0 ΔLL +0,002097 [0,001502;0,002707], Brier +0,000838, 5/5 év.

Mi cáfolná: új években tartós negatív hatás normalizált súlyok mellett. A D365 és D0 kart azonos feature-, rating- és kalibrációs szerződéssel kell továbbfuttatni legalább négy új foldon. Az A állítást akkor vonnánk vissza, ha D365 legfeljebb 1/4 évben nyerne, a pooled LL/Brier CI nullát fedne vagy negatív lenne, illetve ha a javulás kizárólag a súlytömeg megváltozásából, normalizáció nélkül jelenne meg.

Az A fok itt kizárólag a fenti, szűken megfogalmazott és a megadott mércén vizsgált állításra vonatkozik. Nem jelent automatikus production promotiont, bizonyított pénzügyi edge-et, más targetre való átvihetőséget vagy a teljes modellcsalád általános győzelmét. Ezekhez a kapcsolódó adat-, kalibrációs, végrehajtási és forward kapuknak külön, döntéskor rögzített bizonyítékot kell adniuk.

Kapcsolódik: B6.3, B6.4.

Forrás: decay rolling report.

B6.3 Jobb-e az ablak vagy a decay?

Fok: C ·

Válasz egy mondatban: A decay iránya igazolt, de azonos effektív mintájú kemény ablakkal nincs teljes, előre rögzített összevetés.

Miért kérdeztük: az ablak hirtelen eldob, a decay fokozatosan felejt.

Időkezelésnél a stacionaritás és az effektív mintanagyság közti kompromisszumot mérjük. A frissebb adatok relevánsabbak lehetnek, de túl gyors felejtésnél ritka csapatokra és régióközi kapcsolatokra alig marad support. Ablak és decay csak azonos súlytömeg, normalizáció, cutoff és rolling fold mellett hasonlítható; külön diagnosztikák számai nem azonosítják, melyik mechanizmus okozta a különbséget.

Mit futtattunk: több decay-kar és külön időablak-diagnosztikák, nem azonos kísérletben.

A szám: D365 a D0-t +0,002097 LL-lel verte; közvetlen window-kontraszt nincs.

Mi cáfolná: azonos foldokon, azonos effektív súlytömeggel a window stabilan jobb.

A C fok határa egyetlen előre értelmezhető fejlesztési szelet vagy strukturált diagnosztika. Ez elegendő az irány dokumentálására és a következő teszt megtervezésére, de nem általánosítható automatikusan más évre, ligára vagy fogadási piacra. A következő mérésnek előre fagyasztott kontraszttal több időfoldot vagy elegendő forward mintát kell adnia, ugyanazon proper score- és invariánskapukkal; csak ekkor emelhető a fok.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B6.2, C.4.

Forrás: decay és time-regime riportok.

B6.4 Mennyi az optimális felezési idő?

Fok: C ·

Válasz egy mondatban: A deklarált választás 365 nap; a 180 nap numerikusan minimálisan jobb volt, de érzékenységi kar, ezért utólag nem választjuk.

Miért kérdeztük: túl gyors felejtés zajt, túl lassú driftet okoz.

Időkezelésnél a stacionaritás és az effektív mintanagyság közti kompromisszumot mérjük. A frissebb adatok relevánsabbak lehetnek, de túl gyors felejtésnél ritka csapatokra és régióközi kapcsolatokra alig marad support. Ablak és decay csak azonos súlytömeg, normalizáció, cutoff és rolling fold mellett hasonlítható; külön diagnosztikák számai nem azonosítják, melyik mechanizmus okozta a különbséget.

Mit futtattunk: 180/365/730/1095 nap és D0 öt rolling évben.

A szám: pooled LL D180 0,587596, D365 0,587639, D730 0,588112, D1095 0,588471, D0 0,589736.

Mi cáfolná: új előre rögzített rács stabil más optimuma.

A C fok határa egyetlen előre értelmezhető fejlesztési szelet vagy strukturált diagnosztika. Ez elegendő az irány dokumentálására és a következő teszt megtervezésére, de nem általánosítható automatikusan más évre, ligára vagy fogadási piacra. A következő mérésnek előre fagyasztott kontraszttal több időfoldot vagy elegendő forward mintát kell adnia, ugyanazon proper score- és invariánskapukkal; csak ekkor emelhető a fok.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B6.2, D.3.

Forrás: decay rolling report.

B7 — Kalibráció

A kalibráció nem ugyanaz, mint a pontosság. Egy modell lehet jól rangsoroló és rosszul kalibrált — a pred-dist pont ilyen: Brierben és AUC-ban a mezőny második legjobbja, loglossban a közepe. A kalibráció azt javítja, mennyire hihető a szám; a rangsorolást nem.

B7.1 Kell-e intercept a kalibrátorba?

Fok: A ·

Válasz egy mondatban: Nem a swap-szimmetrikus élő útban; az intercept a feedben elsőként listázott csapatnak indokolatlan előnyt ad.

Miért kérdeztük: a tréning blue-side orientációját a live feed sorrendje nem őrzi. A kalibrációs intercept történetileg valódi blue-side alapráta-eltérést korrigált, ezért offline legitimnek látszott. A board a két csapatot venue- vagy feed-sorrendben kapja; erre átvinni ugyanazt az interceptet önkényes listázási előnyt teremt. Ez strukturális kérdés: még jó átlagos logloss mellett sem engedhető meg, hogy puszta csapatcsere után a két valószínűség összege eltérjen egytől.

Mit futtattunk: algebrai komplementaritás- és live board audit, majd a production artifact 789 soros kronologikus tesztje blue-oriented és side-neutral tükörnézetben (E33).

A szám: intercept 0,11348; a kalibrációs blue-alapráta 0,538179; slope-only swap-hiba 3,46e−8, a deployed Platté átlag 0,040678, maximum 0,056679; live első csapat +2,68 pp. Blue-oriented nézetben a slope-only a Plattnál −0,001293 [−0,004799; +0,002306] LL-lel rosszabb, de ez a CI nullát fedő összevetés a döntéskor nem ismert blue oldalt használja. Side-neutral nézetben a javítás +0,000914 [+0,000730; +0,001087] LL-lel veri a Plattot.

Mi cáfolná: stabil, valódi side-azonosító és forwardban bizonyított intercept-hatás. Minden live eseményhez döntéskor ismert, hiteles blue/red side kellene, és az interceptet kizárólag erre az orientációra szabadna alkalmazni. Ezután legalább négy időfoldon pozitív LL/Brier CI, n≥100 forward reliability és swap után csak a valódi side- csere által magyarázott eltérés fordíthatná meg a tiltást; feed-sorrend önmagában soha.

Az A fok itt kizárólag a fenti, szűken megfogalmazott és a megadott mércén vizsgált állításra vonatkozik. Nem jelent automatikus production promotiont, bizonyított pénzügyi edge-et, más targetre való átvihetőséget vagy a teljes modellcsalád általános győzelmét. Ezekhez a kapcsolódó adat-, kalibrációs, végrehajtási és forward kapuknak külön, döntéskor rögzített bizonyítékot kell adniuk.

Kapcsolódik: C.5, B14.3.

Forrás: E8/T42; E33; PRODUCTION_SLOPE_ONLY_CALIBRATION_REPORT.md.

B7.2 Elég-e a slope-only kalibráció?

Fok: C

Válasz egy mondatban: A slope-only szerkezetileg megengedett, de jelenleg nem elég és nem ez a biztonságos pontár: az egyetlen 789 soros kronologikus teszten az identity kalibráció jobb volt.

Miért kérdeztük. Az intercept tiltása nem bizonyítja, hogy a meredekséget át kell írni. A slope-only megtartja a swap-komplementaritást, ezért vonzó javításnak tűnt az alul- vagy túlkonfidenciára; korábban hajlamosak voltunk ezt automatikus következő lépésként kezelni. A helyes kérdés azonban az, hogy proper score-ban veri-e a változatlan nyers árat, nem csak az, hogy algebrailag szabályos-e.

Mit futtattunk. A production artifact 789 soros kronologikus tesztjén identity, interceptes Platt és újraillesztett slope-only kart hasonlítottunk össze, blue-orientált és side-neutral tükörnézetben. Ez egyetlen szelet, ezért a D.2 skála szerint legfeljebb C.

A szám. Side-neutral nézetben identity LL 0,584340, slope-only 0,590317; az identity javulása +0,005977 [+0,000458; +0,011874]. A slope-only a deployed Plattot csak +0,000914 [+0,000730; +0,001087] értékkel veri, tehát a rossz intercept kijavításához elég, de az identity kontrollt nem győzi le. Blue-oriented nézetben a slope-only épp −0,001293 [−0,004799; +0,002306] értékkel veszít a Plattal szemben, ám ez a nézet a tényleges blue oldalt használja. A 0,538179 blue-alapráta valódi, csak a live odds-feed left szlotjára nem vihető át (live_left_order_is_not_blue); ezért ez a szám nem döntéskori érv az intercept mellett.

Mi cáfolná. Előre befagyasztott identity-versus-slope kar legalább négy új rolling évben vagy egy n≥100 forward mintán, azonos side-neutral sorokon. Slope-only csak akkor léphet előre, ha loglossban és Brierben is pozitív CI-vel veri az identityt, miközben a swap-hiba ≤1e-7 marad.

Kapcsolódik. B7.1, B7.3, B14.2.

Forrás: PRODUCTION_SLOPE_ONLY_CALIBRATION_REPORT.md, E33, T60/1.

B7.3 Kell-e temperature-kalibráció?

Fok: C ·

Válasz egy mondatban: A jelenlegi signal-adaton a temperature nem kell: két időhelyes diagnosztikában is a Platt mögött maradt, de ez még nem független promotion-vintage.

Miért kérdeztük: a slope-only és temperature bináris logitnál közeli forma, de artifact-életciklusuk eltér.

Kalibrációs kérdésnél külön kell választani a rangsort, a valószínűség skáláját és a side-szimmetriát. A fit-szelet nem lehet ugyanaz, amelyen a pontmodellt vagy a kalibrátor alakját kiválasztottuk, és a kevés tier-sor könnyen instabil slope-ot ad. A válaszhoz diszjunkt kalibrációs adat, identity kontroll, side-neutral tükrözés, proper score és reliability görbe kell; az ECE vagy egyetlen optimális temperature önmagában nem dönt.

Mit futtattunk: E45 grouped 5-fold OOF összevetést futtatott raw, Platt, temperature és isotonic alakra; E49 a legkorábbi pre-event jelre három expanding időfoldon megismételte ugyanezt all/60d/30d fitablakkal. Az M6 paper replay a temperature-t a Platt helyett, nem rástackelve alkalmazta.

A szám: E45 LL: Platt 0,6095, temperature 0,6274, isotonic 0,6218, raw 0,6494. E49-ben all-history Platt 0,636843, temperature 0,642820; 60 napos Platt 0,636786, temperature 0,642832. A signal-adatra illesztett M6 T=1,476, tehát zsugorít; a régi 0,87 más mennyiségre készült és nem vihető ide.

Mi cáfolná: befagyasztott pre-forward T, M6 double-apply nélkül.

A C fok kizárólag a jelenlegi fejlesztési adatra mondja, hogy a temperature veszít. Új, előre fagyasztott forward vintage megfordíthatja ezt, de átfogalmazás vagy paper ROI nem.

Kapcsolódik: B7.2, B14.2.

Forrás: E45, E49; validate_calibrator.py; run_calibration_window_experiment.py; paper_pnl_recal.py; MODELING_IDEAS T1.1.

B7.4 Melyik szeleten és mekkorán kalibráljunk?

Fok: ? ·

Válasz egy mondatban: A szeletnek a modellválasztási gate-től és a végső holdouttól diszjunktnak kell lennie, de optimális méret nincs kimérve.

Miért kérdeztük: túl kis szelet zajos, újrahasznált szelet optimista.

Kalibrációs kérdésnél külön kell választani a rangsort, a valószínűség skáláját és a side-szimmetriát. A fit-szelet nem lehet ugyanaz, amelyen a pontmodellt vagy a kalibrátor alakját kiválasztottuk, és a kevés tier-sor könnyen instabil slope-ot ad. A válaszhoz diszjunkt kalibrációs adat, identity kontroll, side-neutral tükrözés, proper score és reliability görbe kell; az ECE vagy egyetlen optimális temperature önmagában nem dönt.

Mit futtattunk: E49-ben ugyanazon három expanding tesztfoldhoz teljes történeti, 60 napos és 30 napos kalibrációs ablakot hasonlítottunk négy alakkal.

A szám: a legjobb átlag a 60 napos Platt 0,636786, de a teljes történeti Platt 0,636843: a rés csak 0,000057. A 30 napos Platt 0,639552, vagyis rövidítéskor már romlik. Ez az alakot támogatja, de nem azonosít valódi ablakoptimumot; ezért a fok marad ?.

Mi cáfolná: rolling kalibrációs learning curve stabil minimumot adna.

A kérdőjel nem azt jelenti, hogy nincs implementáció vagy nincs vélemény, hanem azt, hogy a jelenlegi artifactok nem különítik el a versengő magyarázatokat érvényes mintán. A lezáró futás előtt rögzíteni kell a kontrollt, az elsődleges metrikát, a minimum független elemszámot, a cutoff-szerződést és a döntési küszöböt. Addig a rendszer fail-closed vagy shadow állapotban marad; terv, kód, nyers coverage vagy utólag kiválasztott legjobb kar nem emeli a fokot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: D.3, B14.4.

Forrás: E49; run_calibration_window_experiment.py; calibration gate report.

B7.5 Kell-e rétegenkénti kalibráció?

Fok: ? ·

Válasz egy mondatban: Valószínűleg, mert az akadémiai réteg rosszabbul viselkedik, de nincs rétegenként elegendő független minta.

Miért kérdeztük: közös slope elfedheti a tier- eltérést.

Kalibrációs kérdésnél külön kell választani a rangsort, a valószínűség skáláját és a side-szimmetriát. A fit-szelet nem lehet ugyanaz, amelyen a pontmodellt vagy a kalibrátor alakját kiválasztottuk, és a kevés tier-sor könnyen instabil slope-ot ad. A válaszhoz diszjunkt kalibrációs adat, identity kontroll, side-neutral tükrözés, proper score és reliability görbe kell; az ECE vagy egyetlen optimális temperature önmagában nem dönt.

Mit futtattunk: — (nem volt érvényes rétegenkénti forward fit).

A szám: K8 akadémia LL 0,620142, ECE 0,139605; a forward minimum rétegenként 100.

Mi cáfolná: elegendő mintán azonos reliability curve és slope.

A kérdőjel nem azt jelenti, hogy nincs implementáció vagy nincs vélemény, hanem azt, hogy a jelenlegi artifactok nem különítik el a versengő magyarázatokat érvényes mintán. A lezáró futás előtt rögzíteni kell a kontrollt, az elsődleges metrikát, a minimum független elemszámot, a cutoff-szerződést és a döntési küszöböt. Addig a rendszer fail-closed vagy shadow állapotban marad; terv, kód, nyers coverage vagy utólag kiválasztott legjobb kar nem emeli a fokot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: C.6, B14.4.

Forrás: K8 tier diagnosztika.

B7.6 Elromlik-e a kalibráció időben?

Fok: D ·

Válasz egy mondatban: Igen, mérhető időrezsim van, de a drift pontos sebessége nem stabil.

Miért kérdeztük: egyszer illesztett kalibrátor később félreárazhat.

Kalibrációs kérdésnél külön kell választani a rangsort, a valószínűség skáláját és a side-szimmetriát. A fit-szelet nem lehet ugyanaz, amelyen a pontmodellt vagy a kalibrátor alakját kiválasztottuk, és a kevés tier-sor könnyen instabil slope-ot ad. A válaszhoz diszjunkt kalibrációs adat, identity kontroll, side-neutral tükrözés, proper score és reliability görbe kell; az ECE vagy egyetlen optimális temperature önmagában nem dönt.

Mit futtattunk: szomszédos időablakok, year-ablation és decay.

A szám: két szomszédos ablak kalibrációs/rangsor Spearman értéke −0,700; egy héten belüli árszórás akár 31 pp; decay-gain 0,0176 egy fejlesztési mérésben.

Mi cáfolná: hosszabb forwardon állandó slope/intercept.

A D fok tudatos figyelmeztetés: a szám elhasznált holdoutból, utólag nyitott karból vagy retrospektív replayből jön. Leírhatja, miért született egy hipotézis és melyik irányt érdemes újramérni, de confirmatory állításra, modellválasztásra vagy promotionre nem hivatkozható. A fokot ugyanazon szelet új paraméterezése nem javítja; csak előre regisztrált, érintetlen naptári minta és változatlan döntési szabály adhat új bizonyítékot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: C.4, B6.

Forrás: time-regime riportok.

B7.7 Használható-e az ECE modellválasztásra?

Fok: A ·

Válasz egy mondatban: Nem egyedül; az ECE binfüggő és nem proper scoring rule.

Miért kérdeztük: könnyen látványos, de manipulálható javulást mutat. Az ECE függ a binhatárok számától, helyétől és attól, melyik binbe esik egy határhoz közeli predikció; ugyanaz a modell más beosztással más értéket kap. Korábban a kisebb ECE-t hajlamosak voltunk automatikusan jobb kalibrációnak tekinteni, még akkor is, amikor a logloss vagy Brier romlott. Modellválasztási célként ez jutalmazhatja a mesterséges kisimítást és elveszítheti az egyedi predikciók információját.

Mit futtattunk: binérzékenységi és proper-score összevetések.

A szám: ugyanazon modellek ECE- és logloss-sorrendje több táblában eltért; univerzális küszöb nincs.

Mi cáfolná: matematikailag proper, binfüggetlen ECE-változat előre rögzített használata. A klasszikus, binelt ECE-ről ilyen eredmény nem várható; egy másik mérce csak új néven és bizonyított proper scoring tulajdonsággal helyettesíthetné. Gyakorlati feloldásként több előre rögzített reliability nézet egyezése és proper-score javulás kell, de ez sem tenné az ECE-t önálló választási céllá.

Az A fok itt kizárólag a fenti, szűken megfogalmazott és a megadott mércén vizsgált állításra vonatkozik. Nem jelent automatikus production promotiont, bizonyított pénzügyi edge-et, más targetre való átvihetőséget vagy a teljes modellcsalád általános győzelmét. Ezekhez a kapcsolódó adat-, kalibrációs, végrehajtási és forward kapuknak külön, döntéskor rögzített bizonyítékot kell adniuk.

Kapcsolódik: D.4, B7.4.

Forrás: calibration riportok.

B7.8 Jelöltenként vagy keverés után kalibráljunk?

Fok: B ·

Válasz egy mondatban: Jelöltenként, utána probability-térben súlyozva; a nemlineáris kalibráció és várható érték nem felcserélhető.

Miért kérdeztük: részleges lineupnál több jelöltárból készül a közép.

Kalibrációs kérdésnél külön kell választani a rangsort, a valószínűség skáláját és a side-szimmetriát. A fit-szelet nem lehet ugyanaz, amelyen a pontmodellt vagy a kalibrátor alakját kiválasztottuk, és a kevés tier-sor könnyen instabil slope-ot ad. A válaszhoz diszjunkt kalibrációs adat, identity kontroll, side-neutral tükrözés, proper score és reliability görbe kell; az ECE vagy egyetlen optimális temperature önmagában nem dönt.

Mit futtattunk: candidate-mixture implementáció és Jensen- fixture.

A szám: captured mass 1,0 előírás; top-k csonkolás tilos, de független forward effect-size nincs.

Mi cáfolná: lineáris identity kalibrátor esetén a két út egzakt egyezése, vagy új gate-en a post-mixture út jobb coverage-e.

A B fok azt jelzi, hogy a jel több szeletből vagy független reprodukcióból ismétlődött, de a teljes production és pénzügyi lánc még nem feltétlenül zöld. Az állítás csak a megnevezett targetre, populációra és metrikára vihető át. Promotion előtt külön forward adat, döntéskori provenance, kalibráció és végrehajtási ellenőrzés kell; egy új, ellentétes és érvényes adatvintage a fokot visszanyithatja.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B8.1, B12.

Forrás: T16/5, lineup mixture code.

B8 — Bizonytalanság: hogyan mérjük a szórást

A fejezet legfontosabb mondata: bináris kimenetnél a jól kalibrált pont-valószínűség már a teljes kimenet-eloszlás. Ha p = 0,62 helyes, a kimenet Bernoulli(0,62), és Var(y) = p(1−p) — ebben nincs mit becsülni. Amit becsülünk, az episztemikus: mennyire bízhatunk a saját p-nkben ezen a soron. Ez állítás a modell hibájáról, nem a meccsről. A teljes specifikáció a SZORASBECSLES_SPEC.md; a döntő számok ezen a lapon is szerepelnek.

B8.A A lánc, ahogy fel van építve

1. PONTÁR (befagyasztva, hash-elve)          →  p
2a. L  felállás-szórás   a jelölt-posterior kvantiliséből    (nem kell tanítani)
2b. T  tudás-szórás      B-csatornás mezőkből                (tanítani kell)
2c. M  modell-hiba       a pontár hibájából                  (a célváltozó nyitva)
3. ÖSSZEILLESZTÉS        spread² = L² + T² + M²
4. SZINT                 normalizált + adaptív konformal
5. TÉT                   → B12

A kötelező szeparációs fixture (F7): a pontár egzaktul 0,0-t mozdul attól, hogy a szórásfej fut-e. Nem toleranciával — bitre. Ha nem nulla, a két fej összeért, és a futás verdiktje nem hivatkozható. Ez ma zöld mind a három próbált alakon.

B8.B A három forrás — miért külön

Külön kell őket becsülni, mert külön is romlanak el, és mert az L már ma is kiszámolható. Az L-nek van empirikus priorja: a jósolt ötös medián 52,0%-ban jön be (lásd C.2).

B8.C A T bemenetei — „hány meccsünk van minden emberről"

Ezek feature-ök, nem célváltozók.

min_games_before        ← a leggyengébben ismert játékos: a szűk keresztmetszet
mean_games_before · players_without_prior · days_since_last_game
sigma_level = σ_A² + σ_B²   ← az ÖSSZ-bizonytalanság; a diffből NEM áll elő
sigma_imbalance · candidate_count · modal_mass · lineup_source_age
roster_churn20 · roster_stability20 · coverage-flagek · tier · league

Ezek pontosan azok a mezők, amiket a pontárból kitiltottunk. Itt a helyük. Mind decision_time_observable = true jelölést kap; a realizált roster-változás nem lehet köztük, mert az visszamenőleges információ.

B8.D A mérce — nem proper scoring rule

Loglossszal vagy Brierrel választani tilos: az visszatolná pontmodellé.

Az M3/M4 azért kell, mert a fedés önmagában nem elég: egy konstans [0,1] sáv is 100%-ot fed — pontosan ezt csinálta az S1.

B8.E A kérdések

B8.1 Becsülhető-e az L lineup-szórás a jelölt-posteriorból?

Fok: B ·

Válasz egy mondatban: Igen, ha a jelöltpool valós és a teljes tömeget megőrzi; 5/10 ismert játékos alatt a becsületes eredmény gyakran [0,1].

Miért kérdeztük: ez az egyetlen komponens, amelynek később exact-five célára megfigyelhető.

Bizonytalansági kérdésnél a jó átlagár és a jó intervallum két külön termék. A szélességnek fednie kell az exact-five vagy más megfigyelhető célárat, de közben soronként rangsorolnia is kell a későbbi hibát; a százszázalékos, majdnem teljes intervallum haszontalan. Minden új alakot össz- és rétegzett coverage-en, élességen, pozitív hibarangsoron és direction-leakage ellen kell mérni, a korábban megnyitott 1 164 soros szelet újrahasználatát jelölve.

Mit futtattunk: T27 remaszkolt 300-as holdout.

A szám: 9/10-nél M12 98,5%, M13 95,0% fedés; 5/10 alatt 100% no-support envelope.

Mi cáfolná: timestampelt missingness mellett a célár kiesik a sávból.

A B fok azt jelzi, hogy a jel több szeletből vagy független reprodukcióból ismétlődött, de a teljes production és pénzügyi lánc még nem feltétlenül zöld. Az állítás csak a megnevezett targetre, populációra és metrikára vihető át. Promotion előtt külön forward adat, döntéskori provenance, kalibráció és végrehajtási ellenőrzés kell; egy új, ellentétes és érvényes adatvintage a fokot visszanyithatja.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B2.1, B8.5.

Forrás: T27 lineup mixture report.

B8.2 Működik-e a vanilla split-konformal?

Fok: A ·

Válasz egy mondatban: Fedést ad, de használható alakot nem: majdnem konstans és túl széles.

Miért kérdeztük: egyszerű eloszlásmentes szintkontroll kellett. A vanilla split-konformal vonzereje, hogy kevés eloszlási feltevéssel ígér marginális fedést, és jó biztonsági baseline lehet egy új szórásfejhez. Előtte azt reméltük, hogy már ez a legegyszerűbb eljárás használható soronkénti bizonytalanságot ad. A teszt viszont különválasztotta a névleges coverage-et az élességtől és az alak-információtól: egy majdnem [0,1] intervallum jól fed, de döntésre semmit nem mond.

Mit futtattunk: S1 M12/M13 point replayen, 1 164 soron.

A szám: coverage 98,97%/99,57%, átlagos szélesség 0,7992/0,8164, ρ(σ_sum,width)=0,078/0,066.

Mi cáfolná: heteroszkedasztikus input mellett érdemi rangkorreláció és 90%-hoz közeli, keskeny fedés. Ugyanazon 90%-os cél mellett a vanilla kar átlagos szélességének előre rögzített maximum alá kellene esnie, miközben az összfedés 87–93%, minden n≥100 réteg 85–95%, és a becsült szélesség–realizált hiba Spearman-CI-je pozitív. Pusztán a 99%-os fedés megismétlése nem cáfolat, hanem az X oka.

Az A fok itt kizárólag a fenti, szűken megfogalmazott és a megadott mércén vizsgált állításra vonatkozik. Nem jelent automatikus production promotiont, bizonyított pénzügyi edge-et, más targetre való átvihetőséget vagy a teljes modellcsalád általános győzelmét. Ezekhez a kapcsolódó adat-, kalibrációs, végrehajtási és forward kapuknak külön, döntéskor rögzített bizonyítékot kell adniuk.

Kapcsolódik: B8.5.

Forrás: PS4 spread-head report.

B8.3 Működik-e a tanult S2 hibafej?

Fok: C ·

Válasz egy mondatban: Valamennyi alakot tanul, de alulfed és a rétegzett kapuk többségét elbukja.

Miért kérdeztük: konstans konformal helyett soronkénti szélesség kell.

Bizonytalansági kérdésnél a jó átlagár és a jó intervallum két külön termék. A szélességnek fednie kell az exact-five vagy más megfigyelhető célárat, de közben soronként rangsorolnia is kell a későbbi hibát; a százszázalékos, majdnem teljes intervallum haszontalan. Minden új alakot össz- és rétegzett coverage-en, élességen, pozitív hibarangsoron és direction-leakage ellen kell mérni, a korábban megnyitott 1 164 soros szelet újrahasználatát jelölve.

Mit futtattunk: S2 két point modellen, 1 164 soron és 11 rétegen.

A szám: coverage 83,76%/76,63%, ρ=0,379/0,304; zöld réteg 5/11 és 2/11.

Mi cáfolná: normalizált szinttel 90±3% össz- és 85–95% rétegzett coverage.

A C fok határa egyetlen előre értelmezhető fejlesztési szelet vagy strukturált diagnosztika. Ez elegendő az irány dokumentálására és a következő teszt megtervezésére, de nem általánosítható automatikusan más évre, ligára vagy fogadási piacra. A következő mérésnek előre fagyasztott kontraszttal több időfoldot vagy elegendő forward mintát kell adnia, ugyanazon proper score- és invariánskapukkal; csak ekkor emelhető a fok.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B8.5, B8.9.

Forrás: PS4 spread-head report.

B8.4 Mi legyen az M modellhiba célváltozója?

Fok: X ·

Válasz egy mondatban: A korábbi soronkénti excess-logloss cél hibás, ezért M fail-closed nulla egy független csoportszintű targetig.

Miért kérdeztük: egy Bernoulli-kimenetből nem azonosítható a látens q. A régi cél azt állította, hogy egy sor realizált logloss-többlete nemnegatív „modellhibát” mér, amelyet regresszióval meg lehet tanulni. Egyetlen 0/1 outcome azonban nem mondja meg az adott sor igaz q valószínűségét, és az excess előjele a predikció irányától is függ. Így a fej bias-t tanulhat szórás helyett, majd ezt hamisan bizonytalanságként adjuk hozzá L és T komponenshez.

Mit futtattunk: algebrai várhatóérték-audit.

A szám: E[excess|q,p]=(q−p)log((1−p)/p), ami előjeles bias, nem nemnegatív regret.

Mi cáfolná: past-only, cross-fitted csoport-q stabil minimum mintával. Az új targetnek több, előre definiáltan hasonló múltbeli eseményből kell q-t becsülnie, a célsort és jövőjét kizárva, majd nemnegatív hibamértéket képeznie. Legalább négy rolling foldon pozitív hibarangsor-CI, helyes rétegzett coverage és stabil minimum csoportméret kellene; egy újabb soronkénti outcome-transzformáció nem változtatná meg az X-et.

Az X a kipróbált megvalósítást és a fenti, szűk állítást vonja vissza; nem bizonyítja, hogy az egész ötletcsalád minden lehetséges formája értéktelen. Új változat csak a leírt cáfolati protokollal, előre fagyasztott karon és érintetlen időszakon nyitható ki. Ugyanannak az elhasznált szeletnek új paraméterrel történő ismételt megnyitása nem számít új bizonyítéknak.

Kapcsolódik: B8.7, D.4.

Forrás: szórásbecslés-spec §4.

B8.5 Működik-e az S4 normalizált konformal?

Fok: X ·

Válasz egy mondatban: A próbált alak×szint forma nem érte el a 90%-os fedést és fordított rangkapcsolatot adott.

Miért kérdeztük: az S1 szintjét és az S3 alakját kellett volna egyesítenie. Az S1 túl széles, az S3 pedig alakot mutatott, de szintben elcsúszott; a normalizált konformal kézenfekvő kísérlet volt a két tulajdonság szétválasztására. A várakozás az volt, hogy a tanult relatív szélességet egyetlen kalibrációs kvantilis megfelelő 90%-os szintre húzza. A negatív rangkapcsolat azonban azt jelzi, hogy nem pusztán a globális skála rossz: a szélesség soronként fordított irányban reagál a realizált hibára.

Mit futtattunk: S4 M12/M13-on, 1 164 soron.

A szám: coverage 78,95% és 82,73%; ρ=−0,329 és −0,296; zöld réteg 0/11 és 1/11.

Mi cáfolná: új, előre rögzített alak 90±3% fedéssel és pozitív rang-CI-vel. A következő alakot az 1 164 soros értékelés újbóli megnyitása előtt kell rögzíteni, majd új időszakon ellenőrizni. Az X csak akkor fordulna, ha az összfedés 87–93%, minden elegendő réteg 85–95%, az M3/M4 rangteszt pozitív CI-jű, és az átlagos szélesség kisebb az S1-énél; coverage önmagában nem elég.

Az X a kipróbált megvalósítást és a fenti, szűk állítást vonja vissza; nem bizonyítja, hogy az egész ötletcsalád minden lehetséges formája értéktelen. Új változat csak a leírt cáfolati protokollal, előre fagyasztott karon és érintetlen időszakon nyitható ki. Ugyanannak az elhasznált szeletnek új paraméterrel történő ismételt megnyitása nem számít új bizonyítéknak.

Kapcsolódik: B8.2, B8.6.

Forrás: normalized adaptive spread report.

B8.6 Működik-e az S5 adaptív konformal driftben?

Fok: D ·

Válasz egy mondatban: Az összfedést közel helyreállította, de az alak és a rétegzett coverage még nem zöld.

Miért kérdeztük: a statikus kvantilis driftben elcsúszik.

Bizonytalansági kérdésnél a jó átlagár és a jó intervallum két külön termék. A szélességnek fednie kell az exact-five vagy más megfigyelhető célárat, de közben soronként rangsorolnia is kell a későbbi hibát; a százszázalékos, majdnem teljes intervallum haszontalan. Minden új alakot össz- és rétegzett coverage-en, élességen, pozitív hibarangsoron és direction-leakage ellen kell mérni, a korábban megnyitott 1 164 soros szelet újrahasználatát jelölve.

Mit futtattunk: γ=0,01 direkt miss-indikátoros ACI, 1 164 sor.

A szám: coverage 89,52%/89,09%, miss-rate 10,48%/10,91%, de csak 8/11 réteg zöld és a rangkorreláció negatív.

Mi cáfolná: forwardban tartós 90% körüli össz- és rétegzett coverage pozitív alakteszttel.

A D fok tudatos figyelmeztetés: a szám elhasznált holdoutból, utólag nyitott karból vagy retrospektív replayből jön. Leírhatja, miért született egy hipotézis és melyik irányt érdemes újramérni, de confirmatory állításra, modellválasztásra vagy promotionre nem hivatkozható. A fokot ugyanazon szelet új paraméterezése nem javítja; csak előre regisztrált, érintetlen naptári minta és változatlan döntési szabály adhat új bizonyítékot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B8.5, C.4.

Forrás: normalized adaptive spread report.

B8.7 Additív-e L, T és M varianciában?

Fok: ? ·

Válasz egy mondatban: A teljes állítás nem tesztelhető, mert M jelenleg nulla; L és T a próbált replayben rang szerint független volt.

Miért kérdeztük: korrelált komponensek négyzetes összege félreárazza a sávot.

Bizonytalansági kérdésnél a jó átlagár és a jó intervallum két külön termék. A szélességnek fednie kell az exact-five vagy más megfigyelhető célárat, de közben soronként rangsorolnia is kell a későbbi hibát; a százszázalékos, majdnem teljes intervallum haszontalan. Minden új alakot össz- és rétegzett coverage-en, élességen, pozitív hibarangsoron és direction-leakage ellen kell mérni, a korábban megnyitott 1 164 soros szelet újrahasználatát jelölve.

Mit futtattunk: csak L–T diagnosztika.

A szám: L–T Spearman 0,000 mindkét point modellen.

Mi cáfolná: M cél elkészülte után cross-fitted kovarianciamátrix és coverage-ablation.

A kérdőjel nem azt jelenti, hogy nincs implementáció vagy nincs vélemény, hanem azt, hogy a jelenlegi artifactok nem különítik el a versengő magyarázatokat érvényes mintán. A lezáró futás előtt rögzíteni kell a kontrollt, az elsődleges metrikát, a minimum független elemszámot, a cutoff-szerződést és a döntési küszöböt. Addig a rendszer fail-closed vagy shadow állapotban marad; terv, kód, nyers coverage vagy utólag kiválasztott legjobb kar nem emeli a fokot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B8.4, B8.9.

Forrás: normalized adaptive spread report.

B8.8 Tartja-e az F7 szeparációt minden alak?

Fok: B ·

Válasz egy mondatban: A külön spread-fejek igen; a literális S3 nem, ezért pontárjelöltként elutasítottuk.

Miért kérdeztük: uncertainty nem írhatja át észrevétlenül a pontárat.

Bizonytalansági kérdésnél a jó átlagár és a jó intervallum két külön termék. A szélességnek fednie kell az exact-five vagy más megfigyelhető célárat, de közben soronként rangsorolnia is kell a későbbi hibát; a százszázalékos, majdnem teljes intervallum haszontalan. Minden új alakot össz- és rétegzett coverage-en, élességen, pozitív hibarangsoron és direction-leakage ellen kell mérni, a korábban megnyitott 1 164 soros szelet újrahasználatát jelölve.

Mit futtattunk: bitazonossági fixture S1/S2/S3/S4/S5 útvonalakon.

A szám: az elfogadott külön fejek max|Δp|=0; S3 pontelmozdulása M12-n 0,535932, M13-on 0,942713 és rejected.

Mi cáfolná: bármely elfogadott spread-kar nem nulla point diffje.

A B fok azt jelzi, hogy a jel több szeletből vagy független reprodukcióból ismétlődött, de a teljes production és pénzügyi lánc még nem feltétlenül zöld. Az állítás csak a megnevezett targetre, populációra és metrikára vihető át. Promotion előtt külön forward adat, döntéskori provenance, kalibráció és végrehajtási ellenőrzés kell; egy új, ellentétes és érvényes adatvintage a fokot visszanyithatja.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B4.5, B12.1.

Forrás: PS4 spread report, F7 tesztek.

B8.9 Melyik T-bemenet hordoz jelet a σ-n túl?

Fok: ? ·

Válasz egy mondatban: Nem azonosítottuk; a games-before erősen összefügg σ-val, a többi coverage-feature inkrementumát nem mérte tiszta uncertainty-target.

Miért kérdeztük: redundáns mezők hamis precizitást adnak.

Bizonytalansági kérdésnél a jó átlagár és a jó intervallum két külön termék. A szélességnek fednie kell az exact-five vagy más megfigyelhető célárat, de közben soronként rangsorolnia is kell a későbbi hibát; a százszázalékos, majdnem teljes intervallum haszontalan. Minden új alakot össz- és rétegzett coverage-en, élességen, pozitív hibarangsoron és direction-leakage ellen kell mérni, a korábban megnyitott 1 164 soros szelet újrahasználatát jelölve.

Mit futtattunk: — (nincs érvényes M-targetes inkrementális teszt).

A szám: corr(σ_diff,games_before_diff)=−0,746; további saját gain nincs.

Mi cáfolná: cross-fitted group-error targeten monotone ablation minden T-bemenetre.

A kérdőjel nem azt jelenti, hogy nincs implementáció vagy nincs vélemény, hanem azt, hogy a jelenlegi artifactok nem különítik el a versengő magyarázatokat érvényes mintán. A lezáró futás előtt rögzíteni kell a kontrollt, az elsődleges metrikát, a minimum független elemszámot, a cutoff-szerződést és a döntési küszöböt. Addig a rendszer fail-closed vagy shadow állapotban marad; terv, kód, nyers coverage vagy utólag kiválasztott legjobb kar nem emeli a fokot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B4.8, B4.11.

Forrás: E14, szórásbecslés-spec.

B9 — A piaci ár mint információ

A rendszer szándékosan market-blind — a modell nem látja a könyv árát. Ez elvi döntés (evaluate_market_blind.py: „egy modell csak akkor edge, ha market-blind valószínűség veri a könyv árát"), és soha nem teszteltük, hogy jó döntés-e. Ha a piac hatékony, a legjobb modell akár „piaci ár + kis korrekció" is lehet.

A második téma a margin: a könyv ára overroundot tartalmaz, és abból fair valószínűséget kell csinálni. Ma arányos normalizálás fut (left_prob / total, decimal_odds_no_vig) — ez a legnaivabb módszer, és longshotokon ismerten torzít. A Shin- és a power-módszer 1–3 pp-ot mozdíthat, ami összemérhető a vizsgált modellkülönbségekkel.

A B9.3 azért döntő, mert minden edge-számításunk bemenete. Ha a de-vigging 2 pp-ot torzít, az minden ROI-számot elmozdít — és a torzítás nem véletlenszerű, hanem szisztematikusan a longshotok ellen. Márpedig az M7 underdog-kar pont ott fogad.

B9.1 Helyes-e a market-blind elv?

Fok: ? ·

Válasz egy mondatban: Nem tudjuk; jó kutatási kontroll, de nem bizonyított, hogy ez adja a legjobb végső döntési árat.

Miért kérdeztük: a piac sok olyan információt összesít, amelyet a feature-tábla nem lát.

Piaci kérdésnél a model probability csak az egyik bemenet: a könyv információja, marginmódszere, időpontja és végrehajtható oldala ugyanúgy változtatja az edge-et. Mid, záróár vagy egy soft könyv ára nem cserélhető fel automatikusan azzal az askkal, amelyen ténylegesen vehettünk volna. Érvényes válaszhoz időbélyegzett többforrású quote-panel, de-vig szerződés, likviditás és ugyanazon események későbbi closing referenciája kell.

Mit futtattunk: — (nincs market-blind kontra market-aware rolling/forward kar).

A szám: — (nem futott).

Mi cáfolná: azonos cutoffú market-prior + model residual stabilan javít proper score-on és nettó döntésen.

A kérdőjel nem azt jelenti, hogy nincs implementáció vagy nincs vélemény, hanem azt, hogy a jelenlegi artifactok nem különítik el a versengő magyarázatokat érvényes mintán. A lezáró futás előtt rögzíteni kell a kontrollt, az elsődleges metrikát, a minimum független elemszámot, a cutoff-szerződést és a döntési küszöböt. Addig a rendszer fail-closed vagy shadow állapotban marad; terv, kód, nyers coverage vagy utólag kiválasztott legjobb kar nem emeli a fokot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B9.2, D.4.

Forrás: evaluate_market_blind.py; kísérleti artifact nincs.

B9.2 Javítana-e a piaci ár feature-ként?

Fok: C ·

Válasz egy mondatban: A döntéskori Tippmix fair ár erős prediktív prior a model-score mellett, de a forward nettó fogadási előny még nincs igazolva.

Miért kérdeztük: hatékony piacon kisebb és stabilabb feladat lehet a market residual tanulása.

Piaci kérdésnél a model probability csak az egyik bemenet: a könyv információja, marginmódszere, időpontja és végrehajtható oldala ugyanúgy változtatja az edge-et. Mid, záróár vagy egy soft könyv ára nem cserélhető fel automatikusan azzal az askkal, amelyen ténylegesen vehettünk volna. Érvényes válaszhoz időbélyegzett többforrású quote-panel, de-vig szerződés, likviditás és ugyanazon események későbbi closing referenciája kell.

Mit futtattunk: E48 a legkorábbi naplózott, kickoff előtti jelet tartotta meg minden event/oldal párra, majd három expanding időfoldon model-only, market-only és model+Tippmix-logit kart illesztett. Closing ár nem került feature-be.

A szám: 267 független teszteseményen a market-aware minus model-only ΔLL −0,05696, event-bootstrap CI [−0,09969; −0,01564], és mindhárom foldban a market-aware kar nyert.

🔴 A fordított kontraszt ugyanabból a fold-táblából, és ez a döntő. Nem a „segít-e a piac nekünk", hanem a „segítünk-e mi a piacnak" kérdés mondja meg, van-e termékünk. Csak piac 0,58756 / 0,55452 / 0,59000; piac + a mi modellünk 0,58696 / 0,55072 / 0,59437. A hozzáadott értékünk foldonként +0,00060, +0,00380, −0,00437 — átlag +0,00001, és három foldból egyen rontunk. A market-only kar tehát nem „közel ugyanilyen erős": gyakorlatilag azonos.

Vagyis a −0,0595 azt mondja, hogy a piac tud valamit, amit mi nem — a +0,00001 viszont azt, hogy mi nem tudunk semmit, amit a piac ne tudna. A kettő nem ugyanaz, és a második dönt. n=267 fejlesztési minta, nem lezárt ügy — de egy irányba mutat a −23,64% ROI-val (1 290 Tippmix-tipp, pozitív CLV mellett) és a többkönyves moneyline-eredménnyel. Három független vonal egybevág.

Nagyságrendi keret, hogy a rés súlya látszódjon: a piac-rés 0,0595 három-harmincszorosa mindennek, amit valaha nyertünk — a seat-korrekció (+0,0108) a 18%-a, a normalizált decay (+0,0021) a 3,5%-a, a τ×6 finomítás (+0,0004) a 0,7%-a.

Mi cáfolná: pre-start ask/Betfair fair price alapú rolling-origin, ahol a residual nem javít vagy csak leakage-ből javít.

A C fok prediktív információt, nem fogadási edge-et jelent. Promotionhoz ugyanazon forward quote-on kell megmutatni, hogy a prior jobb nettó szelekciót is ad, nem csak kisebb loglosst.

Kapcsolódik: B9.1, B9.4.

Forrás: E48; run_market_prior_experiment.py; a market-aware pipeline forward karja még shadow/preregisztrált állapotú.

B9.3 Jó-e az arányos de-vigging?

Fok: ? ·

Válasz egy mondatban: A saját címkézett mintán egyik módszer sem nyer megbízhatóan: az additív/Shin, proportional és power esemény-klaszteres különbségeinek 95%-os intervalluma is fedi a nullát, ezért defaultváltásra nincs alap.

Miért kérdeztük: a margin elosztása kimenetfüggő lehet, különösen longshoton.

Piaci kérdésnél a model probability csak az egyik bemenet: a könyv információja, marginmódszere, időpontja és végrehajtható oldala ugyanúgy változtatja az edge-et. Mid, záróár vagy egy soft könyv ára nem cserélhető fel automatikusan azzal az askkal, amelyen ténylegesen vehettünk volna. Érvényes válaszhoz időbélyegzett többforrású quote-panel, de-vig szerződés, likviditás és ugyanazon események későbbi closing referenciája kell.

Mit futtattunk: 366 legutolsó, címkézett event-side sort pontos event- és snapshot-idő joinnal összekötöttünk a kétoldali Tippmix oddsszal; proportional, additive, Shin és power valószínűséget számoltunk, majd eseményszintű klaszter-bootstrapot futtattunk.

A szám: 308 független esemény. Sorátlagos logloss: additive/Shin 0,555835, proportional 0,557582, power 0,557221. Eseményenként súlyozott LL-javulás a proportionalhoz képest: additive +0,000112 [−0,007328; +0,007004], Shin ugyanez, power −0,003073 [−0,019094; +0,010420] — egyik sem azonosított.

Mi cáfolná: nagyobb, döntéskor elérhető mintán és végrehajtható sharp close ellen valamelyik előre rögzített módszer CI-je teljesen a nulla fölé kerül, majd downstream szelekcióban is ugyanaz az irány marad. A mostani outcome-logloss nem helyettesíti a closing tesztet.

Kapcsolódik: B12.2, B10.1.

Forrás: E43, run_devig_method_experiment.py, processed/odds/fresh_watch/experiments/devig_methods_2026_08_02/report.json.

B9.4 Melyik könyv a legjobb referencia?

Fok: B ·

Válasz egy mondatban: Nincs igazolt sharp könyv; a jelenleg elérhető legjobb „sharp-ish” jel a de-viggelt Betfair Exchange, de a loop nem fogyasztja.

Miért kérdeztük: soft könyvhöz mért CLV önmagában gyenge cél.

Piaci kérdésnél a model probability csak az egyik bemenet: a könyv információja, marginmódszere, időpontja és végrehajtható oldala ugyanúgy változtatja az edge-et. Mid, záróár vagy egy soft könyv ára nem cserélhető fel automatikusan azzal az askkal, amelyen ténylegesen vehettünk volna. Érvényes válaszhoz időbélyegzett többforrású quote-panel, de-vig szerződés, likviditás és ugyanazon események későbbi closing referenciája kell.

Mit futtattunk: forrásleltár és OddsHarvester audit.

A szám: 2026-07-18-án 33 upcoming LoL-meccs, 12 soft/crypto könyv + Betfair; Pinnacle nincs.

Mi cáfolná: végrehajtható, nagy coverage-ű sharp close más forrásból.

A B fok azt jelzi, hogy a jel több szeletből vagy független reprodukcióból ismétlődött, de a teljes production és pénzügyi lánc még nem feltétlenül zöld. Az állítás csak a megnevezett targetre, populációra és metrikára vihető át. Promotion előtt külön forward adat, döntéskori provenance, kalibráció és végrehajtási ellenőrzés kell; egy új, ellentétes és érvényes adatvintage a fokot visszanyithatja.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B9.5, B13.1.

Forrás: betting roadmap §sharp reference.

B9.5 Mennyit mozog az ár kickoffig?

Fok: ? ·

Válasz egy mondatban: Nincs teljes, venue- és likviditásazonos line-movement eloszlásunk.

Miért kérdeztük: a belépési idő és a rosterhír értéke ebből mérhető.

Piaci kérdésnél a model probability csak az egyik bemenet: a könyv információja, marginmódszere, időpontja és végrehajtható oldala ugyanúgy változtatja az edge-et. Mid, záróár vagy egy soft könyv ára nem cserélhető fel automatikusan azzal az askkal, amelyen ténylegesen vehettünk volna. Érvényes válaszhoz időbélyegzett többforrású quote-panel, de-vig szerződés, likviditás és ugyanazon események későbbi closing referenciája kell.

Mit futtattunk: — (a snapshotgyűjtés létezik, az összefoglaló mérés nem).

A szám: — (nem futott).

Mi cáfolná: esemény×piac panel first-seen, pre-start és close askkal, időtáv-kvantilisekkel.

A kérdőjel nem azt jelenti, hogy nincs implementáció vagy nincs vélemény, hanem azt, hogy a jelenlegi artifactok nem különítik el a versengő magyarázatokat érvényes mintán. A lezáró futás előtt rögzíteni kell a kontrollt, az elsődleges metrikát, a minimum független elemszámot, a cutoff-szerződést és a döntési küszöböt. Addig a rendszer fail-closed vagy shadow állapotban marad; terv, kód, nyers coverage vagy utólag kiválasztott legjobb kar nem emeli a fokot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: C.4, B13.5.

Forrás: OddsHarvester snapshotok.

B9.6 Mid, bid vagy ask ellen mérjük a CLV-t?

Fok: X ·

Válasz egy mondatban: A mid-alapú belépő megdőlt; vásárlásnál elérhető ask, eladásnál bid, volumen, díj és csúszás kell.

Miért kérdeztük: a mid nem végrehajtható és seed piacon fiktív lehet. A korábbi monitor mégis mid-to-mid CLV-t használt, mert ez könnyen elérhető és szimmetrikus referencia volt. Vevőként azonban az askot kell megfizetnünk, ráadásul csak a látható volumenig; a seed 0,50 mid gyakran nem valódi kétoldalú piac. A rossz belépőár nem egyszerű mérési zaj: szisztematikusan túlbecsüli az edge-et és a go-live kaput is zöldre festheti.

Mit futtattunk: Poly audit mid és ask-árazható részhalmazon.

A szám: askon a CLV −4,2%, körülbelül 1,8% fee után −5,9%; 30/38 betnél nem volt pre-game ask, 34% seed.

Mi cáfolná: tényleges fill igazoltan midnél jobb áron, következetesen. Ehhez legalább 100 accepted order kell teljes bid/ask/depth snapshottal, timestampelt fillárral és fee-vel. A mid csak akkor lehetne elfogadható proxy, ha a fill–mid eltérés 95%-os intervalluma méret szerint is nulla körül maradna, és a mid-alapú versus fill-alapú CLV-verdikt egyetlen vizsgált rétegben sem fordulna meg.

Az X a kipróbált megvalósítást és a fenti, szűk állítást vonja vissza; nem bizonyítja, hogy az egész ötletcsalád minden lehetséges formája értéktelen. Új változat csak a leírt cáfolati protokollal, előre fagyasztott karon és érintetlen időszakon nyitható ki. Ugyanannak az elhasznált szeletnek új paraméterrel történő ismételt megnyitása nem számít új bizonyítéknak.

Kapcsolódik: B13.1, B13.3.

Forrás: STATE_OF_PLAY audit banner.

B10 — Nem-ML piacok

B10.1 Van-e moneyline edge bármelyik könyvön?

Fok: B ·

Válasz egy mondatban: Jelenleg nincs bizonyított végrehajtható edge: Tippmixen negatív, a Poly pozitívnak látszó CLV-je audit után érvénytelen.

Miért kérdeztük: ez a production fő pénzügyi állítása.

A non-ML piacok közös terminális score-eloszlásból származnak, ezért egy seriesen belül erősen függők. A külön market-family minta nem tekinthető független fogadások halmazának, és az iid map-feltevés mesterséges sweep- vagy handicap-edge-et hozhat létre. A válaszhoz koherens PMF, családonként elegendő független series, végrehajtható quote és series-szinten klaszterezett score- illetve pénzügyi értékelés szükséges.

Mit futtattunk: paper-P&L/CLV több küszöbön és ask-audit.

A szám: Poly ask-részhalmaz −4,2% CLV, fee után −5,9%; Tippmix CLV negatív.

Mi cáfolná: előre regisztrált, append-only, ask+volume alapú pozitív nettó CI elegendő mintán.

A B fok azt jelzi, hogy a jel több szeletből vagy független reprodukcióból ismétlődött, de a teljes production és pénzügyi lánc még nem feltétlenül zöld. Az állítás csak a megnevezett targetre, populációra és metrikára vihető át. Promotion előtt külön forward adat, döntéskori provenance, kalibráció és végrehajtási ellenőrzés kell; egy új, ellentétes és érvényes adatvintage a fokot visszanyithatja.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B13.1, B9.6.

Forrás: STATE_OF_PLAY, betting roadmap.

B10.2 Van-e Poly non-ML edge?

Fok: X ·

Válasz egy mondatban: A korábbi látszólagos +EV iid-map artefakt volt; valódi non-ML edge nincs igazolva.

Miért kérdeztük: a map winner, handicap és total új felületek. A series-moneyline edge hiánya nem zárja ki, hogy a terminális score-eloszlás valamelyik másik szeletét a piac rosszabbul árazza. A korábbi replay iid mapeket feltételezett, ezért túl könnyen generált sweep- és handicap-előnyt. Mivel ugyanabból a PMF-ből három erősen összefüggő piac készül, a koherencia, a multiplicitás és a végrehajtható quote egyszerre része a kérdésnek.

Mit futtattunk: non-ML replay iid-map és közös PMF összevetéssel.

A szám: 126 eventből 122 árazható volt, de a korábbi profitjel koherenciafeltevésen bukott; market-family gate nem érett.

Mi cáfolná: append-only, common-PMF, executable-quote forward pozitív nettó CI-vel. Mindhárom piaccsaládot előre befagyasztott kalibrációval, ask+volumen belépőn és fee/slippage levonása után kell mérni, series szerint klaszterezett CI-vel. Az X csak akkor fordulna, ha legalább 200 független seriesen a nettó CLV és log-growth alsó határa is pozitív, és az eredmény nem egyetlen market family vagy book hozama.

Az X a kipróbált megvalósítást és a fenti, szűk állítást vonja vissza; nem bizonyítja, hogy az egész ötletcsalád minden lehetséges formája értéktelen. Új változat csak a leírt cáfolati protokollal, előre fagyasztott karon és érintetlen időszakon nyitható ki. Ugyanannak az elhasznált szeletnek új paraméterrel történő ismételt megnyitása nem számít új bizonyítéknak.

Kapcsolódik: B5.9, B10.3.

Forrás: T24, STATE_OF_PLAY.

B10.3 Kell-e külön kalibráció piac-családonként?

Fok: C ·

Válasz egy mondatban: Igen, mert eltérő eseményt jósolnak; a jelenlegi minták azonban a 200-as kapu alatt vannak.

Miért kérdeztük: series-winner kalibráció nem garantál helyes handicap/total széleket.

A non-ML piacok közös terminális score-eloszlásból származnak, ezért egy seriesen belül erősen függők. A külön market-family minta nem tekinthető független fogadások halmazának, és az iid map-feltevés mesterséges sweep- vagy handicap-edge-et hozhat létre. A válaszhoz koherens PMF, családonként elegendő független series, végrehajtható quote és series-szinten klaszterezett score- illetve pénzügyi értékelés szükséges.

Mit futtattunk: common-PMF family calibration gate.

A szám: a három család értékelhető sorozatszáma 72/70/68, a követelmény 200.

Mi cáfolná: egy közös kalibrátor rétegenként is megfelelő coverage-et és reliabilityt adna.

A C fok határa egyetlen előre értelmezhető fejlesztési szelet vagy strukturált diagnosztika. Ez elegendő az irány dokumentálására és a következő teszt megtervezésére, de nem általánosítható automatikusan más évre, ligára vagy fogadási piacra. A következő mérésnek előre fagyasztott kontraszttal több időfoldot vagy elegendő forward mintát kell adnia, ugyanazon proper score- és invariánskapukkal; csak ekkor emelhető a fok.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B5.9, B9.3.

Forrás: T24.

B10.4 Van-e saját szabadsági foka a handicap-fejnek?

Fok: A ·

Válasz egy mondatban: A koherens common-PMF szerződésben nincs: a handicap ára a terminális score-eloszlás összege.

Miért kérdeztük: külön fej egymásnak ellentmondó árakat adhatna. Ha a series-winner, a handicap és a total külön modellekből jön, előfordulhat, hogy egyidejűleg túl nagy valószínűséget adnak egymást kizáró kimenetekre, vagy arbitrázs-szerűen nem összegezhetők. A terminális score-PMF ezzel szemben egyetlen valószínűségi tömeget oszt fel a piacok kifizetési halmazai szerint. A kérdés ezért matematikai szerződés, nem empirikus hiperparaméter-választás.

Mit futtattunk: algebrai koherencia-fixture minden végső score-on.

A szám: a handicap-price maradéktalanul a PMF-ből származik; külön illesztett paraméter 0.

Mi cáfolná: olyan piacdefiníció, amely a terminális score-on kívüli kifizetési állapotot használ. Például void-, push-, map-sorrend- vagy időfüggő elszámolás külön állapotteret igényelhet; ezt a venue contractból kell bizonyítani. Normál series handicapnél minden enumerált score-ra golden payout- fixture fut: bármely maradék szabadsági fok, nem egyező összeg vagy negatív tömeg azonnal visszavonná az A szerkezeti állítást.

Az A fok itt kizárólag a fenti, szűken megfogalmazott és a megadott mércén vizsgált állításra vonatkozik. Nem jelent automatikus production promotiont, bizonyított pénzügyi edge-et, más targetre való átvihetőséget vagy a teljes modellcsalád általános győzelmét. Ezekhez a kapcsolódó adat-, kalibrációs, végrehajtási és forward kapuknak külön, döntéskor rögzített bizonyítékot kell adniuk.

Kapcsolódik: B5.9, B13.

Forrás: common score-PMF implementáció, T24.

B11 — Kockázat és bankroll

Nem néztük meg, mi történik több párhuzamos fogadással. Egy meccs map-piacai erősen korreláltak; egy nap több meccse ugyanazon a ligán szintén. A Kelly egyetlen fogadásra optimális — korrelált portfólióra nem, és ott a túltétezés tönkremenetelhez vezet akkor is, ha minden egyes fogadás +EV.

B11.1 Mekkora a tönkremenetel valószínűsége?

Fok: ? ·

Válasz egy mondatban: Van első empirikus blokk-bootstrap, de csak 56 graded forward tippből; a vizsgált 30 aktív napos horizonton 2%-os flat tét mellett a fél-bankroll átlépés becslése 0,055%, ami nem általánosítható hosszú távú ruin-valószínűségre.

Miért kérdeztük: pozitív egyedi EV mellett is elfogyhat a tőke.

Bankrollkérdésre az egyedi fogadás várható értéke nem elég, mert az egyidejű map-, handicap- és total pozíciók ugyanabból a series-kimenetből fizetnek. A veszteségsor, a napi exposure, a fill-hiány és a stake-policy együtt alakítja a drawdownt és a ruin kockázatát. A hiányzó válasz ezért nem egy képlet hiánya: közös payoff-mátrix, blokkos időreplay, költségmodell és előre rögzített induló bankroll kell hozzá.

Mit futtattunk: a deployed edge_param=0,10 kar 56 graded, fired tippjének teljes UTC napblokkjait 20 000-szer visszamintáztuk policyként, a napokon belüli függést megőrizve.

A szám: 56 tipp, 56 event, 30 aktív nap; megfigyelt 1u ROI −10,48%. Fél-bankroll breach: 0,25–1% flat karokon 0, 2% flat karon 0,00055, 2%/5%-os napi cap mellett 0,00005 a rövid, megfigyelt-hosszúságú bootstrap horizonton.

Mi cáfolná: blokkolt esemény-bootstrap vagy Monte Carlo, reális fill/korreláció és induló bankroll mellett.

A kérdőjel nem azt jelenti, hogy nincs implementáció vagy nincs vélemény, hanem azt, hogy a jelenlegi artifactok nem különítik el a versengő magyarázatokat érvényes mintán. A lezáró futás előtt rögzíteni kell a kontrollt, az elsődleges metrikát, a minimum független elemszámot, a cutoff-szerződést és a döntési küszöböt. Addig a rendszer fail-closed vagy shadow állapotban marad; terv, kód, nyers coverage vagy utólag kiválasztott legjobb kar nem emeli a fokot.

Kapcsolódik: B11.2, B12.7.

Forrás: E44, run_bankroll_risk_simulation.py, processed/odds/fresh_watch/experiments/bankroll_risk_2026_08_02/report.json.

B11.2 Mekkora a várható maximális visszaesés?

Fok: ? ·

Válasz egy mondatban: Az első kis forward diagnosztikában a 2%-os flat kar medián maximum drawdownja 20,42%, 95. percentilise 36,10%; a hosszú távú várható drawdown továbbra is nyitott.

Miért kérdeztük: az átlagos ROI nem írja le a túlélhető veszteségsort.

Bankrollkérdésre az egyedi fogadás várható értéke nem elég, mert az egyidejű map-, handicap- és total pozíciók ugyanabból a series-kimenetből fizetnek. A veszteségsor, a napi exposure, a fill-hiány és a stake-policy együtt alakítja a drawdownt és a ruin kockázatát. A hiányzó válasz ezért nem egy képlet hiánya: közös payoff-mátrix, blokkos időreplay, költségmodell és előre rögzített induló bankroll kell hozzá.

Mit futtattunk: ugyanazt a 30 napblokkos empirikus forward replayt öt tétpolicyre, 20 000 bootstrap úttal policyként.

A szám: p95 max drawdown: 0,25% flat 5,34%, 0,5% 10,40%, 1% 19,94%, 2% 36,10%, 2% flat + 5% napi cap 28,94%. A minta negatív megfigyelt hozamú, ezért ez nem optimális frakció-rangsor.

Mi cáfolná: időrendi, blokkos replay max-drawdown kvantiliseivel minden stake-karra.

A kérdőjel nem azt jelenti, hogy nincs implementáció vagy nincs vélemény, hanem azt, hogy a jelenlegi artifactok nem különítik el a versengő magyarázatokat érvényes mintán. A lezáró futás előtt rögzíteni kell a kontrollt, az elsődleges metrikát, a minimum független elemszámot, a cutoff-szerződést és a döntési küszöböt. Addig a rendszer fail-closed vagy shadow állapotban marad; terv, kód, nyers coverage vagy utólag kiválasztott legjobb kar nem emeli a fokot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B11.1, B12.4.

Forrás: E44, run_bankroll_risk_simulation.py.

B11.3 Mennyire korrelálnak az egyidejű fogadások?

Fok: ? ·

Válasz egy mondatban: Nem mértük; ugyanazon series három non-ML piaca biztosan nem független.

Miért kérdeztük: a terminális score-PMF közös kimenetele egyszerre rendezi őket.

Bankrollkérdésre az egyedi fogadás várható értéke nem elég, mert az egyidejű map-, handicap- és total pozíciók ugyanabból a series-kimenetből fizetnek. A veszteségsor, a napi exposure, a fill-hiány és a stake-policy együtt alakítja a drawdownt és a ruin kockázatát. A hiányzó válasz ezért nem egy képlet hiánya: közös payoff-mátrix, blokkos időreplay, költségmodell és előre rögzített induló bankroll kell hozzá.

Mit futtattunk: — (nincs portfólió-kovariancia mérés).

A szám: — (nem futott).

Mi cáfolná: event-clusterelt payoff-mátrix és nap/liga faktorokból becsült korreláció.

A kérdőjel nem azt jelenti, hogy nincs implementáció vagy nincs vélemény, hanem azt, hogy a jelenlegi artifactok nem különítik el a versengő magyarázatokat érvényes mintán. A lezáró futás előtt rögzíteni kell a kontrollt, az elsődleges metrikát, a minimum független elemszámot, a cutoff-szerződést és a döntési küszöböt. Addig a rendszer fail-closed vagy shadow állapotban marad; terv, kód, nyers coverage vagy utólag kiválasztott legjobb kar nem emeli a fokot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B10.4, B11.4.

Forrás: common-PMF szerkezeti függés.

B11.4 Kell-e meccs- és napi exposure-cap?

Fok: ? ·

Válasz egy mondatban: Biztonsági specifikációként igen, optimális értéke azonban ismeretlen.

Miért kérdeztük: több külön tipp ugyanazt az eseménykockázatot többször számolhatja.

Bankrollkérdésre az egyedi fogadás várható értéke nem elég, mert az egyidejű map-, handicap- és total pozíciók ugyanabból a series-kimenetből fizetnek. A veszteségsor, a napi exposure, a fill-hiány és a stake-policy együtt alakítja a drawdownt és a ruin kockázatát. A hiányzó válasz ezért nem egy képlet hiánya: közös payoff-mátrix, blokkos időreplay, költségmodell és előre rögzített induló bankroll kell hozzá.

Mit futtattunk: első diagnosztikaként 2%-os flat policyt vetettünk össze ugyanazzal a karral, amelyen a teljes napi stake az induló napi bankroll 5%-ánál zár; az eventenkénti cap a moneyline ledgerben nem köt, mert 56 tipp 56 külön event.

A szám: a cap nélküli 2% kar p95 drawdownja 36,10%, a napi 5%-os capé 28,94%; medián végállapot 0,881 kontra 0,951. A quarter-Kelly 2%-os cap mellett ugyanerre a plafonra telítődik: p95 drawdown 36,29%, napi 5%-os cap mellett 28,81%. A különbség a 30 napos negatív mintán diagnosztika, nem általános policybizonyíték.

Mi cáfolná: portfólió-optimalizálás, amely bizonyítja, hogy a közös kimenetek mellett a cap sosem köt és nem csökkenti a tail risket.

A kérdés a korrelált non-ML portfólió és az accepted-fill napló nélkül nyitott marad.

Kapcsolódik: B11.3, B12.5.

Forrás: E44; T13 policy-spec.

B11.5 Mennyi a helyes bankroll-frakció?

Fok: ? ·

Válasz egy mondatban: Nem tudjuk; a 10/100 dolláros unit konfiguráció, nem optimalizált bankrollarány.

Miért kérdeztük: abszolút tét csak bankrollhoz és veszteségtűréshez képest értelmes.

Bankrollkérdésre az egyedi fogadás várható értéke nem elég, mert az egyidejű map-, handicap- és total pozíciók ugyanabból a series-kimenetből fizetnek. A veszteségsor, a napi exposure, a fill-hiány és a stake-policy együtt alakítja a drawdownt és a ruin kockázatát. A hiányzó válasz ezért nem egy képlet hiánya: közös payoff-mátrix, blokkos időreplay, költségmodell és előre rögzített induló bankroll kell hozzá.

Mit futtattunk: 0,25%, 0,5%, 1% és 2% flat frakciókat ugyanazon 56 graded forward tippen, napblokkos bootstrapban. Utility- és veszteségtűrési célfüggvényt nem deklaráltunk, ezért a rács nem választhat „helyes” frakciót.

A szám: medián végállapot rendre 0,986, 0,971, 0,941, 0,881; a legacy-scale counterfactual 0,957, a 2%-ra capelt quarter-/half-Kelly 0,883/0,881. A Kelly-karok szinte minden kiválasztott soron elérik a 2%-os plafont, ezért ezen a kis, negatív mintán nem azonosítanak jobb frakciót. A 95%-os tartományok mind szélesek. Box unit 10 USD, dev unit 100 USD; bankroll és elfogadott drawdown-limit továbbra sincs deklarálva.

Mi cáfolná: előre megadott utility/ruin limitből levezetett és forward-validált frakció.

A kérdés a deklarált veszteségtűrés és független forward sample nélkül nyitott marad.

Kapcsolódik: B12.4, B12.7.

Forrás: E44, run_bankroll_risk_simulation.py; paper_pnl.py, box config.

B12 — Döntés: hogyan lesz az árból tét

Itt a legnagyobb a szakadék aközött, amit specifikáltunk, és amit mérünk: a T13 árazási létra és a három tétosztály papíron megvan, a kódban a legacy_units(p) fut, és a kettő közti különbséget soha nem mértük.

B12.A A lánc, ahogy specifikálva van

1. ÁR            p  (a pontárból)
2. EDGE          edge = p · odds − 1        ← ITT CSAK A PONT-p SZÁMÍT
3. TÉTOSZTÁLY    robust_value / uncertain_value / exploration
4. NYERS KELLY   f* = (p·(odds−1) − (1−p)) / (odds−1)
5. HAIRCUT       applied = f* · market_reliability · lineup_reliability
6. CAP           meccs-szintű portfólió-plafon (a map-piacok erősen korreláltak)
7. TÉT           stake = bankroll · applied,  minimum/maximum limittel

Ebből ma a 2. és a 7. fut — legacy_units(p) alapon. A fejlesztői ág UNIT_USD = 100, a július 18-i Linux-visszaállítás UNIT_USD = 10 bázistéttel fut; a 3–6. lépés specifikálva van és nincs megépítve.

B12.B Miért nem az eloszlás dönti el, hogy fogadunk-e

Kockázatsemleges várható értékben E[EV] a p átlagát használja — tehát ha a p-t bizonytalanság miatt eltolnám, rosszabb átlagot kapnék. Ezt meg is mértük: a σ-val zsugorított ár monoton rosszabb (β=1 → 0,5636 … β=∞ → 0,5567).

A szórás nem azt mondja meg, hogy fogadjunk-e, hanem hogy mennyit.

Három helyen dönt: (1) Kelly-tétméret — a Kelly konkáv a p-ben, a bizonytalanság csökkenti az optimális frakciót; (2) szelekció / winner's curse — oda fogadunk, ahol a p leginkább eltér a piactól, és épp ott a legvalószínűbb, hogy mi tévedünk; (3) kockázati limit.

B12.C A három tétosztály (a T13 végleges szerződése)

Soha nincs abstain. És egy kikötés: [0,1] envelope mellett uncertain_value nem adható — ott az „átlag" egy információtartalom nélküli posterior átlaga, a pozitív előjel numerikus zaj. Ilyenkor exploration.

B12.D Ami ma tényleg fut

B12.E A kérdések

A B12.3 a befagyasztott szerződés egyetlen még élő érve, és soha nem mértük. Ha a σ-ra árazás jobb loglosst ad és rosszabb P&L-t, a szerződésnek igaza volt, csak rossz okból. Ha jobb P&L-t is ad, a szerződés lezárható.

Kilenc kérdésből hat ?. Itt maradt a legtöbb empirikusan nyitott döntés — miközben ezen a lépcsőn dől el, hogy keresünk-e pénzt.

B12.1 Jobb-e a szórás-skálázott Kelly a laposnál?

Fok: ? ·

Válasz egy mondatban: Nem tudjuk; a külön uncertainty-fej még nem zöld, és nincs előre regisztrált forward stake-összevetés.

Miért kérdeztük: a bizonytalan p mellett a teljes Kelly túl agresszív.

Tétkérdésnél ugyanaz a pozitív modell-edge többféle pénzügyi eredményt adhat a stake, a cap, a korreláció és a költség miatt. Retrospektív, újraszámolt tipphalmazon nem választható ki policy, mert maga a kiválasztás is változhat a modellár apró elmozdulására. Az összevetéshez ugyanazon döntéskori quote-on fagyasztott karok, accepted fill, fee-net payoff, közös bankrollút és series- illetve nap-szintű exposure napló szükséges.

Mit futtattunk: — (nem futott érvényes döntési kar).

A szám: — (nem futott).

Mi cáfolná: azonos kiválasztásokon flat/fractional/σ-haircut karok nettó growth, drawdown és ruin összevetése.

A kérdőjel nem azt jelenti, hogy nincs implementáció vagy nincs vélemény, hanem azt, hogy a jelenlegi artifactok nem különítik el a versengő magyarázatokat érvényes mintán. A lezáró futás előtt rögzíteni kell a kontrollt, az elsődleges metrikát, a minimum független elemszámot, a cutoff-szerződést és a döntési küszöböt. Addig a rendszer fail-closed vagy shadow állapotban marad; terv, kód, nyers coverage vagy utólag kiválasztott legjobb kar nem emeli a fokot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B8, B11.

Forrás: szórásbecslés-spec M7.

B12.2 Hol legyen az edge-küszöb?

Fok: D ·

Válasz egy mondatban: Nem tudjuk; a 0,06/0,10/0,17 küszöbök post-hoc dashboard-szeletek, nem validált döntési határok.

Miért kérdeztük: a küszöb egyszerre változtatja a mintát, a winner's curse-t és a volument.

Tétkérdésnél ugyanaz a pozitív modell-edge többféle pénzügyi eredményt adhat a stake, a cap, a korreláció és a költség miatt. Retrospektív, újraszámolt tipphalmazon nem választható ki policy, mert maga a kiválasztás is változhat a modellár apró elmozdulására. Az összevetéshez ugyanazon döntéskori quote-on fagyasztott karok, accepted fill, fee-net payoff, közös bankrollút és series- illetve nap-szintű exposure napló szükséges.

Mit futtattunk: történeti replay több küszöbön, előregisztráció nélkül.

A szám: három aktív küszöb van, de egyikhez sincs érvényes nettó CI.

Mi cáfolná: egy előre fagyasztott elsődleges küszöb és külön exploratory rács új forward mintán.

A D fok tudatos figyelmeztetés: a szám elhasznált holdoutból, utólag nyitott karból vagy retrospektív replayből jön. Leírhatja, miért született egy hipotézis és melyik irányt érdemes újramérni, de confirmatory állításra, modellválasztásra vagy promotionre nem hivatkozható. A fokot ugyanazon szelet új paraméterezése nem javítja; csak előre regisztrált, érintetlen naptári minta és változatlan döntési szabály adhat új bizonyítékot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B9.3, B13.1.

Forrás: paper-P&L modulok.

B12.3 A σ-ra árazás rosszabb fogadást ad-e?

Fok: ? — nyitott kérdés, mert hiányzik az érvényes futás.

Válasz egy mondatban: Nem tudjuk: a σ javíthatja az átlagos pontárat, miközben a kiválasztott fogadások szélső farkában ronthat, de ehhez még nincs döntéskori, kétkarú nettó P&L-mintánk.

Miért kérdeztük. A proper score minden meccset értékel, a fogadási policy viszont éppen azokat a sorokat választja ki, ahol a modell és a piac legjobban eltér. Emiatt egy loglossban jobb σ-árazás is lehet pénzben rosszabb, ha a legnagyobb látszólagos edge-ek valójában a bizonytalan csapatokon keletkeznek. Ez a teszt dönti el, maradjon-e a σ a pontárban, vagy csak az intervallumot és a tétet vezérelje.

Mit futtattunk. — (nem futott)

A szám. — (nem futott)

Mi cáfolná. Előre be kell fagyasztani ugyanazon artifact két árkarját — az egyikben σ-val, a másikban σ nélkül — és ugyanazon döntéskori, végrehajtható quote-okon, azonos fee/slippage és tétpolicy mellett append-only forward eredményt gyűjteni. A jelenlegi kapu minimum 100 graded, független esemény; eseményszintű bootstrap-CI-vel kell összevetni a nettó ROI-t és mellette a CLV-t. Ha a σ-kar nettó eredménye nem rosszabb, a „σ jobb score, de rosszabb bet” állítás megdől.

Kapcsolódik. B4.4 (σ az árban) · B5.4 (σ-alapú zsugorítás megdőlt) · B8 (szórásfej) · D.4 (logloss nem pénz) · B13 (végrehajtható ár és fill).

Forrás: KONSZOLIDACIO_2026-07-30.md §5.1–§5.3: az akkori történeti pillanatképben 79 független snapshotból 21 volt graded, de a régi sorokból hiányzik a döntéskori feature-vektor + odds + mindkét σ-kar + outcome együttes metszete. A forward_lineup_v3 az új, használható sorokat folyamatosan gyűjti; minimumkapuja 100 graded esemény. Kézzel másolt élő számláló szándékosan nincs ebben a statikus dokumentumban. A mindenkori health count forrása a processed/odds/fresh_watch/shadow_models/forward/lineup_fallback/forward_grading_report.json; lásd D.6.14.

B12.4 Jobb-e a fractional Kelly a legacy_units-nál?

Fok: ? ·

Válasz egy mondatban: Nem tudjuk; a legacy képlet valós tipstertétekből lett visszafejtve, nem a mostani modellre optimalizálva.

Miért kérdeztük: Kelly az oddsot és edge-et is használja, a legacy csak p-t.

Tétkérdésnél ugyanaz a pozitív modell-edge többféle pénzügyi eredményt adhat a stake, a cap, a korreláció és a költség miatt. Retrospektív, újraszámolt tipphalmazon nem választható ki policy, mert maga a kiválasztás is változhat a modellár apró elmozdulására. Az összevetéshez ugyanazon döntéskori quote-on fagyasztott karok, accepted fill, fee-net payoff, közös bankrollút és series- illetve nap-szintű exposure napló szükséges.

Mit futtattunk: E44-ben ugyanazon 56 graded forward jelen blokkos counterfactual készült legacy-scale, quarter-Kelly és half-Kelly karral; emellett 98 aktuális shadow orderhez 490 append-only tétkar fagyott be későbbi forward gradingre. Accepted fill egyikben sincs.

A szám: legacy 0,143+1,286p; korábbi visszafejtés R²=0,88, corr(scale,p)=0,94, corr(scale,edge)=−0,03. A kis forward replay medián végállapota legacy-scale 0,957, quarter-Kelly-cap 0,883, half-Kelly-cap 0,881; ez a megfigyelt −10,48% ROI miatt csak stresszdiagnosztika, nem Kelly-ellenes verdikt.

Mi cáfolná: azonos betek mellett fractional Kelly jobb log-growth és elfogadhatóbb drawdown.

A kérdőjel nem azt jelenti, hogy nincs implementáció vagy nincs vélemény, hanem azt, hogy a jelenlegi artifactok nem különítik el a versengő magyarázatokat érvényes mintán. A lezáró futás előtt rögzíteni kell a kontrollt, az elsődleges metrikát, a minimum független elemszámot, a cutoff-szerződést és a döntési küszöböt. Addig a rendszer fail-closed vagy shadow állapotban marad; terv, kód, nyers coverage vagy utólag kiválasztott legjobb kar nem emeli a fokot.

Kapcsolódik: B11, B12.7.

Forrás: E44; run_bankroll_risk_simulation.py; build_forward_staking_arms.py; STATE_OF_PLAY.

B12.5 Számít-e a meccsszintű portfólió-cap?

Fok: ? ·

Válasz egy mondatban: Biztosan köti a kockázatot, de hatását nem mértük.

Miért kérdeztük: ugyanazon PMF több piaca egy közös végkimenetre fizet.

Tétkérdésnél ugyanaz a pozitív modell-edge többféle pénzügyi eredményt adhat a stake, a cap, a korreláció és a költség miatt. Retrospektív, újraszámolt tipphalmazon nem választható ki policy, mert maga a kiválasztás is változhat a modellár apró elmozdulására. Az összevetéshez ugyanazon döntéskori quote-on fagyasztott karok, accepted fill, fee-net payoff, közös bankrollút és series- illetve nap-szintű exposure napló szükséges.

Mit futtattunk: — (nem futott).

A szám: ma nincs cap.

Mi cáfolná: event-clusterelt replayben a cap sem drawdownt, sem ruin-kvantiliseket nem javítana.

A kérdőjel nem azt jelenti, hogy nincs implementáció vagy nincs vélemény, hanem azt, hogy a jelenlegi artifactok nem különítik el a versengő magyarázatokat érvényes mintán. A lezáró futás előtt rögzíteni kell a kontrollt, az elsődleges metrikát, a minimum független elemszámot, a cutoff-szerződést és a döntési küszöböt. Addig a rendszer fail-closed vagy shadow állapotban marad; terv, kód, nyers coverage vagy utólag kiválasztott legjobb kar nem emeli a fokot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B11.3, B11.4.

Forrás: T13 specifikáció.

B12.6 Szétválik-e a három tétosztály a kimenetben?

Fok: ? ·

Válasz egy mondatban: Nem tudjuk; a schema és shadow osztályozás létezik, de accepted-fill forward eredmény nincs.

Miért kérdeztük: ha a robust/uncertain/exploration eredménye azonos, az osztályok nem informálnak.

Tétkérdésnél ugyanaz a pozitív modell-edge többféle pénzügyi eredményt adhat a stake, a cap, a korreláció és a költség miatt. Retrospektív, újraszámolt tipphalmazon nem választható ki policy, mert maga a kiválasztás is változhat a modellár apró elmozdulására. Az összevetéshez ugyanazon döntéskori quote-on fagyasztott karok, accepted fill, fee-net payoff, közös bankrollút és series- illetve nap-szintű exposure napló szükséges.

Mit futtattunk: — (nem futott érett mintán).

A szám: az első shadow batchben robust_value 0, uncertain_value 40, exploration 20; ez szerkezeti [0,1] envelope-hatás.

Mi cáfolná: legalább 100 lezárt esemény osztályonkénti nettó CLV/ROI és kalibrációval.

A kérdőjel nem azt jelenti, hogy nincs implementáció vagy nincs vélemény, hanem azt, hogy a jelenlegi artifactok nem különítik el a versengő magyarázatokat érvényes mintán. A lezáró futás előtt rögzíteni kell a kontrollt, az elsődleges metrikát, a minimum független elemszámot, a cutoff-szerződést és a döntési küszöböt. Addig a rendszer fail-closed vagy shadow állapotban marad; terv, kód, nyers coverage vagy utólag kiválasztott legjobb kar nem emeli a fokot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B8.1, B13.3.

Forrás: forward shadow report.

B12.7 Mennyi a helyes bázistét?

Fok: ? ·

Válasz egy mondatban: Nem tudjuk; a bázistét ma gépenként eltérő konfiguráció és nincs bankrollhoz kötve.

Miért kérdeztük: ugyanaz a unit tízszeres dollárkockázatot jelenthet.

Tétkérdésnél ugyanaz a pozitív modell-edge többféle pénzügyi eredményt adhat a stake, a cap, a korreláció és a költség miatt. Retrospektív, újraszámolt tipphalmazon nem választható ki policy, mert maga a kiválasztás is változhat a modellár apró elmozdulására. Az összevetéshez ugyanazon döntéskori quote-on fagyasztott karok, accepted fill, fee-net payoff, közös bankrollút és series- illetve nap-szintű exposure napló szükséges.

Mit futtattunk: — (nem futott).

A szám: Linux box 10 USD/unit, fejlesztői ág 100 USD/unit.

Mi cáfolná: deklarált bankroll, utility/ruin limit és ebből levezetett, stressztesztelt frakció.

A kérdőjel nem azt jelenti, hogy nincs implementáció vagy nincs vélemény, hanem azt, hogy a jelenlegi artifactok nem különítik el a versengő magyarázatokat érvényes mintán. A lezáró futás előtt rögzíteni kell a kontrollt, az elsődleges metrikát, a minimum független elemszámot, a cutoff-szerződést és a döntési küszöböt. Addig a rendszer fail-closed vagy shadow állapotban marad; terv, kód, nyers coverage vagy utólag kiválasztott legjobb kar nem emeli a fokot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B11.1, B11.5.

Forrás: runtime és paper_pnl.py.

B12.8 Jobb-e a valószínűség-arányos tét a legacynél?

Fok: D ·

Válasz egy mondatban: Retrospektíven vizsgáltuk, de a kiválasztás azonos és az érvényes forward minta hiánya miatt nincs döntő fölény.

Miért kérdeztük: az M1D másképp osztja el a pénzt ugyanazon tippeken.

Tétkérdésnél ugyanaz a pozitív modell-edge többféle pénzügyi eredményt adhat a stake, a cap, a korreláció és a költség miatt. Retrospektív, újraszámolt tipphalmazon nem választható ki policy, mert maga a kiválasztás is változhat a modellár apró elmozdulására. Az összevetéshez ugyanazon döntéskori quote-on fagyasztott karok, accepted fill, fee-net payoff, közös bankrollút és series- illetve nap-szintű exposure napló szükséges.

Mit futtattunk: M1 legacy és dinamikus sizing paper-replay.

A szám: a sizing nem változtat CLV-t vagy egyunites ROI-t, csak dollár-P&L-t és drawdownt; megbízható forward döntési szám nincs.

Mi cáfolná: azonos accepted fill sorokon stabil jobb log-growth kisebb tail risk mellett.

A D fok tudatos figyelmeztetés: a szám elhasznált holdoutból, utólag nyitott karból vagy retrospektív replayből jön. Leírhatja, miért született egy hipotézis és melyik irányt érdemes újramérni, de confirmatory állításra, modellválasztásra vagy promotionre nem hivatkozható. A fokot ugyanazon szelet új paraméterezése nem javítja; csak előre regisztrált, érintetlen naptári minta és változatlan döntési szabály adhat új bizonyítékot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B12.4, B11.2.

Forrás: paper_pnl_dynamic.py, MODELING_IDEAS.

B12.9 Segít-e a σ-emelt edge-küszöb?

Fok: D ·

Válasz egy mondatban: A régi replayben javult a kijelzett Poly CLV, de ugyanaz a mid/seed/fee hiba érvényteleníti, mint az alap gate-et.

Miért kérdeztük: a magas-σ marginális fogadások eldobása kezelheti a winner's curse-t.

Tétkérdésnél ugyanaz a pozitív modell-edge többféle pénzügyi eredményt adhat a stake, a cap, a korreláció és a költség miatt. Retrospektív, újraszámolt tipphalmazon nem választható ki policy, mert maga a kiválasztás is változhat a modellár apró elmozdulására. Az összevetéshez ugyanazon döntéskori quote-on fagyasztott karok, accepted fill, fee-net payoff, közös bankrollút és series- illetve nap-szintű exposure napló szükséges.

Mit futtattunk: M4 edge+max(0,σ−0,10) retrospektív kar.

A szám: körülbelül 20% shaky+marginális bet kiesett; érvényes ask-alapú nettó hatás nincs.

Mi cáfolná: előre regisztrált M4 és base append-only forward összevetése.

A D fok tudatos figyelmeztetés: a szám elhasznált holdoutból, utólag nyitott karból vagy retrospektív replayből jön. Leírhatja, miért született egy hipotézis és melyik irányt érdemes újramérni, de confirmatory állításra, modellválasztásra vagy promotionre nem hivatkozható. A fokot ugyanazon szelet új paraméterezése nem javítja; csak előre regisztrált, érintetlen naptári minta és változatlan döntési szabály adhat új bizonyítékot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B12.1, B13.1.

Forrás: STATE_OF_PLAY uncertainty, audit banner.

B13 — Végrehajtás

B13.1 Pozitív-e a CLV?

Fok: X ·

Válasz egy mondatban: A korábbi pozitív állítás érvénytelen; végrehajtható askon a vizsgált részhalmaz negatív volt.

Miért kérdeztük: CLV volt a go-live fő kapuja. A régi dashboard öt modellformán is pozitív, látszólag szignifikáns CLV-t mutatott, ezért ez közvetlenül élesítési döntést változtatott volna. Az audit során kiderült, hogy az öt ledger erősen korrelált, a belépő mid/seed volt, a fee hiányzott, és a replay visszamenőleg újraválaszthatta a beteket. Ilyen körülmények között a pozitív szám nem óvatos becslés, hanem érvénytelen célmérés.

Mit futtattunk: seed/mid audit, ask-részhalmaz és teljes grading.

A szám: ask CLV −4,2%, fee után −5,9%; a teljesebb gradinggel a forward CLV negatívba fordult.

Mi cáfolná: új, append-only ask+volume, fee-net pozitív CI. Legalább 200 előre naplózott, független series kell döntéskori askkal, elérhető volumennel, accepted/fill státusszal és closing referenciával. A verdikt csak akkor fordulhat, ha a fee- és slippage-net CLV alsó bootstrap-határa pozitív, a log-growth nem egyetlen nagy nyereményből jön, és minden hiányzó quote fail-closed marad.

Az X a kipróbált megvalósítást és a fenti, szűk állítást vonja vissza; nem bizonyítja, hogy az egész ötletcsalád minden lehetséges formája értéktelen. Új változat csak a leírt cáfolati protokollal, előre fagyasztott karon és érintetlen időszakon nyitható ki. Ugyanannak az elhasznált szeletnek új paraméterrel történő ismételt megnyitása nem számít új bizonyítéknak.

Kapcsolódik: B9.6, B10.1.

Forrás: STATE_OF_PLAY 2026-07-09 audit.

B13.2 Mekkora a díj és a csúszás?

Fok: ? ·

Válasz egy mondatban: A Poly taker fee körülbelül 1,8%, de teljes venue×méret slippage görbét nem mértünk.

Miért kérdeztük: a vékony edge-et a költség könnyen elviszi.

Végrehajtási kérdésnél a modell által látott quote, a beküldött order és a tényleges fill három külön állapot. A hiányzó ask, a kis depth, a részleges teljesülés vagy a void úgy ronthatja a nettó eredményt, hogy az elméleti edge változatlan. Ezért csak append-only order-életciklus, bid/ask/volume snapshot, fee, slippage és teljes reconciliation alapján lehet CLV-ről, fill-arányról vagy likviditásról állítani.

Mit futtattunk: — (fee stressz van, tényleges fill-alapú slippage nincs).

A szám: audit fee-korrekció −1,7 pp körüli további CLV-romlást adott.

Mi cáfolná: orderbook-depth és actual fill alapján méretfüggő költségtábla.

A kérdőjel nem azt jelenti, hogy nincs implementáció vagy nincs vélemény, hanem azt, hogy a jelenlegi artifactok nem különítik el a versengő magyarázatokat érvényes mintán. A lezáró futás előtt rögzíteni kell a kontrollt, az elsődleges metrikát, a minimum független elemszámot, a cutoff-szerződést és a döntési küszöböt. Addig a rendszer fail-closed vagy shadow állapotban marad; terv, kód, nyers coverage vagy utólag kiválasztott legjobb kar nem emeli a fokot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B13.3, B13.5.

Forrás: betting roadmap T0.1.

B13.3 Mekkora a fill-arány?

Fok: ? ·

Válasz egy mondatban: Nem tudjuk; a shadow orderek not_submitted, actual fill nincs.

Miért kérdeztük: quote megléte nem garantál teljesülést vagy teljes méretet.

Végrehajtási kérdésnél a modell által látott quote, a beküldött order és a tényleges fill három külön állapot. A hiányzó ask, a kis depth, a részleges teljesülés vagy a void úgy ronthatja a nettó eredményt, hogy az elméleti edge változatlan. Ezért csak append-only order-életciklus, bid/ask/volume snapshot, fee, slippage és teljes reconciliation alapján lehet CLV-ről, fill-arányról vagy likviditásról állítani.

Mit futtattunk: — (nem volt order submission).

A szám: accepted fill sor 0; a korábbi 38-ból 30-nál pre-game ask sem volt.

Mi cáfolná: kis tétű vagy venue API-s accepted/rejected/partial napló, 100%-os accountinggal.

A kérdőjel nem azt jelenti, hogy nincs implementáció vagy nincs vélemény, hanem azt, hogy a jelenlegi artifactok nem különítik el a versengő magyarázatokat érvényes mintán. A lezáró futás előtt rögzíteni kell a kontrollt, az elsődleges metrikát, a minimum független elemszámot, a cutoff-szerződést és a döntési küszöböt. Addig a rendszer fail-closed vagy shadow állapotban marad; terv, kód, nyers coverage vagy utólag kiválasztott legjobb kar nem emeli a fokot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B13.2, B13.4.

Forrás: promotion gate report.

B13.4 Teljes-e a ledger-elszámolás?

Fok: X ·

Válasz egy mondatban: Nem; a régi Poly „forward” replay felülírható és nem követi az order életciklusát.

Miért kérdeztük: hiányzó vagy átírt sor szelekciós torzítást okoz. Ha a modell újrafitje után a replay újraszámolja, mely fogadás „tüzelt volna”, a vesztes vagy határeset sorok eltűnhetnek a múltból, miközben a megmaradt rekordok forwardnak látszanak. Az order életciklusa nélkül azt sem tudjuk, hogy a javaslatot beküldtük-e, részben töltődött-e vagy void lett. Ez a P&L nevezőjét és a coverage-et egyszerre teszi bizonytalanná.

Mit futtattunk: ledger-lineage audit.

A szám: 3% p-változás a fired betek körülbelül 20%-át utólag un-fire-olhatta; a tip-forward ledger csak Tippmixet fedett.

Mi cáfolná: byte-stabil event+market kulcs, submitted/accepted/fill/settled reconciliation 100%-ban. A következő száz ordernél minden állapotváltás új append-only sor legyen, az eredeti decision snapshot módosítása nélkül. Ugyanazon inputmanifest ismételt futása pontosan ugyanazt a kiválasztási halmazt és elszámolást adja; bármely eltűnt, duplikált vagy utólag átírt order fenntartja az X fokot.

Az X a kipróbált megvalósítást és a fenti, szűk állítást vonja vissza; nem bizonyítja, hogy az egész ötletcsalád minden lehetséges formája értéktelen. Új változat csak a leírt cáfolati protokollal, előre fagyasztott karon és érintetlen időszakon nyitható ki. Ugyanannak az elhasznált szeletnek új paraméterrel történő ismételt megnyitása nem számít új bizonyítéknak.

Kapcsolódik: B14.8, A.6/3.

Forrás: MODELING_IDEAS T0.2.

B13.5 Mennyi likviditás van a mi tétünkhöz?

Fok: ? ·

Válasz egy mondatban: Nem tudjuk; az orderbook korábbi tokenlimitje és a seed piacok miatt nincs teljes depth-panel.

Miért kérdeztük: az ask csak kis mennyiségre lehet elérhető.

Végrehajtási kérdésnél a modell által látott quote, a beküldött order és a tényleges fill három külön állapot. A hiányzó ask, a kis depth, a részleges teljesülés vagy a void úgy ronthatja a nettó eredményt, hogy az elméleti edge változatlan. Ezért csak append-only order-életciklus, bid/ask/volume snapshot, fee, slippage és teljes reconciliation alapján lehet CLV-ről, fill-arányról vagy likviditásról állítani.

Mit futtattunk: — (nincs stake-size impact curve).

A szám: a logger 150 tokenes capje helyett körülbelül 1 750 outcome token kellene teljes ciklushoz.

Mi cáfolná: minden kiválasztott piacon depth snapshot és szimulált/valós average fill price.

A kérdőjel nem azt jelenti, hogy nincs implementáció vagy nincs vélemény, hanem azt, hogy a jelenlegi artifactok nem különítik el a versengő magyarázatokat érvényes mintán. A lezáró futás előtt rögzíteni kell a kontrollt, az elsődleges metrikát, a minimum független elemszámot, a cutoff-szerződést és a döntési küszöböt. Addig a rendszer fail-closed vagy shadow állapotban marad; terv, kód, nyers coverage vagy utólag kiválasztott legjobb kar nem emeli a fokot.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B9.5, B13.2.

Forrás: MODELING_IDEAS T0.1.

B14 — Üzemeltetés

B14.1 Reprodukálható-e egy futás a manifestből?

Fok: B ·

Válasz egy mondatban: Az új shadow futások nagy része igen, a teljes production lánc még nem: több manifest csak outputot, nem minden inputot hash-el.

Miért kérdeztük: dirty worktree és változó processed/ mellett a commit nem elég.

Üzemeltetési állításnál a sikeres futás nem azonos a helyes és reprodukálható futással. Branch, artifact, inputhash, runtime, token és source timestamp mind változhat úgy, hogy a dashboard továbbra is elkészül. A bizonyítékhoz gépfüggetlen manifest, golden predikció, hard-fail guard és rerun-paritás kell; az output mtime-ja vagy egyetlen helyi zöld futás nem zárja ki a néma adat- és környezeteltérést.

Mit futtattunk: execution manifest, artifact/source hash és rerun auditok.

A szám: több final riport bitközeli vagy egzakt reprodukciót adott, de az E18–E20 inputvintage-e nem volt önmagából azonosítható.

Mi cáfolná: tiszta gépen egy manifestből minden output egyezne.

A B fok azt jelzi, hogy a jel több szeletből vagy független reprodukcióból ismétlődött, de a teljes production és pénzügyi lánc még nem feltétlenül zöld. Az állítás csak a megnevezett targetre, populációra és metrikára vihető át. Promotion előtt külön forward adat, döntéskori provenance, kalibráció és végrehajtási ellenőrzés kell; egy új, ellentétes és érvényes adatvintage a fokot visszanyithatja.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: D.3, D.6.10.

Forrás: first-batch manifest, konszolidáció.

B14.2 Verzió-stabil-e a telepített artifact?

Fok: X ·

Válasz egy mondatban: Nem bizonyított; az artifact sklearn 1.6.1 alatt készült, a runtime 1.9.0, natív export és bitparitás nélkül.

Miért kérdeztük: pickle kompatibilitás figyelmeztetésen túl predikcióeltérés is lehet. A Python pickle a könyvtári objektum belső szerkezetét is sorosítja, ezért egy minor verzióváltás nem csak betöltési hibát, hanem csendes default- vagy numerikus eltérést is okozhat. Két gép ugyanazzal a fájlhashsel így eltérő boardárat adhat. A production szerződésnek a predikciót, a kalibrációt és a feature-sorrendet kell azonosítania, nem csupán azt, hogy a fájl megnyílt.

Mit futtattunk: környezet- és artifact-metadata audit.

A szám: két külön sklearn minor-vonal; teljes portable parity gate hiányzik. A 2026-08-02-i forward shadow futásban a régi TwinTower pickle-ből hiányzott az új linear_weight mező, ezért a scorer először hard-failt adott. A kompatibilitási út zéró skipet használ — ez az eredeti, skip-előtti architektúrát reprodukálja — és unit teszt védi, de cross-runtime golden parityt nem helyettesít.

Mi cáfolná: natív XGBoost export, verziózott calibrator és az összes golden sor bitparitása. A portable csomagot mindkét tényleges runtime-ban legalább 100 golden soron kell futtatni, külön raw margin-, probability- és post-calibration ellenőrzéssel. A max eltérés legyen ≤1e-12, a feature schema és könyvtárverzió kerüljön manifestbe, és inkompatibilitáskor a scorer hard-failt adjon; puszta sikeres unpickle nem elég.

Az X a kipróbált megvalósítást és a fenti, szűk állítást vonja vissza; nem bizonyítja, hogy az egész ötletcsalád minden lehetséges formája értéktelen. Új változat csak a leírt cáfolati protokollal, előre fagyasztott karon és érintetlen időszakon nyitható ki. Ugyanannak az elhasznált szeletnek új paraméterrel történő ismételt megnyitása nem számít új bizonyítéknak.

Kapcsolódik: B7.3, B14.6.

Forrás: T41/7, portable export report.

B14.3 Egyezik-e a két PandaSkill-adatút?

Fok: B ·

Válasz egy mondatban: A javított, azonos hashű generáción igen; a korábbi eltérés ns/us cutoff- és artifact-keverési hiba volt.

Miért kérdeztük: azonos mezőnév alatt teljesen más rating állt.

Üzemeltetési állításnál a sikeres futás nem azonos a helyes és reprodukálható futással. Branch, artifact, inputhash, runtime, token és source timestamp mind változhat úgy, hogy a dashboard továbbra is elkészül. A bizonyítékhoz gépfüggetlen manifest, golden predikció, hard-fail guard és rerun-paritás kell; az output mtime-ja vagy egyetlen helyi zöld futás nem zárja ki a néma adat- és környezeteltérést.

Mit futtattunk: kézi provenance, F9 teljes dekompozíció és táblaközi audit.

A szám: 45 312 soron max közös feature-eltérés 1,42e−14; 19 ambiguus timestampű sor kiesett.

Mi cáfolná: új inputhashen >1e−9 eltérés.

A B fok azt jelzi, hogy a jel több szeletből vagy független reprodukcióból ismétlődött, de a teljes production és pénzügyi lánc még nem feltétlenül zöld. Az állítás csak a megnevezett targetre, populációra és metrikára vihető át. Promotion előtt külön forward adat, döntéskori provenance, kalibráció és végrehajtási ellenőrzés kell; egy új, ellentétes és érvényes adatvintage a fokot visszanyithatja.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B1.5, D.6.4.

Forrás: final PandaSkill F9 report.

B14.4 Elhasznált-e a 755-ös holdout?

Fok: A ·

Válasz egy mondatban: Igen; legalább 63 értékelés és 60 külön prediction-vektor után csak fejlesztési benchmark.

Miért kérdeztük: ismételt választás implicit overfitting. Minden új kar, seed, featurecsomag és kalibrátor visszajelzést ad ugyanarról a 755 outcome-ról; a kutató ezt akkor is beépíti a következő ötletbe, ha formálisan nem azon tanít. Hatvan fölötti kiértékelésnél a legjobb szám várhatóan már a szelet zajához is alkalmazkodik. Ezért a holdout nem „kicsit gyengébb”, hanem funkciót váltott: hibakereső benchmark maradhat, megerősítő bizonyíték nem.

Mit futtattunk: holdout registry és teljes model inventory.

A szám: legacy_755 státusza development_only_contaminated, tiltott: model selection, promotion, confirmatory claim.

Mi cáfolná: nem cáfolható új futással; új, érintetlen időszak kell. A régi outcome-ok törlése, a kódtörténet elfelejtése vagy egy új random seed nem teszi érintetlenné ugyanazt a mintát. Új confirmatory státuszt csak előre lezárt protokoll után gyűlt naptári sorok kaphatnak, amelyeket a minimum n eléréséig nem nyitunk ki. A 755 ezután is development_only_contaminated marad.

Az A fok itt kizárólag a fenti, szűken megfogalmazott és a megadott mércén vizsgált állításra vonatkozik. Nem jelent automatikus production promotiont, bizonyított pénzügyi edge-et, más targetre való átvihetőséget vagy a teljes modellcsalád általános győzelmét. Ezekhez a kapcsolódó adat-, kalibrációs, végrehajtási és forward kapuknak külön, döntéskor rögzített bizonyítékot kell adniuk.

Kapcsolódik: B5.7, D.3.

Forrás: config/holdout_registry.json, E4/E12.

B14.5 Van-e néma újratanítás?

Fok: B ·

Válasz egy mondatban: Igen a legacy scorerben: artifact- vagy feature-eltérésnél taníthat és menthet explicit engedély nélkül.

Miért kérdeztük: így két gép és két ciklus más modellt szolgálhat.

Üzemeltetési állításnál a sikeres futás nem azonos a helyes és reprodukálható futással. Branch, artifact, inputhash, runtime, token és source timestamp mind változhat úgy, hogy a dashboard továbbra is elkészül. A bizonyítékhoz gépfüggetlen manifest, golden predikció, hard-fail guard és rerun-paritás kell; az output mtime-ja vagy egyetlen helyi zöld futás nem zárja ki a néma adat- és környezeteltérést.

Mit futtattunk: kódút-audit és retrain-hit ellenőrzés.

A szám: a Mac ellenőrzött artifactján 0 retrain-hit; a veszélyes fallback kódban létezik.

Mi cáfolná: hard fail alapértelmezés, csak --allow-train, és tesztelt no-write scorer.

A B fok azt jelzi, hogy a jel több szeletből vagy független reprodukcióból ismétlődött, de a teljes production és pénzügyi lánc még nem feltétlenül zöld. Az állítás csak a megnevezett targetre, populációra és metrikára vihető át. Promotion előtt külön forward adat, döntéskori provenance, kalibráció és végrehajtási ellenőrzés kell; egy új, ellentétes és érvényes adatvintage a fokot visszanyithatja.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: B14.2, B14.6.

Forrás: STATE_OF_PLAY §silent retrain.

B14.6 Egyeznek-e a gépek?

Fok: B ·

Válasz egy mondatban: Nem teljesen: a box visszaállított ágon és 10 dolláros unittal, a dev ág 100 dolláros unittal és további shadow kóddal fut.

Miért kérdeztük: azonos boardnév eltérő artifactot vagy tétet rejthet.

Üzemeltetési állításnál a sikeres futás nem azonos a helyes és reprodukálható futással. Branch, artifact, inputhash, runtime, token és source timestamp mind változhat úgy, hogy a dashboard továbbra is elkészül. A bizonyítékhoz gépfüggetlen manifest, golden predikció, hard-fail guard és rerun-paritás kell; az output mtime-ja vagy egyetlen helyi zöld futás nem zárja ki a néma adat- és környezeteltérést.

Mit futtattunk: branch, commit, artifact-date és konfiguráció összevetés.

A szám: box box-restore-20260718@b944aee; dev board-modell-odds-3types@c0b8ca1; unit 10 vs 100 USD.

Mi cáfolná: deployment manifestben azonos hash/config és golden predikció.

A B fok azt jelzi, hogy a jel több szeletből vagy független reprodukcióból ismétlődött, de a teljes production és pénzügyi lánc még nem feltétlenül zöld. Az állítás csak a megnevezett targetre, populációra és metrikára vihető át. Promotion előtt külön forward adat, döntéskori provenance, kalibráció és végrehajtási ellenőrzés kell; egy új, ellentétes és érvényes adatvintage a fokot visszanyithatja.

A következő futás manifestjének ezért a karok mellett az inputhash-t, az időhatárt, a független eseményszámot és minden kizárási okot is rögzítenie kell. Így a verdikt nemcsak újraszámolható, hanem később az is látszik, pontosan mely állításra és adatvintage-re volt érvényes.

Kapcsolódik: A.3, B14.2.

Forrás: 2026-07-31 deployment audit.

B14.7 Lejár-e csendben az OAuth/token?

Fok: X ·

Válasz egy mondatban: Igen; a Google token halála úgy állította meg a gradinget, hogy a regenerált dashboard továbbra is frissnek látszott.

Miért kérdeztük: az mtime nem adatfrissesség. A ciklus a régi adatból is új HTML-t tud generálni, ezért a dashboard fájlideje frissnek látszik, miközben a legutolsó graded esemény hetekkel korábbi. Korábban ezt operatív kényelmetlenségnek tekintettük, pedig közvetlen mintavesztést és hamis „várjuk a gate-et” állapotot okozott. A frissességet a legnagyobb source timestamp és a feldolgozott eseményszám alapján kell mérni, nem az output mtime-jából.

Mit futtattunk: ops-idővonal és max source timestamp audit.

A szám: a grading 2026-06-21 után hetekig állt; a korábbi gate n=38-on fagyott.

Mi cáfolná: service account vagy production OAuth, 48 órás staleness alarm és szándékos token-kill teszt. A tesztben a credentialt szándékosan érvényteleníteni kell: egy cikluson belül hangos hibát, nem friss dashboardot és nem-null exitet várunk. Helyreállítás után a pending sorok hiány nélkül feldolgozódjanak, és legalább 30 napos monitorozásban ne legyen néma staleness; csak ez zárná le az X-et.

Az X a kipróbált megvalósítást és a fenti, szűk állítást vonja vissza; nem bizonyítja, hogy az egész ötletcsalád minden lehetséges formája értéktelen. Új változat csak a leírt cáfolati protokollal, előre fagyasztott karon és érintetlen időszakon nyitható ki. Ugyanannak az elhasznált szeletnek új paraméterrel történő ismételt megnyitása nem számít új bizonyítéknak.

Kapcsolódik: A.5, D.6.6.

Forrás: betting roadmap T0.3.

B14.8 Append-only-e minden bemenet és döntés?

Fok: X ·

Válasz egy mondatban: Nem; új roster/info-state naplók append-onlyk, de több legacy latest/replay fájl felülíródik.

Miért kérdeztük: refit nem változtathatja meg a múltbeli kiválasztást. A forward fogadás definíciója az, hogy a döntés, az akkor ismert feature-vektor és az elérhető quote a kimenetel előtt rögzül. A latest és from-scratch replay út ezzel szemben új rostert, új modellt vagy új árat vihet ugyanarra a múltbeli eseményre. Így a teljesítmény észrevétlenül szelekciós backtestté válhat, még akkor is, ha a fájl neve forward ledger.

Mit futtattunk: lineage- és byte-stability audit.

A szám: a régi Poly replay 3% p-shiftnél a betek körülbelül 20%-át un-fire-olhatta. A 2026-08-02-i új futás 163 information state-ből 98 linkelt M12/M13 shadow ordert és 490 előregisztrált tétkart írt; 392 flat/Kelly kar aktív, 98 σ-haircut kar informatív live sáv hiányában blokkolt. Valódi beküldött vagy accepted fill sor 0.

Mi cáfolná: minden venue-ra stabil event+market key, első megjelenés fagyasztása és rerunban byte-identitás. Legalább 100 eseményen a decision, quote, model, roster-state és order-event külön append-only rekordot kapjon, egymás hashére hivatkozva. Ugyanazon manifest ismételt futása nem írhat át bájtot és nem változtathatja a fired halmazt; későbbi korrekció csak új, az előzőt érvénytelenítő sor lehet. A legacy időszak ettől még nem válik helyreállíthatóvá.

Az X a kipróbált megvalósítást és a fenti, szűk állítást vonja vissza; nem bizonyítja, hogy az egész ötletcsalád minden lehetséges formája értéktelen. Új változat csak a leírt cáfolati protokollal, előre fagyasztott karon és érintetlen időszakon nyitható ki. Ugyanannak az elhasznált szeletnek új paraméterrel történő ismételt megnyitása nem számít új bizonyítéknak.

Kapcsolódik: B13.4, D.3.

Forrás: MODELING_IDEAS T0.2, konszolidáció; shadow_forward_orders.py; build_forward_staking_arms.py; promotion-gate report.

C. A rendszer viselkedése

Nem kísérlet. A B azt gyűjti, hogy egy ötlet működik-e; ez azt, hogy a meglévő rendszer hogyan viselkedik. Nincs pass/fail, nincs kar — eloszlások, érzékenységek, bontások. Hangban ez a leggyakoribb kérdéstípus: „mennyit számít, ha kicserélnek valakit?"

Minden bejegyzés ugyanazt a nyolc mezőt használja, de a szükséges részletessége a mérés összetettségéhez igazodik.

Alszakaszonként a részletes bontás — pl. C.1.1 a faktorizáció és az ellenőrzése, C.1.5 a két ismert korábbi számítási hiba (a 0,25·Δlogit linearizálás 125 pp-t adott; a CSV a javítás előtti értéket írta ki).

C.1 Felállás-érzékenység

Fok: nem alkalmazható — leíró mérés; a C könyvben nincs pass/fail.

Válasz egy mondatban: A LOGIT3 szerint egy szék cseréje 50%-os alapárnál medián 3,41 százalékpontot mozdít, a szélső lineupok jóval többet.

Miért kérdeztük. A „roster csere” badge nem mondja meg, mennyire fontos a hír. Tudnunk kell, azonos-e az ár a lehetséges ötösök között, vagy a kezdő ismerete megfordíthatja a tippet. Ez érzékenységmérés, nem a lineup-aware modell minősítése.

Mit futtattunk. A script 278 csapat cutoff-helyes szereppooljaiból 41 196 ötöst képzett, majd a LOGIT3 rögzített együtthatóival a referenciaötöshöz viszonyított Δμ, Δσ és Δlogit értéket számolta. Hat ellenfél ellenőrizte a faktorizációt; a százalékpontot közös, 50%-os alapárnál mérte.

A szám. Egy székes csere medián elmozdulása 3,41 pp; az ilyen cserék 34,1%-a nagyobb 5 pp-nél, a maximum 21,60 pp. A Gen.G vizsgált lineupjainak teljes tartománya 47,61 pp; felfelé 0,00 pp, mert a referenciaötös már a pool legerősebb kombinációja. Egy ellenőrzött lineup-csere Δlogit = −0,542034 értéket adott mind a hat ellenfélnél: a logit-eltérés a modell additív alakjában ellenfélfüggetlen, de ugyanaz a logit-eltérés különböző alapáraknál nem azonos százalékpont-változás.

Mi cáfolná. Azonos artifact és cutoff-helyes pool reprodukciója, ha nem adná vissza a 41 196 sort vagy a fő kvantiliseket; a döntési olvasatot pedig olyan forward minta, ahol a bejelentett cserék tényleges ármozgása lényegesen kisebb.

Kapcsolódik. B2.1 (kezdőötös jósolhatósága) · B4.1 (seat-korrekció) · B12 (lineup- reliability és tét) · C.7 (döntési olvasat).

Forrás. src/lolbet/analysis/run_lineup_counterfactuals.py · processed/odds/fresh_watch/lineup_counterfactuals/all_lineups.csv · team_sensitivity.csv · E22/T62.

C.2 Roszter-jósolhatóság

Fok: nem alkalmazható ·

Válasz egy mondatban: A múltbeli modális ötös csak közepesen jósolja meg a következő kezdőt: exact-five medián 52,0%, szék-szint 71,8%.

Miért kérdeztük: ez adja a részleges lineup-posterior empirikus alapját és megmutatja, mekkora információ hiányzik bejelentés nélkül.

Mit futtattunk: csapat×szerep past-only profil az előző 20 meccsből, 2026-os csapatokon; minden célmeccs saját jövője ki volt zárva.

A szám: exact ötös átlag 49,5%, medián 52,0%; 37 csapat 20% alatt, 24 csapat legalább 80%-on; seat accuracy 71,8%.

Az eloszlás fontosabb az egyetlen 52%-os számnál. A lineup-posterior nem használhat minden csapatra azonos tömeget: stabil szervezetnél koncentrált, gyakran cserélő vagy kevés meccses csapatnál széles jelöltpool indokolt. A 71,8%-os seat accuracy azt is megmagyarázza, miért lehet hasznos a részleges feloldás anélkül, hogy kitalált ötöst gyártanánk. Ugyanakkor ez retrospektív, past-only viselkedésmérés; nem bizonyítja, hogy bármely élő forrás a döntés pillanatában jobb.

Mi cáfolná: azonos cutoff-szerződésű új időszak lényegesen eltérő eloszlása. A következő mérés ugyanazt a húszmeccses profilt használja, de csapat-, liga- és tier-bontásban is közöl konfidenciaintervallumot. Ha az exact medián tartósan 70% fölé vagy 35% alá kerül, a jelenlegi posterior-priorokat újra kell illeszteni.

Kapcsolódik: B2.1, B8.1, C.7.

Forrás: build_roster_profiles.py, E23.

C.3 Feature-fontosság

Fok: nem alkalmazható ·

Válasz egy mondatban: A production 79 mezőjéből szinte minden mért jel a hét PandaSkill mezőben van; a nyers gain arány félrevezető lehet.

Miért kérdeztük: fa-modelleknél egy ritkán használt feature nagy átlagos gainnel fontosnak látszhat, miközben teljes hozzájárulása kicsi.

Mit futtattunk: családonkénti nullázás, retrain feature-setek és gain/total_gain audit.

A szám: PandaSkill-család nullázása +0,03348 logloss-romlás, minden más család ≤+0,0004; a context gain-része egy nézetben 43,18%, total_gain szerint 3,68%. Három feature-re egyetlen fa sem hasadt.

🔴 És egy mérés, ami a σ-dominancia olvasatát átminősíti. A ps_team_sigma_diff total-gainje a teljes év-modell 63,51%-áról 23,09%-ra esik, ha a tanítást egyéves felezésű recency-vel súlyozzuk. Vagyis amit a modell „bizonytalanságként" használt, annak jó része idődrift volt: a rég nem játszó játékosok egyszerre bizonytalanabbak és elavultabb adatból származnak, a σ pedig mindkettővel korrelál. A σ ezután is pontár-feature marad (23% nem nulla), de a „bizonytalanság-vezérelt árazás" olvasat részben „elavult-adat-vezérelt" volt.

Ez általánosítható őrszabály: minden erős feature-nél meg kell kérdezni, nem csak az idő proxyja-e. A teszt egyszerű — súlyozz recency-vel, és nézd meg, mennyi marad a fontosságából. (Forrás: PS7_CONTEXT_TIME_REGIME_REPORT.md, E32.)

A nullázás sem végső oksági mérés, mert a többi korrelált feature részben átveheti a kivett mező szerepét; a retrain pedig új fa-struktúrát tanul. A két módszer együtt mégis erősebb képet ad, mint a beépített importance önmagában. A viselkedési következtetés az, hogy a 79 mezős production modell komplex felületet mutat, miközben a döntési jel sokkal kisebb mag köré koncentrálódik. Ez drift- és monitorozási szempontból is fontos: a gyenge családok hibája kevésbé látszik score-ban, de schema- vagy hiányhibát továbbra is okozhat.

Mi cáfolná: atomikus retrainben más család stabil, független gainje. Ehhez a családot PS7 fölé egyedül kell hozzáadni több rolling foldon, nem a 755 legjobb kombinációját kiválasztani. Pozitív pooled CI és legalább három azonos irányú év kellene.

Kapcsolódik: B4.10, B4.14, D.6.8.

Forrás: E2/E3/E5, summarize_gate_feature_importance.py.

C.4 Idődrift

Fok: nem alkalmazható ·

Válasz egy mondatban: A modell és a rosterkörnyezet gyorsan változik; ugyanazon jelöltek ára rövid idő alatt több tíz százalékpontot mozdulhat.

Miért kérdeztük: statikus holdout és egyszeri kalibráció nem reprezentálja automatikusan a következő hónapot.

Mit futtattunk: egymást követő időablakok, context-year ablation, decay-rács és lineup-snapshot érzékenység.

A szám: megfigyelt elmozdulás egy héten belül akár +31 pp; szomszédos ablakok rangkapcsolata Spearman −0,700; a decay egyik mérésben +0,0176, a tiszta D365 rolling gain +0,002097 LL.

A négy szám külön mechanizmust keverhet. A rosterpool frissülése megváltoztatja a seat-deltát; az új Oracle-adat átírja a múlt súlyát; a modell- vagy kalibrátorverzió ugyanazon feature-vektort is más árra képezheti. Ezért az árdriftet csak változatlan artifact- és inputhash mellett szabad „világdriftnek” nevezni. Operatívan minden boardárhoz first-seen, last-changed, model hash és information-state kell, különben a +31 pp okát utólag nem lehet felbontani. Az időtengelyt ezért nem egyetlen driftmutatóval, hanem adat-, modell-, kalibráció- és rosterkomponensre bontva kell monitorozni.

Mi cáfolná: hosszabb forward időszak stabil paraméterekkel és kalibrációval. Legalább nyolc egymást követő hét, változatlan artifact és előre rögzített driftküszöb kellene; a slope, ECE és rangsor CI-jének is stabil tartományban kell maradnia.

Kapcsolódik: B6, B7.6, B8.6.

Forrás: time-regime és decay riportok.

C.5 Kalibrációs viselkedés

Fok: nem alkalmazható ·

Válasz egy mondatban: A production Platt-intercept nem valódi live side-hatást, hanem listázási sorrendből származó +2,68 pp eltolást okoz.

Miért kérdeztük: az offline blue_result orientáció és a feed team1 sorrendje nem ugyanaz.

Mit futtattunk: swap-páros predikciók nyers és kalibrált komplementaritása, majd boardútvonal-ellenőrzés.

A szám: intercept 0,11348; nyers komplementaritási hiba 5,96e−8, Platt után átlag 4,07 pp; az első listázott csapat élő előnye 2,68 pp.

A 2,68 pp nem valódi blue-side hatásbecslés: ennyivel tolja átlagosan a live boardon az elsőként listázott csapatot az offline intercept. A strukturális hiba és a score-kérdés ezért különválik. Az offline blue-alapráta 0,538179 valódi, de a feed által adott left szlot nem azonos a blue oldallal (live_left_order_is_not_blue). A blue-oriented összevetés ezért olyasmit tud, amit az élő döntési út nem: aki ezt a −0,001293-as eredményt az intercept védelmére használja, döntéskor nem létező információval érvel. Az intercept eltávolítása helyreállítja a szimmetriát, de a slope-only refit nem következik ebből; az identity a vizsgált szeleten +0,005977 [+0,000458; +0,011874] LL-lel jobb volt nála. A biztonságos shadow összevetés így identity versus slope-only, nem automatikus slope-promotion. Külön reliability bontás kell a favorit-, közép- és longshot-sávokra is, mert azonos pooled logloss mellett az egyik kalibrátor a döntési küszöb közelében lényegesen rosszabb lehet. A boardon ezért az alkalmazott kalibrációs módnak és artifacthashnek is látszania kell.

Mi cáfolná: valódi side-ID-val ugyanilyen hatás, vagy slope-only után fennmaradó eltolás. A live feednek explicit blue/red oldalt kellene adnia, majd legalább 100 forward eseményen külön mérni a side-hatást és a listázási sorrendet. Feed-order interceptet semmilyen átlagos score-javulás nem igazol.

Kapcsolódik: B7.1, B14.3.

Forrás: E8/T42, E33, PRODUCTION_SLOPE_ONLY_CALIBRATION_REPORT.md.

C.6 Populáció és tier

Fok: nem alkalmazható ·

Válasz egy mondatban: A 2026-os adat 381 csapatot fed, de a 340 „main” címke döntő többsége csak default, nem pozitív tier-megállapítás.

Miért kérdeztük: akadémiai csapatokon a modell rosszabb, így a false-main szennyezi a réteges mérését.

Mit futtattunk: 2026-os csapat-, játékos- és match-populációs leltár a tier-classifier reason mezőivel.

A szám: 381 csapat, 2 501 játékos, 6 607 meccs; 34 academy, 7 challenger, 340 main; 110 játékos több tierben.

Mi cáfolná: 50 véletlen default-main kézi Leaguepedia-auditja alacsony false-main aránnyal.

Kapcsolódik: B7.5, B8.9.

Forrás: E24, classify_team_tier audit.

A 2026-os mezőny. 381 csapat játszott (az adat 2026-07-28-ig tart, tehát ~7 hónap), 2 501 játékossal, 6 607 meccsen. Ebből az utolsó 90 napban 322 (85%), az utolsó 30-ban 198 (52%) — a szezon során nagyjából felére szűkül az aktív mezőny.

Meccsszám szerint: 246 csapatnak van ≥20 meccse, 318-nak ≥6, és 63 csapat 1–5 meccsel jelenik meg. Ezekre a PandaSkill lényegében a kezdőpriort adja.

Tier-bontás. A besorolást a common/teams.py::classify_team_tier végzi:

110 játékos (4,4%) több tierben is játszott az évben — ez a fel-le mozgás, és pont ez teszi nehézzé a szétválasztást.

C.6.1 Mennyire megbízható a szétválasztás?

A besorolás három forrásból dől el, és a döntő többség a leggyengébből:

Vagyis a main nem pozitív megállapítás, hanem a jel hiánya. Ha egy feeder-csapat neve nem tartalmaz kulcsszót és nincs a kézi táblában, némán main lesz.

Öt gyanús eset a mai main halmazban, csak névminta alapján: 2 Massive, Frites Esports Club, NextGeneration Esports, Rising Gaming, Vitality Rising Bees. Ezek lehetnek valódi főcsapatok is — a lényeg, hogy nem tudjuk, és a rendszer nem is kérdezi.

Miért számít. Az akadémiai réteg minden mérésünkben gyengébb és rosszabbul kalibrált (K8: logloss 0,620142, ECE 0,139605), és a fallback-policyk ott buknak. Ha a 340 „main" között lapul néhány tucat feeder, akkor a main-réteg számai is szennyezettek — és a fő ↔ akadémia rétegzés, amire több verdikt épül, gyengébb, mint hisszük.

Ez egy nyitott (?) leíró kérdés. A következő lezáró mérés egy kézi mintavétel 50 véletlen main csapatból, Leaguepedia-ellenőrzéssel; ez adná meg a false-main arányt.

2026-08-02-i kibővített classifier-audit (E41). A teljes aktuális roster-snapshot 1 304 egyedi csapatentitását vizsgálva 1 111 kap kizárólag defaultból main címkét. Az öt forrás-ablation a 45 már kézzel ellenőrzött példán: all-main 9/45, name-only 21/45, context+name 31/45, relation+name 35/45, full classifier 45/45. Ez nem vak holdout — a kézi lista egy része a szabályok készítésében is részt vett —, ezért fixture-eredmény, nem 100%-os generalizáció.

A függetlenebb pozitív kontrollban 48 Liquipedia academy/secondary/development/feeder kapcsolatból a teljes classifier 48/48-at, a csak név-alapú szabály 27/48-at talál meg. A névmarker tehát önmagában elégtelen. Az E50 első forrásköre a stabil 50-es default-main minta minden sorát átvizsgálta: 20 esetben a szervezeti kapcsolat eldönthető, 30 esetben a nyilvános oldal csak a roster vagy a versenyrészvétel létezését igazolja. Az eldönthető részen 0/20 feeder; Wilson felső szél 16,11%. Ez forrás-cenzorált alminta, ezért nem terjeszthető ki az 50-re. A main-precision kérdés és a második vak reviewer továbbra is nyitott.

Az audit közben kiderült, hogy a címketér maga sem egytengelyű. A default halmazban nemzeti válogatott, streamer-party, egyetemi csapat és Game Changers-roster is van: ezek nem akadémiák, de a main szervezeti jelentése sem írja le őket. A következő sémának ezért külön kell tárolnia az entity_kind mezőt (org-team/national/temporary/university/GC) és a competition_tier mezőt; a legacy main/acad/cl csak származtatott kompatibilitási címke lehet.

A tier-guard replay 287 történeti feloldáson guard nélkül és guarddal is 286/287 helyes. A guard egy eredményt változtatott, de nulla hibát előzött meg és nulla sort blokkolt. A jelenlegi formájáról ezért nem állítható, hogy tényleges védelmet ad; az A5 időbeli vak holdout és az A3 50-es kézi audit protokollját a KISERLET_KATALOGUS_2026-08-02.md rögzíti.

C.7 A rosterváltozás döntési hatása

Fok: nem alkalmazható ·

Válasz egy mondatban: A lineupmodell ott ad értéket, ahol az ötös tényleg eltér a referenciától; változatlan rosteren nem javít.

Miért kérdeztük: a C.1 teljes kombinatorikus tartománya felső érzékenység, a döntéshez a tényleges rostereltéréses szelet kell.

Mit futtattunk: 690-es fejlesztési holdouton külön roster-változott és roster-azonos réteget, M12/M13 full lineup és team kontrollal.

A szám: változásnál n=198, A kar logloss gain +0,0807 [0,0338;0,1301], B kar +0,1072 [0,0471;0,1729]; azonos rosteren −0,005/−0,001, lényegében nulla.

Ez a bontás megmagyarázza, miért félrevezető minden upcoming meccsre azonos lineupmodellt és azonos tét-haircutot alkalmazni. Változatlan ötösnél a referencia már hordozza a szükséges információt; a bonyolultabb út csak varianciát adhat. Változásnál viszont a team-only alap épp azt nem látja, ami megváltozott. A boardnak ezért nem pusztán roster-badge-et kell mutatnia, hanem a változás idejét, a régi és új ötöst, valamint a modellár elmozdulását is. A mérés a 690-es, fejlesztésre már használt szeleten született, tehát viselkedési leírás és hipotézis, nem promotion-bizonyíték.

Mi cáfolná: független forwardon a változásrétegben eltűnő gain. Legalább 100 lezárt, döntéskor timestampelt lineup-state kell, előre rögzített „változott” definícióval. Ha a változásréteg CI-je nullát fed, vagy az azonos roster réteg hasonló gainre vált, a jelenlegi heterogenitási magyarázatot vissza kell vonni.

Kapcsolódik: B2.4, B5.2, C.1.

Forrás: T30/§24; a 690-es szelet fejlesztésre már használt.

D. A módszer — hogyan döntünk

Ezt a könyvet a legkönnyebb kihagyni és a leginkább megbánni.

D.1 Döntési protokoll — ki dönt, mit, és miért így

Ezt a szakaszt a Király írja. A Bolond a protokoll egyik szereplője, ezért a szerepek leírása nem tőle jön — ugyanaz az elv, amiért a mérést végző nem osztályozza a saját eredményét.

D.1.1 Három szerep, rögzített rangsorral

A rangsor nem udvariassági forma, hanem konfliktus-kezelés. A Bolond futtatja a kísérleteket — tehát nem ő adhatja rájuk a fokozatot. A Király osztályoz — tehát az ő saját futásait a Bolondnak kell megtámadnia. Amit valaki ír, azt a másik minősíti.

Precedens (T13). A Bolond abstain-t javasolt hiányos felállásnál, a Király elfogadta, a Mérnök felülbírálta: nem abstain, hanem marginalizált ár + kisebb tét. A felülbírálás áll, és azóta ez az élő policy. A precedens azért fontos, mert megmutatja, hogy a rangsor nem formalitás — ténylegesen megfordított egy közös verdiktet.

D.1.2 A folyamat

kerdes → elore rogzitett kontraszt → idohelyes futas → alternativ magyarazat tamadasa
       → bizonyitekfok → elfogadasi teszt → (esetleg) promotion

A kérdésnek a futás előtt meg kell neveznie: a kontrollt, az elsődleges metrikát, a szeletet, az elemszám-minimumot, és azt az eredményt, amely megváltoztatná a döntést. Az utólag kinyitott finomrács exploratory — nem emelheti a bizonyíték fokát.

Minden válasz öt mezőt tölt: verdikt · bizonyíték · alternatív magyarázat · javítás · elfogadási teszt. Nincs „szerintem valószínű" bizonyíték nélkül. Egy production-példa smoke test, nem validáció.

D.1.3 Három külön döntés, amit nem szabad összemosni

Ezért lehetséges, hogy egy irány prediktíven igazolt és mégsem kerül élesbe (a σ ilyen), és az is, hogy egy guard hatásmérés nélkül bekerül, mert csak hibánál tilt (a fail-closed ilyen).

D.1.4 Mi történik nézeteltérésnél

1. A támadó számot hoz, nem véleményt. Szám nélküli kifogás nem blokkol.
2. A védő vagy elfogadja (és a bejegyzés D.8-ba kerül), vagy cáfoló futást ad.
3. Ha mindkettőnek van száma és ellentmondanak: a szélesebb bizonyítékalap nyer — több

független év, több szelet, több adatvintage. Ha ez sem dönt, a kérdés ? marad.

1. Ha a kérdés technikai ízlés (nem mérhető), a Mérnöké a döntés, és D.5-be kerül.

D.1.5 A protokoll eddigi mérlege

Tizenöt visszavonás (D.8), köztük mindkét fél saját állításainak nyílt korrekciói. Ez a szám a protokoll egyetlen valódi bizonyítéka: egy rendszer, ami nem termel visszavonást, nem szigorú — csak csendes.

D.2 A bizonyíték-fokozat

Egy D nem szégyen — a futásaink többsége D. A szégyen, ha D-t A-ként idézünk. Fokozatot emelni csak új futással szabad, átfogalmazással soha.

D.2.a Ismert érvénytelen bemenetek és következményeik

Egy 2026-07-30-i ns/μs konverziós hiba (T59) elrontotta a történeti PandaSkill-lookupot: a per-role mezők a játékos idősorának utolsó, gyakran jövőbeli sorát kapták. A K8 enriched táblát 19:19-kor regenerálták a javítással.

Minden 19:19 előtti, per-role adatra épülő futás érvénytelen — köztük három futás (E18 szerepbontás · E19 aggregáció · E20 σ-moduláció).

Dokumentációs szabály: ahol egy bejegyzés érvénytelenített futáson áll, a Forrás mezőbe kerüljön [E18 érvénytelen — T59 ns-bug], és a fokozat annyi legyen, amennyit a megmaradt bizonyíték elbír. Ne töröld az érvénytelen futást — az is információ.

Az érvénytelenség nem azt állítja, hogy a numerikus irány biztosan hamis, hanem azt, hogy abból a futásból nem tudjuk. E36 v1 az ns-hibás, v2 a javított atomikus inputon futott, és a gépi verdikt bitre azonos maradt; ettől a v1 nem válik visszamenőleg hivatkozhatóvá. A három érintett ág három külön kimenetet mutat: E18 és E19 tiszta párral részben vagy egészben túlélte, E20-nak nincs párja, ezért ?. A státuszt mindig a futás provenance-e, nem az dönti el, hogy később véletlenül ugyanaz lett-e az eredmény.

És egy általános tanulság ebből (D.6.10): nem a kód volt rossz, hanem alattunk cserélődött a bemenet. Az őr: minden futás írja ki a bemeneti fájlok hash-ét és mtime-ját a manifestbe — ma csak a saját outputját hash-eli.

D.3 Előre rögzítés és holdout-higiénia

A szeletek gépi registryben (config/holdout_registry.json): legacy_755 = development_only_contaminated, ≥63 kiértékelés, forbidden_use: [model_selection, promotion, confirmatory_effect_claim]. A forward_lineup_v3 sealed_collecting, 0/1 nyitás, ≥100 graded esemény kell.

D.4 A célfüggvény — a logloss nem pénz

A modellfejlesztés elsődleges célja a valószínűség minősége, ezért logloss és Brier kell: ezek minden eseményt értékelnek és proper scoring rule-ok. A fogadási rendszer végső célja viszont a költség utáni, kockázattal együtt értelmezett pénzügyi eredmény. A kettő nem helyettesíti egymást. Jobb logloss nem bizonyít edge-et, mert nem látja az oddsot; pozitív kis mintás ROI pedig nem bizonyít jó modellt, mert erősen variábilis és szelekciófüggő.

A helyes célhierarchia:

1. Pontár: logloss + Brier; AUC csak diagnosztika, ECE csak kalibrációs diagnosztika.
2. Intervallum: exact-five price coverage, rétegzett coverage, élesség és monoton hibarangsor;

itt loglossot használni tilos.

1. Szelekció: végrehajtható quote-on költség utáni EV és forward CLV.
2. Tét: log-bankroll, max drawdown és ruin-valószínűség korrelált portfólión.
3. Promotion: mindezek mellett teljes coverage, provenance, ops és rollback.

Mikor válik szét a proper score és a P&L? A logloss minden lezárt mérkőzésen méri a közölt valószínűséget, függetlenül attól, volt-e fogadható ár. A P&L csak azon a szelekcionált részhalmazon létezik, ahol az ajánlott odds átlépi az edge-küszöböt, volt végrehajtható ask és fill, majd a díj és a csúszás levonása után is marad hozam. Emiatt három mechanizmus választja szét őket:

A σ ezt két külön úton mutatja meg. Az M3 a pontárat 0,5 felé húzza, ezért egyszerre változtatja a proper score-t és azt, mely sorok tüzelnek. Az M4 nem módosítja a közölt p-t, csak magas σ-nál emeli az edge-küszöböt, tehát a proper score változatlan marad, miközben a fogadási halmaz és a P&L változhat. A két kar P&L-különbsége ezért csak ugyanazon döntéskori quote-, outcome- és költségsnapshotból értelmezhető; külön, újraszámolt ledgerekből nem.

A jelenlegi konkrét sorok nem adnak érvényes σ-hatást. A régi Poly replay 38 tippet mutatott: a base/M3/M4 bruttó mid-CLV rendre +0,109/+0,130/+0,135 volt, de 30/38 sorhoz nem volt pregame ask, 34% seed-placeholderből jött, és már 3%-os p-eltolás a tüzelő betek körülbelül 20%-át utólag eltüntethette. Az ask-árazható részhalmaz összesítve −4,2% CLV-t, a körülbelül 1,8%-os fee után −5,9%-ot adott. Ez megmutatja a mechanizmus nagyságát, de nem azonosítja az M3/M4 inkrementális hatását; ahhoz az append-only σ-on/off forward napló kell.

A σ-vita mutatja az eltérést. A signed σ 4/5 évben javítja a pontár loglossát, de nem tudjuk, hogy a kiválasztott fogadásokon javítja-e a nettó P&L-t. Ezért a point-model állítás A, a döntési állítás ?. Egyik fokát sem szabad a másik metrikájából kölcsönözni.

D.5 Margin-döntések — amit bizonyíték nélkül döntöttünk el

Ezt a szakaszt a Király írja: ezek a Király és a Mérnök döntései, és hogy „miért így", azt nem az ellenzék fogalmazza. Ez a leggyakoribb szóbeli kérdés — „miért csináltuk így?" —, ezért minden sorhoz odakerül a veszteség-aszimmetria: mennyibe kerül tévedni az egyik és a másik irányban. Ahol a bizonyíték nem dönt, ott ez dönt.

D.5.1 Álló döntések — ezek maradnak, amíg új mérés nem jön

D.5.2 Örökölt döntések — sosem hoztuk meg, csak beleszülettünk

Ezek a legveszélyesebbek: nem volt mérlegelés, mert nem volt kérdés.

D.5.3 A döntési szabály, amit ezekből kiolvasok

Ahol a mérés nem dönt, három kérdés dönt, ebben a sorrendben:

1. Melyik irányban drágább tévedni? Ez a #2 (slope-only) és a #5 (nincs promotion)

mögötti logika. Kis biztos veszteség > kicsi valószínűségű nagy veszteség.

1. Melyik alak nem tud elromlani? Az algebrai garancia (p(−x) = 1 − p(x)) többet ér, mint

a tesztelt helyesség — mert a teszt elavulhat, az azonosság nem.

1. Melyik döntés méri meg magát? Az exploration osztály (#4) azért jobb az abstainnél,

mert adatot termel. Egy döntés, ami nem hagy nyomot, nem javítható.

Amit ebből nem következtetünk: hogy az örökölt döntések (D.5.2) rosszak. Csak azt, hogy nem döntések voltak, hanem alapértelmezések — és mind a hatot úgy kell kezelni, mintha holnap kiderülhetne, hogy fordítva jobb.

D.6 A néma hibák taxonómiája

A projekt visszatérő hibaosztályai. Mindegyikhez: hogyan néz ki, mi fogta el, mi fogná el automatikusan.

D.7 Módszertani szabályok

1. Feature-verdiktet minimum öt rolling-origin éven kell alapozni; egyetlen holdout nem választ

kart, még akkor sem, ha a CI szép.

1. Minden időalapú lookup a közös nanoszekundumos segéden megy át, és jövősor-fixture védi.
2. Azonos nevű feature két táblában bitre egyezik, vagy külön nevet és artifact-azonosítót kap.
3. A decay-súly mean-one normalizált; különben a regularizáció és az effektív hiperparaméter

csendben változik.

1. Swap-szimmetrikus ár kalibrációs interceptet csak valódi, stabil side-azonosítóval kaphat.
2. A döntéskori feature-vektort, quote-ot, likviditást, artifact-hasht és policy-verziót az első

megjelenéskor perzisztálni kell.

1. Feltételesen kinyitott finomrács exploratív; ugyanaz a szelet nem válik új confirmatory

bizonyítékká több elnevezéssel.

1. Technikai hiány fail-closed. A legitim lineup-bizonytalanság külön állapot, amely szélesebb

intervallumot és kisebb tétet kaphat.

1. Production artifact csak explicit promotion-gate, golden parity és rollbackterv után változik.
2. Minden publikált metrika mellett szerepel a teljes populáció, coverage, kizárási ok,

elemszám, időhatár és a felhasznált inputhash.

1. Feature-ablationt nem nevezünk el pusztán darabszámmal. Minden kar mellett szerepel a pontos

mezőlista vagy annak hash-e; E37-ben a T4 ≈ T10, miközben a T7 sokkal rosszabb volt.

1. Érvénytelen futás akkor sem hivatkozható, ha egy későbbi tiszta pár ugyanazt a verdiktet adja;

a régi szám csak történeti nyom, a fokot a tiszta futás viszi.

D.8 Visszavonások

D.9 A 26 drágán megvett tanulság

Az alábbi lista nem új kísérletsorozat, hanem a registry teljes tanulságjegyzékének önhordó változata. Azért kell egyben is megmaradnia, mert ugyanaz a hiba több lépcsőben más néven jelent meg. A számok a kapcsolódó B/C bejegyzésekben kapják a fokot; itt az általánosítható szabály áll.

1. Az előre rögzített invariáns-fixture többet ér az aggregált holdout-számnál. A K8 első

abs-karja +0,02283 LL-előnyt mutatott, de megsértette a „szokásos ötös ⇒ egzakt nulla” azonosságot. A javított futásban az előny eltűnt. Strukturálisan hibás kar akkor sem választható, ha az átlagos score szép.

1. ECE nem proper scoring rule, ezért nem kiválasztási cél. Az A30 λ=0 ECE-je javult,

miközben logloss, Brier és AUC romlott. A lapos predikció könnyen kap szép ECE-t; döntéshez logloss és Brier kell páros CI-vel.

1. A holdout egyszer nyílik, és nem szavaz. A legacy 755-ön körülbelül 42 konfigurációt

néztünk. √(2 ln k) szerint ez nagyjából 2,7σ kiválasztási felfújás, több, mint a K8 blokk-C körülbelül 2,1σ-s „győzelme”. Új név nem teszi új adattá ugyanazt a szeletet.

1. Aggregált átlagkülönbség × coverage nem egyenlő a páros veszteség összegével. Ebből lett a

≈0,0017 kontra tényleges 0,00868723 tévedés. Két kar rését soronként, közös metszeten kell képezni, és csak utána szabad átlagolni.

1. A nyers együttható nagysága nem feature-fontosság. Nyers skálán a winrate20_delta

0,149, a dpm20_delta 0,0003; |súly|×szórás után ps_mu 44,3%, dpm20 19,5%, winrate20 13,2%. Skálakorrekció nélkül együttható-sorrendet nem idézünk.

1. Gain-importance és ablation más kérdés, és inkrementumhoz az ablation dönt. A production

gain szerint a player_avg blokk 0,49, nullázva mégis csak −0,0006-ot ér. Az eltérés redundanciát jelez: más mezők átveszik a jelet.

1. Degenerált statisztika nem bizonyíték. A K8 blokk-A corr=0,0000 értéke 0/0 helyzetből

jött, mert pinning mellett team_lineup_move_max_abs=0. Előbb varianciát és nevezőt kell ellenőrizni, csak utána értelmezhető a korreláció.

1. A seed-ensemble szórása nem episztemikus bizonytalanság. Rögzített adaton és

architektúrán az optimalizáció zaját méri. Stabilitási diagnosztikának használható, lineup-bizonytalanságnak nem.

1. A csapatszintű PandaSkill nem rosterfüggetlen baseline. A ténylegesen játszó ötös μ-átlagát

hordozza; ha a seat-réteg is tényleges−referencia deltát ad hozzá, a rosterhatás kétszer számolható. Innen indult a T5-pinning, és ezért kellett mindkét végpont fixture-je.

1. A roster-stable/changed címke döntéskor nem megfigyelhető, ha a tényleges ötösből készül.

Ilyen router retrospektív információt használ. Minden routing feature-nek explicit decision_time_observable=true szerződés kell.

1. A handicap-fejnek nincs automatikusan saját szabadsági foka. Bo3-ban a −1,5 handicap

pontosan a 2–0 esemény, a series-score PMF determinisztikus marginálisa. Az önálló AUC 0,553 ezért lehet helyes szerkezeti viselkedés, nem feltétlen gyenge fej.

1. A régi +0,174 pár-szinergia együtt költöző roster jelét mérte. Nulla co-movernél

r=−0,0127, legalább kettőnél +0,3161. Csapaterő és rosterstabilitás levonása nélkül a „szinergia” nem elkülönített interakció.

1. A rating-drift nagyobb lehet a teljes felállás-térnél. Ugyanaz a meccs és öt játékos egy

hét alatt +31 pp-t mozdult, a 126-lineupos sávok nem fedték egymást. Lineup-hatást csak változatlan artifact- és adatvintage mellett szabad összevetni.

1. A production árazása bizonytalanság-vezérelt. A ps_team_sigma_diff nullázási hatása

+0,01238, több mint kétszerese az erőcsatorna +0,00515 értékének. Ez a modell tényleges üzemmódja, még ha az elvi szerződés a B-csatornát tiltja is a pontárban.

1. A szerepenkénti bontás nem a kétlépcsős modell újdonsága. A production öt per-role

metrikája név szerint egyezik a seat-25 maggal. A különbség a szemantika: production abszolút bal–jobb érték, a shadow referencia-delta.

1. **A √(2 ln k) korrekció a kiválasztott maximumra szól, nem minden előre rögzített páros

CI-re.** Minden kontrasztra ráhúzni túlkorrigálás. A kérdés az, hogy a kontraszt előre rögzített volt-e, és ugyanaz-e az előjel a szelet két felén.

1. „X kivétele ront” és „X árjelként nem igazolt” két külön kísérlet. Ugyanaz a

B-csatorna szó a csapat- és seat-lépcsőben eltérő változót jelenthet. Minden csatornaállítás mellett szerepeljen a lépcső és a konkrét mezőlista.

1. Az egyvégpontos fixture hamis biztonság. A pinning nulla-korrekciós végpontja zöld volt,

miközben teljes cserénél átlag 4,29 pp, maximum 18,22 pp hibát adott. Minden identitáshoz triviális és maximális végpont kell.

1. A kalibrátor interceptje nem semleges „kalibráció”. Szimmetrizált modellnél alaprátát tesz

vissza; ismeretlen oldal esetén önkényes feed-szlotra kerül. A 0,538 blue-alapráta valós, de live_left_order_is_not_blue, ezért a live útban intercept nem alkalmazható.

1. A tanítópopuláció szűkítése nem ingyenes EIV-javítás. A stabil részminta az attenuáció

24%-át vette vissza, csak 1,2σ-n belül, mert a szelekciós torzítás és a kisebb minta ellensúlyozta. Azonos méretű véletlen kontroll nélkül a mechanizmus nem azonosítható.

1. A bizonytalanság-feature lehet elavult-adat-feature. Recency-súlyozás mellett a

ps_team_sigma_diff total-gainje 63,51%→23,09%. A σ továbbra sem nulla jel, de dominanciája részben idődriftből jött.

1. Az eloszlásos alak nem viselhet egyszerre pontár- és sávszerepet.

Φ(Δμ/√(σ²+β²)) pontként elmozdította a befagyasztott centert 0,54–0,94 ponttal és F7-et sértett. A nevező szélesíthet bizonytalanságot, de nem írhatja át észrevétlenül a közepet.

1. Egy egyholdoutos rangsor öt éven megfordulhat. T5-pinned a régi szeleten kis plusznak

látszott, rollingban 0/5; ugyanott a seat-A 5/5. A baseline-vita és a nyereség forrása külön kérdés.

1. A negatív eredményt is regisztrálni kell. Tizenhét report maradt hivatkozás nélkül,

köztük E19 tiszta párja. A futás elkészítése és a nyilvántartásba vétele két külön feladat; egyik nélkül a tudás elveszik.

1. A feature-szám nem monoton a minőséggel. E37-ben T4 ≈ T10, a T7 mégis 44-szer akkora

réssel volt rosszabb, mint T5 és T10 különbsége. A változó a mezőhalmaz, nem a k; minden ablation mellé ki kell írni, mi maradt ki.

1. Egy érvénytelen futás nem feltétlenül téved, de akkor sem hivatkozható. E36 ns-hibás v1

és tiszta v2 verdiktje azonos volt. E18/E19 részben túlélte a tiszta párt, E28 E19 egyik részét megdöntötte, E20 tiszta párja pedig az E39. Az inputhiba státusza és az eredmény előjele két külön állítás.

D.9.1 Amit nem csinálunk újra

• Nem keresünk új konfigurációt a legacy 755-ön verdiktért.
• Seed-szórást nem nevezünk lineup- vagy episztemikus bizonytalanságnak.
• Seat-szintű ps_sigma nem kap lineáris irányjogot új, érvényes bizonyíték nélkül.
• [0,1] envelope mellé nem adunk hamis uncertain_value osztályt; az állapot exploration.
• Gyorsításként nem csonkoljuk top-k-ra a lineup-posteriort; cache engedett, tömegelvesztés nem.
• Friss Oracle-lel futtatott számot nem hasonlítunk régihez a pótlás explicit kizárása nélkül.

E. Lyukak és hallgatólagos feltevések

E.1 Amit soha nem próbáltunk

Hat korábbi lyuk időközben lezárult és ezért nincs a táblában: a 0,045-ös adatúteltérés oka az ns/us lookup-hiba volt; a decay ötéves rolling-originban lefutott; az S5 adaptív konformal technikailag lefutott; az E39 tisztán újrafuttatta a konkrét σ-modulációt; az E40 lezárta a player-tau rács felső oldalát; az E41 replay megmérte a tier-guard tényleges hatókörét. A false-main prevalencia ettől még nyitott.

E.2 Hallgatólagos feltevések

Ezek nem egyszerű ? kérdések: olyan alapfeltevések, amelyeket a rendszer döntés közben igaznak vesz. Mindegyikhez explicit őr vagy kísérlet kell.

1. A bejelentett felállás jobb, mint a modális. Lehet frissebb, de lehet bő keret, későn

frissített vagy staffal szennyezett. A teszt a B2.3 cutoff-helyes source ablation.

1. A series-kimenet a helyes célváltozó. Kényelmesen illeszkedik a moneyline-hoz, de a non-ML

és a mintaméret a map-target mellett szól. A teszt B0.1–B0.3.

1. A training blue_result orientáció a live sorrendben is értelmes. Ez már hamisnak bizonyult:

a feed első csapata +2,68 pp-t kapott. Az őr valódi side-ID vagy slope-only kalibráció.

1. A piac nem tud olyat, amit a modell nem lát. Rosterhír, draftvárakozás és privát

információ miatt ez erős feltevés. A teszt market-prior + residual.

1. Minden csapat egy populáció. A 381 2026-os csapatból 340 csak default miatt „main”, miközben

academy calibration rosszabb. A teszt pozitív tierforrás és rétegzett kapu.

1. Az arányos de-vigging torzítatlan. Longshoton rendszeres hibát vihet az edge-be. A teszt

proportional/Shin/power záróár-kalibráció.

1. A bankroll gyakorlatilag végtelen. A fix 10/100 dolláros unit mögött nincs deklarált tőke,

utility vagy ruin-limit. A teszt B11.

1. A fogadások függetlenek. Ugyanazon series map winner, handicap és total kifizetése közös

PMF-ből jön, ezért ez szerkezetileg hamis. Az őr eseményszintű exposure-cap.

F. Függelék

F.1 Rövid idővonal

F.2 Reprodukciós parancsok

Az alábbi parancsok a repository gyökeréből, a lockolt uv környezetben futnak. A report előtt az inputhash-eket és a git státuszt is rögzíteni kell.

uv run python -m lolbet.analysis.audit_production_pandaskill_provenance
uv run python -m lolbet.analysis.audit_k8_context_f9
uv run python -m lolbet.analysis.run_decay_rolling_origin
uv run python -m lolbet.analysis.run_k8_rolling_origin_validation
uv run python -m lolbet.analysis.run_atomic_aggregation_rolling_origin
uv run python -m lolbet.analysis.run_minimal_model_rolling_origin
uv run python -m lolbet.analysis.run_rolling_origin_sigma
uv run python -m lolbet.analysis.run_ps_core_sigma_lattice
uv run python -m lolbet.analysis.run_rating_internal_rolling_origin
uv run python -m lolbet.analysis.run_production_slope_only_calibration
uv run python -m lolbet.analysis.run_two_sided_distributional
uv run python -m lolbet.analysis.run_lineup_counterfactuals
uv run python -m lolbet.analysis.run_normalized_adaptive_spread
uv run python -m lolbet.analysis.report_promotion_gates
uv run pytest -q

A production artifactot egyik parancs sem írhatja felül. A scorer retrainje csak explicit engedéllyel történhet; reprodukcióhoz külön outputkönyvtár kell.

F.3 Szeletek

F.4 A ma futó modell

2026-07-31-én a production pontár a 2026-06-16-i match_level_model_artifact.joblib: szimmetrikus csapatpárra tanított joint XGBoost, 79 feature-rel és interceptes Platt-kalibrációval. Az input Oracle history, PandaSkill csapat/játékos/régió snapshot és a legacy feature-build. A moneyline közvetlen modellár; a board három non-ML családja ebből származtatott map/series eloszlást használ. A tét legacy_units(p)=0,143+1,286p, oddsfüggetlen; a dev ág unitja 100 USD, a visszaállított Linux-boxé 10 USD. Nincs portfolio-cap, valódi Kelly, bet-class alapú production sizing vagy automatikus order submission. Az összes új PandaSkill-, PS7_CONTEXT-, M12/M13-, PMF- és uncertainty-artifact shadow.

F.5 Hash-jegyzék

A hash csak az adott fájlt azonosítja; nem bizonyítja, hogy minden upstream input helyes. Ezért a run manifestnek külön kell tartalmaznia a forrásfájlok hashét, max timestampjét, sorszámát, a git commitot, a dirty diffet és a runtime verziókat.

F.6 Teljes gyökérszintű dokumentumjegyzék

Ez a 2026-08-02-i repository gyökerében lévő mind a 74 kisbetűs .md Markdown-fájl név szerinti leltára. A lista teljességet, nem bizonyítékerőt jelent. A jelenlegi igazság elsődleges belépési pontja ez a kézikönyv; a kísérlet státuszát a KISERLET_NYILVANTARTO.md, a futás részleteit az adott report, az éles állapotot a STATE_OF_PLAY.md és az artifact manifest mondja meg. A HANDOFF, ARCHIVE, DIALOGUE, CURRENT és dátumozott pillanatképek történeti nyomok: későbbi mérés felülírhatta a verdiktjüket, ezért önmagukban nem promotion-források.

AB_CHANNEL_ABLATION_REPORT_2026-07-28.md
ARCHITECTURE.md
ARCHITEKTURA_MAGYARAZAT.md
ATOMIC_AGGREGATION_ROLLING_ORIGIN_REPORT.md
ATOMIC_PS_K8_AB_RERUN_REPORT_2026-07-30.md
BETTING_STRATEGY_AND_ROADMAP.md
BET_AUDIT.md
CALIBRATION_GATE_1415_ALL_MODELS_REPORT.md
CALIBRATION_REFIT.md
CODEX_CLAUDE_AUDIT_DIALOGUE.md
CODEX_CLAUDE_AUDIT_DIALOGUE_ARCHIVE_2026-07-28.md
CODEX_CLAUDE_AUDIT_DIALOGUE_ARCHIVE_2026-07-29.md
CS_EXPANSION_RESEARCH_BRIEF.md
CURRENT_TIPS.md
DECAY_ROLLING_ORIGIN_REPORT.md
ELO_RESIDUAL_BUILD_PLAN.md
FEATURE_DONTESI_TABLA.md
FORWARD_LINEUP_SHADOW_REPORT_2026-07-28.md
FULL_PER_ROLE_ABLATION_REPORT_2026-07-29.md
HANDOFF_2026-07-23.md
HANDOFF_2026-07-24.md
HANDOFF_2026-07-27_TEENDOK.md
HANDOFF_2026-07-28_TANULSAGOK.md
HOL_TARTUNK_2026-07-28.md
INDEPENDENT_RICH_XGB_REPORT_2026-07-30.md
K1_K3B_K3_REPORT_2026-07-29.md
K8_PINNED_BASELINE_BRIEF.md
K8_PINNED_EXPERIMENT_REPORT_2026-07-29.md
K8_ROLLING_ORIGIN_REPORT.md
KISERLETSOROZAT_2026-07-28.md
KISERLET_KATALOGUS_2026-08-02.md
KISERLET_NYILVANTARTO.md
KISERLET_OSSZEFOGLALO_2026-08-02.md
KONSZOLIDACIO_2026-07-30.md
KONSZOLIDACIO_ARCHIVE_PRE_T61_2026-07-30.md
LATENT_PAIR_SYNERGY_REPORT_2026-07-28.md
LEGACY_755_ALL_MODELS_REPORT_2026-07-30.md
LINEUP_AWARE_SCORING_HANDOFF.md
LINEUP_FALLBACK_ARMS_REPORT_2026-07-28.md
LINEUP_POLICY_CALIBRATION_REPORT_2026-07-29.md
LINEUP_SOURCE_RESEARCH_BRIEF.md
MATCH_LEVEL_MODEL_UPDATE.md
MIT_PROBALTUNK.md
MIT_PROBALTUNK_EDIT.md
MODELLEK_ES_INPUTOK_2026-07-28.md
MULTIBOOK_MONEYLINE_PLAN.md
NORMALIZED_ADAPTIVE_SPREAD_REPORT.md
ODDS_COHERENCE.md
ODDS_LOGGER_TMUX.md
OPERATIONS.md
PACKAGE_RETRAIN_REPORT_2026-07-27.md
PANDASKILL_F9_DECAY_K8_ROLLING_REPORT_2026-07-30.md
PRICE_STABILITY_FINDINGS_2026-07-27.md
PRODUCTION_PANDASKILL_PROVENANCE_REPORT.md
PRODUCTION_PORTABLE_EXPORT_REPORT.md
PRODUCTION_SLOPE_ONLY_CALIBRATION_REPORT.md
PS4_ES_SZORAS_FEJ_SPEC.md
PS4_POINT_HEAD_REPORT.md
PS4_POINT_SPREAD_COMPARISON_REPORT.md
PS4_SPREAD_HEAD_REPORT.md
PS7_CONTEXT_TIME_REGIME_REPORT.md
PS7_CONTEXT_YEAR_ABLATION_REPORT.md
RATING_INTERNAL_ROLLING_ORIGIN_REPORT.md
README.md
RICH_CONTEXT_XGB_REPORT_2026-07-30.md
STATE_OF_PLAY.md
SZORASBECSLES_SPEC.md
T40_EXECUTION_REPORT_2026-07-29.md
TANITASI_SZERZODES_2026-07-28.md
TELJES_KISERLET_NYILVANTARTAS.md
TIP_GENERATION_HANDOFF.md
UNION_2146_MODEL_BENCHMARK_REPORT.md
XGBOOST_MODEL_DEEP_RESEARCH_NOTES.md
now_do_what.md

F.7 Teljes analysis-moduljegyzék

Az src/lolbet/analysis/ 116 Python-fájlt tartalmaz. Ezek közt vannak futtatható kísérletek, auditok, report-generátorok, közös helpermodulok és régi diagnosztikák. Egy fájl létezése nem jelenti, hogy a futása érvényes vagy a kimenete aktuális. Számot csak akkor lehet idézni belőle, ha a kapcsolódó report/manifest rögzíti az inputhash-t, cutoffot, elemszámot és státuszt; az E18–E20 mutatja, miért nem elég a scriptnév. Az alábbi leltár célja, hogy egy elemzőeszköz se váljon láthatatlan „udvari tudássá”.

__init__.py
analysis_plots.py
analyze_d_policy_gap.py
analyze_live_odds_snapshots.py
analyze_master_dataset.py
analyze_odds_comovement.py
analyze_per_seat_holdout.py
analyze_polymarket_vs_strength.py
analyze_team_dataset.py
annotate_model_architecture.py
audit_forward_d_actual.py
audit_independent_rich_xgb.py
audit_k8_context_f9.py
audit_match_level_pipeline.py
audit_production_pandaskill_provenance.py
audit_rich_context_xgb.py
audit_series_winner_vs_registry.py
audit_team_tiers.py
backtest_polymarket_closed_vs_strength.py
benchmark_calibration_gate_1415.py
benchmark_legacy_755.py
benchmark_union_2146.py
bootstrap_lineup_information_value.py
build_bet_audit.py
build_complete_experiment_registry.py
build_feature_snapshot.py
build_first_batch_manifest.py
build_forward_staking_arms.py
build_full_per_role_features.py
build_roster_profiles.py
build_team_directory.py
calibrate_lineup_fallback_policies.py
compare_full_lineup_to_team_baseline.py
compare_generated_odds.py
compare_margin_rules.py
compare_polymarket_pregame_vs_model.py
compare_production_vs_shadow.py
deep_feature_odds_analysis.py
diagnose_strength_model_calibration.py
diagnose_target_side_semantics.py
diagnose_xgb_vs_logreg_calibration.py
evaluate_ab_channel_ablation.py
evaluate_lineup_fallback_arms.py
evaluate_lineup_mixture.py
evaluate_nonml_package_shadow.py
evaluate_package_training_matrix.py
evaluate_per_seat_starter_mixture.py
evaluate_polymarket_pregame_close.py
evaluate_shadow_models.py
evaluate_two_sided_starter_mixture.py
export_production_artifact_portable.py
export_roster_panel_data.py
feature_set_retrain.py
fit_per_seat_conformal.py
grade_forward_lineup_fallback.py
holdout_registry.py
infer_team_aliases_from_fixtures.py
lineup_provenance.py
lineup_variants.py
measure_pair_synergy.py
measure_role_assignment_ambiguity.py
measure_team_baseline_ablation.py
model_market_odds.py
predict_lineup_matchup.py
predict_team_matchup.py
promotion_gate_freeze.py
rebuild_t40_immutable_input.py
reconcile_bookmaker_team_names.py
refresh_starter_mixture_coverage.py
report_promotion_gates.py
rescore_with_actual_lineups.py
run_aggregation_lattice.py
run_atomic_aggregation_rolling_origin.py
run_bankroll_risk_simulation.py
run_calibration_window_experiment.py
run_decay_rolling_origin.py
run_devig_method_experiment.py
run_k1_k3b_k3_experiments.py
run_k8_pinned_experiment.py
run_k8_rolling_origin_validation.py
run_lineup_counterfactuals.py
run_lineup_stability_strata.py
run_market_prior_experiment.py
run_minimal_model_rolling_origin.py
run_normalized_adaptive_spread.py
run_production_slope_only_calibration.py
run_ps4_point_head.py
run_ps7_context_time_regime_experiment.py
run_ps7_context_year_ablation.py
run_ps_core_sigma_lattice.py
run_rating_internal_rolling_origin.py
run_role_vs_aggregate_logit.py
run_rolling_origin_sigma.py
run_sigma_modulation_lattice.py
run_spread_head.py
run_stable_team_stage_experiment.py
run_t40_audit.py
run_target_granularity_experiment.py
run_team_tier_experiment_series.py
run_two_sided_distributional.py
run_year_vs_recency_experiment.py
same_named_feature_contract.py
scan_board_market_offers.py
shadow_forward_orders.py
shadow_information_state.py
shadow_lineup_fallback_snapshots.py
summarize_gate_feature_importance.py
summarize_odds_inventory.py
summarize_ps4_point_spread.py
summarize_role_assignment_ambiguity.py
train_independent_rich_xgb.py
train_rich_context_xgb.py
tune_elo_residual.py
tune_skill_encoder.py
tune_twintower.py
tune_twintower_residual.py

F.8 Mitől hivatkozható egy fájl?

Az F.6/F.7 leltár három külön állítást választ szét. Megvan: a fájl jelen van ebben a worktree-ben. Lefutott: létezik hozzá output, de ettől még lehet rossz inputon, használt holdouton vagy hiányos manifesttel futott. Hivatkozható: a D.2 szerinti fokhoz szükséges provenance, időirány, minta és előzetes döntési szabály is megvan. Az E20 például megvan és régi futása lefutott, de nem hivatkozható; a tiszta E39 ugyanazt a kart új inputhashen viszi. A tau×8 scriptkar E40-ben lefutott és lezárta a rácsot; az E33 riport hivatkozható strukturális és C szintű score-állításra, de nem production promotionre.

Ellentmondásnál a sorrend: érvényességi registry és holdout-státusz; input/output manifest; konkrét report; ez a konszolidált könyv; történeti handoff vagy dialogue. Az alsóbb szint segíthet megérteni, miért hittünk valamit, de nem írhatja felül a későbbi, érvényesebb bizonyítékot. Egy reportot nem törlünk attól, hogy megdőlt: SUPERSEDED vagy [érvénytelen] státusszal megmarad, mert nélküle a visszavonás oka és az ismétlés veszélye eltűnne.

A teljes leltárt a konzisztencia-teszt a fájlrendszerhez méri. Új gyökérszintű .md vagy új analysis .py esetén a teszt addig piros, amíg a név ide be nem kerül. Ez a D.6.13 kétirányú őre: nem maradhat mérés nyilvántartás nélkül, és nem állíthatunk hiányt repository-keresés nélkül.

F.9 Teljes kísérlet-kereszttérkép (E1–E51 és E48b)

Ez a tábla a registry minden E-azonosítóját visszaköti a konszolidált könyvhöz. Nem másolja ide a teljes reportot, de egyetlen kísérletet sem hagy névtelenül: megadja a döntő számot, a jelenlegi értelmezést és azt a szakaszt, ahol a kérdés részletesen él. Az „érvénytelen” sor nem törölt; a „fejlesztési” sor nem promotion; a ? nem negatív eredmény, hanem érvényes válasz hiánya.

F.10 Kísérletsorozat- és feladatazonosítók

Az E az eredményregistry stabil sora. A K egy előre megnevezett kísérletsorozati kar, a T pedig végrehajtási/audit feladat; ugyanaz a mérés több nevet is viselhet. Emiatt a T-szám nem önálló bizonyíték: például T42/7 az E8 auditfeladata, az érvényes javító mérés pedig E33. A kereszthivatkozás célja a régi párbeszédek visszakereshetősége, nem újabb fokozat létrehozása.

A registryben előforduló összes alapszintű T-azonosító:

T1
T2
T3
T4
T5
T6
T7
T8
T9
T10
T11
T12
T15
T17
T18
T19
T20
T21
T22
T23
T24
T25
T26
T27
T28
T29
T30
T31
T32
T33
T34
T35
T36
T37
T38
T39
T40
T41
T42
T43
T44
T45
T47
T48
T49
T50
T52
T53
T54
T58
T61
T62

F.11 A teljes nyitott végrehajtási sor

Ez a registry aktuális 12 tételes sora. A sorrend kockázat és információérték szerint értendő, nem automatikus felhatalmazás futtatásra vagy production-módosításra. A legacy 755 egyik effect-claimhez sem nyitható újra; fixture ott engedett, ahol algebrai vagy technikai invariánst ellenőrzünk, és nem modellt választunk.

A már lezárt K1, K3 seat-ág és K3b nem kerül vissza a sorba új néven. A K3 csapatszintű kérdése csak a 2. tételben él tovább, mert a team- és seat-B nem ugyanaz a mennyiség. Új tétel akkor kerül ide, ha megnevezi a kontrollt, az engedett szeletet, az elsődleges mércét és a lezárási feltételt.

F.12 A teljes nyitott kérdésjegyzék

A ? itt nem hiányosan megírt bejegyzést jelent, hanem olyan kérdést, amelyhez nincs a D.2 szerint hivatkozható döntő mérés. A következő lista a B könyv összes ilyen bejegyzését tartalmazza; nem prioritási sor, és önmagában nem ad felhatalmazást futtatásra. A „mi zárja le” oszlop a legkisebb elfogadható bizonyíték alakját rögzíti. Eredmény csak a saját B-bejegyzésébe kerülhet vissza, elemszámmal, időhatárral, bizonytalansággal és forrással együtt.

A jegyzék gépi része szándékosan csak az azonosítókat tartalmazza. A teszt ezt a listát a bejegyzések tényleges Fok: ? mezőiből képzett halmazhoz méri, ezért új ?, lezárt kérdés vagy fokozatváltás ugyanabban a commitban megköveteli az F.12 frissítését.

B0.1
B0.2
B0.3
B1.3
B1.6
B1.8
B2.3
B3.5
B3.8
B7.4
B7.5
B8.7
B8.9
B9.1
B9.3
B9.5
B11.1
B11.2
B11.3
B11.4
B11.5
B12.1
B12.3
B12.4
B12.5
B12.6
B12.7
B13.2
B13.3
B13.5

F.13 Kanonikus teljes kísérlet-nyilvántartás

A TELJES_KISERLET_NYILVANTARTAS.md az összes eredményhordozó sor normalizált emberi nézete; a mezőazonos gépi tábla a config/experiment_registry.csv. A teljességi egység az E1–E51 és a külön eredménysorként élő E48b, összesen 52 rekord. A még nem eredményként létező teljes sor külön gépi táblája a config/experiment_open_items.csv: 12 F.11 végrehajtási tétel és 30 F.12 bizonyítási kérdés. A K kampány- és a T feladatazonosító kereszthivatkozás, ezért nem számít újabb bizonyítéknak.

A generátor minden sorhoz megőrzi a kérdést, eredményt, verdiktet és forrást, majd hozzáteszi a területet, explicit D.2 fokot vagy annak hiányát, életciklust, blockert, utódot, kapcsolódó szakaszt és az ismert reprodukciós parancsot. Hiányzó vagy duplikált E-sor, üres forrás, hiányzó F.9 kapcsolat, illetve elavult generált Markdown/CSV teszthiba. A registry egyetlen sora sem production-promotion: ezt továbbra is külön manifest és kapudöntés engedélyezheti.

G. Karbantartási szabályok

G.1 Olvasási sorrend

1. A.7 a fogalmakhoz, majd A.1–A.6 a jelenlegi rendszerállapothoz.
2. B0–B14 annak eldöntéséhez, mit próbáltunk és mi maradt nyitva.
3. C.1–C.7 a rendszer mért viselkedéséhez.
4. D a bizonyíték és döntés szabályaihoz.
5. E a még hiányzó kísérletekhez, F a reprodukcióhoz és a teljes nyitott kérdésjegyzékhez.

G.2 Frissítési szerződés

• Új szám csak elemszámmal, mértékegységgel, időhatárral és forrással kerülhet be.
• ? csak új, érvényes futással változhat; terv vagy implementáció nem eredmény.
• A fokot a D.2 skála adja. Elhasznált holdout legfeljebb D, strukturális bukás X.
• Érvénytelen futást nem törlünk: D.2.a és D.8 megőrzi az okot és a helyettesítő bizonyítékot.
• Azonos nevű feature csak azonos input- és artifacthash mellett tekinthető azonosnak.
• Production státuszt csak deployment manifest és promotion gate változtathat; jobb shadow score

önmagában nem.

• A pillanatnyi board-darabszám és adatvintage dátumozott snapshot, nem rendszerállandó.
• Új gyökérszintű Markdown-fájl és új src/lolbet/analysis/*.py modul ugyanabban a commitban

bekerül az F.6/F.7 leltárba; különben a konzisztencia-teszt piros.

G.3 Jelenlegi teljesség

Az A–F könyv minden felsorolt szakasza ki van töltve. Az F.6/F.7 a repository jelenlegi 74 gyökérszintű kisbetűs .md fájlját és 112 analysis-modulját hiány nélkül felsorolja. A B könyv valamennyi kérdéséhez szerepel fok, rövid válasz, indok, futás vagy explicit „nem futott” állapot, szám vagy hiányjel, cáfolati feltétel, kapcsolat és forrás. Az F.12 mind a 30 ? bejegyzést külön, lezárási feltétellel indexeli; ezek nem szöveghiányok, hanem dokumentált, végrehajtható kísérleti megbízások. A következő frissítés feladata nem további próza, hanem az E.1/F.11/F.12-ben felsorolt új mérések eredményeinek beemelése.