Cara Membuat Correction Log yang Berguna untuk Human dan Machine

Sebuah tim menemukan AI salah menyebut alamat cabang.

Content manager memperbaiki halaman website.

Selesai?

Belum tentu.

Dua minggu kemudian, error yang sama muncul lagi.

Semua orang mulai saling tanya.

“Kemarin yang diubah apa?”

“Source yang salah yang mana?”

“Sudah submit correction ke directory?”

“AI dites ulang kapan?”

“Alamat lama itu sebenarnya pernah benar atau dari awal salah?”

Tidak ada yang ingat persis.

Ini alasan correction log dibutuhkan.

Bukan karena organisasi ingin terlihat birokratis.

Karena correction tanpa memory organisasi akan berulang menjadi pekerjaan investigasi dari nol.

Correction log yang baik harus berguna untuk dua pembaca: manusia yang mengambil keputusan dan machine workflow yang perlu membaca status secara konsisten.

Mulai dari objek yang dikoreksi, bukan narasi panjang

Jangan mulai dengan memo:

“Pada hari Senin tim menemukan terdapat informasi yang kurang sesuai pada beberapa kanal digital…”

Terlalu kabur.

Mulai dengan claim.

Claim ID: LOC-JKT-004.

Entity: Brand X, Cabang Senopati.

Claim field: street_address.

Incorrect value: Jalan A No. 10.

Correct value: Jalan B No. 12.

Valid from: 1 Juli 2026.

Status: corrected.

Sekarang manusia tahu apa yang berubah.

Mesin juga bisa memproses field.

Correction log bukan sekadar changelog editorial.

Ia adalah registry perubahan fakta.

Bedakan typo, update, dan correction

Ini penting.

Typo:
Tulisan “Jakarat” menjadi “Jakarta”.

Update:
Jumlah cabang berubah dari 20 menjadi 22 karena dua cabang baru dibuka.

Correction:
Website sebelumnya menulis 20 padahal pada tanggal tersebut seharusnya 22.

Deprecation:
Produk A dihentikan dan tidak lagi dijual.

Supersession:
Policy v2 menggantikan policy v1.

Clarification:
Fakta tidak salah, tetapi wording lama menimbulkan interpretasi salah.

Kalau semua dilabeli “updated”, kita kehilangan semantics.

Untuk AI trust, semantics ini penting karena perubahan waktu berbeda dari kesalahan.

AI menyebut fakta lama yang pernah benar bukan kasus yang sama dengan AI mengutip fakta yang tidak pernah benar.

Correction log harus mempertahankan distinction tersebut.

Field minimum yang berguna

Untuk organisasi kecil, tidak perlu 40 kolom.

Mulai dengan:

Correction ID.

Entity.

Claim.

Previous value.

Current value.

Change type.

Effective date.

Detected date.

Corrected date.

Canonical source.

Affected URLs.

External source conflict.

Severity.

Owner.

Reviewer.

Status.

Verification date.

Notes.

Kalau ada AI monitoring:

Platform observed.

Query.

Answer snapshot.

Citation/source observed.

Retest result.

Sekarang satu correction punya lifecycle.

Detected.

Triaged.

Corrected internally.

External correction pending.

Retested.

Resolved.

Monitoring.

Correction log yang tidak punya status cepat berubah menjadi kuburan spreadsheet.

Human-readable dan machine-readable tidak harus dua sistem terpisah

Kita bisa punya satu data model.

Human view menampilkan tabel yang mudah dibaca.

Machine view bisa berupa JSON, CSV, database, atau API.

Contoh konsep:

claim_id = "PRICE-014"

entity_id = "product-x"

previous_value = "Rp499.000"

current_value = "Rp549.000"

change_type = "update"

effective_date = "2026-08-01"

source_url = halaman harga resmi

status = "verified"

Tidak perlu mempublikasikan seluruh database internal.

Tetapi struktur seperti ini memudahkan automation.

Sistem dapat:

Menandai artikel yang menyebut previous value.

Membuat queue update.

Memeriksa product feed.

Membandingkan chatbot knowledge.

Men-trigger retest.

Membuat human review task.

Inilah arti “berguna untuk machine”.

Bukan harus membuat schema rumit di website.

