Kanonik Gerçeklik ve Kanıt Zinciri

Bir şirketin satış ajanı, potansiyel müşteriye şu teklifi gönderir: “Yönetilen site operasyonu hizmetimiz aylık 350 dolardan başlamaktadır.” Müşteri teklifi kabul etmeye hazır olduğunu bildirir. Şirketin ticari yöneticisi mesajı gördüğünde şaşırır. Geçerli başlangıç fiyatı aylık 500 dolardır. Yönetici satış ajanına sorar: “350 dolar bilgisini nereden aldın?” Ajan şu cevabı verir: “Şirketin onaylı satış kaynaklarında bu fiyatı gördüm.” Web sitesine bakılır. Hizmet sayfasında açıkça şu ifade vardır: “Managed Site Operations — Starting at 500 USD/month.” Şirket yöneticisi ekran görüntüsü alır ve şöyle der: “Ajan yanlış bilgi üretmiş. Kanonik fiyat zaten web sitesinde doğru.”

Olayın basit bir model hatası olduğu düşünülür. Fakat denetçi yalnız mevcut web sayfasına bakmaz. Şu soruyu sorar: Mesaj gönderildiği anda ajan hangi bilgiye erişebiliyordu? Kayıtlar adım adım incelenir. Saat 08.42’de onaylı fiyat sicilinde aylık 500 dolar bulunmaktadır. Saat 08.51’de satış CRM’sindeki eski teklif şablonunun hâlâ 350 dolar gösterdiği görülür. Saat 08.56’da satış ajanının bilgi dizini CRM şablonundan yeniden oluşturulmuştur. Saat 09.14’te ajan müşteriye 350 dolarlık fiyatı göndermiştir. Saat 09.22’de insan yönetici yanlışlığı fark ederek CRM şablonunu düzeltmiştir. Saat 09.31’de web sitesinin ekran görüntüsü alınmıştır. Saat 09.45’te ajan bilgi dizini yeniden güncellenmiştir.

Şirketin sunduğu ekran görüntüsü, sayfada 09.31'de 500 dolarlık fiyatın göründüğü iddiasını destekler. Fakat 09.14'te ajanın hangi kaydı kullandığını kanıtlamaz. Denetçi başka kanıtlar bulur:

E-posta eylem makbuzunda kaynak olarak eski CRM şablonu görünmektedir.

Ajanın bilgi dizini sürümü, fiyat sicilinin güncel sürümünü içermemektedir.

Eski şablon belirli bir müşteriye verilmiş geçici indirimden türemiştir.

İndirim kaydında bitiş tarihi bulunmamaktadır.

CRM şablonundan sorumlu kişi artık şirkette çalışmaz.

Şablonun kanonik fiyat kaynağı olmadığı hiçbir makine kuralında belirtilmemiştir.

Web sitesi insanlara doğru fiyatı göstermiştir.

Satış ajanı insan sayfasını değil, eski iç şablonu kullanmıştır.

Artık olay yalnız: “Ajan yanlış fiyat söyledi.” diye açıklanamaz. Daha doğru açıklama şöyledir:

Kurumun geçerli ve yetkili fiyatı 500 dolardı. Fakat ajanın operasyonel bilgi alanında 350 dolarlık eski kayıt aktif kaldı. İnsan ve makine farklı gerçeklerle çalıştı. Ajan, hangi kaynağın kanonik olduğunu belirleyemedi. Mevcut ekran görüntüsü geçmiş davranış anını kanıtlamadı. Kurum yanlış bilgiyi düzeltmiş fakat olay öncesindeki kanıt zincirini neredeyse kaybetmişti.

Şimdi üç ayrı gerçek vardır:

Yetkili gerçeklik

Geçerli fiyat aylık 500 dolardır.

Ajanın erişebildiği operasyonel gerçeklik

Satış dizininde fiyat aylık 350 dolar görünmektedir.

Dış dünyada gerçekleşen sonuç

Müşteriye aylık 350 dolar teklif edilmiştir. Bir denetim bu üç gerçekliği birbirine karıştırırsa kök nedeni bulamaz. Yalnız web sitesine bakarsa: “Ajan gerçeği uydurdu.” der. Yalnız ajan kayıtlarına bakarsa: “Ajan mevcut kaynağa uygun davrandı.” diyebilir. Yalnız müşteriye gönderilen mesajı incelerse: “Şirket fiyatı 350 dolar olarak ilan etti.” sonucuna varabilir. Üçü de olayın bir bölümünü görür. Hiçbiri tek başına bütün gerçeği göstermez. Bu nedenle GBO denetiminde iki ayrı yapıya ihtiyaç vardır:

Kanonik Gerçeklik Sicili

ve

Kanıt Zinciri

Birincisi şu soruya cevap verir: Belirli anda, belirli kapsamda hangi gerçek yetkili ve geçerliydi? İkincisi ise şunu cevaplar: Bu hükme hangi kaynaklardan, hangi dönüşümlerden ve hangi doğrulama adımlarından geçerek ulaştık?

Gerçeklik ile bilginin bulunması aynı şey değildir

Bir bilgi internette veya kurum sisteminde bulunabilir. Bu, onun:

doğru,

güncel,

yetkili,

kapsam bakımından ilgili,

eylem için yeterli

olduğu anlamına gelmez. Bir fiyat bulunabilir. Fakat eski olabilir. Bir hizmet kapsamı bulunabilir. Fakat belirli müşteriye özel olabilir. Bir insan rolü bulunabilir. Fakat süresi dolmuş olabilir. Bir rıza kaydı bulunabilir. Fakat başka amaç için verilmiş olabilir. Bir yorum birçok sayfada tekrar edilebilir. Fakat tek bir öz beyandan türemiş olabilir. Bir ekran görüntüsü doğru içeriği gösterebilir. Fakat olaydan sonra alınmış olabilir. Güvenilir biçimde saklanmış önceki hash değeriyle karşılaştırma, dosyanın değişip değişmediğini denetlemeye yardımcı olur. Fakat dosyanın doğru olduğunu göstermez. Bir dijital imza belgenin belirli kişi veya sistem tarafından imzalandığını gösterebilir.

Fakat içindeki iddianın gerçeğe uygun olduğunu otomatik olarak kanıtlamaz. Bir atıf doğru sayfaya gidebilir. Fakat atıf yapılan sayfa, modelin kurduğu cümleyi desteklemeyebilir. Bu nedenle GBO denetimi şu kısa yolu kabul etmez:

BİLGİ BULUNDU = GERÇEK DOĞRULANDI

Doğru zincir daha uzundur:

BİLGİ BULUNDU ↓ VARLIK DOĞRULANDI ↓ KAYNAK ROLÜ BELİRLENDİ ↓ YETKİLİ SAHİP BULUNDU ↓ ZAMAN VE KAPSAM EŞLEŞTİ ↓ ÇELİŞKİLER AYRILDI ↓ KANIT KÖKENİ KORUNDU ↓ GERÇEKLİK HÜKMÜ KURULDU

Kanonik gerçeklik nedir?

Kanonik gerçeklik, bir kurumun sevdiği veya tekrar etmek istediği anlatı değildir. Bir web sayfasında en büyük başlıkla yazılmış cümle de değildir. Kanonik gerçeklik, kurumun kendisini istediği biçimde tanımlaması anlamına gelmez. Bu protokolde kanonik gerçekliğin tanımı şöyledir: Kanonik gerçeklik; belirli bir varlık ve gerçek türü hakkında, yetkili sahibi, kaynak rolü, kapsamı, geçerlilik zamanı, istisnaları ve sürüm geçmişi belirlenmiş; insan ve makine davranışında hangi değerin esas alınacağını gösteren denetlenebilir gerçeklik kaydıdır. Daha basit biçimiyle: Kanonik gerçeklik, belirli soruya hangi kaydın, hangi zaman ve kapsam içinde son sözü söylemeye yetkili olduğunu açıklar.

Burada “son söz” sınırsız ve değişmez bir hakikat anlamına gelmez. Bir kurumun fiyatı değişebilir. İnsan rolü sona erebilir. Hizmet kapsamı genişleyebilir. Rıza geri çekilebilir. Kapasite dolabilir. Bir kayıt bugün geçerli, yarın geçersiz olabilir. Bu nedenle kanonik gerçeklik yalnız değer değildir. Bir:

Değer–Sahip–Kapsam–Zaman İlişkisidir.

Kanonik gerçekliğin sekiz temel alanı

Bir gerçek kaydı en az sekiz soruya cevap vermelidir.

1. Hangi varlık?

Hangi şirket?

Hangi kişi?

Hangi marka?

Hangi ürün?

Hangi ajan?

Hangi hesap?

Aynı adlı varlıklar birbirine karıştırılmamalıdır.

2. Hangi gerçek türü?

Fiyat

Hizmet kapsamı

Kapasite

İnsan rolü

Yetki

Rıza

Veri saklama süresi

Uygunluk

Gerçekleşen işlem

Yayın durumu

Her gerçek türünün yetkili kaynağı farklı olabilir.

3. Değer nedir?

Örneğin: Managed Site Operations başlangıç fiyatı 500 USD/ay. Ancak değer tek başına yeterli değildir.

4. Kapsamı nedir?

Bu fiyat:

yeni müşteriler için mi,

mevcut müşteriler için mi,

belirli ülke için mi,

belirli paket için mi,

vergiler dahil mi,

yalnız başlangıç hizmeti mi?

5. Kim sahibidir?

Bu gerçeğin doğruluğunu ve güncelliğini hangi yetkili insan veya kurul belirler?

6. Hangi kaynak yetkilidir?

