Governance untuk Knowledge Graph Internal: Siapa yang Boleh Mengubah Entity

Knowledge graph internal terlihat rapi di slide.

Brand A terhubung ke Product B.

Product B terhubung ke Market C.

CEO D terhubung ke Company A.

Semua node punya ID.

Semua edge punya label.

Masalah baru muncul ketika seseorang bertanya:

“Siapa yang boleh mengubah relationship ini?”

Ruangan diam.

Data engineer merasa graph adalah system mereka.

Marketing merasa entity brand adalah domain mereka.

Legal merasa legal entity tidak boleh disentuh sembarang orang.

Product team mengubah product taxonomy tanpa memberi tahu.

Agency menambahkan node baru karena butuh untuk GEO.

Enam bulan kemudian graph menjadi cantik secara struktur tetapi tidak ada yang berani menjamin kebenarannya.

Knowledge graph tanpa governance hanyalah database relasi.

Semakin banyak dipakai AI, semakin besar consequence kalau relasinya salah.

Mulai dari prinsip: entity punya owner

Jangan serahkan seluruh graph ke satu admin teknis.

Admin mengelola system.

Business owner mengelola truth.

Contoh:

Legal entity:
legal/corporate secretary.

Brand:
brand/marketing.

Product:
product.

Price:
commerce.

Office:
operations.

Certification:
compliance.

Person role:
HR/corporate secretary.

Client relationship:
account/legal sesuai contract.

Technical service:
engineering/product.

Setiap node dan relationship class punya authoritative owner.

Graph team tidak perlu tahu semua fakta.

Mereka memastikan owner punya workflow untuk menulis fakta dengan benar.

Edit right berbeda dari approval right

Seseorang boleh input data.

Belum tentu boleh approve.

Buat role.

Contributor:
mengusulkan perubahan.

Reviewer:
memeriksa evidence.

Approver:
menentukan perubahan berlaku.

Publisher:
mendorong ke production graph.

Auditor:
memeriksa history.

Untuk low-risk entity, role bisa digabung.

Untuk high-risk, pisahkan.

Contoh tag kategori blog mungkin tidak perlu approval legal.

Relationship “Company A owns Company B” perlu.

Risk-based governance.

Edge lebih berbahaya daripada kelihatannya

Node “PT ABC” benar.

Node “Brand X” benar.

Edge “ownedBy” salah.

Graph sekarang menghasilkan misinformation.

AI assistant bisa menyimpulkan Brand X dimiliki PT ABC.

Search system bisa menggabungkan data.

Reporting bisa salah.

External schema bisa ikut salah jika graph menjadi source.

Jadi governance tidak hanya fokus pada entity.

Relationship adalah claim.

Setiap edge punya:

Source.

Effective date.

Owner.

Confidence.

Status.

Last verified.

Relationship tertentu punya temporal dimension.

CEO of.

Partner with.

Distributor of.

Certified by.

Available in.

Subsidiary of.

Semua bisa berubah.

Kalau graph tidak menyimpan waktu, old truth menjadi current truth.

Stable ID jangan berubah karena nama berubah

Entity ID harus mewakili identity.

Nama adalah attribute.

Contoh perusahaan rebrand.

Jangan hapus entity lama lalu buat entity baru jika legal entity sebenarnya sama.

Update preferred label.

Simpan former name.

Effective date.

Relationship continuity.

Sebaliknya, dua legal entity berbeda jangan digabung hanya karena brand-nya sama.

Identity resolution harus punya rule.

Human reviewer diperlukan pada merge/split.

Auto-dedup based on name sangat berisiko.

“PT Maju Jaya” bisa banyak.

Use identifier.

Legal number jika boleh dan relevan.

Domain.

Address.

Parent.

Context.

Merge operation harus reversible.

Provenance adalah wajib untuk claim material

Knowledge graph internal sering punya triple:

Brand A -> hasOffice -> Jakarta.

Tanya:

Source?

Kalau jawabannya:

“Kayaknya dari website lama.”

Graph belum governance-ready.

Simpan provenance.

Source ID.

Owner.

Date retrieved.

Effective date.

Reviewer.

W3C PROV menawarkan model untuk merepresentasikan asal data melalui entity, activity, dan agent. Organisasi tidak harus mengadopsi seluruh ontology PROV. Tetapi prinsip bahwa data transformation dan origin harus traceable sangat relevan untuk graph.

Graph tanpa provenance sulit dipercaya ketika dua source conflict.

