🔬 Clash Watchdog AI — Metodologi audit

Versi: v1.0.0 — DISAHKAN Status: ✅ Disahkan oleh tim pendiri, 16 Apr 2026 Dokumen induk: ../MUST_READ.md Dokumen pendamping: ../architecture/agentic-audit-v1.md — menetapkan cara metodologi ini dijalankan oleh agen AI Tata kelola: lihat MUST_READ Bagian 15 (Proses Amandemen)

Amandemen 16 Apr 2026 (saat pengesahan): Semua proses audit yang ditetapkan dalam dokumen ini dijalankan di bawah Arsitektur Audit Agentik yang ditetapkan dalam dokumen pendamping di atas. Inti statistiknya tetap sepenuhnya deterministik; hanya orkestrasi, penjadwalan, dan penyusunan draf laporan yang bersifat agentik. Janji Reprodusibilitas 5 tahun (§7.5) tetap terjaga karena fungsi-fungsi statistiknya dikunci versinya, dan tindakan agen dicatat dalam buku besar asal-usul data (§2.4).

---

0. Pendahuluan

Dokumen ini adalah konstitusi teknis operasi audit Clash Watchdog AI. Dokumen ini menjawab satu pertanyaan:

Jika diberikan sebuah game crash dan N ronde data historisnya, bagaimana kami menentukan apakah game itu adil, mencurigakan, atau tidak adil?

Setiap audit yang pernah kami publikasikan harus dapat ditelusuri ke versi tertentu dari dokumen ini. Jika kami mengubah cara mengukur keadilan, versi dokumen ini ikut berubah — dan setiap audit historis tetap tertambat pada versi yang dipakai saat audit itu dibuat.

Inilah kalimat terpenting dalam dokumen ini:

Setiap kesimpulan audit harus dapat direproduksi lima tahun dari sekarang, oleh pihak ketiga mana pun, dengan memakai versi metodologi dan data mentah sebagaimana adanya pada saat publikasi, dan harus menghasilkan hasil yang sama.

Jika kami tidak dapat menjanjikan itu, kami tidak dapat memublikasikan kesimpulannya.

0.1 Hubungan dengan MUST_READ

Dokumen ini mewarisi dan menjalankan hal-hal berikut dari MUST_READ.md:

• Bagian 2 — Enam Hukum Konstitusional (terutama Hukum 4: tidak ada mistifikasi algoritmik)
• Bagian 4 — Arsitektur Produk (mesin data Status Game × Status Pemain)
• Bagian 11 — Sikap Hukum & Risiko (persyaratan proses yang adil)
• Bagian 15 — Proses Amandemen (cara dokumen ini dapat diubah)

Setiap pertentangan antara dokumen ini dan MUST_READ.md diselesaikan dengan mengikuti MUST_READ.md.

---

1. Definisi keadilan tiga kolom

Kami menolak definisi keadilan yang hanya bersumbu tunggal. Sebuah game crash dapat "adil secara matematis secara rata-rata" dan tetap "tidak adil dalam pengalaman". Sebuah game dapat "terdistribusi baik secara statistik" dan tetap "buram secara kriptografis". Karena itu, kami menilai setiap game pada tiga kolom independen, dan hanya game yang lolos cukup banyak kolom dengan bukti yang cukup yang memperoleh daftar putih publik.

1.1 Kolom A — Keadilan RTP (keadilan alokatif)

"Apakah pengembalian jangka panjang game sesuai dengan yang diklaim operatornya?"

Sifat yang diukur: persentase RTP (return to player / tingkat pengembalian) jangka panjang, interval kepercayaannya, dan stabilitas keunggulan bandar dari waktu ke waktu.

Statistik utama: RTP teramati vs. RTP yang dinyatakan. Penyimpangan diukur dalam poin persentase absolut.

Asumsi dasar: operator membuat klaim publik (misalnya, "RTP = 97%") yang kami pakai sebagai hipotesis nol. Kami menguji apakah data menolak hipotesis nol itu.

Berlaku untuk: setiap game crash, apa pun teknologinya. Ini kolom yang paling universal untuk dibandingkan.

1.2 Kolom B — Keadilan distribusi (keadilan prosedural)

"Apakah perilaku game ronde demi ronde terlihat seperti yang semestinya dihasilkan RNG yang dinyatakannya?"

Sifat yang diukur: distribusi lengkap pengali (titik crash), independensi ronde-ronde yang berurutan, serta tidak adanya pola anomali dalam panjang rentetan, kepadatan pembalikan, dan autokorelasi.

Statistik utama: uji kecocokan khi-kuadrat, Kolmogorov-Smirnov, Anderson-Darling, uji runs, autokorelasi pada lag 1 sampai 50, dan hukum Benford pada digit pertama pengali.

Asumsi dasar: game crash dengan RNG (generator angka acak) yang jujur menghasilkan pengali yang mengikuti distribusi teoretis yang diketahui (biasanya geometrik terpotong / hukum pangkat dengan bentuk M ~ 1/(1-U) dengan U seragam pada [0, 1-house_edge]). Kami menguji apakah data teramati cocok dengan distribusi ini dalam batas derau statistik.

Berlaku untuk: setiap game crash yang data tingkat rondenya cukup bagi kami (≥2.000 ronde untuk ambang minimum).

1.3 Kolom C — Keadilan kriptografis (keadilan yang dapat dibuktikan)