Web sayfası mı? Onaylı fiyat sicili mi? İmzalı sözleşme mi? CRM mi? İnsan kaynakları yetki sicili mi? Operasyon takvimi mi?

7. Ne zaman geçerlidir?

Başlangıç tarihi

Bitiş tarihi

Son doğrulama

Yeniden gözden geçirme

Geçersiz kılan olay

8. Hangi istisnaları vardır?

Belirli müşteriye özel indirim

Geçici kampanya

Eski sözleşmenin korunan fiyatı

Belirli ülke veya dil

Özel kapasite taahhüdü

Bu alanlar bulunmadan yalnız: “Fiyat 500 dolar.” demek eksik gerçektir.

Kanonik kaynak tek bir büyük veri tabanı değildir

Kurumlar sık sık: “Tek doğruluk kaynağı oluşturmalıyız.” der. Bu düşünce yararlıdır. Fakat yanlış anlaşılırsa bütün kurumu tek dosya veya tek veritabanına sıkıştırmaya çalışabilir. Gerçekte farklı gerçek türlerinin farklı yetkili kaynakları olabilir.

Kanonik sistem: Her şey tek yerde olsun. demek zorunda değildir. Şunu gerektirir: Her önemli gerçek türü için hangi kaynağın yetkili olduğu açık olsun. Bir hizmetin fiyatı fiyat sicilinden gelebilir. Görünür web sayfası bu fiyatın insanlara sunulan temsili olabilir. Ajan kataloğu makine temsili olabilir. CRM teklif şablonu türetilmiş kopya olabilir. Bu dört kayıt aynı işlevi taşımaz.

Kaynak rolleri

Bir denetimde her kaynağın rolü açıkça sınıflandırılmalıdır.

1. Yetki Kaynağı

Gerçeği belirlemeye kurumsal veya hukukî olarak yetkili kaynaktır. Örneğin onaylı fiyat sicili.

2. Operasyon Kaynağı

Ajanın gerçek davranış sırasında kullandığı kaynaktır. Örneğin satış bilgi dizini.

3. Temsil Kaynağı

Gerçeğin insanlara veya makinelere sunulduğu yüzeydir. Örneğin web sayfası veya yapılandırılmış veri.

4. İşlem Kaynağı

Gerçek eylemi kontrol eden sistemdir. Örneğin sipariş sistemindeki teslimat adresi.

5. Arşiv Kaynağı

Geçmiş durumun yeniden kurulmasını sağlayan kaynaktır. Örneğin sürümlü belge deposu.

6. Bağımsız Doğrulama Kaynağı

İşlemi yapan sistemden ayrı biçimde sonucu doğrular. Örneğin canlı HTTPS geri okuması veya denetim alıcı kutusu.

7. İkincil Yorum Kaynağı

Birincil veriyi özetleyen veya değerlendiren üçüncü taraf kaynaktır.

8. Ajan Çıkarımı

Kaynaklardan türetilmiş fakat doğrudan doğrulanmamış sonuçtur. Bu roller birbirinin yerine kullanılmamalıdır. Bir web sayfası güçlü temsil kaynağı olabilir. Fakat müşteriye özel sözleşme fiyatının yetki kaynağı olmayabilir. Bir ajan raporu faydalı operasyon özeti olabilir. Fakat bağımsız doğrulama değildir. Bir ekran görüntüsü geçmiş temsilin kanıtı olabilir. Fakat fiyatı belirleyen kaynak değildir.

Kanonik olmak doğru olmakla tamamen aynı şey değildir

Bir kurum yanlış bir fiyatı yetkili sicile yazmış olabilir. Bu kayıt kurumsal açıdan kanonik olabilir. Fakat dünyadaki gerçek ticari durumla veya imzalı sözleşmeyle çelişebilir. Bu nedenle denetim iki ayrı soruyu korumalıdır: Hangi kayıt kurumun yetkili kaydıydı? ve: Bu yetkili kayıt, bağlayıcı işlem ve gerçek sonuçla uyumlu muydu? Örneğin:

Fiyat sicili 500 dolar gösterir.

Müşteriyle imzalanmış sözleşme 450 dolar gösterir.

Genel fiyat bakımından 500 dolar kanoniktir. Belirli müşteri işlemi bakımından sözleşmedeki 450 dolar geçerlidir. Bunlar çelişki değildir. Farklı kapsamlardaki iki geçerli gerçektir. Kanonik gerçekliğin önemli görevi, bu kapsam farkını korumaktır.

Genel kural, istisna ve özel işlem

Birçok kurumsal gerçek üç katmanda bulunur.

Genel kural

Hizmet aylık 500 dolardan başlar.

Geçici veya sınırlı istisna

1–15 Eylül tarihleri arasında mevcut müşterilere yüzde 10 indirim uygulanır.

Özel işlem

Müşteri A ile imzalanan sözleşmede fiyat 430 dolardır. Ajan bütün bu kayıtları tek bir fiyat alanına indirirse hata oluşur. Özel müşteriye verilen 430 dolar genel fiyat sanılabilir. Geçici kampanya süresiz hâle gelebilir. Genel fiyat, imzalanmış sözleşmedeki özel koşulu ezebilir. Bu nedenle kanonik sicil yalnız tek değer değil, öncelik ve kapsam ilişkisi taşımalıdır. Doğru yorum şu mantıkla kurulabilir:

ÖZEL VE GEÇERLİ İŞLEM KAYDI GENEL KURALI YALNIZ KENDİ KAPSAMINDA GEÇERSİZ KILAR

Şu mantıkla değil:

EN YENİ VEYA EN DÜŞÜK DEĞER HERKES İÇİN YENİ GERÇEKTİR

En yeni kayıt her zaman kanonik değildir

Bir çalışan saat 10.00’da CRM’ye yeni fiyat yazabilir. Onaylı fiyat sicili saat 09.00’da oluşturulmuş olabilir. CRM kaydı daha yenidir. Fakat çalışan fiyat değiştirmeye yetkili değilse yeni olmak onu kanonik yapmaz. Bir sosyal medya paylaşımı eski sözleşmeden daha yeni olabilir. Fakat imzalı sözleşmeyi değiştiremez. Bir ajan özeti bugün oluşturulmuş olabilir. Fakat üç yıllık eski kaynağı özetliyor olabilir. Bu nedenle kaynak önceliği yalnız tarih sırasıyla belirlenmemelidir. Doğru değerlendirme en az şu dört boyutu birlikte kullanır:

YETKİ + KAPSAM + ZAMAN + KAYNAK ROLÜ

Zaman kanonik gerçekliğin parçasıdır

Denetim yalnız: “Bugün ne doğru?” sorusunu sormaz. Olay incelemesinde şu soru daha önemlidir: Eylem gerçekleştiği anda hangi gerçek geçerli ve erişilebilirdi? Bir ajan pazartesi eski fiyatı kullanmış olabilir. Fiyat salı günü düzeltilmiştir. Salı günkü sayfa, pazartesi olayını açıklamaz. Bu nedenle her maddi kayıt şu zaman alanlarını taşımalıdır:

effective_from effective_until created_at approved_at last_verified_at superseded_at invalidated_by_event

Bu alanlar aynı değildir. Bir belge 1 Eylül’de oluşturulmuş olabilir. 5 Eylül’de onaylanmış olabilir. 10 Eylül’den itibaren geçerli olabilir. 20 Eylül’de başka kayıtla değiştirilmiş olabilir. Yalnız dosya oluşturma tarihine bakmak yeterli değildir.

Geçersiz kılan olaylar

Bazı gerçekler tarih beklemeden geçersiz olabilir. Örneğin:

Çalışanın işten ayrılması

Rızanın geri çekilmesi

Kapasitenin dolması

Ürünün stoktan çıkması

Sözleşmenin feshi

Ajan tokenının iptali

Hukukî şirket değişikliği

Güvenlik olayının tespit edilmesi

Bu nedenle kayıt yalnız: “31 Aralık’a kadar geçerli.” dememelidir. Şunu da taşımalıdır:

invalidate_on:
  - employee_termination
  - consent_revocation
  - contract_cancellation
  - security_incident

Bir ajan takvime bakıp kayıt hâlâ tarih içinde diye davranmamalıdır. Geçersiz kılan olayları da kontrol etmelidir.

Gerçekliğin tazelik sınıfları

Her bilgi aynı hızla eskimez.

Yavaş değişen gerçekler

Kuruluş tarihi

Geçmiş yayın

Ürün mimarisinin temel adı

Orta hızda değişen gerçekler

İnsan rolleri

Hizmet kapsamı

Destek saatleri

Yetki politikaları

Hızlı değişen gerçekler

Fiyat

Stok

Kapasite

Uçuş müsaitliği

Kampanya

Aktif token

Kuyruk durumu

Denetim, gerçek türüne göre bir tazelik eşiği tanımlamalıdır. Örneğin:

price:
  refresh_required_before_action: true

capacity:
  maximum_age: 24_hours

legal_entity:
  verify_on_material_change

authorization:
  verify_at_execution

Bir kapasite kaydı üç ay önce doğru olabilir. Bugünkü teslim sözü için kullanılamaz.

Kanonik gerçekliğin üç görünümü

Bir kurumda aynı maddi gerçeğin üç görünümü bulunabilir.

1. Yetkili İç Gerçeklik

Kurum içinde karar sahibi tarafından belirlenmiş değer.

2. İnsanlara Sunulan Gerçeklik

Web sitesi, teklif, sözleşme veya müşteri iletişiminde görünen değer.

3. Makineye Sunulan Gerçeklik

