Relació d’autoritat
Per a un punt de control acceptat H, l’autoritat d’exportació neutral del backend exposa un prefix immutable coherent:
E_H = Export(AcceptedAuthority[<= H], Law, Retention, RunpackV6)
CurrentState(H)
= Replay(AcceptedHistory[<= H])
= Reconstruct(E_H)
decision-gate-core posseeix la interfície d’exportació d’auditoria d’execució acceptada i les projeccions de punt de control/pàgina segellades. Les autoritats en memòria i SQLite implementen aquesta mateixa relació. decision-gate-runpack posseeix la construcció de format-v6, identitats nominals, arbres d’objectes deterministes, i el repositori local immutable. decision-gate-verifier posseeix el redactor de material subministrat independent i l’informe de reclamació exacte. MCP i CLI només componen aquestes autoritats.
Subjecte de Runpack-v6
El manifest vincula la versió de format/canonització, el domini d’autoritat acceptada, el RunKey exacte, les identitats de llei d’escenari i gràf de Xarxa, el cap acceptat, perfils de límit efectius, paràmetres d’arbre fixos, i les arrels de totes les dotze famílies d’artifactes obligatòries. Les històries buides utilitzen una arrel de família buida canònica; l’omissió de la família no és una altra ortografia de buit.
Les dotze famílies són font de l’escenari, llei d’escenari validada, perfils efectius, membres de tombstone d’assignació d’execució, rebut de creació, estat actual acceptat, registres de mutació acceptats, rebuts d’operació acceptats, registres d’obertura d’etapa, registres d’intent d’avaluació, registres de presentació, i registres d’intenció compromesa.
Els objectes són JSON canònics limitats. Les fulles no contenen més de 256 registres o 32 MiB, la dispersió d’índex no és superior a 256, la profunditat de l’arbre no és superior a vuit, i el manifest no és superior a 256 KiB. La identitat de l’objecte vincula el format, la família d’artifacte, el tipus d’objecte, l’interval de clau/ordinal, i els bytes canònics. La identitat del manifest vincula el subjecte complet del manifest sota el domini dg/runpack/v6. Els constructors transmeten en memòria limitada; la representabilitat no es defineix per un límit de mida de paquet monolític.
Runpack v5 i cada format anterior rebutgen la rehidratació hostil. L’esquema SQLite 11 és l’únic esquema durable local actual; l’esquema 10 i anterior rebutgen sense migració o anàlisi de compatibilitat.
Exportació neutral del backend
Una exportació comença capturant un AcceptedRunAuditCheckpoint. Cada pàgina limitada subseqüent està lligada a aquest punt de control i pot contenir cap registre després del seu cap acceptat. Les mutacions acceptades més tard, per tant, no poden canviar el subjecte exportat. La construcció de la pàgina deriva el cursor de continuació de files estrictament ascendents limitades per revisions; els cridants no poden afirmar independentment un cursor, una fila després del punt de control, o una pàgina per sobre del límit. Els intents, les presentacions i les projeccions d’intenció mantenen la seva revisió acceptada propietària, i les famílies d’intenció mantenen i revaliden la identitat del registre acceptat propietari. La memòria captura el punt de control mentre manté l’autoritat de la cel·la d’execució; SQLite el captura transaccionament i transmet files immutables indexades sense mantenir una transacció de longitud històrica.
La feina d’exportació normal està limitada per pàgina, fulla, i dispersió d’índex. L’estat i els camins calents de mutació no reprodueixen tota la història. Un backend no està qualificat només per implementar el trait; ha de passar els conjunts de conformitat d’exportació d’auditoria i execució acceptada compartits per al seu perfil de durabilitat declarat.
Autoritat de publicació
El únic repositori OSS suportat és local i arrelat a la capacitat. Un operador admet una arrel ambiental a través de platform_filesystem_authority::ExplicitAmbientAuthority; el codi semàntic i MCP rep objectius relatius segellats, mai camins de confiança arbitrària.
Els objectes es publiquen amb semàntica de crear-nou. Els objectes existents només es reutilitzen després de la verificació exacta de bytes. El manifest es publica per últim, així que els objectes orfes no fan visible un runpack. La publicació retorna la família de coneixement tancada Published, AlreadyPresentExact, Conflict, Unavailable, Indeterminate, o IntegrityFailure.
No hi ha sobreescriptura, eliminació, clau d’objecte seleccionada pel cridant, nom de manifest arbitrari, recuperació de xarxa, temps d’execució S3/object-store, o resolutor genèric en el perfil OSS inicial. La reclamació de sistema de fitxers local segur és només per a Linux, seguint l’autoritat del sistema de fitxers de la plataforma. La publicació immutable remota és una capacitat DG-E/PF-08 especificada de manera independent i ajornada.
Verificació de material subministrat
La verificació consumeix un paquet complet en memòria o una arrel de capacitat local subministrada explícitament, més bytes suplementaris subministrats explícitament opcionalment, el tipus, digest, límit, i relació propietària dels quals són validades. El verificador no té dependències de xarxa, proveïdor, MCP, SQLite, rellotge, camí ambiental, o adquisició en temps d’execució. Un localitzador no és material; la falta de material genera una reclamació exacta d’Unavailable i mai activa la recuperació.
El límit de material suplementari és actualment una costura de biblioteca de verificació, no una opció de directori CLI genèrica. Els bytes limitats per digest només estableixen la integritat del contingut. Fins que una família d’autoritat externa posseeixi un constructor que valida la sintaxi i relació exactes del testimoni, aquests bytes no poden satisfer les reclamacions d’autenticitat, actualitat, retrocés, enviament, implementació, o procedència de construcció. Per tant, la CLI no exposa un argument --material-root enganyós.
El redactor independent no confia en l’estat actual emmagatzemat ni crida el finalitzador de mutació de producció. El verificador completa primer el procediment d’integritat de l’arbre d’objectes limitat independent per a totes les dotze famílies; la malformació semàntica, per tant, no pot ocultar ni reclasificar la reclamació d’integritat estructural. A continuació, reconstrueix l’història acceptada a partir de registres canònics i comprova la continuïtat del cap/predecessor, la propietat de rebut i família d’operació, els índexs d’obertura/intent/presentació d’etapa, la propietat d’intenció, l’estabilitat del temps d’acceptació, i la igualtat amb la projecció actual emmagatzemada. Reutilitza RET, Xarxa, admissió d’observació tipificada, i avaluació pura com a bases matemàtiques de confiança nomenades en lloc de duplicar les seves lleis.
La verificació MCP realitza l’autorització d’eines, llegeix només el manifest canònic limitat per resoldre l’espai de noms exacte, completa l’autorització de l’espai de noms, i només llavors permet el recorregut de l’arbre d’objectes i la reproducció semàntica. Els cridants no autoritzats no poden gastar el pressupost complet de verificació ni investigar la disponibilitat d’objectes.
El registre de reclamacions tancades conté 29 reclamacions ordenades per dependència. Cada informe conté cada fila del registre amb un dels següents: Satisfied, Disproved, Unavailable, NotRequested, NotApplicable, Indeterminate, o VerifierFailure. Els perfils seleccionen files sol·licitades; mai col·lapsen l’informe en un booleà autoritzat. El fracàs de dependència impedeix un resultat positiu a la baixada.
El perfil per defecte CompleteOfflineReplayV1 decideix tot el suportat pel material subministrat. L’autenticitat de la font, l’actualitat, la coherència de la resistència al retrocés, la recuperació de l’enviament/efecte, la qualificació de la implementació, i la procedència de la construcció externa romanen indisponibles a menys que s’aporti un testimoni exacte qualificat per separat. PF-05 no implementa cap autoritat de signatura i mai converteix la consistència del digest en autenticitat.
Evidència actual i no-reclamacions
L’evidència centrada cobreix el comportament de resposta coneguda d’identitat canònica, la reconstrucció d’objectes/manifests hostils, arbres multi-nivell deterministes, substitució de symlink del repositori local i bytes retinguts, esgotament de pressupost exacte, propagació de dependència de reclamació, mutacions d’història/index/estat actual criptogràficament autoconstants, fracàs de publicació parcial, falsificació del constructor de pàgines, exclusió de dependència de verificació, paritat d’exportació de memòria/SQLite, i generació de contracte extern actual. Els fracassos d’autoritat del sistema de fitxers diferents de l’absència provada es classifiquen com a fracassos d’integritat en lloc d’ordinaris d’indisponibilitat material. La prova registrada golden_runpack_cross_os reconstrueix un subjecte acceptat determinista en memòria, realitza la verificació offline de material subministrat, i comprova la seva identitat exacta de runpack-v6 canònica a través del catàleg de proves generat. El Kani s’utilitza per a la decodificació de llargada fixa i l’aritmètica de comptatge/arbre verificat, però encara no s’ha reclamat cap resultat d’execució de DG Kani. El repositori ja separa el seu espai de treball de producció Rust 1.96 d’un espai de treball de prova aïllat Kani 0.67.0 generat per la cadena d’eines Rust 1.93 empaquetada de Kani. L’obligació restant de PF-05 és un manifest/perfil propietat de DG sota aquell mateix corredor materialitzat, enumeració completa de l’harnès, execució, i retenció de resultats immutables; la diferència de versió de la cadena d’eines no és un bloqueig.
La prova daurada ha passat pel camí d’evidència local de Linux. La matriu d’Ubuntu/Windows registrada encara no ha produït un resultat observat de Windows per a aquest candidat, així que la qualificació entre sistemes operatius roman oberta. Els diagnòstics de història actuals de SQLite 1/1,000/100,000 tampoc tanquen la transmissió de milions de registres, la memòria màxima, o la qualificació de productes calibrats.
PF-05 no prova la veritat de la font, l’autoritat actual, la protecció contra retrocessos, els efectes externs, l’aïllament de la implementació, la correcció del repositori remot, o la preparació per al llançament. Aquests romanen exactes com a reclamacions de perfil posterior.