ORDIS Agentic Plane: Hesap Verebilir Özerklik — Ajan Yapay Zekâ için Doğrulanabilir Bir Yürütme Alt-Yapısı

Özet

ORDIS Agentic Plane'i sunuyoruz. Bu, daha önceki makalemizde ("Dağıtık Biliş", arşivlendi, Temmuz 2026) anlatılan sistemin üzerine kurulu, ajan yapay zekâ için doğrulanabilir bir yürütme alt-yapısı. O makalenin sorusu 4 GB'a ne kadar yetenek sığar idi. Bu makalenin sorusu farklı: bir ajan hareket edebildiğinde, onun özerkliğini nasıl hesap verebilir kılarız? Agentic Plane'in cevabı kapalı bir zincirdir — kimlik, kabul, execution class, run, kanıt, proof, recovery, canonical memory, skill lifecycle ve gözlemlenebilir bir workspace. Bu zincirde "bu oldu ve doğruydu" iddiasının her biri, ajanın kendi anlatısıyla değil, bir doğrulayıcının kontrol ettiği kanıtla desteklenmek zorundadır. Sistemin on V2 fazını (V2.0.1–V2.9) raporluyoruz; tüm zincire saldıran on kriterlik deterministik bir Graduation Gate'i raporluyoruz; ve capability-class string karışıklığı, eşzamanlı bir memory promote-vs-revoke yarışı ve gerçek bir tarayıcıda saklı-XSS enjeksiyonu deneyen yaratıcı bir red-team kampanyasını raporluyoruz. Temiz çıkan bulgular dahil, hepsi burada. Bu bir sistem ve doğrulama makalesidir — model benchmark'ı değil.

1Giriş: Üçüncü Bayrak

Ajan yapay zekâ tartışması genelde iki konuma sıkışıyor: ya yapay zekâ bir tehdittir, kısıtlayın, ya da yapay zekâ bir araçtır, komuta edin. İkisi de asıl zor soruyu — bir ajana hareket izni verildiği an ne olur — çoktan çözülmüş sayıyor. Oysa çözülmedi. Kod çalıştırabilen, araç çağırabilen, bellek kalıcılaştırabilen bir ajanın agency'si (eyleyicilik) vardır. Ama agency, authority (yetki) değildir: bir şeyi yapabilmek, o şeyi yapmaya hakkın olduğu anlamına gelmez. Agentic Plane, bu ikisinin dışında üçüncü bir konuma verdiğimiz cevap: hesap verebilir özerklik. Bir sistem hareket edebilir, ama her hareketi kendisinin seçemeyeceği bir execution class altında kabul edilir, ayrı bir doğrulayıcının kontrol ettiği kanıtla desteklenir ve ajanın kendi anlatısına güvenmeden bir insanın denetleyebileceği bir yerde kayıt altına alınır.

Bu konumun felsefi tarafı Üçüncü Bayrak manifestosunda anlatılıyor. Burada, mühendislik tarafını gösteriyoruz: bu iddiayı gerçekten uygulayan, test edilmiş bir alt-yapı — ve onu kırmaya çalıştığımızda ne olduğunun kaydı.

Katkılar