"Dapatkah kami memverifikasi secara matematis bahwa setiap hasil ronde persis sama dengan yang dikunci operator game untuk dihasilkan, sebelum ronde dimulai?"

Sifat yang diukur:

• Integritas rantai hash di sepanjang siklus hidup seed (nilai acak awal) provably fair (dapat dibuktikan adil).
• Konsistensi server seed yang dibuka dengan hash yang dikunci sebelumnya.
• Kebenaran penurunan HMAC(server_seed, client_seed || nonce).
• Pola rotasi server seed dari waktu ke waktu (kontribusi orisinal kami — lihat §4.3).

Pemeriksaan utama: verifikasi SHA-256 atas setiap hash yang dikunci terhadap pra-citra yang dibuka. Penurunan pengali dengan HMAC-SHA-256 untuk setiap ronde yang dapat diamati.

Asumsi dasar: game provably fair mengunci server seed (dengan memublikasikan hash SHA-256-nya) sebelum ronde apa pun dimainkan dengan seed itu. Ketika seed kemudian dibuka, pengamat mana pun dapat menghitung ulang setiap ronde dengan seed itu dan memverifikasi bahwa tidak ada yang dirusak.

Berlaku untuk: hanya game yang mengklaim beroperasi secara provably fair (saat ini: Stake Crash, BC.Game Crash, Roobet Crash, dan beberapa lainnya). Tidak berlaku untuk game RNG server tradisional (Aviator, JetX, Spaceman, dan lain-lain), yang mendapat N/A di kolom ini — bukan skor negatif.

1.4 Matriks putusan gabungan

Klasifikasi keseluruhan sebuah game bergantung pada berapa kolom yang memberikan hasil positif, negatif, atau tidak meyakinkan. Setiap N/A (kolom tidak berlaku) dikeluarkan dari penyebut.

Status "kandidat" baru menjadi final setelah lolos alur kerja Proses yang Adil di §6.

---

2. Pengumpulan data dan independensi sumber

Tidak ada satu sumber data pun yang dipercaya sendirian. Setiap audit dibangun dari tiga sumber independen, dan kesimpulan hanya dipublikasikan bila sumber-sumber yang disyaratkan saling cocok.

2.1 Tiga sumber

Sumber 1 — Pengungkapan resmi / publik Data publik milik operator game sendiri. Contohnya:

• Halaman riwayat publik provably fair (Stake, BC.Game, Roobet memperlihatkan log hash ronde demi ronde).
• Pengungkapan regulasi (Lei 14.790 di Brasil mewajibkan operator berlisensi memublikasikan metrik RTP).
• API publik yang diperlihatkan oleh klien game.

Jika operator mengubah atau menghapus data ini setelah kami mengamatinya, peristiwa itu sendiri menjadi titik data yang dicatat — kami menyimpan cuplikan yang tidak dapat diubah dari semua pengamatan Sumber 1.

Sumber 2 — Kontribusi komunitas Data yang dikirim pengguna melalui ekstensi browser Clash Watchdog AI, formulir input manual, dan OCR tangkapan layar opsional. Setiap kontribusi:

• Ditandai dengan pengenal kontributor berupa nama samaran (tidak pernah dikaitkan dengan identitas asli).
• Diberi cap waktu di sisi server pada saat pengiriman.
• Diperiksa silang terhadap kontribusi lain dari pengguna yang berbeda untuk rentang ronde yang sama.
• Dikeluarkan dari audit jika ada kontribusi yang tampak sebagai upaya peracunan data (pencilan di luar 6σ dari sumber lain pada rentang ronde yang sama ditandai dan dikarantina).

Sumber 3 — Akun perantara (proxy) yang dioperasikan sendiri Clash Watchdog AI mengoperasikan akun-akunnya sendiri yang diaudit pada setiap game sasaran, dengan taruhan minimum semata-mata untuk mengamati ronde yang kami ikuti dengan nilai nyata yang dipertaruhkan. Ini pendekatan "pembeli misterius" yang dipakai dalam perlindungan konsumen dan audit keuangan.

• Setiap akun perantara didanai dengan saldo tetap yang kecil (anggaran per game belum ditentukan, lihat §10).
• Akun dirotasi dan dibuat tidak saling berkorelasi untuk menghindari deteksi / perlakuan yang dibedakan.
• Setiap tindakan dicatat dengan cap waktu dan rekaman tingkat jaringan.
• Tidak ada akun perantara yang pernah berusaha untuk "menang" — tujuannya pengamatan, bukan keuntungan.

2.2 Aturan validasi silang

           ┌────────────┐
           │  Source 1  │
           │  Official  │
           └─────┬──────┘
                 │
   ┌─────────────┼─────────────┐
   │             │             │
   ▼             ▼             ▼
  cross        cross          cross
  check        check          check
   ▲             ▲             ▲
   │             │             │
   └─────────────┼─────────────┘
                 │
        ┌────────┴────────┐
        │                 │
  ┌─────▼──────┐   ┌──────▼──────┐
  │  Source 2  │   │   Source 3  │
  │ Community  │   │ Self-Proxy  │
  └────────────┘   └─────────────┘

Aturan publikasi:

• Ketiga sumber cocok dalam batas toleransi → kesimpulan dapat dipublikasikan dengan keyakinan penuh.
• Dua sumber cocok, yang ketiga tidak ada → kesimpulan dapat dipublikasikan dengan catatan "sumber parsial".
• Dua sumber cocok, yang ketiga tidak cocok → WATCHLIST, penyelidikan dibuka.
• Sumber 1 tidak cocok dengan Sumber 2 dan 3 (yaitu, operator melaporkan data yang berbeda dari yang diamati pengguna dan akun kami sendiri) → ini sinyal manipulasi terkuat yang mungkin ada dan langsung memicu peninjauan Daftar Hitam Darurat (lihat §6.3).