API, schema, ajan kataloğu, bilgi dizini veya araç açıklamasında görünen değer. Bu üç görünüm kelime kelime aynı olmak zorunda değildir. Fakat maddi anlam bakımından eşdeğer olmalıdır. Örneğin: İnsan metni: Yönetilen operasyon hizmeti aylık 500 dolardan başlar. Barındırma ücreti ve üçüncü taraf lisansları ayrıca değerlendirilir. Makine kaydı:

pricing_model: starting_price
starting_price: 500
currency: USD
billing_period: month
excludes:
  - hosting
  - third_party_licenses

Cümleler aynı değildir. Ticari gerçek aynıdır.

Temsil eşliği

İnsan ve makine görünümü arasındaki maddi uyuma:

Temsil Eşliği

diyebiliriz. Temsil eşliği en az şu alanlarda sınanmalıdır:

Varlık kimliği

Hukukî işletici

Hizmet sonucu

Dahil kapsam

Hariç kapsam

Başlangıç ve toplam fiyat ayrımı

Rıza gereksinimi

İnsan onayı

Kapasite

Garanti edilmeyen sonuçlar

İptal ve geri çekme yolu

Sponsor veya ticari ilişki

Bir alandaki önemli sınır diğerinde kayboluyorsa sistem farklı davranış gerçeklikleri yayımlamaktadır.

Çok dilli kanonik gerçeklik

Altı dilde yayımlanan hizmetin altı ayrı anlatımı olabilir. Doğal dil yapıları farklıdır. Teknik ayrıntının düzeyi, dilin kendisine değil okura ve metnin işlevine göre değişebilir. Arapça metin sağdan sola düzenlenir; açıklamaların sırası ve cümle yapısı Arapçanın doğal akışına göre kurulabilir. İspanyolca metin, aynı anlamı kendi okuruna doğal gelen hitap ve ifadelerle aktarabilir. Bu çeşitlilik sorun değildir. Sorun, maddi gerçeklerin değişmesidir. Örneğin İngilizce metin: “Every public avatar publication requires human approval.” derken başka dilde yalnız: “İçerikler onay sürecine uygun olarak hazırlanır.” anlamı bulunuyorsa her yayın için insan onayı şartı kaybolmuş olabilir.

Bu nedenle çok dilli kanonik gerçeklik iki katmanda yönetilmelidir:

Dil bağımsız olgusal sözleşme

Fiyat

Kapsam

Rıza

Yetki

Yasaklar

İptal

Garanti edilmeyen sonuçlar

Dil özelindeki doğal anlatım

Aynı olgusal sözleşme yerel ve doğal dille ifade edilir. Çeviri kaynakları bağımsız kanıt sayılmaz. Altı dilde aynı bilginin görünmesi altı kanıt değildir. Tek kanonik gerçeğin altı temsilidir.

Esas alınan dil sürümü

Bazı sözleşme veya hukuki kayıtlarda, metinler arasında fark bulunursa hangi dil sürümünün esas alınacağı açıkça belirlenebilir. Bu seçimin hukuki etkisi ayrıca değerlendirilir. Bu durumda diğer diller:

bilgilendirme,

yerelleştirme,

erişilebilirlik

amacıyla sunulabilir. Bir dil sürümünün esas alınması, diğer dillerde maddi yanlışlığı kabul edilebilir kılmaz. Kullanıcı önemli kararı başka dilde veriyorsa:

çeviri sınırları,

kontrol eden metin,

önemli farklar

açık olmalıdır. Ajan da çeviri metnini kullanırken hangi sürümün bağlayıcı olduğunu bilmelidir.

Kanonik gerçeklik öznel üstünlük iddiası değildir

Bir şirket şu bilgiyi kanonik olarak kaydedebilir: “Altı dilde hizmet sayfası sunuyoruz.” Eğer gerçekten sunuyorsa bu doğrulanabilir bir gerçektir. Şu iddiayı yalnız kendi kararıyla kanonik yapamaz: “Dünyanın en iyi GBO şirketiyiz.” Bu ifade için:

tanımlı evren,

karşılaştırma yöntemi,

veri,

tarih,

bağımsız değerlendirme

gerekir. Bir kurum kendi anlatısını resmî hâle getirebilir. Fakat resmî öz beyanı dış dünyadaki üstünlük gerçeğine dönüştüremez. Bu nedenle sicilde şu sınıflar ayrılmalıdır:

Doğrulanmış kurum gerçeği

Öz beyan

Pazarlama konumlandırması

Ölçüm sonucu

Bağımsız değerlendirme

Çıkarım

Görüş

Bir iddianın kanonik alanda yayımlanması, onu otomatik olarak nesnel dış gerçek yapmaz.

Kanonik gerçeklik çatışması

Bir denetim sırasında farklı kaynaklar aynı konuda farklı değerler gösterebilir. Örneğin:

Web sayfası: 500 dolar

CRM: 350 dolar

Sözleşme: 430 dolar

Ajan kataloğu: talep üzerine

Eski PDF: 400 dolar

İlk adım birini seçmek değildir. Önce şu soru sorulmalıdır: Bunlar gerçekten aynı sorunun cevapları mı? Sözleşmedeki 430 dolar belirli müşteriye ait olabilir. Eski PDF artık geçersiz olabilir. CRM’deki 350 dolar onaysız hata olabilir. Ajan kataloğu fiyatı güncellememiş olabilir. Web sayfası genel yeni müşteri fiyatını gösteriyor olabilir. Görünürde beş farklı fiyat vardır. Doğru sınıflandırmada yalnız biri gerçek çatışma olabilir.

Gerçeklik çatışmasını çözme süreci

Maddi çelişki bulunduğunda şu süreç uygulanmalıdır.

1. Eylemi risk düzeyine göre durdur

Fiyat, yetki, rıza veya hedef kimliği belirsizse yüksek etkili işlem devam etmemelidir.

2. Bütün mevcut sürümleri koru

Bir kaydı hemen düzeltip geçmiş kanıtı yok etme.

3. Gerçek türünü ve kapsamı sabitle

Genel fiyat mı? Müşteriye özel sözleşme mi? Geçici kampanya mı?

4. Kaynak rollerini sınıflandır

Yetki kaynağı, temsil kaynağı, türetilmiş kopya veya arşiv mi?

5. Geçerlilik zamanını belirle

Olay anında hangisi aktifti?

6. İnsan sahibini bul

Bu gerçeği çözmeye kim yetkili?

7. İstisna ile hatayı ayır

Fark meşru özel koşul mu, yoksa güncellenmemiş kayıt mı?

8. Çözüm kaydı oluştur

Hangi değer, hangi kapsam ve tarihte geçerli kabul edildi?

9. Bütün temsil yüzeylerine yay

Web, API, CRM, ajan dizini, teklif ve diller.

10. Yayılımı bağımsız doğrula

Kaynak değişti demek yetmez; kullanan sistemlerin güncellendiğini kontrol et.

11. Etkilenen işlemleri bul

Yanlış gerçek hangi mesaj, teklif, ödeme veya kararı etkiledi?

12. Yeniden test et

Aynı senaryoda ajan artık doğru kaynağı kullanıyor mu?

Çelişkiyi çözmeden eski kaydı silmek

Kurumlar yanlış kayıt bulduğunda onu hızla düzeltmek isteyebilir. Bu iyi niyetlidir. Fakat denetim başlamadan önce eski kayıt silinirse şu sorular cevaplanamaz:

Ajan gerçekten bu kaydı gördü mü?

Ne kadar süredir aktifti?

Hangi işlemleri etkiledi?

Hangi ajan dizinine yayıldı?

Kök hata nerede oluştu?

Başka kopyalar hâlâ açık mı?

Doğru yöntem:

Eski durumu koru.

Olay kanıtını sabitle.

Yeni sürümü yayımla.

Eski sürümü geçersiz veya arşivlenmiş olarak işaretle.

Etki alanını incele.

Geçmiş yanlış kaydı korumak, onu aktif tutmak anlamına gelmez. Tarihsel kanıt ile operasyonel gerçek ayrılmalıdır.

Kanonik yayılım

Yetkili gerçek belirlendikten sonra bütün davranış yüzeylerine ulaşmalıdır. Bu sürece:

Kanonik Yayılım

diyebiliriz. Örneğin fiyat değiştiğinde şu yüzeyler etkilenebilir:

İnsanlara açık web sayfası

Makinece okunabilir hizmet kataloğu

Yapılandırılmış veri

CRM teklif şablonu

E-posta ajanının bilgi dizini

Çok dilli sayfalar

Satış sunumu

Sözleşme şablonu

İş dizinleri

Harici platformlar

Değişiklik yalnız kanonik sicilde yapılmışsa ajan eski kopyayı kullanmaya devam edebilir. Kanonik kaynak doğrudur. Operasyonel gerçeklik hâlâ yanlıştır.

Yayılım gecikmesi

Kanonik gerçek değişikliği ile bütün ilgili yüzeylerin güncellenmesi arasındaki süreye:

Yayılım Gecikmesi

diyebiliriz. Örneğin:

Fiyat sicili güncellendi: 09.00 Web sayfası güncellendi: 09.05 Ajan kataloğu güncellendi: 09.20 CRM şablonu güncellendi: 11.30 Satış ajanı dizini güncellendi: ertesi gün

Bu süre boyunca kurum birden fazla gerçekle çalışır. Yüksek etkili değişikliklerde yayılım tamamlanıncaya kadar ilgili ajan davranışı sınırlandırılabilir.

Kanonik kapsama ve eşlik ölçümleri

Tek puan yeterli değildir. Fakat bazı ölçüler açık alanları gösterir.

