Bilgi ve sistemler — 02
Bir belge güncellenir. Yeni sürüm sisteme yüklenir. Bir sonraki yanıt artık bu sürümü kullanır.
İlk bakışta bilgi güncellenmiş görünür. Fakat eski sürüm başka yerlerde yaşamaya devam edebilir: bir önbellekte, daha önce üretilmiş bir özette, başka bir kaydın içinde veya geçmiş bir kararın dayanağında.
Bu yüzden bir bilginin değişmesi, dosyanın değiştiğini fark etmekten daha geniş bir meseledir.
Sistem, neyin değiştiğini ve bu değişikliğin hangi kullanımları etkilediğini nasıl takip eder?
KLM ve nage üzerinde çalışırken bu soru iki düzeyde karşıma çıkıyor: bilginin izini nasıl kaydedeceğimiz ve o bilgiyle çalışan sistemin nasıl davranacağı.
Değişen şey tam olarak ne?
Basit, varsayımsal bir örnek düşünelim.
Bir kurumun yönergesinde başvurular için on günlük süre tanımlanmış olsun. Yeni yönerge bu süreyi yedi güne indirsin ve belirli bir tarihten itibaren geçerli kılsın.
Burada yalnız metin değişmedi. Bir kuralın geçerlilik koşulu da değişti.
Eski yönerge, yürürlükte olduğu dönemde yapılan bir işlemi açıklamak için hâlâ gerekli olabilir. Yeni bir başvuruyu yanıtlarken ise yeni yönerge kullanılmalıdır.
Dolayısıyla sistemin tek bir “güncel belge” alanından fazlasına ihtiyacı vardır. Hangi kaynağın hangi sürümünü tuttuğunu, bunun ne zaman geçerli olduğunu ve hangi işlemlerde kullanıldığını ayırt edebilmelidir.
Ayrıca her değişiklik aynı ağırlığı taşımaz. Yazım düzeltmesi, tarih değişikliği ve karar koşulunun değişmesi farklı sonuçlar doğurabilir.
Bir dosyanın içerik özeti — hash’i — değiştiğinde, içeriğin farklı olduğunu saptayabiliriz. Fakat bu farkın anlamını ve etkisini belirlemek için başka bir değerlendirme gerekir.
KLM: değişikliğin izini okunabilir kılmak
KLM, bir yanıtın arkasındaki bilgi, iddia ve kanıt ilişkilerini açıkça kaydetmeye yönelik bir sözleşme çalışması.
Bu soruda önemli olan, yalnızca kaynak adresini saklamak değil, kullanılan belirli kaynak sürümünü ayırt edebilmek.
Bir bağlantı bugün başka bir belgeyi gösteriyorsa, geçmişte üretilen yanıtın neye dayandığını o bağlantıdan çıkaramayabiliriz. Kayıtta kaynak kimliği, sürüm veya içerik özeti gibi izlerin bulunması bu ayrımı mümkün kılar.
KLM belirtiminde bilgi birimleri için geçerlilik başlangıcı, geçerlilik sonu, sürüm ve önceki birimin yerini alma ilişkisi tanımlanıyor. Böylece yeni bir kayıt, hangi eski kaydın yerine geçtiğini ifade edebilir.
Bu alanlar kendiliğinden anlam değişikliği tespit eden bir mekanizma oluşturmaz. Uygulamanın, değişikliği nasıl fark ettiğini ve bu alanları hangi dayanakla doldurduğunu ayrıca belirlemesi gerekir.
KLM’nin burada sağladığı şey, değişiklik hakkında verilen kararın izini saklayabileceğimiz bir çerçevedir.
Yeni sürümün gelmesi, eskisinin silinmesini gerektirir mi?
Örnekteki eski yönergeyi tamamen kaldırırsak, geçmiş bir yanıtı açıklamak zorlaşabilir. Eski ve yeni yönergeyi ayrım yapmadan birlikte kullanırsak, bu kez yeni yanıtın hangi kurala dayanacağı belirsizleşir.
Geçmişi korumak ile mevcut kullanımın koşullarını belirlemek birlikte ele alınmalıdır.
Bir bilgi birimi aktif olabilir, yerine yeni sürüm gelmiş olabilir, süresi dolmuş olabilir veya geri çekilmiş olabilir. Bunlar farklı durumlardır.
KLM bu yaşam döngüsü ayrımlarına yer veriyor. Bir kaynağın silindiği söyleniyorsa da silmenin kapsamının belirtilmesini istiyor. Bilgi deposundan kaldırılmış bir kayıt; önbellekten, işlem günlüklerinden veya türetilmiş çıktılardan da kaldırılmış olmayabilir.
“Silindi” sözcüğü, sistemin bütününde aynı işlemin tamamlandığı varsayımını taşımamalı.
nage: kayıt kararını çalışan sisteme taşımak
nage tarafında soru, bu ayrımların işletim sırasında nasıl korunacağına uzanıyor.
Yeni bilgi alınırken birden fazla işlem gerçekleşebilir: kaynak kaydı oluşturulur, işlenir, aranabilir hâle getirilir ve kullanıma açılır. Bu işlemlerin her biri farklı bir noktada başarısız olabilir.
Yeni sürüm depoya yazılmış, fakat arama indeksi güncellenmemişse sistem hangi sürümü kullanacaktır? Eski sürüm arşivlenmiş, fakat önbellekte kalmışsa ne olacaktır? İki güncelleme aynı anda gelirse hangisi etkin sürüm sayılacaktır?
nage’nin tasarımında yönetilen bilgi birimleri; kaynakları, sürümleri, yaşam döngüleri ve kullanılabilir yetenekleriyle birlikte ele alınıyor. Bir belgenin bulunması, aranabilir olması ve kullanım için kabul edilmiş olması ayrı durumlar.
Bu ayrımı tek bir “hazır” işaretine sıkıştırmak, tamamlanmamış bir işlemi kullanılabilir gibi gösterebilir.
Buradaki işletim sorusu şudur:
Yeni sürümün hangi koşullarda kullanılabileceğini nasıl doğrularız?
nage’de ürün genelindeki yaşam döngüsü kabulü hâlâ açık bir çalışma alanı. Bu nedenle bu anlatım, bütün güncelleme ve silme senaryolarının tamamlanmış olduğunu ileri sürmüyor; sınanması gereken davranışı tarif ediyor.
Bir kaynağın değişmesi nerelere ulaşır?
Bir yanıtın belirli bir iddiası eski yönergeye dayanmış olsun. O yanıt daha sonra özetlenmiş, özet de başka bir çalışma için kullanılmış olabilir.
Kaynak değiştiğinde etki yalnız ilk yanıtta kalmaz.
Bu yüzden kaynaklardan çıktılara doğru iz sürebilmek önemlidir: Bu sürümü hangi iddialar kullandı? Hangi çıktılar o iddialardan türetildi?
KLM’nin kanıt ve türetim ilişkileri, bu etki izini kaydetmek için bir temel sunuyor. Fakat etkilenmiş bir kayıt bulmak, onu otomatik olarak yanlış ilan etmek değildir.
Geçmişte geçerli bir kurala göre üretilmiş yanıt, tarihsel bağlamında doğru kalabilir. Aynı yanıt bugün yeni bir işlem için uygun olmayabilir.
Sistemin bu iki kullanımı ayıracak bir politikaya ihtiyacı vardır. Bazı kayıtlar yeniden değerlendirmeye alınabilir; bazıları tarihsel olarak korunabilir; bazıları yeni kullanım için kapatılabilir.
İlişki kaydı, bu kararın hangi kayıtları kapsaması gerektiğini görünür kılar.
Güncellik hakkında neyi bilmiyoruz?
Bir kaynağın sisteme bugün alınmış olması, içeriğinin bugün geçerli olduğunu göstermeyebilir. Yakın tarihli bir dosya da daha eski bir kuralı aktarabilir.
Kaynağın alınma zamanı, değişme zamanı ve geçerlilik zamanı farklı bilgiler taşır.
Bunlardan biri bilinmiyorsa, eksikliği açık bırakmak gerekir. KLM’nin bilinmeyen sinyalleri nedenleriyle birlikte koruma yaklaşımı burada da anlamlıdır. Ölçülmemiş güncelliğe bir sayı vermek, eksik bilgiyi ortadan kaldırmaz.
Bu yazının başındaki soruya döndüğümüzde, “sistem anlar” ifadesi birkaç somut işe ayrılıyor: değişikliği saptamak, yeni kaydı eski kayda bağlamak, kullanım koşullarını belirlemek ve etkilenen çıktıları bulmak.
Bu işlerin her birinin dayanağı ve sınırı ayrı olmalı.
Bilgi güncellemesini değerlendirirken artık şu soruyu da sormak gerekiyor:
Yeni bilgiyi ekledik; peki eski bilginin nerelerde kullanılmaya devam ettiğini görebiliyor muyuz?
Kaynak notu — 15 Ekim 2026: Yazı, KLM belirtiminin bilgi yaşam döngüsü ve etki izi bölümleri ile nage’nin tasarım ve mevcut uygulama belgelerine dayanır. Yönerge örneği varsayımsaldır. Yeni bir uygulama veya kabul testi sonucu sunulmamıştır.
KLM proje sayfası · nage proje sayfası · Bilinmeyen neden sıfır değildir?
Bağlantıları
KLM’nin sürüm, geçerlilik, silme kapsamı ve etki izi sözleşmelerini ele alır.
nage tasarımındaki bilgi yaşam döngüsünü ve henüz açık işletim kabul sorularını ele alır.
Önceki yazının değişen bilgi ve etki izi sorusunu, ERM’de bir yargının canlı desteğine taşır.