2.3 Ukuran sampel minimum (sementara, v1.0)

Ini jumlah ronde minimum yang diperlukan sebelum sebuah kolom "boleh berbicara". Di bawah ambang ini, kolom memberikan INCONCLUSIVE (tidak meyakinkan), seperti apa pun datanya.

Catatan — angka sementara. Ambang ini diturunkan dari analisis daya uji yang menargetkan kemampuan mendeteksi penyimpangan RTP sebesar 1% pada α = 0,05, β = 0,10. Nilai finalnya akan dikonfirmasi oleh lampiran teknis sebelum v1.0.0 disahkan.

2.4 Buku besar asal-usul data

Setiap catatan data mentah yang masuk ke alur audit kami ditandai dengan:

• source_id — sumber yang mana dari ketiganya
• collection_timestamp (UTC, ISO 8601)
• observation_timestamp (UTC, ISO 8601) — kapan ronde itu benar-benar terjadi
• collector_pseudonym (untuk Sumber 2) atau proxy_account_id (untuk Sumber 3)
• raw_payload_hash (SHA-256 dari muatan mentah yang tidak diubah)
• pipeline_version (hash commit kode penyerapan yang memprosesnya)

Buku besar ini hanya dapat ditambah. Catatan tidak pernah dihapus — jika sebuah catatan kemudian didiskualifikasi (misalnya, peracunan data terdeteksi), catatan itu ditandai tetapi tetap disimpan sebagai jejak audit.

---

3. Rangkaian statistik berlapis

Setiap audit menghasilkan keluaran pada dua lapisan sekaligus. Kedua lapisan harus selalu cocok: jika lapisan publik menyatakan "lolos" tetapi lampiran teknis menyatakan "gagal", audit itu tidak sah dan harus dijalankan ulang.

3.1 Lapisan publik (untuk pemain, jurnalis, regulator)

Singkat, mudah dipahami, muat dalam satu layar. Memakai bahasa sederhana dan sedikit metrik utama.

Lapisan publik setiap laporan audit berisi:

• Ringkasan Kolom A: RTP: observed 96.82% (±0.18%) vs. declared 97.00% → lencana lolos/gagal.
• Ringkasan Kolom B: Distribution fit p-value: 0.31 → lencana lolos/gagal, dengan satu kalimat tafsiran dalam bahasa sederhana.
• Ringkasan Kolom C: Provably-fair hash chain: verified for 12,430 consecutive rounds → lencana lolos/gagal, atau Not applicable.
• Putusan keseluruhan: salah satu dari 🛡️ WHITELIST, ⚠️ WATCHLIST, 🚫 BLACKLIST, beserta tingkat bukti (§5) yang menjadi dasar kesimpulan.
• Satu kalimat tafsiran dalam bahasa sederhana per kolom.
• Versi metodologi yang dipakai untuk menjalankan audit.
• Tanggal tinjauan berikutnya.

3.2 Lapisan lampiran teknis (untuk ahli statistik, akademisi, regulator)

Pengolahan statistik lengkap. Dipublikasikan bersama laporan publik, sebagai notebook Jupyter di GitHub, di bawah clashwatchdog-ai/audit-reports/<game-slug>/<date>/notebook.ipynb.

Lampiran teknis setiap audit berisi:

Untuk Kolom A (RTP):

• Rata-rata RTP teramati dengan interval kepercayaan 95% melalui bootstrap (10.000 pengambilan ulang sampel)
• Uji Kolmogorov-Smirnov yang membandingkan jendela bergulir RTP teramati dengan RTP yang dinyatakan
• Dekomposisi varians (di dalam sesi vs. antarsesi)
• Analisis tren: regresi linear RTP terhadap waktu untuk mendeteksi pergeseran

Untuk Kolom B (distribusi):

• Uji kecocokan khi-kuadrat dengan jumlah kelas ≥ 20
• Kolmogorov-Smirnov terhadap distribusi crash teoretis
• Anderson-Darling (memberi bobot lebih pada penyimpangan di ekor distribusi — penting untuk game crash)
• Uji runs untuk independensi serial
• Plot autokorelasi untuk lag 1 sampai 50
• Pemeriksaan hukum Benford pada digit pertama pengali
• Uji-uji terpilih NIST SP 800-22 (Fase 2+)
• Koreksi uji berganda: Benjamini-Hochberg dengan FDR = 0,05 untuk semua uji yang dilaporkan

Untuk Kolom C (provably fair):

• Verifikasi SHA-256 penuh atas setiap server seed yang dibuka terhadap hash yang dikuncinya
• Penghitungan ulang pengali dengan HMAC-SHA-256 untuk setiap ronde dalam jendela yang diverifikasi
• Analisis rotasi: distribusi masa pakai seed, korelasi rotasi dengan peristiwa tingkat pengguna (lihat §4.3)
• Pemeriksaan kesinambungan nonce: deteksi nonce yang terlewat atau terduplikasi

Artefak reprodusibilitas:

• Notebook Jupyter itu sendiri (dapat dijalankan)
• CSV data mentah (atau rujukan ke cuplikan yang tidak dapat diubah di danau data kami)
• Hash commit metodologi
• Spesifikasi lingkungan (requirements.txt atau pyproject.toml)
• Skrip reproduksi satu perintah (make reproduce atau python reproduce.py)

