“Apa yang tercatat?”
GTIN, nama, varian, harga, menu item, status aktif, dan stok yang disediakan oleh pemilik sistem masing-masing.
Inti gagasan
Graph bukan pengganti database produk.
Database tetap menyimpan golden record dan katalog operasional. Context graph menjadi lapisan relasi dan bukti yang menjelaskan bagaimana satu rekaman terhubung ke SKU lokal, menu aktif, modifier, sumber, aturan, dan koreksi.
“Kenapa ini berlaku di kasus ini?”
Relasi apa yang menghubungkan input ke entitas, sumber mana yang mendukungnya, scope tenant/outlet mana yang berlaku, aturan mana yang disetujui, dan konflik apa yang belum selesai.
Posisi yang disarankan: jangan membangun “graph universal” dulu. Mulai dengan graf commerce yang kecil, tenant-aware, berisi edge bernama dan bukti yang bisa ditelusuri, untuk mendukung tiga alur yang memang akan dijual/dipakai Navv.
01 · Model
Satukan alur, pisahkan domain kebenarannya.
Gunakan satu pola graph, tetapi jangan melebur produk kemasan, listing retailer, menu merchant, dan transaksi menjadi satu objek. Identitas global dan data operasional tenant punya pemilik serta izin yang berbeda.
Entitas referensi / canonicalEntitas milik tenantInput atau hasilBukti dan scope
Produk dan ontology
Identitas lintas channel, hanya dari sumber yang boleh digunakan.
ProductProductVariantGTINBrandManufacturerCategoryCanonicalDish
Operasi channel
SKU, listing, harga, ketersediaan, menu dan modifier milik retailer/restoran.
TenantOutletRetailerSKUListingMenuItemModifierOptionAvailability
Riwayat yang dapat diperiksa
Simpan klaim, asal data, resolusi, aturan, persetujuan, dan koreksi sebagai objek tersendiri.
SourceRecordEvidenceRuleResolutionRunConflictFeedbackProposal
| Edge bernama | Makna di Navv | Bukti minimum yang melekat |
|---|---|---|
has_gtin, variant_of, pack_contains | Identitas dan hierarki varian/unit dagang. | Identifier/sumber, jenis kemasan, tanggal dan status verifikasi. |
merchant_sku_for, listed_at | SKU/listing lokal menunjuk produk tertentu di tenant dan outlet tertentu. | Import atau konfirmasi retailer, tenant scope, masa berlaku. |
alias_of, canonicalizes_to | Nama lokal, alias lisan, atau variasi ejaan mengarah ke kandidat entitas. | Contoh asal, bahasa/channel, metode ekstraksi, confidence, keputusan reviewer. |
menu_item_of, offers_modifier, active_at | Item dan pilihan hanya berlaku pada menu/outlet/channel yang ditetapkan. | Merchant/POS, versi menu, periode aktif, harga dan batas pilihan. |
supports, contradicts, supersedes | Bukti mendukung/menyangkal klaim; revisi menggantikan aturan lama tanpa menghapus jejak. | Dokumen/record asal, pointer field/halaman/baris, waktu, reviewer, versi. |
Jangan jadikan similarity sebagai edge fakta. Kemiripan nama/gambar menghasilkan kandidat. Edge seperti
same_as atau resolves_to yang dipakai untuk tindakan perlu status yang jelas—candidate, reviewed, atau verified—beserta bukti dan siapa yang menyetujuinya.02 · Runtime
Mulai dari konteks kasus, lalu telusuri neighborhood yang relevan.
Jangan cari “teks yang mirip” di seluruh korpus. Resolve dulu tenant, outlet, channel, dan entitas kandidat; kemudian ikuti edge bernama yang diizinkan untuk jenis permintaan itu.
Terima input
Foto, barcode, suara, teks, atau katalog enterprise.
Pasang konteks
Tenant, outlet, channel, waktu, locale, tujuan dan hak akses.
Resolve node awal
Alias, GTIN, SKU, merchant, menu, atau source record.
Telusuri edge
Ambil hanya entitas, bukti, dan aturan yang berhubungan.
Evaluasi kasus
Scope, otoritas sumber, freshness, confidence dan konflik.
Jawab atau berhenti
Hasil beralasan; jika ambigu, klarifikasi atau minta review.
Scope fit
Aturan outlet/tenant yang tepat mengalahkan ontology global untuk harga, opsi, dan availability.
Path distance
Relasi lebih pendek dan sudah diverifikasi biasanya lebih kuat daripada inferensi lewat banyak edge.
Status & freshness
Approved dan masih berlaku lebih kuat daripada kandidat, sumber usang, atau menu yang sudah diganti.
Otoritas field
Brand/manufacturer untuk spesifikasi, retailer untuk listing/harga toko, restoran untuk menu dan modifier.
Corroborate / conflict
Bukti sejalan menambah dukungan; kontradiksi ditandai dan dijelaskan, bukan dirata-ratakan.
Abstain dengan alasan
Jika bukti atau edge penting hilang, kembalikan gap dan minta klarifikasi/review.
Bobot dan ambang keputusan harus dipelajari dari pilot per use case; confidence adalah dukungan untuk kasus ini, bukan angka akurasi universal.
“Nasi goreng kambing, pedas sedang, tanpa telur.”
Konteks awal adalah restoran/outlet yang dipilih pengguna. Graph membatasi resolusi ke menu aktif tenant itu; ontology membantu alias hidangan dan modifier, tetapi harga dan opsi valid hanya datang dari menu merchant.
Utterance→alias / canonical dish→MenuItem tenant→modifier yang ditawarkan→harga & availability aktif
Hasil API: draft cart terstruktur + item/modifier yang cocok + sumber menu + tingkat keyakinan. Jika restoran tidak menawarkan “pedas sedang” atau telur tidak bisa dihilangkan, minta klarifikasi—jangan membuat modifier baru. Order baru dikirim setelah konfirmasi.
Foto/barcode minuman kemasan → produk dan listing toko.
Resolver mencari identitas global dan listing tenant sebagai dua keputusan terpisah. Product identity tidak membuktikan harga atau stok toko.
OCR / barcode→candidate GTIN / variant→golden product→RetailerSKU→listing lokal
Hasil API: produk/varian kandidat, ukuran unit, field dan sumber yang mendukung, konflik pack size bila ada, serta tindakan confirm atau review. Harga/stok berasal dari POS tenant.
Bandingkan product master principal dengan katalog retailer.
GTIN exact, brand+title, unit, dan kemasan membentuk bukti berlapis. Konflik tidak dirata-ratakan menjadi satu confidence yang tampak pasti.
Supplier record→identity candidate←Retailer SKU→evidence & conflicts
Hasil API: matched / candidate / conflict / review, field-level differences, sumber, edge path, dan alasan. Hanya keputusan yang disetujui masuk sebagai pemetaan aktif.
03 · Governance
Aturan menempel pada scope, bukti, versi, dan pemiliknya.
Sumber terbaru tidak otomatis menang. Tenant, otoritas field, status persetujuan, tanggal berlaku, dan kontradiksi menentukan apakah sebuah klaim boleh dipakai.
Aturan yang terikat pada graph
- Harga dan availability menu diambil dari tenant/outlet aktif; ontology global tidak dapat menetapkannya.
- Retailer SKU hanya dipetakan setelah konfirmasi sumber atau operator; unit karton tidak disamakan dengan unit eceran.
- Global GTIN/product facts dan tenant listing dipisahkan; sumber berlisensi menentukan field yang boleh didistribusikan.
- In-car ordering harus mengembalikan draft dan meminta konfirmasi eksplisit sebelum submit.
Jejak minimum
source_iddan pointer ke record, halaman, baris, foto, atau event asal.tenant_id/namespace, sumber pemilik data, tujuan dan batas penggunaan.observed_at,valid_from/to, versi dan status: proposed/approved/rejected/superseded.- Metode ekstraksi/matching, confidence per field/relasi, reviewer/approver, dan alasan koreksi.
Tenant boundary
Cross-tenant alias, transaksi, harga, dan audio tidak ikut query tenant lain. Shared ontology hanya memuat data yang sah untuk dipakai bersama.
Feedback jadi proposal
Correction event menyimpan run, input, jalur graph, hasil, dan perubahan manusia. Ia menjadi proposal; approval manusia diperlukan sebelum pemetaan aktif berubah.
Konflik tetap terlihat
Dua sumber berbeda tetap tercatat bersama scope dan waktu. Jangan overwrite diam-diam; versi lama perlu tetap dapat direkonstruksi. Perubahan sumber menjadi proposal revisi untuk ditinjau.
Audio dan data personal: audio pesanan dan transcript bukan bahan graph bersama secara default. Simpan hanya bila ada dasar/izin yang tepat, minimalkan isi, batasi akses/retensi, dan gunakan untuk pembelajaran lintas tenant hanya jika perjanjiannya secara eksplisit mengizinkan.
04 · Kontrak API
Kirim keputusan beserta alasan yang bisa diperiksa.
Pemakai API tidak perlu menerima seluruh graph. Mereka memerlukan jawaban ringkas, jalur relasi yang relevan, bukti, dan status tindakan berikutnya.
| Field respons | Isi | Contoh makna |
|---|---|---|
status | matched, candidate, needs_review, clarify, not_found | Jangan menyamakan kandidat fuzzy dengan keputusan final. |
entity / candidate_ids | Identitas dan tipe entitas yang ditemukan. | ProductVariant, MerchantMenuItem, retailer listing. |
evidence[] | Field, nilai, source pointer, otoritas, freshness, status persetujuan. | Alasan audit/koreksi; bukan hanya “model bilang cocok”. |
path[] | Edge bernama yang menghubungkan input ke hasil. | alias_of → MenuItem → active_at Outlet. |
confidence, conflicts[] | Penilaian per kasus dan hal yang bertentangan/tidak diketahui. | Score perlu dikalibrasi terhadap data pilot; bukan janji akurasi. |
considered[], excluded[] | Ringkasan kandidat/bukti yang dipertimbangkan dan yang dikeluarkan karena scope, status, atau aturan. | Reviewer dapat memahami batas hasil tanpa menerima seluruh graph. |
next_action | confirm, ask_user, review, atau proceed. | Menjaga batas sebelum order, merge, atau publish. |
Desain praktis: endpoint bisnis yang sudah direncanakan tetap bisa dipakai—
/resolve/product, /resolve/menu, /catalogs/compare, /feedback. Context graph menjadi mekanisme di balik responsnya, bukan API graph mentah yang memaksa pelanggan memahami skema internal Navv.05 · Rencana awal
Bangun bukti dulu; pilih graph database belakangan.
Untuk tim kecil, context graph dapat dimulai sebagai model data relasional dengan entity ID, edge bernama, bukti, versi, dan scope tenant. Jangan membeli kompleksitas graph platform sebelum traversal nyata membutuhkannya.
Bangun: entity/evidence/edge minimum untuk satu kategori retail dan satu design-partner restoran; skema sumber, tenant, waktu, dan persetujuan.
Bukti: kasus nyata, contoh konflik, baseline koreksi, sumber dan izin tertulis.
Bangun: jalur bounded untuk product dan menu; filter tenant/outlet sebelum pencarian; respons evidence/path/status.
Bukti: hasil matching benar, abstain saat ragu, tidak ada kebocoran lintas tenant.
Bangun: run log, human review queue, feedback proposal, approval, konflik dan versioning.
Bukti: koreksi berulang memperbaiki resolusi dan setiap perubahan bisa dijelaskan.
Bangun: satu catalog reconciliation pilot dengan file/master yang diizinkan dan audit output.
Bukti: dipakai ulang, hasil diakui pelanggan, dan ada jalur nilai berbayar sebelum syndication/measurement.
Batas arsitektur awal: tabel relasional
entities, edges, evidence, rules, resolution_runs, dan feedback_proposals dapat mencukupi untuk graph kecil serta traversal terbatas. Pertimbangkan graph engine hanya jika pengukuran menunjukkan traversal multi-hop, query lintas domain, atau pengelolaan relasi makin sulit dipelihara di model tersebut.06 · Ukuran sukses
Ukur mutu keputusan, bukan banyaknya node.
Graph berharga jika meningkatkan keputusan atau auditability tanpa menambah risiko dan kerja operator.
Precision per status, duplicate merge salah, variasi GTIN/unit yang keliru.
Item dan modifier tepat, klarifikasi, cart correction, harga/availability freshness.
Field penting dengan sumber, coverage provenance, konflik tertangani, usia bukti.
Review rate, waktu sampai keputusan, koreksi berulang, perubahan yang ditolak.
Guardrail: nol tindakan lintas tenant; nol merge/publish/order otomatis saat status masih candidate atau konflik belum diputuskan. Uji terhadap baseline resolver/katalog sederhana sebelum mengklaim context graph lebih akurat.
Rekomendasi
Gunakan context graph sebagai “lapisan alasan dan kontrol”.
Model terbaik untuk Navv bukan graph yang memuat semuanya; melainkan graph yang menghubungkan data yang memang dibutuhkan untuk menyelesaikan permintaan pelanggan, dengan bukti dan batas akses yang ikut terbawa.
Relasi identitas + provenance
GTIN/varian, SKU/listing, alias/menu item, source, waktu, dan status review.
Rule traversal per use case
Aturan scope tenant, modifier aktif, otoritas field, konflik, dan ambang abstain.
Knowledge graph serba tahu
Jaringan resep, distributor, demand, harga pasar, dan supply chain lintas perusahaan hingga data dan haknya nyata.
Sumber
Rujukan dan batas interpretasi.
Rancangan ini mengadaptasi pola build → serve → learn dari penjelasan TrailHQ tentang Context Graph ke kasus Navv. Ini usulan arsitektur produk, bukan klaim bahwa Navv sudah mengimplementasikannya atau bahwa kinerja komersial Trail berlaku langsung untuk Navv.
TrailHQ — How the Context Graph Works · dibaca 23 September 2026.
Konsisten dengan data playbook, arsitektur shared core, dan dua dokumen riset CPG/menu.