Fonaments de Decision Gate

Vau trobar tres reclamacions a la pàgina de resum: un agent de recerca va citar un cas que no existeix, un agent de codificació va informar de cinc proves aprovades que no tenia, i un agent de llançament va dir "llest per enviar" i tenia raó. Aquesta pàgina recorre el mateix terreny lentament: què passa entre un agent que diu alguna cosa i un flux de treball que ho accepta.

L’agent diu que ha passat alguna cosa

Cada una d’aquestes escenes comença de la mateixa manera: prosa fluida afirmant un fet. “Citat: Varghese v. China Southern Airlines.” “He afegit 5 proves i totes passen.” “v2.1 està llesta per enviar.”

El mode de fallada no és que els agents menteixin més del que solien. És que el sistema circumdant tracta la frase com el fet. Res en “tots aproven” porta la prova realitzada, el compromís contra el qual es va executar, o qui ho va observar. Una afirmació és una proposta sobre la realitat, i una proposta necessita alguna cosa fora del propositor abans que esdevingui veritat operativa.

La proposició que importa

El primer pas és decidir a què s’adhereix realment la frase i escriure-ho com a condicions escrites:

Claim: "I added 5 tests and they all pass."

C1: new_test_count == 5
C2: all(required_test_status == PASSED)
C3: tested_commit_digest == delivery_commit_digest

Cada condició nomena un domini d’observació tancat (un recompte enter, un enum d’estat, un resum d’amplada fixa) i un predicat sobre ell. No hi ha lloc per a “aproximadament cinc” o “principalment aprovat”, i no hi ha coerció implícita que decideixi tard si 1 és igual a 1.0. Nota C3: res en la frase original esmentava compromisos, però “aprovat” no té sentit sense “aprovat en què”. Escriure les condicions és on les suposicions silencioses esdevenen obligacions explícites.

Prova

Les condicions es compleixen mitjançant proves, i les proves mai no obtenen el benefici del dubte. Cada peça porta els seus fets obertament: com va arribar (presentada pel sistema de convocatòria, o adquirida d’una font local declarada), de què es tracta exactament (quin executiu, quin compromís, quin compte), quan es va observar, quines proteccions d’integritat la cobreixen, i quina independència té la seva font respecte a l’agent que s’està comprovant.

Aquests fets no es col·lapsen en un únic puntuació de confiança. La política d’ús d’evidència d’una condició nomena la combinació que és suficient per a aquesta afirmació en aquest context. Un flux de treball de desenvolupament pot acceptar el propi informe de prova de l’agent; un flux de treball de llançament pot requerir un rebut d’un sistema independent, vinculat al compromís exacte. El mateix valor boolean, sota dues polítiques, porta dues quantitats diferents de prova — i el sistema manté aquesta distinció en comptes de suavitzar-la.

Present, absent, desaparegut, insuficient

Quan una condició demana proves, la resposta es resol exactament d’una de quatre maneres:

ResolucióSignificat
PresentUn valor que satisfà la política està disponible.
ObservatAbsentUna observació completa demostra l’absència en un univers declarat.
ManquantsNo s’ha subministrat ni adquirit mai res per a aquest objectiu.
InsuficientExisteix evidència, però cap d’ella satisfà la política.

Les dues files del mig són on els sistemes ordinaris sobrevaloren. Una consulta de registre que es queda sense temps no prova res. Una cerca que no va retornar files però que mai va acabar de paginar no prova res. Només una consulta completa sobre un univers declarat pot provar que un registre està absent — que és exactament la comprovació que la escena de citacions fabricades necessitava: no “no ho vam trobar”, sinó “una cerca completa del reporter prova que no hi és”.

Vertader, Fals, Desconegut

Un predicat tipat sobre una resolució vàlida produeix un dels tres resultats semàntics:

ResultatSignificat
CertLa prova satisfà el predicat.
FalsLa prova contradiu el predicat.
UnknownLa prova admissible no decideix el predicat.

Desconegut és l’estat de treball, no un error. Els sistemes de dos valors han de redondejar-ho — no provat esdevé fals (dades mancants castigades com a fallida) o no provat esdevé vertader (progrés no suportat acceptat). Tres valors permeten que la porta es mantingui: la reclamació de l’agent de codificació sense informe de prova no és falsa, és indecisa, i el flux de treball pot dir precisament quina obligació està oberta.

Les fallades es queden fora d’aquest triangle. Un error de sintaxi, un temps d’espera, una autorització denegada — aquests són esdeveniments operatius amb el seu propi maneig. Mai no es presenten com a Unknown, i mai no es converteixen silenciosament en False.

Requisits

Les condicions individuals es combinen en requisits — la lògica de “fet”:

ALL(C1, C2, C3)                          -- every obligation holds

ALL(tests_passed, coverage_met,
    critical_findings == 0)              -- the release gate from the overview

QUORUM(2 of: alice_approved,
             bob_approved,
             carol_approved)             -- human sign-off as evidence

L’avaluació dels requisits és determinista i preserva l’Unknown: un requisit els inputs del qual no poden decidir encara es manté indecís en lloc de passar a ser per defecte. L’aprovació humana es compon com qualsevol altra condició: una signatura enregistrada és una prova, una que falta manté la porta tancada, i dos de tres quorums deixen de significar “qui hagi respost primer a Slack.”

Els fluxos de treball són gràfics

El treball real no és una línia recta. Les proves i un escaneig de seguretat poden funcionar en paral·lel; l’aprovació espera en ambdós; la entrega espera l’aprovació. Decision Gate modela un flux de treball com un gràfic de dependències sobre etapes:

build --> verify-tests ----+
                           +--> approval --> bind-artifact --> release
build --> security-scan ---+

Una etapa no està llesta, preparada, oberta o completada — i la preparació deriva del progrés complet acceptat, no de la narrativa de ningú sobre això. El progrés només avança: una vegada que una etapa està llesta perquè els seus requisits previs s’han completat, el progrés posterior en altres llocs no pot desfer-la. Acabar l’última caixa no prova res per si mateix; l’escenari declara la seva pròpia llei de completament sobre les etapes completades.

Progrés acceptat

L’avaluació produeix un resultat; l’acceptació el converteix en història. Cada execució manté un registre acceptat del que s’ha establert: quines condicions s’han resolt, a partir de quines proves, sota quina política, completant quines etapes. Les reclamacions provades es registren amb la seva prova. Les reclamacions no provades es mantenen — tancades per fallada — amb l’obligació no resolta nomenada. Res avança perquè una sentència soni acabada.

El registre està dissenyat per ser verificat més tard: el que es va reclamar, el que es va observar i el que es va decidir es poden tornar a verificar sense confiar en el sistema que ho va enregistrar. Això és el que transforma “l’agent ho va dir” en “l’execució ho mostra.”

Continua

Applications mostra aquestes peces dins de superfícies de producte reals. How It Works argumenta rigorosament — incloent el que aquesta maquinària deliberadament no afirma. La Documentació conté la referència completa.