3.3 Perangkat

Implementasi acuan Fase 1:

3.4 Pembangunan bertahap

Kami tidak menerapkan setiap uji sejak hari pertama. Rangkaian statistik dibangun dalam fase-fase yang sejalan dengan strategi SEO/konten perusahaan — setiap kemampuan baru juga menjadi artikel pembaruan metodologi yang dipublikasikan.

Setiap peningkatan fase adalah kenaikan versi MINOR (v1.0 → v1.1 → v1.2), dengan catatan perubahan publik, dan diumumkan dengan jendela pemberitahuan awal 14 hari (lihat §6.4).

---

4. Verifikasi mendalam provably fair

Bagian ini merinci Kolom C dan merupakan bagian metodologi yang paling rumit secara teknis. Ini juga bagian tempat Clash Watchdog AI menghasilkan kontribusi riset orisinal: kerangka analisis rotasi di §4.3.

4.1 Pengantar provably fair (sebagai catatan)

Game crash provably fair yang umum bekerja sebagai berikut:

1. Operator membuat server_seed acak 256 bit.
2. Sebelum ronde apa pun dimainkan, operator memublikasikan SHA-256(server_seed) sebagai komitmen publik.
3. Untuk ronde n dengan seed ini, pengali diturunkan sebagai:

   hmac   = HMAC-SHA-256(key=server_seed, message=client_seed || nonce_n)
   hex    = first 52 bits of hmac, as a big-endian integer
   if hex == 0: multiplier = high_cap
   else:        multiplier = max(1.00, floor((2^52 * house_edge) / hex * 100) / 100)
   

   (rumus eksaknya berbeda-beda menurut operator — alur kami mencatat penurunan khusus setiap operator)
4. Setelah sejumlah ronde (biasanya 1.000 sampai 10.000, atau 24 jam), operator membuka server_seed. Pada saat itu, siapa pun dapat menghitung SHA-256(revealed_seed) dan membandingkannya dengan komitmen awal. Jika cocok, seed itu dikunci secara jujur sebelum ronde-rondenya dimainkan.
5. server_seed baru dibuat, komitmen baru dipublikasikan, dan siklus berulang.

4.2 Verifikasi rantai penuh (kemampuan Fase 1)

Untuk setiap siklus seed yang selesai pada setiap game yang dipantau, kami:

1. Mengambil hash komitmen awal (dari Sumber 1 + Sumber 3 secara independen).
2. Mengambil server seed yang dibuka.
3. Menghitung SHA-256(revealed_seed) dan membandingkannya dengan langkah 1.
4. Untuk setiap ronde n dalam [0, seed_lifetime - 1]:
   • Mengambil client_seed dan nonce sebagaimana dicatat oleh operator dan oleh akun perantara kami.
   • Menghitung ulang pengali dengan penurunan yang didokumentasikan operator.
   • Membandingkannya dengan pengali teramati dari Sumber 1, 2, dan 3.
5. Mencatat hasilnya di buku besar asal-usul data (§2.4).

Setiap ketidaksesuaian pada langkah mana pun adalah potensi ketidakcocokan hash, yang langsung menempatkan game di WATCHLIST dan memicu penyelidikan. Ketidaksesuaian yang terkonfirmasi (dapat direproduksi, lintas sumber) langsung menjadi Daftar Hitam Darurat.

4.3 Analisis rotasi (kemampuan Fase 2 — kontribusi orisinal Clash Watchdog AI)

Verifikasi rantai hash, dengan sendirinya, hanya dapat memastikan bahwa operator tidak melanggar komitmen yang sudah dibuatnya. Verifikasi itu tidak dapat mendeteksi serangan yang lebih halus: operator memilih kapan merotasi server seed dengan cara yang berkorelasi dengan hasil.

Contohnya: operator dapat secara jujur mengunci server_seed_1, secara jujur menjalankan 1.000 ronde dengannya, secara jujur membukanya — namun tetap memiringkan game demi keuntungannya dengan merotasi ke server_seed_2 (yang sudah dikunci sebelumnya) tepat pada saat rotasi menguntungkannya. Waktu rotasi menjadi permukaan serangan.

Analisis rotasi memeriksa distribusi masa pakai seed dan peristiwa rotasi, dan menanyakan:

1. Distribusi masa pakai. Apakah seed dirotasi dengan selang yang kira-kira teratur, seperti yang diklaim operator? Kami mencocokkan distribusi masa pakai seed teramati dengan kebijakan yang dinyatakan dan menghitung uji kecocokan K-S.

2. Korelasi peristiwa. Apakah rotasi berkorelasi dengan peristiwa tingkat pengguna yang dapat kami amati dari Sumber 3?

   • Rotasi tepat setelah kemenangan bernilai tinggi pada akun perantara?
   • Rotasi tepat sebelum taruhan akun perantara yang semestinya menang pada pengali yang luar biasa tinggi?
   • Waktu rotasi yang berkorelasi dengan puncak lalu lintas harian?

3. Pergeseran distribusi sebelum / sesudah rotasi. Apakah distribusi pengali dalam 100 ronde sebelum rotasi berbeda secara statistik dari 100 ronde sesudahnya? Diuji dengan Kolmogorov-Smirnov dua sampel.