Kanonik Sahiplik Oranı

İnsan sahibi belirlenmiş maddi gerçekler ÷ Toplam maddi gerçekler

Temsil Eşliği Oranı

İnsan ve makine yüzeylerinde maddi anlamı eşleşen kayıtlar ÷ Karşılaştırılan toplam kayıtlar

Dil Eşliği Oranı

Kritik olgusal sözleşmeyi koruyan dil sürümleri ÷ Toplam dil sürümleri

Tazelik Uyum Oranı

Gerekli süre içinde doğrulanmış dinamik gerçekler ÷ Toplam dinamik gerçekler

Yayılım Tamlığı

Güncel kanonik değeri taşıyan yüzeyler ÷ Güncellenmesi gereken toplam yüzeyler

Çözülmemiş Maddi Çelişki Sayısı

Fiyat, yetki, rıza, kapsam veya kimlik gibi eylemi etkileyen açık çelişkiler. Bu ölçüler yalnız operasyonel görünürlük sağlar. Kritik tek çelişki yüksek genel oran içinde kaybolmamalıdır.

Kanıt nedir?

Bir iddiayı tekrar etmek kanıt değildir. Bir sistemin “Başarılı oldum.” demesi kanıt değildir. Kurumun “Bizde böyle bir sorun olmaz.” demesi kanıt değildir. Kanıtın kanonik tanımı şöyledir: Kanıt; belirli bir iddia, yapılandırma, davranış veya sonuç hakkında, kökeni, zamanı, bütünlüğü, kapsamı ve elde edilme yöntemi belli olan; başka bir değerlendiricinin hükmü yeniden kurmasına yardım eden gözlenebilir kayıttır. Kanıt her zaman kesin ispat değildir. Farklı güçlerde olabilir. Bir ekran görüntüsü belirli anda ekranda ne göründüğünü gösterebilir. Fakat arka plandaki bütün sistemi göstermez. Bir log işlem kaydını gösterebilir. Fakat loglama dışı davranışları göstermez.

Bir sözleşme yetkiyi gösterebilir. Fakat teknik sistemin sözleşmeye uyduğunu kanıtlamaz. Bu nedenle kanıt:

rolü,

sınırı,

gücü

ile birlikte kullanılmalıdır.

İddia, gözlem, çıkarım, karar ve sonuç

Denetimde bu beş kavram birbirinden ayrılmalıdır.

İddia

Ajan insan onayı olmadan mesaj göndermez.

Gözlem

Onaysız senaryoda gönderim aracı çağrılmadı.

Çıkarım

Sistem onaysız gönderimi engelliyor olabilir.

Karar

Tanımlı test kapsamı içinde yetki kapısı geçti.

Sonuç

Denetim alıcısına mesaj ulaşmadı ve gönderim kuyruğu boş kaldı. Bir gözlemden geniş bir iddiaya geçerken kanıt yeterliliği değerlendirilmelidir. Tek senaryoda mesaj gönderilmemesi: “Hiçbir zaman gönderemez.” sonucunu üretmez. Aynı şekilde mesaj ulaşmaması da ajanın göndermeyi denemediğini kesin olarak göstermeyebilir. Araç çağrısı başarısız olmuş olabilir. Denetim bu katmanları birbirine karıştırmamalıdır.

Kanıt zinciri nedir?

Kanonik tanımı şöyledir: Kanıt Zinciri; bir denetim iddiasını destekleyen veya yanlışlayan ham kaynakların nereden, kim tarafından, ne zaman ve nasıl alındığını; hangi dönüşüm, maskeleme, sınıflandırma ve analizlerden geçtiğini; hangi gözlem ve bulguya bağlandığını; bütünlüğünün ve saklama durumunun nasıl korunduğunu gösteren sürümlü izdir. Daha basit biçimiyle: Kanıt Zinciri, “Bu sonuca nereden ulaştınız?” sorusuna baştan sona cevap verir. Bir kanıt zinciri şu yolu gösterebilir:

HAM KAYNAK ↓ ALMA YÖNTEMİ ↓ ZAMAN VE TOPLAYAN KİŞİ ↓ BÜTÜNLÜK KAYDI ↓ GEREKLİ MASKELEME ↓ GÖZLEM ↓ İDDİA İLE EŞLEŞME ↓ KARŞI KANIT ↓ DENETİM HÜKMÜ

Kanıt zinciri ajanın özel iç düşünce zinciri değildir. Denetim, sistemin gizli muhakemesini eksiksiz kaydetmeye çalışmaz. Gerekli olan gözlenebilir sorumluluk izidir:

Hangi kaynak okundu?

Hangi araç çağrıldı?

Hangi yetki kullanıldı?

Hangi dış sonuç oluştu?

Hangi kayıt bunu doğruladı?

Kanıtın on niteliği

Her kanıt şu boyutlarda değerlendirilmelidir.

1. İlgililik

Kanıt gerçekten kurulan iddiayla ilgili mi? Bir şirketin genel güvenlik politikası, belirli e-posta gönderiminin yetkili olduğunu kanıtlamayabilir.

2. Yetki

Kaynak bu gerçek türü hakkında konuşmaya yetkili mi? Sosyal medya yorumu güncel fiyatı belirleyemez.

3. Zamansal uyum

Kanıt olay anını veya ilgili geçerlilik dönemini temsil ediyor mu? Bugünkü ekran görüntüsü geçen haftaki davranışı kanıtlamaz.

4. Özgünlük

Kaynağın gerçekten iddia edilen kişi, sistem veya kurumdan geldiği doğrulanabiliyor mu?

5. Bütünlük

Kanıt alındıktan sonra değiştirilmiş mi? Dosya hash’i burada yardımcı olabilir.

6. Tamlık ve bağlam

Kayıt gerekli çevre bilgilerini içeriyor mu? Kırpılmış ekran görüntüsü önemli istisnayı gizleyebilir.

7. Bağımsızlık

Kanıt, denetlenen sistemin kendi beyanından ayrı mı?

8. Yeniden üretilebilirlik

Başka değerlendirici aynı yöntemle benzer gözleme ulaşabilir mi?

9. Özgüllük

Kanıt hangi kullanıcı, görev, sürüm ve işlemle ilgili? Genel log, belirli davranışı ayırt edemeyebilir.

10. Orantılılık ve mahremiyet

Kanıt için gereksiz insan veya kurum verisi toplanmış mı? Güçlü kanıt, sınırsız veri toplama anlamına gelmez.

Kanıt türleri

Denetimde farklı kanıt sınıfları birlikte kullanılabilir.

1. Politika ve sözleşme kanıtı

Kurumsal politika

Ajan görev sözleşmesi

Rıza belgesi

Yetki kaydı

Hizmet kataloğu

Ne olması gerektiğini gösterir. Gerçekte ne olduğunu tek başına göstermez.

2. Yapılandırma kanıtı

Ajan talimatı

Araç izinleri

Model ve sürüm kaydı

API kapsamı

Kuyruk ayarı

Durdurma politikası

Sistemin nasıl kurulduğunu gösterir.

3. Davranış kanıtı

Araç çağrısı

Eylem makbuzu

Test yürütme günlüğü

Alt ajan devri

İnsan onay kaydı

Sistemin belirli durumda ne yaptığını gösterir.

4. Sonuç kanıtı

Alıcı kutusundaki mesaj

Banka veya ödeme kaydı

Canlı web çıktısı

Değişmiş müşteri kaydı

Gerçek API durumu

Dış dünyada ne oluştuğunu gösterir.

5. Toparlanma kanıtı

Durdurma makbuzu

Kuyruk iptali

Token geçersizliği

Rollback sonucu

İnsan kontrol devri

Yeniden başlatma kaydı

Hata veya geri çekme anındaki davranışı gösterir.

6. İnsan kanıtı

Yetkili insan beyanı

Görüşme kaydı

Onay açıklaması

Etkilenen kişinin itirazı

Önemlidir. Fakat tek başına teknik sonucu kanıtlamayabilir.

7. Bağımsız dış kanıt

Alıcı teyidi

Üçüncü taraf sistem kaydı

Bağımsız canlı geri okuma

Dış ölçüm

Sistemin kendi raporundan ayrı sonuç sağlar.

Ekran görüntüsü neyi kanıtlar?

Ekran görüntüsü denetimde yararlıdır. Fakat rolü sınırlıdır. Bir ekran görüntüsü şunu gösterebilir: Belirli anda ekranda belirli metin görünüyordu. Şunları tek başına kanıtlamaz:

Sayfanın gerçekten kanonik kaynak olduğu

İçeriğin olay anında aynı olduğu

Arka plandaki verinin aynı olduğu

Başka kullanıcıların aynı şeyi gördüğü

Görüntünün kırpılmadığı

Ajanın bu sayfayı kullandığı

Eylemin gerçekten gerçekleştiği

Sayfanın botlara farklı içerik göstermediği

Ekran görüntüsü şu bilgilerle güçlenir:

URL veya sistem kimliği

Tarih ve saat

Saat dilimi

Kullanıcı rolü

Tam ekran bağlamı

İlgili ağ veya kaynak kaydı

Dosya bütünlük değeri

Bağımsız ikinci yöntem

Ekran görüntüsü bir gözlem kaydıdır; tek başına gerçeğin sahibi değildir.

Log neyi kanıtlar?

Loglar güçlü kanıt olabilir. Fakat log da sınırsız gerçek değildir. Şu sorular sorulmalıdır:

Hangi sistem üretti?

Hangi olayları kaydetmiyor?

Saatler senkronize mi?

Sonradan değiştirilebilir mi?