Correction log harus punya provenance

Siapa bilang current value benar?

Ini pertanyaan penting.

“Tim marketing bilang” bukan provenance yang cukup untuk semua claim.

Harga bisa berasal dari ERP.

Alamat dari operations master.

Legal name dari dokumen korporasi.

License dari regulator.

Product spec dari PIM.

Policy dari legal repository.

Leadership dari corporate secretary.

Setiap claim punya source of truth.

Correction log menyimpan referensi origin.

Kalau nanti ada conflict, reviewer tahu harus kembali ke mana.

NIST AI Risk Management Framework menekankan pentingnya governance, mapping, measurement, dan management dalam pengelolaan risiko AI. Correction log bisa dilihat sebagai control sederhana yang menghubungkan observasi error dengan tindakan dan monitoring, meski tentu NIST tidak memberikan template spesifik untuk “GEO correction log”.

Distinction ini perlu disebut.

Kita mengadaptasi principle governance.

Bukan mengklaim NIST merekomendasikan spreadsheet tertentu.

Correction log publik atau internal?

Tidak semua harus publik.

Internal log dapat menyimpan:

Owner.

Root cause.

System details.

Vendor.

Incident analysis.

Sensitive information.

Public correction note cukup untuk perubahan material yang memang relevan bagi pembaca.

Contoh:

“Diperbarui 4 Agustus 2026: alamat kantor Surabaya telah berubah. Versi sebelumnya mencantumkan alamat lama yang tidak lagi digunakan.”

Atau:

“Koreksi 7 Agustus 2026: artikel sebelumnya menyebut masa berlaku X secara keliru. Informasi telah disesuaikan berdasarkan dokumen Y.”

Public note meningkatkan transparency.

Tetapi typo kecil tidak perlu dibuat seperti crisis announcement.

Gunakan materiality threshold.

Correction log jangan menghapus sejarah

Kesalahan paling umum adalah overwrite.

Nilai lama hilang.

Tanggal tidak ada.

Tiga bulan kemudian tidak ada yang tahu kenapa angka berubah.

Untuk claim penting, simpan previous value.

Mark as superseded atau incorrect.

Jangan biarkan old value tetap dianggap current.

Machine workflow membutuhkan temporal semantics.

Valid_from.

Valid_until.

Superseded_by.

Correction_date.

Contoh:

CEO A valid sampai 30 Juni.

CEO B effective 1 Juli.

Kalau artikel Mei menyebut CEO A, artikel tersebut tidak salah secara historis.

Kalau halaman current masih menyebut CEO A, baru stale.

Tanpa temporal field, sistem correction sering “memperbaiki” sejarah.

Itu justru merusak provenance.

Hubungkan correction log dengan source conflict

Saat AI salah, jangan hanya memperbaiki website resmi.

Cari external source yang mungkin menyebabkan error.

Directory.

Marketplace.

Media.

Partner.

Cached PDF.

Old press release.

Social profile.

Public registry.

Record:

External source A: stale.

Action: correction submitted.

Status: pending.

External source B: historically correct.

Action: add update note, jika publisher bersedia.

External source C: duplicate entity.

Action: merge request.

Sekarang tim bisa membedakan apa yang dikontrol dan tidak.

Target bukan menghapus semua source lama.

Target membuat current fact lebih jelas dan conflict bisa dijelaskan.

Severity menentukan SLA

Correction log tanpa priority bisa membuat typo logo diproses lebih cepat daripada alamat klinik salah.

Buat severity.

Low:
cosmetic.

Medium:
mempengaruhi pemahaman.

High:
mempengaruhi buyer decision.

Critical:
health, legal, financial, security, atau operational harm serius.

Set response expectation.

Critical: immediate human escalation.

High: same-day atau sesuai SLA organisasi.

Medium: planned correction.

Low: backlog.

Jangan mengambil angka SLA dari internet lalu menganggap universal.

Sesuaikan dengan risk dan resource.

Yang penting rule sudah ada sebelum insiden.

Retest adalah bagian dari correction

Status “website fixed” bukan status final.

Setelah correction:

Cek page live.

Cek structured data jika field terkait memang dimarkup.

Cek feed jika product data.

Cek internal knowledge base.

Cek chatbot.