4. Kesinambungan nonce. Dalam masa pakai satu seed, apakah semua nonce tercatat? Celah dalam urutan nonce mengisyaratkan ada ronde yang dimainkan tetapi tidak dicatat secara publik.

5. Verifikasi komitmen di muka. Operator provably fair yang aman mengunci rantai hash seed masa depan (komitmen di muka). Jika operator tidak mengunci di muka, jendela rotasi menjadi celah serangan. Kami mencatat dan memublikasikan kedalaman komitmen di muka untuk setiap game yang diaudit.

Keluaran analisis rotasi:

• Grafik linimasa rotasi (lapisan publik).
• Hasil uji statistik untuk masing-masing dari kelima pemeriksaan (lampiran teknis).
• "Skor Risiko Rotasi" keseluruhan (Clean / Low / Medium / High / Critical — bersih / rendah / sedang / tinggi / kritis).

Skor Risiko Rotasi Medium atau lebih buruk menurunkan Kolom C sebuah game dari positif menjadi tidak meyakinkan, meskipun verifikasi hash dasarnya lolos.

4.4 Mode pemantauan berkelanjutan

Untuk audit tingkat Gold (§5), analisis rotasi berjalan terus-menerus. Data diserap hampir secara real time dari Sumber 1 dan 3, dan Skor Risiko Rotasi diperbarui setiap hari. Setiap perubahan material pada skor dalam jendela pemantauan memicu siklus peninjauan.

---

5. Ambang klasifikasi bertingkat bukti

Kami tidak mengklasifikasikan game dengan satu garis batas, melainkan dengan tangga bertingkat yang beban buktinya menyesuaikan dengan ukuran sampel. Data yang lebih banyak menghasilkan ambang yang lebih ketat.

5.1 Tiga tingkat

Di bawah minimum Tingkat 1, tidak ada kesimpulan yang dipublikasikan — game ditandai Insufficient Data (data tidak cukup) di daftar pantauan.

5.2 Ambang daftar putih (sebuah game masuk WHITELIST jika semua aturan yang berlaku di bawah ini lolos)

5.3 Ambang daftar hitam (sebuah game masuk BLACKLIST jika aturan yang berlaku di bawah ini terpicu DAN ketiga sumber mengonfirmasi)

5.4 Daftar pantauan

Apa pun yang berada di antara ambang daftar putih dan daftar hitam. Daftar pantauan bukan kegagalan — itu keadaan pengamatan yang sedang berlangsung. Game di daftar pantauan dicantumkan dengan penjelasan yang mudah dibaca tentang apa yang belum ada atau belum meyakinkan.

5.5 Penyelarasan insentif (catatan strategi bisnis)

Karena ambang daftar putih makin ketat seiring naiknya tingkat, operator yang ingin naik (Provisional → Verified → Gold) harus menyediakan atau mengizinkan pengumpulan data yang lebih banyak. Ini berarti:

• Lebih banyak lalu lintas pengguna ke halaman analisis kami tentang game mereka (keuntungan SEO kami).
• Lebih banyak transparansi dari mereka (keunggulan data kami makin dalam).
• Lebih banyak peluang pengamatan berkelanjutan (analisis rotasi kami makin kuat).

Metodologi itu sendiri menjadi mekanisme penyelarasan insentif. Lihat MUST_READ §5.2 untuk implikasi komersialnya.

---

6. Proses yang adil

Tidak ada kesimpulan audit yang dipublikasikan tanpa melewati alur kerja Proses yang Adil yang sesuai dengan jenis putusannya. Bagian ini mengatur peralihan dari status kandidat internal ke pencantuman yang terlihat publik.

6.1 Peralihan positif (WATCHLIST → WHITELIST, atau kenaikan tingkat)

• Jendela: 0 hari (langsung dipublikasikan).
• Pemberitahuan: operator diberi tahu setelah publikasi, bukan sebelumnya.
• Alasan: peralihan positif memperbaiki status publik sebuah game dan tidak membawa risiko pencemaran nama baik. Mewajibkan jendela pemberitahuan untuk kabar baik hanya akan memperlambat pembangunan kepercayaan tanpa manfaat.

6.2 Peralihan negatif (WHITELIST/WATCHLIST → BLACKLIST)

• Jendela: 30 hari.
• Alur kerja:
  1. Audit internal selesai, status kandidat daftar hitam ditetapkan.
  2. Peninjauan dan persetujuan oleh kedua pendiri (MUST_READ §9).
  3. Paket pemberitahuan dikirim secara pribadi kepada operator, berisi:
     • Draf lengkap laporan publik dan lampiran teknis.
     • Semua data mentah yang dipakai.
     • Tautan ke versi metodologi (§7).
     • Undangan untuk menanggapi dalam 30 hari.
  4. Pilihan tanggapan operator selama jendela 30 hari:
     • Mengajukan bukti tandingan. Jika operator memberikan data yang menunjukkan kesimpulan kami keliru (misalnya, kami melewatkan sebuah sumber data, atau memakai rumus penurunan yang salah), kami menjalankan ulang audit. Jika audit ulang mengonfirmasi bahwa operator benar, kami mencabut status kandidat, menerbitkan koreksi publik dalam laporan transparansi berikutnya, dan game tetap pada pencantuman sebelumnya.
     • Menyanggah metodologi. Jika operator menyanggah metodologi kami tetapi tidak menyanggah data kami, teks sanggahannya dipublikasikan berdampingan dengan laporan kami ketika daftar hitam diberlakukan.
     • Tidak melakukan apa pun. Setelah 30 hari, status daftar hitam otomatis berlaku, dan catatan dilampirkan pada laporan yang menyatakan bahwa operator tidak menanggapi.
     • Memperbaiki game. Jika operator mengubah game secara material sebagai tanggapan atas temuan kami dan meminta audit ulang, kami memperlakukannya sebagai siklus audit baru. Laporan daftar hitam awal tetap berada di arsip publik sebagai catatan sejarah.
  5. Pada H+30: daftar hitam diberlakukan dengan tanggapan operator (atau catatan tidak adanya tanggapan) terlampir.