Approval workflow harus mengikuti relationship type

Buat rule table.

Brand alias:
marketing approve.

Legal name:
legal approve.

Office status:
operations approve.

Product capability:
product approve.

Security certification:
security/compliance approve.

Executive role:
corporate secretary approve.

Regulatory license:
compliance/legal approve.

Price:
commerce approve.

Jangan buat “knowledge graph team” sebagai penentu semua.

Mereka menjaga schema dan quality.

Business truth tetap milik domain owner.

Draft state sangat berguna

Jangan langsung publish perubahan ke graph production.

Use state:

Proposed.

Under review.

Approved.

Active.

Superseded.

Deprecated.

Rejected.

Conflicted.

Graph bisa menyimpan proposal tanpa membuatnya current truth.

Ini penting untuk automation.

Agent menemukan source baru:

“CEO mungkin berubah.”

Agent boleh membuat proposed edge.

Tidak boleh otomatis mengganti active CEO tanpa rule.

Human owner review.

Begitu approved, old edge diberi validUntil.

New edge active.

History utuh.

AI bisa membantu enrichment, bukan menentukan truth sendirian

Agent bisa:

Menemukan duplicate.

Suggest alias.

Extract organization name.

Identify potential relationship.

Flag stale source.

Propose taxonomy.

Compare data.

Bagus.

Tetapi high-impact graph mutation perlu control.

AI extractor mungkin salah memahami:

“Company A bekerja sama dengan Company B”

menjadi:

Company A owns Company B.

Ini catastrophic semantic jump.

Human review berdasarkan relationship risk.

Jangan auto-write semua extracted triple ke production.

Gunakan staging graph.

Confidence bukan substitute approval

Model bilang confidence 0,98.

Tidak berarti benar.

Confidence score bisa membantu prioritization.

Tidak boleh menggantikan evidence.

Rule:

High confidence + weak source = tetap weak evidence.

Low confidence + authoritative source = mungkin extraction issue.

Source authority dan semantic fit harus dinilai.

Jangan membuat graph yang memberi bobot terlalu besar pada model certainty.

Correction log harus terhubung ke graph

Jika relationship salah diperbaiki:

Simpan previous state.

Reason.

Source.

Who changed.

Timestamp.

Affected systems.

Retest.

Graph revision adalah correction event.

Jangan overwrite edge tanpa history.

Kenapa?

Downstream AI mungkin masih membawa old value.

Audit perlu tahu kapan truth berubah.

External source mungkin perlu correction.

Internal report lama mungkin memakai relationship lama.

Versioning memudahkan reconciliation.

Deletion perlu policy

Jangan delete entity hanya karena sudah tidak aktif.

Company dissolved tetap entity historis.

Product discontinued tetap bisa diperlukan untuk archive.

Employee former role tetap history.

Gunakan deprecation.

inactive.

validUntil.

supersededBy.

Hard delete hanya untuk:

Duplicate yang benar-benar salah.

Test data.

Privacy/legal requirement.

Data corruption.

Atau reason lain yang policy izinkan.

Historical graph lebih berguna daripada graph yang pura-pura dunia baru mulai hari ini.

Sensitive entity tidak boleh masuk hanya demi completeness

Knowledge graph bisa temptasi:

“Masukkan semua.”

Tidak.

Personal data.

Internal relationship.

Customer contract.

Employee details.

Security asset.

Confidential supplier.

Tidak semua perlu di-graph-kan.

Data minimization berlaku.

Define data class.

Public.

Internal.

Confidential.

Restricted.

Graph authorization mengikuti class.

Agent yang punya access public entity tidak otomatis boleh membaca confidential customer relation.

Governance graph harus bertemu access control.

Schema change juga perlu governance

Bukan cuma data.

Ontology berubah.

Relationship baru.

Definition berubah.

Example:

“partnerOf” terlalu vague.

Apakah technology partner?

Reseller?

Client?

Strategic alliance?

Joint venture?

Kalau edge semantics kabur, graph menghasilkan conclusion kabur.

Ontology committee kecil atau data governance owner perlu review schema.

Document:

Definition.

Allowed domain/range.

Examples.

Exclusions.

Effective version.

Migration rule.

Semantics adalah contract.

Jangan ubah diam-diam.

Knowledge graph untuk GEO perlu boundary

GEO team mungkin ingin graph membantu entity clarity, internal linking, schema generation, content planning, dan AI evidence.