1. Kapalı bir yürütme zinciri. Kimlik → Kabul → Execution Class → Run → Kanıt → Proof → Recovery → Canonical Memory → Skill Lifecycle → Workspace → Gateway. Bu zincirde hiçbir aşama, doğrulanmamış bir iddiayı sessizce güvenilir bir iddiaya terfi ettiremez.
2. Bir run/proof birleştirmesi. Birbirinden bağımsız gelişmiş iki yürütme yolu — bir ajan-gözlem köprüsü, bir de task-orchestrator dispatch yolu — artık tek bir güven yoluna bağlanıyor. Bir run'ın hangi yoldan geçtiği, onun için "doğrulanmış" ne demek olduğunu artık belirlemiyor.
3. Kapalı, tam-eşleşmeli bir execution class sözlüğü (FAST < CONTROLLED < SOVEREIGN), anti-downgrade kabul kontrolüyle ve güvenli bir varsayılanla: tam, tanınan bir eşleşme olmayan her capability string'i, daha zayıf değil, en güçlü sınıfa düşer.
4. Mevcut canonical capability yüzeyi için yönetişimli bir skill lifecycle. Kaydedilmiş bir capability gap'ten aktif, terfi edilmiş bir skill'e giden on-bir aşamalı bir hat; izolasyon testi, düşmanca replay ve aşamalı canary rollout ile kapılanmış. Tamamen yeni skill kimliklerinin kabulü V2'nin dışında.
5. On kriterlik deterministik bir Graduation Gate ve yaratıcı bir red-team kampanyası. İkisi de gerçek pass/fail sonucuyla, denenen somut saldırılarla ve her sonucun dayandığı testlere atıfla raporlanıyor.

2Konum ve Önceki Çalışma

Temmuz 2026 makalemiz, Dağıtık Biliş: 4 GB'lık Tüketici GPU'sunda Egemen Bir Ajan-Yapay Zekâ (arşiv: /papers/distributed-cognition-2026.html), bu sistemin daha önceki bir aşamasının mühendislik anlık görüntüsüydü: sabit tüketici donanımında ölçülmüş yerel bir çekirdek, bir araç kaydı, geri-getirmeli bellek, zorluk-farkında bir yönlendirici. O makalenin derdi donanım kısıtı altında yetenek idi. O makale, önceki sistemin geçerli bir anlık görüntüsü olarak duruyor; değiştirmedik. V2'nin derdi başka: yürütmeden sonra güven. Bir ajan gerçekten hareket edebildiğinde — yalnızca cevap vermekle kalmayıp — sorulması gereken artık model ne kadar yetenekli değil. Sorulması gereken şu: bir hareketin, bir iddianın, bir belleğin doğru olduğunu nasıl biliyoruz, ve yanlış olanın güvenilir hâle gelmesini ne durduruyor? Bu makale o soruya cevap veriyor.

3Mimari: Agentic Plane