6.3 Daftar hitam darurat

Disediakan untuk situasi ketika jendela 30 hari akan menimbulkan kerugian berkelanjutan bagi pemain. Pemicunya:

• Eksploitasi aktif teramati merugikan pemain secara real time.
• Sumber 1 (pengungkapan operator sendiri) menyimpang dari Sumber 2 dan 3 — yang menunjukkan operator memublikasikan data palsu.
• Rantai hash putus tanpa penjelasan yang masuk akal dan tidak bersalah.
• Operator secara aktif memusnahkan bukti yang menjadi dasar audit kami.

Alur kerja:

• Jendela: 72 jam.
• Persetujuan yang diperlukan: kedua pendiri + satu penasihat eksternal (jurnalis, akademisi, atau mantan regulator — dipertahankan sebagai panel tetap beranggotakan 3 orang, yang salah satunya harus menandatangani).
• Format publikasi: Urgent Safety Notice (pemberitahuan keselamatan mendesak) singkat langsung dipublikasikan di halaman depan Clash Watchdog AI, dengan tautan ke laporan darurat lengkap ketika jendela 72 jam berakhir.
• Pemberitahuan paralel: laporan darurat dibagikan pada saat yang sama kepada regulator terkait, LSM perlindungan konsumen, dan sedikitnya dua jurnalis industri judi yang sudah mapan.

Daftar hitam darurat adalah tindakan yang jarang dan berat. Kami memperkirakan memakainya paling banyak 1–2 kali dalam 24 bulan pertama operasi.

6.4 Klasifikasi ulang karena peningkatan metodologi

Ketika perubahan versi metodologi MINOR atau MAJOR akan mengubah status pencantuman yang sudah ada:

• Jendela pemberitahuan awal: 14 hari.
• Yang kami publikasikan selama pemberitahuan awal:
  • Versi metodologi baru dan catatan perubahannya.
  • Daftar game yang akan berubah status di bawah metodologi baru, dan bagaimana perubahannya.
  • Penjelasan alasan peningkatan.
• Setelah 14 hari: metodologi baru berlaku. Laporan lama tetap tertambat pada versi metodologi aslinya (§7.3).

6.5 Aturan dua pendiri (hanya v1.0)

Selama 24 bulan pertama operasi, setiap perubahan pencantuman publik — selain pembaruan rutin daftar pantauan ke daftar pantauan yang bersifat positif — memerlukan persetujuan tertulis yang eksplisit dari kedua pendiri. Ini lapisan disiplin manual yang cukup memperlambat kami untuk menangkap kesalahan sebelum menjadi publik. Ketika tim tumbuh lebih dari dua orang, aturan ini digantikan oleh dewan peninjau formal.

---

7. Pemversian dan reprodusibilitas

Dokumen metodologi ini mengikuti Semantic Versioning 2.0.0. Setiap laporan audit publik tertambat secara permanen pada versi metodologi yang dipakai saat laporan itu dibuat.

7.1 Arti nomor versi

7.2 Aturan persetujuan

• PATCH: salah satu pendiri boleh melakukan commit.
• MINOR: kedua pendiri harus menandatangani.
• MAJOR: kedua pendiri + satu penasihat eksternal harus menandatangani. Diikuti pemberitahuan awal 14 hari sesuai §6.4.

7.3 Penambatan kesimpulan

Setiap kepala laporan audit mencantumkan:

game: stake-crash
audit_date: 2026-06-15
methodology_version: 1.1.0
evidence_tier: 2
verdict: WHITELIST
data_snapshot_hash: <SHA-256 of the full raw-data bundle>
notebook_commit: <GitHub commit hash of the reproduction notebook>

Ketika kami kemudian meningkatkan metodologi dari v1.1 ke v1.2, laporan ini tetap mempertahankan tambatan v1.1.0-nya. Laporan itu tidak dijalankan ulang secara diam-diam. Status pencantuman saat ini dapat digantikan oleh audit baru di bawah metodologi baru, tetapi laporan aslinya tidak pernah berubah.

7.4 Kebijakan arsip

Semua versi metodologi sebelumnya disimpan di bawah /methodology/archive/v1.0.0, /methodology/archive/v1.1.0, dan seterusnya. Versi lama tidak pernah dihapus. Siapa pun yang mengaudit riwayat kami harus dapat memverifikasi, lima tahun dari sekarang, aturan apa yang berlaku pada tanggal mana pun.

7.5 Janji reprodusibilitas (komitmen terpenting)

Setiap laporan audit yang dipublikasikan Clash Watchdog AI harus dapat direproduksi oleh pihak ketiga mana pun, lima tahun setelah publikasi, hanya dengan memakai: (a) cuplikan data mentah yang dirujuk di kepala laporan, (b) dokumen metodologi pada versi yang dikunci di kepala laporan, (c) notebook pada hash commit yang dikunci di kepala laporan. Reproduksi itu harus menghasilkan putusan yang sama. Jika tidak, laporan itu tidak sah saat dipublikasikan, dan kami akan menariknya kembali serta memublikasikan koreksi dalam laporan transparansi berikutnya.