Bagus.

Tetapi graph internal bukan proof bahwa external AI akan memahami atau menggunakan relationship sama.

Jangan menulis:

“Kami sudah memasukkan entity ke knowledge graph, jadi ChatGPT akan tahu.”

Tidak ada jaminan.

Graph adalah internal source of truth dan orchestration layer.

Value:

Consistency.

Governance.

Reusable structured facts.

Faster publishing.

Correction propagation.

Evidence mapping.

External visibility tetap bergantung pada public source, platform, crawl, retrieval, dan model behavior.

Internal graph meningkatkan operational quality.

Bukan remote control untuk AI engine.

Graph health metric harus fokus pada integrity

Jangan hanya:

Jumlah node.

Jumlah edge.

Growth.

Coverage.

Tambahkan:

Percentage material claims with source.

Stale edges.

Conflicted edges.

Unowned entity.

Unverified relationships.

Pending approval.

Duplicate entity.

Deprecated data still used.

Correction recurrence.

Unauthorized mutation.

Itu health.

Graph besar dengan 5 juta edge tidak otomatis bagus.

Graph kecil dengan high-integrity claim bisa jauh lebih valuable.

Siapa yang boleh mengubah entity?

Jawabannya:

Bukan “siapa yang punya akses admin”.

Yang boleh mengubah adalah actor yang punya authority sesuai jenis fakta, melalui workflow yang menjaga evidence, review, version, dan audit.

Contributor boleh propose.

Domain owner memverifikasi truth.

Graph system menerapkan policy.

High-risk relationship mendapat approval lebih kuat.

Automation membantu.

History tidak dihapus.

Sensitive data dibatasi.

Inilah governance.

Knowledge graph sering dijual sebagai fondasi AI.

Pernyataan itu hanya benar jika fondasinya sendiri bisa dipercaya.

Kalau siapa pun bisa mengedit node, edge tidak punya source, merge otomatis, dan history hilang, graph justru menjadi multiplier misinformation.

AI akan menerima struktur yang rapi.

Masalahnya struktur itu membawa fakta yang salah dengan sangat efisien.

Karena itu sebelum bertanya “bagaimana membuat knowledge graph lebih besar?”, organisasi sebaiknya bertanya:

Siapa owner setiap entity class?

Siapa boleh propose?

Siapa approve?

Apa evidence?

Kapan relationship berlaku?

Bagaimana conflict ditangani?

Bagaimana correction dicatat?

Apa yang tidak boleh masuk?

Kalau delapan pertanyaan itu jelas, graph mulai layak menjadi infrastructure.

Kalau belum, jangan memberi agent permission write penuh hanya karena diagramnya terlihat sophisticated.

Ada satu problem yang sering muncul setelah graph mulai dipakai banyak team: competing truth.

Product team menyebut feature “available”.

Sales menyebut “available on request”.

Engineering menyebut “beta”.

Marketing sudah publish “available”.

Graph harus menyimpan satu state yang operasional, tetapi siapa yang menang?

Gunakan conflict workflow.

Jangan overwrite source A dengan source B.

Buat conflict record.

Claim.

Source A.

Source B.

Owner.

Impact.

Temporary status.

Resolution deadline.

Reviewer.

Sampai resolved, downstream system bisa diberi rule untuk menampilkan wording konservatif atau tidak menggunakan claim tersebut.

Ini lebih sehat daripada graph memaksa satu truth karena field database tidak boleh kosong.

Graph governance juga perlu observability.

Setiap mutation penting menghasilkan event.

Node changed.

Edge added.

Edge deprecated.

Owner changed.

Source expired.

Conflict opened.

Conflict resolved.

Dengan event log, downstream system bisa sync.

Search index.

CMS.

Schema generator.

AI knowledge base.

Analytics.

Kalau graph berubah tetapi dependent system tidak tahu, source of truth hanya benar secara teori.

Operational truth membutuhkan propagation.

Terakhir, buat emergency correction privilege.

Kalau high-risk edge jelas salah, organization perlu cara cepat menonaktifkannya tanpa menunggu meeting governance mingguan.

Tetapi emergency action harus logged dan reviewed sesudahnya.

Emergency privilege bukan bypass permanen.

Ia adalah incident control.

Graph governance matang punya dua sifat yang kelihatannya bertentangan: cukup ketat untuk mencegah edit sembarangan, cukup cepat untuk menghentikan misinformation ketika error material ditemukan.