Saat Validator Mulai Salah Tuduh

Saya buka terminal, jalankan ingest-blueprint-selftest.sh, dan melihat baris kegagalan yang nggak masuk akal. Validator menuduh ada data fakta yang tidak terverifikasi. Padahal, sumber yang dikutip emang sengaja saya kosongkan dari token fakta korpus itu.

Awalnya saya kira ini masalah regex yang terlalu sensitif. Saya sempat ngubah pola pencocokan string berkali-kali, berharap errornya hilang. Tapi suite pengujian tetap gagal dengan pesan yang sama.

Ternyata ini bukan bug di regex. Ini adalah blind spot dalam cara kita menguji sistem. Validator yang benar seharusnya diam saat menghadapi sumber yang emang tidak memuat klaim. Kalo dia tetap menuduh, berarti presisinya jebol.

Konsep presisi dalam evaluasi sistem emang didefinisikan sebagai true positive dibagi dengan jumlah total prediksi positif, atau true positive ditambah false positive [1]. Kalo false positive-nya tinggi, sistem jadi tidak bisa dipercaya dan cuma asal menembak.

Mengukur Tingkat Tuduhan Palsu

Untuk memperbaiki ini, saya menambahkan lapisan pengujian baru di commit c690354. Lapisan pertama bernama R80b, yang fokus mengukur false positive rate secara ketat.

Caranya cukup sederhana tapi disiplin. Saya ambil 20 kalimat dari korpus. Setiap kalimat dijalankan satu per satu sebagai halaman data mandiri. Halaman-halaman ini mengutip sumber src001 yang secara desain tidak memuat token fakta dari korpus tadi.

Validator yang sehat nggak boleh menuduh apa-apa di sini. Kalo validator menuduh, sistem akan menghitungnya sebagai WARN data-fact-unverified. Saya pasang batas toleransi yang keras. Kalo false positive melebihi 2 dari 20 kasus, atau lebih dari 10 persen, seluruh suite pengujian bakal gagal total.

Pendekatan ini terinspirasi dari praktik kontrol kualitas di laboratorium medis, di mana kontrol negatif harus selalu menghasilkan hasil negatif agar tes dianggap valid [2]. Tanpa kontrol negatif yang ketat, kita nggak akan tahu apakah alat ukur kita berfungsi atau cuma memberikan noise.

Kalo kamu jalanin tes ini, ngecek dulu output-nya. Kalo muncul peringatan di kasus yang seharusnya bersih, artinya konfigurasi validator masih terlalu agresif.

Menegakkan Reason-Code yang Eksak

Masalah kedua yang saya temukan adalah vagueness dalam pesan error. Dulu, validator cuma bilang "gagal" atau "invalid" tanpa konteks yang bisa diandalkan oleh sistem otomatis. Ini bikin proses debugging jadi susah saat pipeline berjalan di server produksi.

Di lapisan R97, saya bangun audit suite yang memaksa validator memberikan alasan penolakan yang spesifik. Ada 7 sub-kasus penolakan yang masing-masing harus menghasilkan reason-code yang eksak lewat asersi otomatis.

Kode-kode itu adalah digest-mismatch, stale-acc-content, quote-too-short, hash-not-in-quote, warn-undisposed, stage-not-final, dan render-drift.

Ini bukan sekadar pesan teks biasa buat dibaca manusia. Reason-code ini harus sesuai dengan spesifikasi tipe URI yang bisa dibaca mesin, sebagaimana standar pelaporan masalah yang umum dipakai di API modern [3]. Dengan begini, sistem lain bisa mem-parse kegagalan ini secara programatik tanpa perlu nebak-nebak makna di balik pesan error yang panjang dan berbelit.

Kontrol Positif sebagai Jangkar

Satu hal yang sering dilupakan saat kita giat menambahkan kasus kegagalan adalah memastikan kasus yang berhasil tetap berhasil. Penelitian menunjukkan bahwa bias dalam pengujian bisa melonjak drastis, bahkan hingga 200 persen, kalo kontrol positif diabaikan dalam desain eksperimen [4].

Makanya, di dalam suite R97, saya masukkan 1 kontrol positif. Ini adalah kasus audit valid yang wajib menghasilkan exit code 0. Kalo kontrol positif ini gagal, berarti ada perubahan regresif yang merusak logika inti validator, bukan sekadar penambahan fitur keamanan.

Selain itu, digest kanonik sepanjang 64 karakter heksadesimal diambil langsung dari field digest pada output pemeriksaan. Ini menjadi sumber kebenaran tunggal. Saya sengaja nggak menghitung ulang digest itu di dalam skrip pengujian.

Kenapa? Karena menghitung ulang justru membuka peluang perbedaan implementasi hashing yang bisa mengacaukan hasil tes. Saya pilih pendekatan ini karena konsistensi lebih penting daripada verifikasi ulang yang redundan.

Kalo sumber kebenarannya udah jelas dari output sistem, tugas kita cuma memastikan validator membacanya dengan benar, bukan ngajarin validator cara menghitung hash dari nol. Dalam pengujian ini, saya fokus pada skenario validator salah tuduh ukur presisi sebagai metrik utama untuk menjaga kualitas data.

Sources

• [1] scikit-learn developers, "Precision" — scikit-learn.org
• [2] Desai JR et al. "Utilization of Positive and Negative Controls to Examine Comorbid Associations in Observational Database Studies", Med Care, 2016 — doi:10.1097/MLR.0000000000000640
• [3] Nottingham M, Wilde E, Dalal S. "Problem Details for HTTP APIs", RFC 9457, IETF 2023 , rfc-editor.org
• [4] CDC. "About Laboratory Quality Assurance Programs" , cdc.gov