Janji ini bukan sekadar cita-cita. Ini persyaratan fungsional dari setiap artefak yang kami hasilkan.

---

8. Aturan bahasa hukum

Metodologi kami bersifat teknis. Kata-kata kami juga harus teknis. Bahasa yang longgar adalah permukaan serangan hukum yang tidak mau kami buka.

8.1 Kata-kata yang kami pakai

• "Dalam N pengamatan, rata-rata RTP Game X terukur sebesar Y%, yang menyimpang W poin persentase dari Z% yang dinyatakan operator."
• "Distribusi pengali Game X gagal dalam uji kecocokan khi-kuadrat pada p = A terhadap distribusi teoretis yang diturunkan dari parameter yang dinyatakan operator."
• "Game X saat ini berada di daftar pantauan kami sambil menunggu pengumpulan sampel tambahan."
• "Rantai hash provably fair Game X tidak dapat diverifikasi untuk N ronde dalam jendela pengamatan."
• "Sampel kami belum cukup untuk mendukung kesimpulan saat ini."

8.2 Kata-kata yang tidak pernah kami pakai

• "Game X curang."
• "Game X dicurangi."
• "Game X adalah penipuan."
• "Jangan memainkan Game X."
• "Game X tertangkap mencuri dari pemain."
• "Kami memprediksi Game X akan crash di Y."
• Bahasa perintah atau ramalan dalam bentuk apa pun.

8.3 Kala dan modus

• Semua klaim faktual dalam bentuk lampau indikatif: "terukur", "gagal", "menyimpang".
• Semua pernyataan status saat ini dalam bentuk kini deskriptif: "berada di daftar pantauan kami", "sedang menunggu peninjauan".
• Tidak ada bentuk masa depan tentang hasil game. Tidak pernah. Satu-satunya bentuk masa depan yang kami pakai adalah tentang tindakan kami sendiri: "akan diaudit ulang pada tanggal X".
• Tidak ada modus pengandaian tentang niat operator. Kami menggambarkan data, bukan motivasi.

8.4 Aturan presisi angka

• Persentase dengan satu angka desimal di lapisan publik, tiga angka desimal di lampiran teknis.
• Interval kepercayaan selalu eksplisit (tidak pernah estimasi titik tanpa rentang).
• Nilai p dengan dua angka penting.
• Ukuran sampel selalu terlihat di layar yang sama dengan kesimpulannya.

---

9. Butir yang ditunda dan terbuka

Keputusan-keputusan ini ditandai untuk diselesaikan sebelum v1.0.0 disahkan. Keputusan ini didokumentasikan di sini agar tidak ada yang dapat berpura-pura melupakannya.

---

10. Peta jalan pembangunan bertahap (mengikat)

Ini urutan pembangunan sistem audit itu sendiri. Peta jalan ini mengikat dalam arti bahwa kami tidak akan merilis kesimpulan audit yang memakai sebuah kemampuan sebelum kemampuan itu dibangun dan diuji.

Fase 1 — bulan 0–3 (audit layak minimum)

• Kolom A: rata-rata RTP + interval kepercayaan bootstrap
• Kolom B: khi-kuadrat + Kolmogorov-Smirnov
• Kolom C: verifikasi rantai hash SHA-256 (rantai penuh, tanpa analisis rotasi)
• Sumber data: hanya Sumber 1 + Sumber 3 (penyerapan komunitas Sumber 2 ditunda ke Fase 2)
• Tingkat: hanya putusan Tingkat 1 (Provisional) yang dipublikasikan
• Publikasi yang diharapkan: 3 audit Provisional pada akhir Fase 1 (Stake Crash, BC.Game Crash, Roobet Crash)
• Artefak pembangunan: satu templat notebook Jupyter yang dapat dipakai ulang, satu alur penyerapan data, dan dokumen /methodology/audit-v1.md yang tayang di situs

Fase 2 — bulan 3–6 (kemampuan kolom penuh)

• Kolom A: + dekomposisi varians, + deteksi pergeseran
• Kolom B: + Anderson-Darling, + uji runs, + autokorelasi pada lag 1–50
• Kolom C: + analisis rotasi (kemampuan §4.3 penuh)
• Sumber data: penyerapan komunitas Sumber 2 dibuka (versi beta ekstensi browser)
• Tingkat: putusan Tingkat 2 (Verified) menjadi mungkin
• Publikasi yang diharapkan: 5 audit tambahan, kenaikan pertama ke Verified untuk game Fase 1
• Pada fase ini juga game non-kripto pertama (Aviator, diaudit melalui Sumber 1 + 2, tanpa Kolom C) diharapkan

Fase 3 — bulan 6–12 (pemantauan berkelanjutan + ketelitian akademis)

• Kolom B: + Benford, + uji terpilih NIST SP 800-22, + koreksi Benjamini-Hochberg
• Kolom C: + mode pemantauan berkelanjutan, + perbandingan rotasi antaroperator
• Sumber data: ketiga sumber sudah matang
• Tingkat: putusan Tingkat 3 (Gold) menjadi mungkin untuk audit yang berjalan paling lama
• Publikasi yang diharapkan: pembaruan berkelanjutan, total 10 game yang diaudit, daftar putih Gold pertama
• Kerja sama tinjauan akademis eksternal yang pertama