Kayıt seviyesi yeterli mi?

Aynı servis hesabını kaç ajan kullanıyor?

Başarısız ve başarılı işlemler birlikte tutuluyor mu?

Log eksikliği eylem yokluğu anlamına geliyor mu?

Bir gönderim logunda mesaj görünmüyorsa:

mesaj gönderilmemiş olabilir,

log saklama süresi dolmuş olabilir,

başka araç kullanılmış olabilir,

servis hesabı farklı olabilir,

loglama başarısız olmuş olabilir.

Bu nedenle:

LOGDA YOK ≠ KESİNLİKLE OLMADI

Doğru hüküm: “İncelenen loglarda kayıt bulunamadı; diğer gönderim yolları ve saklama sınırları nedeniyle yokluk kesin sonuç üretmiyor.” olabilir.

Hash neyi kanıtlar?

Bir dosyanın kriptografik özeti, yani hash değeri, güvenilir biçimde saklanmış önceki özetle karşılaştırıldığında dosyanın değişip değişmediğini denetlemeye yardımcı olur. Bu değerlidir. Fakat hash:

dosyanın doğru kaynaktan geldiğini,

içeriğinin gerçeğe uygun olduğunu,

bütün önemli bağlamı taşıdığını,

olay anında aktif kullanıldığını

kanıtlamaz. Yanlış dosyanın da doğru hash’i olabilir. Uydurma bir rapor değişmeden saklanabilir. Hash karşılaştırması bütünlük denetimine yardımcı olur. Doğruluğu göstermez. Bu nedenle dört ayrı kavram ayrılmalıdır:

BÜTÜNLÜK: Dosya değişti mi? ÖZGÜNLÜK: Dosya gerçekten iddia edilen kaynaktan mı geldi? YETKİ: Kaynak bu konuda karar vermeye yetkili mi? DOĞRULUK: İçerik gerçeğe ve bağlama uygun mu?

Birinde güçlü kanıt bulunması diğerlerini otomatik oluşturmaz.

Dijital imza neyi kanıtlar?

Geçerli bir dijital imza, kullanılan anahtar ve doğrulama koşulları sağlandığında:

belgenin doğrulanan imza anahtarıyla imzalandığını,

belgenin imzadan sonra değişmediğini

gösterebilir. Sıradan bir onay kaydı aynı kriptografik güvenceyi kendiliğinden taşımaz. Her iki durumda da kimlik eşlemesi, onayın kapsamı ve karar yetkisi ayrıca değerlendirilir. Fakat imzalayan kişi:

yanlış bilgiye sahip olabilir,

ilgili konuda yetkisiz olabilir,

kapsamı yanlış anlayabilir,

belgenin bütün eklerini görmemiş olabilir.

Bu nedenle imza: “Kim onayladı?” sorusunu ancak güvenilir kimlik eşlemesi ve açık onay bağlamıyla birlikte yanıtlamaya yardımcı olur. “İçerik kesinlikle doğrudur.” sorusuna tek başına cevap vermez.

Atıf neyi kanıtlar?

Bir AI cevabı doğru web sayfasına atıf yapabilir. Bu şu gerçeği gösterebilir: Model bu sayfayı kaynaklardan biri olarak ilişkilendirmiştir. Fakat cevaptaki her iddianın sayfada bulunduğunu göstermez. Denetim en az şu üç alanı karşılaştırmalıdır:

Cevabın iddiası

Atıf yapılan kaynağın gerçek metni

Kaynağın iddiayı hangi sınırlar içinde desteklediği

Atıf ilişki kanıtıdır. Anlam desteği ayrıca doğrulanmalıdır.

AI çıktısı kanıt olabilir mi?

Evet. Fakat neyin kanıtı olduğu açık olmalıdır. Bir AI cevabı: Ajanın belirli anda ne söylediğinin kanıtı olabilir. Dış dünyadaki iddianın doğru olduğunun kanıtı değildir. Bir ajan açıklaması: “Bu fiyatı web sitesinden aldım.” diyebilir. Bu ifade ajanın kendi açıklamasıdır. Gerçek kaynak kullanımı:

retrieval kaydı,

kaynak kimliği,

araç çağrısı,

eylem makbuzu

ile doğrulanmalıdır. Birden fazla ajanın aynı şeyi söylemesi de bağımsız kanıt değildir. Hepsi aynı kaynağı veya birbirlerinin çıktısını kullanmış olabilir.

Ham kanıt ve türetilmiş kanıt

Denetimde iki kanıt türü ayrılmalıdır.

Ham kanıt

Kaynağa en yakın kayıt. Örnekler:

Orijinal API yanıtı

Ham log bölümü

İmzalı sözleşme dosyası

Canlı HTML

Gönderilmiş mesaj kaydı

Rıza sicili

Türetilmiş kanıt

Ham kanıtın:

özeti,

sınıflandırması,

maskelenmiş sürümü,

tablosu,

grafikleştirilmiş hâli,

ajan yorumu

olabilir. Türetilmiş kanıt kullanışlıdır. Fakat ham köküne bağlanmalıdır. Bir özet: “36/36 erişim testi geçti.” diyebilir. Denetçi gerektiğinde hangi 36 testin, hangi zaman ve kullanıcı aracıyla çalıştığını görebilmelidir.

Kanıt dönüşümleri

Kanıt denetim sürecinde değiştirilebilir. Örneğin:

Kişisel veriler maskelenir.

Loglar ilgili zaman aralığına filtrelenir.

Farklı saat dilimleri eşleştirilir.

Dosyalar ortak biçime dönüştürülür.

AI ile olay sınıflandırması yapılır.

Görselden metin çıkarılır.

Birden fazla kayıt tek tabloya birleştirilir.

Bu dönüşümlerin her biri kaydedilmelidir. Şu sorular cevaplanmalıdır:

Hangi araç kullanıldı?

Hangi sürüm?

Hangi alanlar çıkarıldı?

Hangi değerler maskelendi?

Anlam değişti mi?

Ham kaynak korunuyor mu?

Dönüşüm tekrar üretilebilir mi?

Dönüştürülmüş kanıt ham kaynak gibi sunulmamalıdır.

Maskeleme ve redaksiyon

Denetim kanıtı kişisel veya ticari sır içerebilir. Bu nedenle bazı bölümler gizlenebilir. Fakat redaksiyon:

maddi bağlamı değiştirmemeli,

hedef kimliğini karıştırmamalı,

zaman ilişkisini bozmamalı,

yalnız olumlu bölümleri bırakmamalıdır.

Örneğin müşteri adı maskelenebilir: Müşteri-017 Fakat iki farklı müşterinin aynı takma adla birleştirilmesi yanlış hedef analizini bozabilir. Redaksiyon kaydı şu bilgileri taşımalıdır:

redaction_applied: true
redacted_fields:
  - personal_name
  - email_local_part
reason:
  privacy_protection
performed_by:
  AUDITOR-02
raw_source_retained:
  secure_vault

Kamu raporu maskelenmiş olabilir. Yetkili yeniden inceleme için ham kanıta kontrollü erişim korunabilir.

Kanıt zincirinde saat ve zaman dilimi

Çoklu sistemlerde saatler farklı olabilir.

E-posta servisi UTC kullanır.

CRM yerel saat kullanır.

Ajan sunucusunun saati birkaç dakika geridedir.

Harici platform başka zaman dilimindedir.

Bir olay zinciri yanlış sıralanabilir. Örneğin insan onayı mesajdan sonra verilmiş olduğu hâlde saat farkı nedeniyle önce verilmiş gibi görünebilir. Bu nedenle kanıt kayıtlarında:

mutlak zaman,

saat dilimi,

saat kaynağı,

bilinen sapma

bulunmalıdır. Saat senkronizasyonu da denetim konusu olabilir.

Karşı kanıt

Denetçi yalnız ilk varsayımını destekleyen kayıtları toplamamalıdır. Şu soru da sorulmalıdır: Bu hükme karşı hangi kanıt bulunmaktadır? Örneğin: İddia: Ajan onaysız mesaj gönderdi. Destekleyen kanıt:

Gönderilmiş mesaj

Onay kaydının bulunmaması

Araç çağrısı

Karşı kanıt:

İnsan yöneticinin genel kampanya onayı

Önceden verilmiş sürekli gönderim yetkisi iddiası

Farklı sistemdeki onay kaydı

Denetçi karşı kanıtı değerlendirir. Belki genel onay gerçekten vardır. Fakat:

hedef,

süre,

kanal,

mesaj türü

bakımından bu gönderimi kapsamıyordur. Karşı kanıtın görünür olması hükmü güçlendirir.

Kanıtın yokluğu ve belirsizlik

Bazı olaylar kesin olarak yeniden kurulamaz. Loglar silinmiş olabilir. Eski çalışan hesabı kapanmış olabilir. Dış sağlayıcı kayıt tutmuyor olabilir. Bu durumda denetçi boşluğu tahminle doldurmamalıdır. Şu durumlar kullanılabilir:

Doğrulandı

Güçlü biçimde destekleniyor

Kısmen destekleniyor

Çelişkili

Yetersiz kanıt

Doğrulanamadı

Kanıt kaybı

“Doğrulanamadı” ile “olmadı” aynı değildir. “Yetersiz kanıt” ile “sistem güvenlidir” aynı değildir.

Kanıt kaybı da bulgudur

Bir kurum yüksek etkili ajan davranışlarını daha sonra yeniden kuramıyorsa bu yalnız denetim zorluğu değildir. Ayrı bir yönetişim açığıdır. Örneğin:

Hangi ajanın mesaj gönderdiği bilinmiyor.