Cek key external profiles.

Kemudian retest query AI.

Catat result.

Kalau error tetap muncul, status bukan failed.

Bisa jadi “corrected at source, external propagation pending”.

Ini distinction penting.

Organisasi tidak punya kontrol atas kapan sistem pihak ketiga memperbarui retrieval atau learned representation.

Jangan menjanjikan timeline.

Monitor.

Correction log membantu kita membuktikan tindakan sudah dilakukan walaupun downstream answer belum berubah.

Machine-readable correction tidak sama dengan “AI pasti membaca”

Misalnya organisasi mempublikasikan changelog JSON.

Bagus untuk integrasi internal.

Tetapi jangan mengklaim semua AI engine akan otomatis membaca dan memahami file tersebut.

Tidak ada standar universal yang menjamin correction endpoint akan dipakai semua model.

Machine-readable di sini berarti data konsisten dan dapat digunakan sistem yang memang terhubung dengannya.

Untuk web publik, clarity manusia tetap penting.

Visible date.

Clear statement.

Canonical page.

Updated fact.

Accessible source.

Structured data yang sesuai jika ada supported vocabulary.

Jangan membuat hidden correction layer yang bertentangan dengan visible content.

Auditability lebih penting daripada kecanggihan.

Correction log juga perlu reason code

Kenapa error terjadi?

Unknown.

Internal stale data.

External stale source.

Wrong entity.

Manual input error.

Syndication error.

Policy changed.

Product changed.

Model synthesis error.

Citation mismatch.

Source conflict.

Unverified claim.

Reason code membuat trend terlihat.

Kalau 70 persen correction berasal dari internal stale data, problem bukan “AI”.

Problemnya content operations.

Kalau banyak error berasal dari duplicate entity, perbaiki identity architecture.

Kalau citation mismatch dominan, dokumentasikan.

Jangan membuat AI sebagai kambing hitam universal.

Monthly correction review

Sekali sebulan, jangan hanya menghitung berapa correction selesai.

Tanya:

Claim apa paling sering salah?

Entity mana paling banyak conflict?

Source mana paling sering stale?

Berapa high-severity item masih open?

Berapa correction recurring?

Berapa yang muncul lagi setelah resolved?

Apakah ada owner yang bottleneck?

Apakah source of truth jelas?

Apakah update process punya gap?

Correction log berubah dari spreadsheet reaktif menjadi observability system.

Ini jauh lebih valuable.

Format sederhana yang bisa dipakai sekarang

Satu baris per claim correction.

Jangan satu baris per halaman.

Karena satu halaman bisa punya lima fakta berbeda.

Dan satu claim bisa muncul di sepuluh halaman.

Gunakan stable claim ID.

Hubungkan claim ke affected assets.

Dengan model ini, ketika price berubah, tim tidak perlu mencari manual seluruh site.

Sistem bisa mengetahui asset mana yang bergantung pada claim tersebut.

Inilah jembatan menuju knowledge graph atau structured content yang lebih mature.

Tetapi jangan lompat terlalu cepat.

Spreadsheet yang disiplin lebih berguna daripada graph database canggih yang tidak di-maintain.

Correction culture lebih penting daripada correction tool

Organisasi yang sehat tidak malu mengoreksi.

Mereka punya process.

Mereka tidak menghapus jejak secara oportunistik.

Mereka membedakan historical truth dan current truth.

Mereka memberi owner.

Mereka retest.

Mereka belajar dari pattern.

Di era AI search, correction punya audience baru.

Bukan hanya manusia yang membaca halaman hari ini.

Informasi bisa disalin, dirangkum, diindeks, dikutip, atau muncul kembali dalam answer lain.

Karena itu perubahan fakta harus meninggalkan jejak yang cukup jelas.

Correction log yang baik tidak menjamin AI langsung berubah.

Ia melakukan sesuatu yang lebih fundamental.

Ia membuat organisasi tahu apa yang benar, apa yang pernah salah, kapan berubah, siapa yang bertanggung jawab, source mana yang harus diperbaiki, dan apakah correction benar-benar bertahan setelah diuji ulang.

Untuk human, itu accountability.

Untuk machine workflow, itu structured state.

Untuk AI trust, keduanya sama-sama penting.