Bir teknik due diligence oturumunda, inceleme ekibi genellikle hangi araçların kullanıldığını sormakla başlar ve karşı taraf bu soruyu rahatlıkla yanıtlar; depo adı verilir, dallanma stratejisi anlatılır, çizim arşivinin sunucudaki konumu gösterilir. Asıl kırılma, sorunun bir sonraki katmanına geçildiğinde yaşanır: sekiz ay önce müşteriye teslim edilmiş bir yapılandırmanın tam olarak hangi bileşen sürümlerinden oluştuğu, o teslimattan bu yana kaç değişiklik geçirdiği ve bu değişikliklerin hangisinin onaylı, hangisinin sahada acil müdahale olarak yapıldığı sorulduğunda, odadaki cevap çoğu zaman bir sistemden değil bir kişiden gelir. O kişi bunu bilir, çünkü değişikliği kendisi yapmıştır; sistem bilmez, çünkü sistem yalnızca sonucun son hâlini taşımaktadır.
Bu örüntü, teknoloji ve mühendislik yoğun şirketlerde şaşırtıcı biçimde tekrarlar ve şirketin olgunluk düzeyiyle doğrusal olarak azalmaz. Otuz kişilik bir mühendislik ekibinde sürüm disiplini genellikle yazılım deposunda titizlikle uygulanırken, aynı ekibin ürettiği hesap tabloları, teknik şartname taslakları, saha revizyon çizimleri ve müşteriye özel konfigürasyon dosyaları paylaşımlı bir sürücüde dosya adına eklenen tarih ve baş harf kısaltmalarıyla yönetilmeye devam eder. Kurum, kendi kritik çıktısının bir bölümünü izlenebilir, diğer bölümünü izlenemez tutmayı bilinçli bir tercih olarak değil, aracın kapsamıyla disiplinin kapsamını aynı şey sanmakla sonuçlandırır.
Altta çalışan mekanizma, kısayolun kendisinde değil, kısayolun koşul değiştikten sonra devam etmesindedir. Beş kişilik bir kurucu ekipte, kimin neyi ne zaman değiştirdiği bilgisi ortak hafızada tutulabildiği sürece, formel bir sürüm kaydı tutmanın marjinal faydası düşük, marjinal maliyeti ise görünür biçimde yüksektir; her değişikliğin gerekçesini yazmak, o değişikliği yapmaktan daha uzun sürer. Ekip büyüdüğünde, ürün çeşitlendiğinde ve müşteri başına farklılaşan yapılandırmalar çoğaldığında ise ortak hafıza taşıma kapasitesini kaybeder, fakat kayıt tutmama alışkanlığı yerinde kalır. Kurum artık bilmediği bir şeyi bildiğini varsayarak çalışmaktadır, ve bu varsayımın yanlışlığı ancak bir geri alma, bir denetim ya da bir inceleme anında yüzeye çıkar.
İkinci mekanizma katmanı, sürüm yönetiminin sahipliğiyle ilgilidir. Bu alan tipik olarak bir role değil, bir kişiye — genellikle ekibin en kıdemli mühendisine — fiilen bağlanır; o kişi neyin ana hatta alınacağına, hangi değişikliğin acil sayılacağına ve hangi sürümün müşteriye gideceğine karar verir, fakat bu karar yetkisi hiçbir belgede tanımlı değildir. Yetkinin belgesizliği gündelik operasyonda bir sürtünme üretmez, aksine hızlandırır; kimse onay beklemez, kimse süreç tartışmaz. Buna karşılık aynı belgesizlik, o kişinin izinli olduğu, ayrıldığı ya da paralel iki projeye aynı anda bölündüğü anda, kararın kimde olduğu sorusunu cevapsız bırakır ve bu boşluk çoğu zaman en riskli değişikliğin en az gözetimle geçtiği pencereyi açar.
Bu yapının kurumsal bedeli, teknik borç kaleminde değil, incelemenin bambaşka başlıklarında ortaya çıkar. Kaynak koda ve tasarım arşivine ilişkin temsil ve tekeffül maddeleri, satıcının teslim ettiği teknik varlığın bütünlüğünü ve üçüncü taraf bileşenlerden arındırılmışlığını beyan etmesini gerektirir; bu beyanı destekleyecek bir sürüm ve bağımlılık kaydı yoksa, beyanın kapsamı ya daraltılır ya da beyanın arkasına bir escrow konur. Aynı şekilde, açık kaynak lisans uyumu incelemesinde sorulan soru hangi kütüphanenin kullanıldığı değil, hangi sürümünün hangi tarihten itibaren hangi ürüne girdiğidir; bu zincir gösterilemediğinde inceleme ekibi en geniş lisans yükümlülüğünü varsayarak ilerler, çünkü aksini gösteren bir kayıt yoktur.
Değerlemeye yansıma kanalı burada niceliksel olmaktan çok yapısaldır. Alıcı taraf, sürüm izlenebilirliği zayıf bir hedefte, kapanış sonrası entegrasyon süresini ve ürün geliştirme hızının ilk yıl içinde düşeceği varsayımını modeline koyar; devralınan ekibin ilk altı ayının önemli bir bölümü yeni ürün üretmeye değil, mevcut ürünün ne olduğunu haritalamaya gider. Bu varsayım fiyata bazen doğrudan bir iskonto olarak, çoğu zaman ise earn-out eşiklerinin geriye çekilmesi, kapanış öncesi koşul listesine teknik envanter tamamlama yükümlülüğü eklenmesi ya da escrow oranının bir mertebe yukarı kalibre edilmesi olarak geçer. Satıcı bu kalemleri ayrı ayrı müzakere ederken, hepsinin aynı boşluktan beslendiğini genellikle geç fark eder.
Ölçüm boyutu, bu alanda en sık boş bırakılan ve en kolay doldurulan katmandır. Sürüm yönetiminin sağlığını gösteren göstergeler egzotik değildir: onaysız ya da geriye dönük olarak kayda alınmış değişikliklerin toplam değişiklik içindeki payı, üretime çıkan sürümlerin geri alınma sıklığı, bir hatanın hangi sürümde girdiğinin tespit edilmesi için geçen ortalama süre, ve teslim edilmiş bir yapılandırmanın kayıtlardan yeniden kurulabilme oranı. Bu göstergelerin hiçbiri şirketin mevcut sisteminde olmayan bir veriyi gerektirmez; yalnız hiç kimse onları düzenli bir ritimle bakılan bir tabloya taşımamıştır. Ölçülmeyen alan, inceleme ekibi tarafından iyi ya da kötü olarak değil, belirsiz olarak sınıflanır, ve belirsizlik fiyatlamada her zaman olumsuz tarafa yazılır.
Süreklilik boyutunda aranan şey, disiplinin varlığı değil, disiplinin kişiden bağımsız olarak yeniden üretilebilmesidir. Bunun pratik sınaması basittir: şirkete altı ay önce katılmış bir mühendis, kimseye sormadan, yalnızca mevcut belge ve kayıtlara bakarak, belirli bir müşteriye teslim edilmiş belirli bir yapılandırmayı yeniden kurabiliyor mu? Cevap olumluysa sürüm yönetimi kurumsal bir kapasitedir; olumsuzsa, ne kadar titiz uygulanıyor olursa olsun, kişisel bir alışkanlıktır ve alışkanlıklar bilançoda varlık olarak taşınmaz. İnceleme ekibinin kurucu bağımlılığı başlığı altında değerlendirdiği şey, kurucunun ne kadar çalıştığı değil, kurumun kurucunun hafızasına ne ölçüde ipotekli olduğudur.
Yapısal müdahalenin ilk bileşeni kapsam tanımıdır: sürüm yönetimi neyi kapsayacak sorusu, araç seçiminden önce cevaplanır. Kod deposu bu kapsamın yalnızca bir parçasıdır; teknik şartnameler, mühendislik hesapları, saha revizyonları, müşteri bazlı konfigürasyonlar, test setleri ve dış bileşen bağımlılık listeleri aynı izlenebilirlik rejimine alınmadığı sürece, kapsam dışında kalan her kalem daha sonra en pahalı boşluk olarak geri döner. İkinci bileşen yetki mimarisidir: değişikliği kim önerir, kim onaylar, kim üretime alır ve acil müdahale durumunda bu zincir hangi kuralla kısaltılır — bu dört rolün aynı kişide toplanması operasyonel hız kazandırırken, incelemede tek kişilik kontrol noktası olarak okunur. Üçüncü bileşen kayıt anıdır: kaydın onay sonrasında değil, değişiklik önerildiği anda tutulması, gerekçenin sonradan rekonstrüksiyonunu ortadan kaldırır.
BEIREK'in bu alandaki müdahalesi, şirkete yeni bir araç kurmakla değil, mevcut üretimin izlenebilirlik haritasını çıkarmakla başlar: hangi çıktı türü hangi rejimde yönetiliyor, hangi çıktı hiçbir rejimde değil, ve kapsam dışı kalan kalemlerin hangileri sözleşmesel bir beyana konu olacak. Bu haritanın üzerine, değişiklik önerisinden üretime alınmaya kadar uzanan zinciri dört ayrı role bölen bir yetki tablosu ve acil müdahale için ayrı bir kısa yol tanımı yerleştirilir; kısa yolun varlığı disiplini zayıflatmaz, aksine kısa yolun tanımsız olduğu durumlarda ana zincirin fiilen terk edilmesini önler. Ölçüm tarafında, onaysız değişiklik payı, geri alma sıklığı ve yeniden kurulabilirlik oranı aylık bir gözden geçirme ritmine bağlanır; bu ritmin amacı performans denetimi değil, sürüm kaydının kendisinin sürekli kullanılan bir belge hâline gelmesidir, zira yalnız denetimde açılan kayıt, denetimde de eksik çıkar.
Bu müdahalenin bir yatırım süreci öncesinde yapılmasıyla süreç içinde yapılması arasındaki fark, işin niteliğinde değil, kimin gözü önünde yapıldığındadır. Kapanış öncesi koşul listesine giren bir teknik envanter tamamlama yükümlülüğü, aynı işi karşı tarafın takvimine ve karşı tarafın kabul kriterine göre yapmak anlamına gelir; aynı iş bir yıl önce yapıldığında ise şirketin kendi ritmine göre yapılmış, tamamlanmış ve doğrulanmış bir kapasite olarak veri odasına girer. Bu iki durumun değerlemeye yansıması aynı olmaz, çünkü inceleme ekibinin gördüğü şey birincisinde bir taahhüt, ikincisinde bir kayıttır.
Nihayetinde sürüm yönetimi, bir şirketin teknik kalitesini değil, teknik kalitesini ispat edebilme kapasitesini ölçer, ve yatırım masasında bu ikisi arasındaki fark fiyatın kendisidir. Bir mühendislik ekibinin ürettiği çözümün ne kadar iyi olduğu, o çözümün nasıl oluştuğunun geriye doğru izlenebildiği ölçüde şirkete ait sayılır; izlenemediği ölçüde ise, ne kadar iyi olursa olsun, onu üretmiş kişilere ait kalır. Değerlemenin sorduğu tek soru budur: bu performans şirketin mi, yoksa şirkette çalışan birkaç kişinin mi?