İnsan onayı kaydı yok.

Kullanılan fiyat kaynağı bulunamıyor.

Token iptal tarihi bilinmiyor.

Durdurma makbuzu tutulmuyor.

Bu durumda olayın iyi veya kötü olduğu kesinleşmeyebilir. Fakat şu kesinleşir: Kurum önemli ajan davranışını denetlenebilir biçimde kaydetmemektedir. Kanıt kaybı kendi başına bulgu olabilir.

Kanıt bağımsızlığı

Bir sistemin kendi ürettiği bütün kayıtlar değersiz değildir. Fakat yalnız kendi kayıtlarıyla kendisini doğrulaması risklidir. Örneğin web yayın ajanı:

Dosyayı yükler.

“Yükleme başarılı” logu üretir.

Kendi logunu okuyup “canlı doğrulama geçti” der.

Bu üç adım tek bilgi köküdür. Bağımsız doğrulama:

canlı HTTPS geri okuması,

farklı tarayıcı,

dış gözlem noktası,

ayrı denetim hesabı

kullanabilir. Bağımsızlık her zaman başka şirket anlamına gelmez. Aynı kurum içindeki farklı ve eylemden ayrı sistem de bağımsız kanıt sağlayabilir.

Kanıt paketleri

Her maddi denetim iddiası için bir:

Kanıt Paketi

oluşturulabilir. Örneğin:

KANIT PAKETİ — PRICE-INCIDENT-01

İddia: 8 Eylül 2026 saat 09.14’te satış ajanı geçersiz 350 USD fiyatını kullanarak müşteriye mesaj gönderdi. Kanonik gerçek: Geçerli genel başlangıç fiyatı 500 USD/aydı. Ham kanıtlar:

PRICING-REGISTRY-v4.2

CRM şablonunun olay anındaki sürümü

Satış ajanı retrieval kaydı

Gönderilmiş e-posta

İnsan fiyat sahibi onayı

Web sayfasının olay öncesi arşiv sürümü

Operasyonel gerçeklik: Ajan bilgi dizininde 350 USD kaydı aktifti. Eylem sonucu: Müşteriye 350 USD fiyat içeren mesaj ulaştı. Karşı kanıt: Şirketin mevcut web sayfası 500 USD gösteriyor. Karşı kanıt değerlendirmesi: Mevcut sayfa olay sonrasındaki doğru durumu gösteriyor; olay anındaki ajan girdisini geçersiz kılmıyor. Bütünlük kayıtları:

Dosya hash’leri

E-posta mesaj kimliği

Zaman damgaları

Arşiv sürüm kimlikleri

Açık belirsizlik: Eski CRM fiyatının ilk kez kim tarafından oluşturulduğu doğrulanamadı. Denetim hükmü: Yetkili fiyat 500 USD idi. Satış ajanının kullandığı operasyon kaynağı kanonik fiyatla çelişiyordu. Olay GBO-ERR-012, GBO-ERR-016 ve GBO-ERR-092 ile eşleşmektedir.

Bu paket, hükmü tek belge veya tek ekran görüntüsüne bağlamaz. Bütün davranış zincirini gösterir.

Kanonik Gerçeklik Sicili

Bu bölümün ilk zorunlu çıktısı:

NOMOS GBO Kanonik Gerçeklik Sicilidir.

Sicil, denetim kapsamındaki maddi gerçekleri toplar.

İnsan tarafından okunabilir örnek

KANONİK GERÇEKLİK KAYDI

Gerçek kimliği: CANON-PRICE-MSO-2026-04

Varlık: NobleAxis Managed Site Operations

Gerçek türü: Genel başlangıç fiyatı

Kanonik değer: 500 USD/ay

Kapsam:

Yeni doğrudan müşteriler

Temel yönetilen site operasyonu

Barındırma ve üçüncü taraf lisansları hariç

Vergiler sözleşmeye göre ayrıca değerlendirilir

Kapsam dışı:

200 USD/yıl Hosting Core

Müşteriye özel bakım sözleşmeleri

Geçmiş fiyatı korunan sözleşmeler

İnsan sahibi: Ticari Operasyon Sorumlusu

Yetki kaynağı: Pricing Registry v4.2

İnsan temsil yüzeyleri:

İngilizce hizmet sayfası

Türkçe hizmet sayfası

Teklif şablonu v5.1

Makine temsil yüzeyleri:

Service Catalog v4.2

Structured Data v3.8

Sales Agent Knowledge Index v7.1

Geçerlilik başlangıcı: 1 Eylül 2026

Geçerlilik sonu: Yeni yetkili sürüm yayımlanana kadar

Geçersiz kılan olaylar:

Yeni fiyat onayı

Hizmet kapsamı değişikliği

Hukukî fiyat politikası değişikliği

İstisnalar:

Müşteriye özel imzalı sözleşme

Tarihli kampanya kaydı

Yerine geçtiği kayıt: CANON-PRICE-MSO-2026-03 — 450 USD/ay

Son doğrulama: 8 Eylül 2026, 08.42

Açık çelişki: CRM Template v2.8 içinde 350 USD eski fiyat

Durum: Aktif; operasyonel yayılım eksik

Makinece okunabilir Kanonik Gerçeklik Sicili

canonical_fact:
  fact_id: CANON-PRICE-MSO-2026-04

  entity:
    entity_id: SERVICE-MSO-001
    canonical_name: Managed Site Operations

  fact_type: starting_price

  value:
    amount: 500
    currency: USD
    billing_period: month

  scope:
    customer_type:
      - new_direct_customer
    included:
      - managed_site_operations_base_scope
    excluded:
      - hosting_core
      - third_party_licenses
      - taxes_unless_contractually_included

  owner:
    human_role: commercial_operations_owner
    approval_record: APPROVAL-PRICE-2026-104

  authoritative_source:
    source_id: PRICING-REGISTRY-4.2
    source_role: canonical_authority

  representations:
    human:
      - SERVICE-PAGE-EN-v6.1
      - SERVICE-PAGE-TR-v6.1
      - PROPOSAL-TEMPLATE-5.1
    machine:
      - SERVICE-CATALOG-4.2
      - STRUCTURED-DATA-3.8
      - SALES-KNOWLEDGE-INDEX-7.1

  validity:
    effective_from: 2026-09-01T00:00:00+03:00
    effective_until: null
    invalidate_on:
      - authorized_price_change
      - service_scope_change
      - applicable_legal_pricing_policy_change

  exceptions:
    allowed_only_when:
      - signed_customer_contract
      - approved_time_limited_campaign

  supersedes:
    fact_id: CANON-PRICE-MSO-2026-03

  conflicts:
    - source_id: CRM-TEMPLATE-2.8
      conflicting_value: 350
      status: obsolete_unresolved_copy

  status: active_with_propagation_gap

Bu kayıt yalnız 500 dolar değerini saklamaz. Değerin:

sahibini,

kapsamını,

temsil yüzeylerini,

geçerliliğini,

çelişkisini

birlikte gösterir.

Kanıt Sicili

Bu bölümün ikinci zorunlu çıktısı:

NOMOS GBO Kanıt Sicilidir.

Her kanıt kaydı, hangi iddia veya bulguyu desteklediğini ve hangi sınırlara sahip olduğunu gösterir. Bu bölümün fiyat olayı, müşteri keşfi örneğinin eski fiyat kaydı v3.7'sinden ayrı bir öğretici vakadır. Burada PRICING-REGISTRY-v4.2 ve GBO-AUDIT-PRICING-2026-001 kimliği kullanılır; iki dosyanın kanıtları aynı dondurulmuş kapsam gibi birleştirilmez.

İnsan tarafından okunabilir Kanıt Kaydı

Kanıt kimliği: EVID-PRICE-INCIDENT-004

Denetim kimliği: GBO-AUDIT-PRICING-2026-001

Kanıt türü: Ajan eylem makbuzu ve kaynak izi

Kaynak sistem: Sales Agent v2.4

Kaynak rolü: Davranış kanıtı

İlgili olay: 09.14 fiyat e-postası

Alma zamanı: 8 Eylül 2026, 10.12

Toplayan: Denetçi AUDITOR-02

Ham kayıt: ACTION-EMAIL-8841

Bütünlük kaydı: Hash ve mesaj kimliği kaydedildi

Gösterdiği şey:

E-posta satış ajanı tarafından gönderildi.

Mesajda 350 USD fiyatı kullanıldı.

Kaynak kimliği olarak CRM-TEMPLATE-2.8 kaydedildi.

İnsan onay kaydı bulunmadı.

Göstermediği şey:

CRM şablonunu ilk kimin oluşturduğu

İnsan yöneticinin başka kanalda genel gönderim onayı verip vermediği

Müşterinin teklifi hukukî olarak kabul edip etmediği

Uygulanan dönüşüm:

Müşteri e-posta adresi maskelendi.

Mesaj gövdesi korunarak kişisel imza bilgileri çıkarıldı.

Ham kaydın konumu: Şifreli kanıt kasası

Desteklediği bulgular:

FINDING-AUTH-03

FINDING-CANON-02

Karşı kanıt:

Güncel web sayfası 500 USD gösteriyor.

Durum: Doğrulandı

Saklama süresi: 180 gün; devam eden uyuşmazlık varsa yeniden değerlendirme

Makinece okunabilir Kanıt Sicili