---

11. Orientasi tim (statistik)

Karena metodologi ini bergantung pada literasi statistik, dan belum ada pendiri yang dikonfirmasi secara publik memiliki latar belakang statistik formal, tim pendiri berkomitmen melakukan hal-hal berikut dalam 30 hari setelah dokumen disahkan:

Bacaan / latihan wajib:

1. Knuth, The Art of Computer Programming, Volume 2: Seminumerical Algorithms — bab 3 (Random Numbers). Ini pembahasan baku tentang pengujian RNG.
2. NIST Special Publication 800-22 Rev. 1a — A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications. Domain publik.
3. Wasserman, All of Statistics — bab 9 (Hypothesis Testing), 10 (Likelihood), 13 (Nonparametric).
4. Gentle, Computational Statistics — bab tentang bootstrap dan Monte Carlo.
5. Lehmann & Romano, Testing Statistical Hypotheses — bab 15 (Nonparametric) untuk teori uji kecocokan.

Orientasi praktis:

• Mereproduksi audit generator angka acak yang sudah dipublikasikan (NIST telah memublikasikan contoh laporan).
• Membangun audit ujung ke ujung berskala mainan atas game crash "jujur" yang disimulasikan dan game crash "sedikit bias" yang disimulasikan. Memverifikasi bahwa metodologi mengklasifikasikan keduanya dengan benar.
• Menjadwalkan konsultasi berbayar 2 jam dengan ahli statistik sebelum audit publik pertama dipublikasikan.

Jika dalam 30 hari kami menyimpulkan bahwa salah satu dari kami harus fokus penuh waktu pada statistik sementara yang lain menangani rekayasa dan konten, kami memperbarui MUST_READ §9 (Struktur Tim) sesuai keputusan itu.

---

12. Glosarium

Definisi singkat istilah yang dipakai di seluruh dokumen ini. Definisi yang lebih panjang beserta contohnya dikelola di kumpulan artikel Learn publik di situs web.

• Client seed — Masukan yang secara opsional dapat disesuaikan pemain untuk memengaruhi (tetapi tidak memilih) hasil ronde provably fair. Digabungkan dengan server_seed dan nonce melalui HMAC.
• Game crash — Game judi yang pengalinya naik dari 1,00× dengan laju yang berubah-ubah, dan pemain harus melakukan "cash out" sebelum pengali "crash" pada titik yang ditentukan secara acak.
• Proses yang Adil (Due Process) — Alur kerja kami untuk mengalihkan putusan internal menjadi pencantuman yang terlihat publik; lihat §6.
• Tingkat bukti (Evidence Tier) — Salah satu dari Provisional, Verified, atau Gold; menentukan seberapa ketat ambang klasifikasi daftar putih/daftar hitam; lihat §5.
• Rantai hash — Urutan kriptografis yang setiap server seed-nya dikunci terlebih dahulu melalui SHA-256 sebelum ronde apa pun dimainkan dengannya.
• HMAC — Kode autentikasi pesan berbasis hash dengan kunci. Dipakai dalam penurunan provably fair untuk mengikat hasil pada rahasia server sekaligus masukan pemain yang terlihat.
• Nonce — Penghitung yang bertambah satu untuk setiap ronde dalam masa pakai satu server seed. Digabungkan dengan client_seed dalam masukan HMAC.
• Provably fair — Sekelompok teknik yang memungkinkan pemain memverifikasi secara matematis, setelah kejadian, bahwa tidak ada hasil ronde yang diubah dari yang telah dikunci sebelum ronde dimulai.
• Skor Risiko Rotasi — Skor internal kami (Clean / Low / Medium / High / Critical) yang merangkum analisis rotasi §4.3 untuk sebuah game.
• RTP (Return to Player) — Persentase dari seluruh taruhan yang dibayarkan kembali kepada pemain dalam jangka panjang. Pelengkap keunggulan bandar.
• Server seed — Nilai acak 256 bit yang dibuat oleh operator game, dikunci melalui hash SHA-256 sebelum permainan, dan dibuka setelah semua ronde dengan seed itu dimainkan.
• Validasi Silang Tiga Sumber — Doktrin pengumpulan data kami: pengungkapan resmi + kontribusi komunitas + akun perantara yang dioperasikan sendiri, yang saling dibandingkan.
• Daftar pantauan (Watchlist) — Status publik kami untuk game yang sedang diaudit secara aktif tetapi belum memiliki cukup bukti (atau memiliki bukti yang bertentangan) untuk diberi putusan daftar putih atau daftar hitam.

---

13. Tindakan berikutnya (sebelum pengesahan v1.0.0)

1. Menyelesaikan semua butir yang ditunda dan terbuka (§9).
2. Menyelesaikan rencana orientasi statistik 30 hari (§11).
3. Menulis dan menguji notebook acuan Fase 1 pada pasangan simulasi jujur/bias.
4. Melibatkan pengacara hukum media untuk tinjauan satu jam atas §8 (aturan bahasa hukum).
5. Mendaftarkan sedikitnya satu akun perantara Sumber 3 di Stake Crash dan memulai penyerapan data.
6. Menyiapkan tabel buku besar asal-usul data di basis data Fase 1.
7. Menandatangani dokumen ini (kedua pendiri) dan mengubah statusnya dari DRAFT menjadi RATIFIED.

---

Draf disusun oleh tim pendiri, 15 Apr 2026. Versi 1.0.0-DRAFT — "Timbangan sebelum beban pertama."