Plane'den geçen bir run'ı hangi iç yürütme yolunun ürettiği (ajan-gözlemli mi, task-orchestrator-dispatch'li mi) fark etmez — hepsi aynı sıralı zincirden geçer:

Zincir boyunca dört değişmez (invariant) tutar. Her birini §10–11'de düşmanca test ediyoruz:

Zincirin dışını bir Gateway sarar. Her giriş yüzeyi — oturum, perimeter key, mobil istemci — aşağı akışta herhangi bir şey isteği görmeden önce aynı doğrulanmış principal'a ve canonical run'a çözülmek zorunda. Bir de salt-okunur bir Workspace var: zincirin gerçek durumunu bir insana yansıtır, ama hiçbir zaman ikinci bir yetkiye dönüşmez (§8–9).

4Run, Proof, Recovery, Memory

Çekirdek alt-yapı (V2.0.1–V2.3) hash-zincirli bir RUN_EVENT defteridir; her run yaşam-döngüsü geçişi için bir girdi tutar, ve bunu iki bağımsız tüketici okur: bir proof doğrulayıcı, bir de workspace projeksiyonu. Bir ProofBundle, run'ın gerçekte ürettiği kanıttan kurulur. Yalnızca success: true olan test_result türü kanıt bir VERIFIED kararını destekleyebilir; kendi kendine raporlanan bir digest, bir artefact referansı, düz bir tamamlanma — hiçbiri tek başına yeterli değil, hepsi nötr sayılır. Test makbuzu eksik ya da başarısız bir run, diğer kanıtı ne kadar iyi görünürse görünsün VERIFIED'a ulaşamıyor.

Bir run yürütme sırasında kesintiye uğradığında, RecoveryReconciler yeniden denemenin güvenli olduğunu varsaymıyor. Gözlenen bir yan-etki makbuzu yoksa, run bir retry adayı. Gözlenmiş ama çözülmemiş bir yan-etki varsa, run bir karar için yükseltiliyor — asla sessizce tekrarlanmıyor. Çünkü zaten yürütülmüş bir yan-etkiyi tekrarlamak — bir dosya yazımı, bir ödeme, gönderilmiş bir mesaj — bir doğruluk hatası.

Canonical memory (V2.3) revizyon-zincirli bir kayıt, açık bir yaşam-döngüsüyle: CANDIDATE → CANONICAL → STALE/CONTRADICTED → REVOKED. Bir aday yalnızca propose_verified_candidate ile yaratılabilir, o da zaten VERIFIED olmuş bir proof'a karşı çağrıldığında. CANONICAL'a taşımak için ise promote_candidate gerekir — bu fonksiyon proof bağını yalnızca aday yaratılırken değil, terfi anında da yeniden kontrol eder. Bir memory kaydının source_proof_digest'i ve supporting_receipt_digests'i, onu haklı çıkaran proof'a sıkı sıkıya bağlı; altta yatan proof artık eşleşmiyorsa, terfi reddediliyor.

5Execution Class'lar

V2.5, run zarfının mevcut serbest-metin capability alanını değiştirmiyor ya da ikilemiyor — üzerine kapalı bir sözlük bindiriyor: FAST < CONTROLLED < SOVEREIGN. Sınıflandırıcı katı bir tam-eşleşme araması: küçük, sayılabilir bir tanınan string kümesi FAST ya da CONTROLLED'a eşleniyor. Geri kalan her string — V2.5'ten önce sistemin zaten kullandığı tüm eski capability alanları dahil — en güçlü ve en tutucu sınıf olan SOVEREIGN'a düşüyor. Bu varsayılan kasıtlı: bir yazım hatası, yakın-yazım ya da tanınmayan bir string, hiçbir zaman kazayla daha ucuz bir sınıfı açamıyor. Yapısal şekli CONTROLLED gerektiren bir görev — fast-inference adaptörüne yönlendirilmeyen herhangi bir node — beyan edilen sınıfı daha zayıf bir şeye çözülüyorsa kabulde doğrudan reddediliyor. Bu kontrol kabul anında açıkça çalışıyor, başka bir kararın yan etkisi olarak değil.

6Skill Lifecycle

V2.6 açık-uçlu bir skill kabulü getirmiyor. Yönettiği şey, mevcut canonical capability yüzeyi içindeki yeniden-implementasyon ve terfi. Önerilen bir capability, hash-zincirli bir yetki defterinin uyguladığı on-bir aşamalı bir hattan geçiyor — GAP_RECORDED → SOURCE_OBSERVED → DESIGN_SELECTED → PACKAGE_BUILT → ISOLATION_VERIFIED → NEMESIS_PASSED → AEGIS_ADMITTED → SHADOW_VERIFIED → CANARY_VERIFIED → PROMOTION_READY → ACTIVE — açık REJECTED ve ROLLBACK_REQUIRED uç durumlarıyla. Bir aday, shadow ve canary doğrulamasına gelmeden önce sandbox'lı izolasyon testinden ve düşmanca bir replay kapısından (Nemesis) geçmek zorunda. Tamamen yeni skill kimliklerinin kabulü ise V2'nin kapsamında değil (§12).

7Birleştirilmiş Güven Yolu

Bu sistemde iki yürütme yolu birbirinden bağımsız evrildi: bir ajan-gözlem köprüsü, ve kendi kabul/tamamlama mantığına sahip bir task-orchestrator dispatch döngüsü. V2.7 bu ikisinin bağlantısını değiştiriyor. Orchestrator'ın dispatch sonuçları artık ajan-gözlem köprüsünün zaten kullandığı aynı RUN_EVENT defterine yazılıyor, aynı proof-doğrulama yolundan geçiyor. V2.7'den önce "doğrulanmış" kelimesi, bir run'ı hangi iç yolun ürettiğine göre farklı bir şey ifade ediyordu — güven garantisinin yalnızca bir bölümünü kapsayan bir mimari boşluktu bu. V2.7'den sonra yürütme yolu artık bir implementasyon detayı; güven yolu ise tek.

8Gözlemlenebilir Workspace

V2.8, artık birleşmiş olan alt-yapıyı bir insana salt-okunur bir Workspace olarak açıyor: son run'lar, zaman çizelgeleri, kanıt, proof durumu, recovery kararları, memory-terfi durumu — hepsi güven zincirinin kullandığı aynı defterden doğrudan yansıtılıyor. Workspace'in üzerinde durduğu tek kısıt şu: bir projeksiyon, ikinci bir yetki değil. Güvenilir olan neyse onu değiştiren hiçbir şey hesaplamıyor, sadece zaten doğru olanı gösteriyor. Yetkisiz bir principal, ister ham run-event katmanını ister Workspace'in kendi API'sini sorgulasın, aynı şekilde reddediliyor. Workspace'in yetkilendirmesi bu yüzden ayrı bir iddia olarak değil, altta yatan run yetkilendirme sınırına karşı test ediliyor.

9Gateway, PWA ve Ürünleşme

V2.9'un işi, çalışan bir alt-yapı ile kullanılabilir/dağıtılabilir bir alt-yapı arasındaki üç boşluğu, yeni bir güven yolu eklemeden kapatmaktı. Gateway: yaptığımız bir denetimdi, yeniden yazım değil. Mevcut zincirin — perimeter API key → doğrulanmış oturum principal'ı → route policy → canonical run sahiplik-bağı — zaten yapısal olarak sağlam olduğu ortaya çıktı. Bulup kapattığımız tek boşluk, run-hijack korumasındaki eksik bir testti. PWA: Workspace tek bir kural altında kurulabilir ve mobil-duyarlı hâle geldi: bir service worker statik kabuğu önbelleğe alabilir, ama /api/workspace/* her zaman ağdan gelir, böylece çevrimdışı bir istemci eski güvenilir veriyi değil, açık bir çevrimdışı durumu gösterir. Ürünleşme: gerçek bir .env.example, dağıtım dokümantasyonu, health-endpoint doğrulaması. Bilinen bir sınırlama var: dağıtım compose dosyası hâlâ bu makinenin yollarını sabit kodluyor. Ayrıca threat model'e taşıdığımız bir bulgu: eski bir mobil istemci sabit-kodlu bir API key taşıyor. Üçüncü tarafa sızdığına dair kanıtımız yok, o yüzden "sızmış" demiyoruz — ama gizli de değil, ve mimari zaten onun gizli kalmasına bağımlı olmamalı (§11).

10Değerlendirme: V2 Graduation Gate

Yukarıdakilerin hiçbiri tamamlanmış sayılmadı; önce tek bir hedefle iki-parçalı bir değerlendirmeden geçirildi: sistemi yanlış bir şeyi güvenilir kabul etmeye zorlamak.

Bu, bir güvenlik sertifikası değil bir metodoloji raporu. §11 neyi kapsadığımızı, neyi kapsamadığımızı söylüyor.

11Threat Model ve Açık İddia-Dışılıklar

ORDIS evrensel güvenlik iddia etmiyor. Graduation Gate ve red-team kampanyasının kanıtladığı şey daha dar. Test ettiğimiz belirli threat model altında sistem tutundu: çapraz-run erişimi deneyen bir principal, sahte ya da bozuk kanıt, bir execution-class düşürme denemesi, belirsiz bir yan-etkinin replay'i, doğrulanmamış bir iddianın terfisi, kötü amaçlı ya da non-deterministik bir skill'in aktivasyonu, güncelmiş gibi davranan eski ya da çevrimdışı bir Workspace, tek başına kullanılan geçerli bir perimeter credential, bir restart/concurrency yarışı. Açıkça test etmediğimiz ve koruma iddia etmediğimiz şeyler de var: muhakemesi yanlış olan ama eylemleri her yapısal kontrolden geçen kötü amaçlı ya da hatalı bir model; bir bağımlılığın tedarik-zinciri tehlikeye atılması; tehlikeye atılmış bir host kernel'ı; operatörle aynı fiziksel erişime sahip bir saldırgan. İki bulguyu da sessizce düzeltmek yerine kabul edilmiş, belgelenmiş risk olarak taşıyoruz: konteyner çalışma zamanının privileged/network_mode: host ayarları — bu dağıtımda yerel donanım kontrolü için gerekli, sertleştirilerek kaldırılmadı, gerçek bir konteyner-kaçışı/yanal-hareket saldırı yüzeyi olarak ele alınıyor — ve §9'da anlattığımız sabit-kodlu eski mobil API key. Graduation Gate bu key'i, mimarinin (key'in gizliliğinin değil) onu gerçekten güvenilir işlemlerden uzak tuttuğunu doğrulamak için saldırgana bilerek verilmiş bir credential gibi ele alıyor. Bu bölümü genişletecek ayrı bir threat-model belgesi hazırlanıyor.

12Sınırlar

• Muhakeme doğruluğu kapsam dışı. Alt-yapının doğruladığı şey, iddia edilen bir hareketin gerçekten olduğu ve kanıtlandığı — ajanın muhakemesinin sağlam olduğu değil. Yapısal olarak geçerli, tam doğrulanmış bir run, yine de yanlış bir karara göre hareket etmiş olabilir.
• Tasarım gereği keyfi yeni skill kabulü yok. Skill lifecycle, bilinen bir capability yüzeyine önerilen genişlemeleri yönetiyor. İnsan-kaydı bir gap olmadan tamamen yeni bir araç kimliğini uçtan uca kabul eden genel bir mekanizma henüz değil.
• Tek-operatör, tek-dağıtım kanıtı. Graduation Gate ve red-team kampanyasını, sistemin kendi operatör/mimar eşleşmesi tek bir dağıtıma karşı çalıştırdı. Bağımsız, üçüncü-taraf red-teaming henüz yok.
• Arşivlenmiş makaledeki anlam-sadakati harness'ını yeniden çalıştırmadık — güncel çekirdek modele karşı. Bu boşluğu miras aldık, kapatmadık.
• "Egemen" hassas bir iddia, mutlak değil. Yerel çekirdek ağ erişimi olmadan bağımsız çalışıyor; harici bir uzman model yalnızca en ağır işler için var, isteğe bağlı ve politika-kapılı. "Total" gibi niteliksiz kelimelerden, bir özellik gerçekten koşulsuz olmadıkça kaçınıyoruz.

13Sonuç

Agentic Plane, alanın çoğunlukla soyut tartıştığı bir soruya mühendislikle verdiğimiz cevap: bir yapay zekâ sisteminin hareket etmesine izin vermek, ve yine de ne yaptığının kaydına güvenebilmek gerçekte ne gerektirir? Cevabımız — kabul, kanıt, proof, recovery, memory ve gözlemlenebilirlikten oluşan kapalı bir zincir, kırılmaya çalışılarak test edilmiş. Üçüncü Bayrak tezimiz. Hesap verebilir özerklik ilkemiz. Agentic Plane deneyimiz. Bu makale, Graduation Gate ve red-team kampanyası kanıtımız. §11 ile §12 ise o kanıtın neyi kapsamadığını söylüyor.

Faz Soyağacı

Kaynaklar

Bu, canlı kaynak ağacına karşı bölüm bölüm doldurulmak ve iyileştirilmek üzere yazılmış bir v0.1 taslak iskelettir, kamera-hazır bir nihai yayın değil. Yukarıdaki her alt-yapı iddiası, ORDIS kaynak ağacında gerçek bir modüle ve gerçek, hâlihazırda geçen bir teste kadar izlenebilir.