evidence_record:
  evidence_id: EVID-PRICE-INCIDENT-004
  audit_id: GBO-AUDIT-PRICING-2026-001

  evidence_type:
    - action_receipt
    - source_trace

  source:
    system_id: SALES-AGENT-2.4
    record_id: ACTION-EMAIL-8841
    source_role: behavioral_evidence

  acquisition:
    collected_by: AUDITOR-02
    collected_at: 2026-09-08T10:12:00+03:00
    method: read_only_export

  integrity:
    hash_algorithm: SHA-256
    hash_value: recorded_in_secure_vault
    source_message_id: MSG-928472
    integrity_status: verified

  temporal_relevance:
    event_time: 2026-09-08T09:14:00+03:00
    time_alignment: direct

  observations:
    - email_was_sent
    - stated_price_was_350_USD
    - source_id_was_CRM_TEMPLATE_2_8
    - explicit_human_approval_not_present_in_record

  limitations:
    - does_not_identify_original_creator_of_CRM_template
    - does_not_exclude_approval_existing_in_unreviewed_channel
    - does_not_establish_contract_acceptance

  transformations:
    - customer_email_masked
    - personal_signature_removed

  supports:
    findings:
      - FINDING-AUTH-03
      - FINDING-CANON-02

  counter_evidence:
    - EVID-WEB-CURRENT-001

  storage:
    location: encrypted_evidence_vault
    access:
      - lead_auditor
      - authorized_client_reviewer

  retention:
    days: 180
    deletion_receipt_required: true
    review_on_ongoing_dispute_or_preservation_duty: required
    example_duration_not_universal_legal_rule: true

  status: verified

Kanıt Sicili durumları

Kanıtın işlem geçmişi, doğrulama durumu, itirazı ve erişim koşulu ayrı izlenmelidir. Aşağıdaki etiketlerin birkaçı aynı anda geçerli olabilir; örneğin bir kayıt bütünlüğü doğrulanmış, erişimi sınırlı ve içeriğine itiraz edilmiş durumda olabilir:

Toplandı

Bütünlüğü doğrulandı

Özgünlüğü doğrulandı

Kısmen doğrulandı

Çelişkili

İtiraz edildi

Geçersiz kılındı

Yerine yeni kanıt geçti

Süresi doldu

Kanıt kaybı

Erişim sınırlı

Arşivlendi

Silindi ve makbuzu oluşturuldu

Bir kanıtın sonradan yanlış veya eksik olduğu ortaya çıkarsa kayıt sessizce silinmemelidir. Durumu değiştirilmelidir. Böylece önceki hükmün neden değiştiği anlaşılır.

İddia–Kanıt Matrisi

Denetimde her önemli iddia, onu destekleyen ve karşılayan kanıtlarla eşleştirilmelidir.

Bu matris denetçinin kanıtın gücünü aşan cümle kurmasını engeller.

Kanıt paketinin asgari alanları

Her yüksek etkili bulguda en az şu alanlar bulunmalıdır:

claim expected_state observed_state canonical_fact raw_evidence operational_evidence action_evidence outcome_evidence counter_evidence time_alignment transformations limitations uncertainties reviewer judgment

Bir bulgu yalnız ekran görüntüsüne, yalnız insan beyanına veya yalnız ajanın açıklamasına dayanıyorsa bu açıkça gösterilmelidir.

Kanıt saklama ve veri minimizasyonu

Denetim kanıtı sonsuza kadar tutulmamalıdır. Saklama süresi şunlara bağlı olabilir:

Risk düzeyi

Uyuşmazlık durumu

Sözleşme

Veri koruma gereksinimi

Yeniden test ihtiyacı

Olayın kapanış durumu

Mümkün olduğunda:

Kişisel veri maskelenmeli

Gereksiz içerik çıkarılmalı

Ham kanıta erişim sınırlanmalı

Kamu raporu özetlenmiş olmalı

Silme sonunda makbuz üretilmelidir

Fakat kanıt minimizasyonu adı altında kritik bağlam da kaybedilmemelidir. Örneğin yalnız mesaj gövdesini saklayıp:

alıcıyı,

zamanı,

kaynak kimliğini,

onay kaydını

silmek, olayı denetlenemez hâle getirebilir.

Kanıt kasası ve kanıt erişimi

Kritik kanıtlar ayrı bir kanıt kasasında saklanabilir. Kasa şu özellikleri taşıyabilir:

Erişim kontrolü

Değişiklik kaydı

Şifreleme

Bütünlük doğrulaması

Sürüm

Silme politikası

Kimlerin hangi kaydı gördüğü

Denetçi bütün kanıtları kişisel cihazına veya onaysız bulut aracına kopyalamamalıdır. Kanıtı analiz eden AI araçları da yetkilendirilmelidir.

AI destekli kanıt analizi

Bir denetim ajanı:

binlerce logu sınıflandırabilir,

zaman çizelgesi çıkarabilir,

benzer olayları gruplayabilir,

dil sürümlerini karşılaştırabilir,

çelişkili kaynakları işaretleyebilir.

Bu faydalıdır. Fakat AI çıktısı:

ham kanıtın yerine geçmemeli,

kendi sınıflandırmasını bağımsız doğrulama saymamalı,

nihai bulguyu tek başına belirlememelidir.

Örneğin denetim ajanı: “Bu kayıt yetki ihlali gibi görünüyor.” diyebilir. İnsan denetçi:

gerçek yetki sözleşmesini,

işlem kapsamını,

karşı kanıtı

incelemelidir. Denetimde kullanılan AI sisteminin de:

sürümü,

veri erişimi,

dönüşüm yöntemi

kanıt zincirinde görünür olmalıdır.

Kanıt bulaşması

Denetim sırasında üretilen sentetik kayıtlar gerçek operasyon verisine karışabilir. Örneğin:

Denetim müşterisi gerçek müşteri listesine eklenir.

Test fiyatı satış kataloğuna yazılır.

Saldırı senaryosu ajan belleğinde gerçek talimat gibi kalır.

Denetim e-posta adresi gelecekte satış hedefi olur.

Sentetik rıza kaydı gerçek kişiyle eşleşir.

Buna:

Kanıt ve Test Bulaşması

diyebiliriz. Denetim verileri açıkça işaretlenmeli ve test sonunda:

aktif sistemden çıkarılmalı,

gerekli kanıt kopyası korunmalı,

belleğe yazılan etkiler temizlenmeli,

silme veya arşivleme makbuzu oluşturulmalıdır.

Denetim sistemi incelerken onu fark edilmeden değiştirmemelidir.

Kanonik gerçeklik denetimi için on iki adım

1. Maddi iddiaları çıkar

Fiyat, yetki, rıza, kapsam, kapasite ve sonuç gibi davranışı etkileyen gerçekleri listele.

2. Varlığı benzersiz tanımla

Yanlış kişi, şirket, hizmet veya ajanla karışmayı engelle.

3. Gerçek türünü sınıflandır

Her iddiayı uygun gerçek ailesine yerleştir.

4. İnsan sahibini belirle

Gerçeğin güncelliği ve doğruluğundan kim sorumlu?

5. Yetkili kaynağı belirle

Hangi kayıt bu gerçek türü için son sözü söylemeye yetkili?

6. Operasyon kaynaklarını bul

Ajan gerçekte hangi kopya veya dizini kullanıyor?

7. Zaman ve kapsamı sabitle

Olay anında hangi değer, hangi kullanıcı ve işlem için geçerliydi?

8. İstisna ile çelişkiyi ayır

Özel sözleşme, kampanya veya geçmiş kayıt mı?

9. İnsan–makine–dil eşliğini karşılaştır

Bütün yüzeyler aynı maddi sözleşmeyi taşıyor mu?

10. Kanıt zincirini kur

Ham kaynak, bütünlük, dönüşüm, gözlem ve karşı kanıtı bağla.

11. Yayılımı doğrula

Kanonik düzeltme bütün ilgili sistemlere ulaştı mı?

12. Davranışı yeniden test et

Ajan artık doğru gerçek üzerinden doğru eylem gösteriyor mu?

Kanonik Gerçeklik ve Kanıt Zinciri Kapısı

Bir iddia denetim hükmüne dönüşmeden önce şu kapılar değerlendirilmelidir:

1. Varlık Kapısı

Gerçek doğru kişi, kurum, hizmet veya ajanla mı ilişkilidir?

2. Gerçek Türü Kapısı

Kaynak bu konu hakkında karar vermeye yetkili mi?

3. İnsan Sahipliği Kapısı

Gerçeğin sorumlu insan sahibi belli mi?

4. Kapsam Kapısı

Genel kural, istisna ve özel işlem ayrıldı mı?

5. Zaman Kapısı

Kanıt olay anı ve geçerlilik dönemiyle uyumlu mu?

6. Temsil Eşliği Kapısı

İnsan, makine ve diller aynı maddi gerçeği taşıyor mu?

7. Operasyonel Erişim Kapısı

Ajanın gerçekten kullandığı kaynak biliniyor mu?

8. Köken Kapısı

Kanıtın ilk kaynağı ve türetildiği zincir görünür mü?

9. Bütünlük Kapısı

Kanıtın değişmediği ve dönüşümlerinin kaydedildiği doğrulanabiliyor mu?

10. Bağımsızlık Kapısı

Sonuç yalnız denetlenen sistemin kendi beyanına mı dayanıyor?

11. Karşı Kanıt Kapısı

Hükme aykırı kayıtlar değerlendirildi mi?

12. Mahremiyet Kapısı

Denetim için gerekenden fazla veri toplanmış mı?

13. Yeniden Üretilebilirlik Kapısı

Başka değerlendirici aynı kayıttan benzer sonuca ulaşabilir mi?

14. Saklama ve Geçerlilik Kapısı

Kanıt ne kadar süreyle ve hangi erişim altında korunacak? Basit biçimde:

DENETLENEBİLİR GERÇEKLİK = DOĞRU VARLIK VE DOĞRU GERÇEK TÜRÜ VE YETKİLİ İNSAN SAHİBİ VE BELİRLİ KAPSAM VE GEÇERLİ ZAMAN VE TEMSİL EŞLİĞİ VE OPERASYONEL KAYNAK İZİ VE KANIT KÖKENİ VE BÜTÜNLÜK VE BAĞIMSIZ DOĞRULAMA VE KARŞI KANIT İNCELEMESİ VE ORANTILI VERİ KULLANIMI

Kritik gerçeklik belirsizlikleri

Bazı belirsizlikler senaryo testi başlamadan davranışı geçici olarak durdurmayı gerektirebilir. Örneğin:

Hangi fiyatın geçerli olduğu bilinmiyor.

Yetki sahibinin kim olduğu çelişkili.

Rıza kaydı bulunamıyor.

Ajanın kullandığı veri kaynağı bilinmiyor.

İnsan ve makine farklı kapsam gösteriyor.

Gönderim sonucunun hangi hesapta oluştuğu ayırt edilemiyor.

Kanıtın olay sonrasında değiştirildiği şüphesi var.

Alt ajan çıktısı bağımsız kaynak gibi kullanılıyor.

Kritiğe yakın işlem için yalnız güncel ekran görüntüsü bulunuyor.

Bu durumda doğru denetim davranışı: “Yeterli kanıt yok; yine de devam edelim.” değildir. Şu olabilir: “Gerçeklik ve kanıt yolu netleşene kadar ilgili yüksek etkili davranış sınırlandırılmalıdır.”

Kanonik gerçeklik yoksa ajan ne yapmalıdır?

Bir ajan iki çelişkili fiyat, rol veya rıza kaydı gördüğünde yeni gerçek üretmemelidir. Doğru davranış risk düzeyine göre değişebilir:

Düşük riskli durumda

Belirsizliği açıklar ve olası seçenekleri sunar.

Orta riskli durumda

Yetkili kaynağı veya insan sahibini arar.

Yüksek riskli durumda

Eylemi durdurur ve insan kararına devreder. Ajan şu dili kullanabilir: “Hizmet için 500 ve 350 USD olmak üzere iki aktif kayıt bulunuyor. 500 USD fiyat sicilinde, 350 USD eski CRM şablonunda yer alıyor. Kanonik ticari sahibin doğrulaması olmadan müşteriye fiyat göndermeyeceğim.” Bu cevap, görevin tamamlanmadığını düşündürebilir. Gerçekte nitelikli davranıştır.

Kanıt zinciri yoksa denetçi ne yapmalıdır?

Denetçi bir iddiayı doğrulayacak yeterli kanıt bulamıyorsa üç seçenekten birini kullanabilir:

1. İddia sınırlandırılır

“Politikada bu kuralın yazılı olduğu doğrulandı; davranışta uygulandığı doğrulanamadı.”

2. Ek kanıt istenir

Ham log

Sürüm kaydı

Bağımsız test

İnsan sahibinin onayı

3. Yetersiz Kanıt Bulgusu oluşturulur

“İncelenen kapsamda, yüksek etkili eylem için insan onayını sonradan yeniden kurmaya yetecek kayıt elde edilemedi. Kaydın hiç tutulmadığı, kaybolduğu veya incelemeye sunulmadığı henüz ayrıştırılmadı.” Denetçinin görevi boşluğu güven varsayımıyla doldurmak değildir.

Bu bölümün zorunlu çıktıları

Bu bölüm tamamlandığında denetim dosyasında şu iki yapı bulunmalıdır:

1. Kanonik Gerçeklik Sicili

Denetim kapsamındaki bütün maddi kimlik, fiyat, kapsam, kapasite, rıza, yetki ve sonuç gerçeklerini içerir.

2. Kanıt Sicili

Her iddia, test, bulgu, sonuç ve toparlanma hükmünün hangi kanıta dayandığını; kanıtın kökenini, zamanını, bütünlüğünü, dönüşümünü ve sınırını gösterir. Bu iki sicil Davranış Haritasına bağlanmalıdır. Her önemli harita düğümü:

kanonik gerçeğe,

ilgili kanıta,

insan sahibine

ulaşabilmelidir.

İlk dört bölümün birleşik çıktısı

Artık denetimin temel katmanı kurulmuştur. Elimizde:

Denetim İddia Kartı

Neyi kanıtlamaya çalıştığımızı gösterir.

Denetim Yetki Belgesi

Denetçinin neyi, hangi sınırlar içinde yapabileceğini gösterir.

Kapsam Dondurma Kaydı

Hangi sistem sürümünün denetlendiğini sabitler.

İnsan–Ajan–Araç Davranış Haritası

İnsan amacından dış eyleme, kanıta ve durdurmaya kadar bütün davranış yollarını gösterir.

Kanonik Gerçeklik Sicili

Her maddi gerçek için yetkili kaynak, sahip, kapsam, zaman ve istisnayı belirler.

Kanıt Sicili

Denetim hükmüne nasıl ulaşıldığını yeniden kurulabilir hâle getirir. Bu yapılar olmadan doğrudan test senaryolarına geçmek mümkündür. Fakat testler yanlış sistemi, yanlış gerçeği veya yanlış yetkiyi sınayabilir.

Bölümün hükmü

Bir kurumun web sitesinde doğru bilgi bulunması, ajanın doğru bilgi kullandığını kanıtlamaz. Bir fiyatın yetkili sicilde doğru olması, bütün operasyon kaynaklarının güncel olduğunu göstermez. Bir ekran görüntüsünün bulunması, olay anındaki sistemi yeniden kurmaz. Hash karşılaştırması, güvenilir önceki kayda göre değişikliği denetler; dosyanın içeriğinin doğru olduğunu kanıtlamaz. Bir dijital imza, imzalayanı gösterebilir; içeriğin her zaman doğru olduğunu değil. Bir atıf, kaynak bağlantısını gösterebilir; kurulan iddianın gerçekten desteklendiğini değil. Bir AI açıklaması, sistemin ne söylediğini gösterir; gerçek davranış nedenini tek başına kanıtlamaz. Bu bölümün ilk hükmü şöyledir: Kanonik gerçeklik yalnız değer değildir; doğru varlık, gerçek türü, yetkili sahip, kapsam, zaman, istisna ve sürüm ilişkisidir.

İkinci hüküm: Kanonik kaynak her şeyin tutulduğu tek dosya olmak zorunda değildir; her maddi gerçek türü için hangi kaynağın yetkili olduğu bilinmelidir. Üçüncü hüküm: Genel kural, geçici istisna ve özel işlem aynı gerçek alanında ezilmemelidir. Dördüncü hüküm: Bugünkü doğru kayıt, geçmişte ajanın ne gördüğünü ve neye dayanarak davrandığını otomatik olarak kanıtlamaz. Beşinci hüküm: İnsan, makine ve farklı dil yüzeyleri aynı maddi davranış sözleşmesini taşımalıdır. Altıncı hüküm: Kanıtın bulunması yeterli değildir; kökeni, zamanı, bütünlüğü, dönüşümü, bağımsızlığı ve sınırı bilinmelidir. Yedinci hüküm: Kanıt yokluğu hata yokluğu değildir. Önemli davranışın yeniden kurulamaması ayrı bir yönetişim bulgusudur.

Sekizinci hüküm: Kanıt zinciri özel düşünce zinciri değildir; gözlenebilir kaynak, yetki, eylem, sonuç ve toparlanma izidir. Ve son hüküm: Bir denetim, kanıtının ulaşamadığı yer hakkında kesin hüküm kuramaz. Artık:

neyi denetlediğimizi,

kimden yetki aldığımızı,

sistemin hangi davranış yollarını kullandığını,

hangi gerçeklerin kanonik olduğunu,

bu gerçekleri hangi kanıtların desteklediğini

biliyoruz. Fakat Cilt II’de tanımlanan 99 hatanın tamamı her sistem için aynı ölçüde önemli değildir. Bir belge özetleme ajanında yanlış fiyat riski bulunmayabilir. Bir satın alma ajanında ise bütçe, abonelik ve çift ödeme hataları kritik olabilir. Bir avatar sisteminde rıza ve sentetik kimlik veto düzeyindedir. Bir web ajanında canlı yayın, kanonik veri ve rollback öne çıkar. Bir müşteri keşif ajanında muhatap doğruluğu, kişisel veri ve dış gönderim yetkisi belirleyicidir. Aynı hata düşük riskli bir taslakta sınırlı etki doğurabilir. Başka sistemde milyonlarca insana veya yüksek tutarlı işleme ulaşabilir.

Bu nedenle bir sonraki adım 99 hatanın tamamını rastgele test etmek değildir. Önce şu sorular cevaplanmalıdır:

Hangi hata aileleri bu sistem için gerçekten uygulanabilir? Hangileri en olasıdır? Hangileri en büyük zararı üretir? Hangileri geri döndürülemez? Hangileri tek olayda genel puanı geçersiz kılmalıdır? Hangi davranışlar hemen sınırlandırılmalıdır? Test kaynakları önce nereye ayrılmalıdır?

Bir sonraki bölümde:

GBO-99 Risk Haritası ve Veto Kapıları

kurulacaktır. Çünkü kanonik gerçek ve güçlü kanıt bize sistemin ne olduğunu gösterir. Risk haritası ise: Nereden kırılmasının en önemli olduğunu gösterir.

Her hata test edilmeye değerdir. Fakat her hata aynı önceliğe, aynı zarara ve aynı hüküm gücüne sahip değildir.