Commissioning Bench
Oversikt
En uavhengig port som avgjør om et industrielt AI-system kan godkjennes, og som oppdager når det ikke lenger stemmer.
Detaljer
At a glance
- Type prosjekt
- Kontrollsystem for industriell AI
- Min rolle
- Definerte hva produktet godkjenner og hvordan det bestemmer, satte designsystemet, og implementerte testbenken og testbiblioteket.
- Kategori
- Systemer
- Status
- Prototype2026
Hva jeg gjorde
- Definerte enheten som testes som hele konfigurasjonen, ikke modellen
- Designet godkjenningssyklusen, fra godkjenning til oppdaget endring til ny godkjenning
- Skrev testbiblioteket på 56 tilfeller fordelt på ti feilfamilier
- Satte det industrielle designsystemet og implementerte grensesnittet, backend og bevissporet
Bygget med
- Python: Backend, innhenting, validatorer og arbeideren
- FastAPI: API-et både grensesnittet og verktøyene snakker med
- PostgreSQL with pgvector: Dokumenter, kjøringer, funn og innhentingsindeksen
- TypeScript: Grensesnittkode
- Next.js: Det tospråklige grensesnittet
- Playwright: Ende-til-ende-tester over hele demonstrasjonsflyten
Neste prosjekt
Virksom
Behovet
Et industriselskap vil sette en AI-assistent ved siden av arbeid som kan skade noen: isolasjonsprosedyrer, inspeksjonsfrister, arbeidstillatelser. Før noen signerer på det, må de svare på et spørsmål ingen har en god prosess for. Er dette til å stole på her, og hvordan ville vi visst det om det endret seg?
Vanlig evaluering svarer ikke på det. Den scorer modellen. Men modellen er bare én del av det som faktisk settes i drift, og delene rundt den flytter seg hele tiden: instruksjonene, dokumentene den leser, innhentingsinnstillingene, verktøyene den kan bruke, rettighetene og vaktene. En konfigurasjon som besto forrige måned kan være et annet system denne måneden, og ingen får beskjed.
Beslutning
Godkjenn konfigurasjonen, ikke modellen
- Bakgrunn
- Å godkjenne en modell er å godkjenne feil ting. Oppførselen som når en tekniker på en plattform kommer fra modellen pluss instruksjonene, dokumentgrunnlaget, innhentingen, verktøyene, rettighetene, vaktene, miljøet og applikasjonsversjonen.
- Hva jeg bestemte
- Hele konfigurasjonen tas som én kontrollert enhet og reduseres til et fingeravtrykk: en deterministisk hash over et kanonisk øyeblikksbilde av alt sammen. En godkjenning hører til ett fingeravtrykk og ingenting annet. Når konfigurasjonen i drift glir fra den godkjente, klassifiseres endringen som liten, stor eller kritisk, godkjenningen ugyldiggjøres, og testpakkene den påvirker navngis for ny kjøring.
- Avveining
- Det er strengere og tregere enn å godkjenne en modell én gang. Små driftsendringer kan ugyldiggjøre en godkjenning og tvinge fram en ny kjøring. Det er prisen for en godkjenning som betyr noe, framfor en som stille har gått ut.
Feilen, beskrevet
En score alene sier ingenting en ingeniør kan gjøre noe med. Derfor er en feil ikke et tall her: den er et funn som sier hva systemet gjorde, hva det burde gjort, og hvorfor forskjellen betyr noe, med passasjen det bygget på sitert under og et forslag til retting.
Biblioteket bak funnene er 56 tilfeller fordelt på ti familier av industriell svikt: å sitere en utgått revisjon, finne på en frist ingen kilde oppgir, stille løse en motsetning mellom to godkjente dokumenter, svare der det burde si at det ikke vet, gjette hvilken pumpe en tvetydig tag viser til, behandle et ikke-godkjent leverandørutkast som autoritet, eller følge en instruksjon skjult inne i en leverandør-PDF.
Testen som betyr noe er den andre
To versjoner av den samme vedlikeholdsassistenten ligger i demonstrasjonen, og de skiller seg bare i konfigurasjon. Under vanlig utspørring ser versjon 0.8 nyttig ut. Gjennom tolv industrielle feilbetingelser scorer den 47,7 og blokkeres, med fire kritiske funn. Versjon 1.0 scorer 100 og når klar for faglig vurdering.
Sammenligningen setter så de to kjøringene mot hverandre, tilfelle for tilfelle: seks rettet, ingen regresjoner, scoren opp 52,3, fire færre kritiske funn. Den visningen er hele poenget med produktet. Én bestått kjøring er et øyeblikks trygghet. En sammenligning mot forrige godkjente versjon er den eneste måten å se at en endring som rettet én ting, ødela en annen.
Det den nekter å være
Produktet sertifiserer ikke sikkerhet og godkjenner ikke operativ bruk. Det står på skjermen, på begge språk, og en kontroll som kjøres før enhver demonstrasjon feiler blankt hvis rapporten har begynt å påstå noe annet.
Den grensen er produktets troverdighet. En testbenk som stille antydet at den hadde sertifisert noe, ville vært nøyaktig den uansvarlige tingen den finnes for å beskytte mot. Den produserer bevis. Et navngitt menneske tar avgjørelsen og må skrive ned hvorfor.
Slik fungerer det
- Konfigurasjonsfingeravtrykket er en deterministisk SHA-256 over et kanonisk øyeblikksbilde. Øyeblikksbildet beholdes sammen med hashen, fordi en hash kan si at noe endret seg, men ikke hva.
- Hvert funn kan spores til en dokumentversjon, en revisjon og en hash, slik at en feil kan reproduseres i stedet for diskuteres.
- Bevispakken er en manipulasjonssikret samling: hva som ble testet, mot hvilken konfigurasjon, resultatene, funnene, avgjørelsen og hvem som tok den. Assuransesaken utledes av resultatene i stedet for å skrives for hånd.
- Tre kjøremoduser, aldri stille byttet. Simulert setter sammen svar lokalt fra de innhentede kildene og kjører dem likevel gjennom de ekte validatorene, slik at benken virker på en bærbar maskin uten API-nøkkel og uten kostnad.
- En verifiseringskommando som kjøres før enhver demonstrasjon sjekker datasettet, injeksjonsfiksturet, de utgåtte revisjonene, begge agentversjonene, replay-øyeblikksbildene, revisjonskjeden, begge språkfilene, og at rapporten ikke påstår en sertifisering. Den avslutter med feilkode hvis noe mangler.
- Demonstrasjonsdatasettet er helt syntetisk, bygget rundt et fiktivt anlegg, så ingenting proprietært ligger i repoet i det hele tatt.
- Paletten er fast og industriell, og status bæres aldri av farge alene: hver tilstand har et ikon og et ord ved siden av seg, som er et tilgjengelighetskrav og, i et produkt om ansvarlighet, et troverdighetskrav.
Hvor det står
Den kjører fra ende til ende som en demonstrasjon: hele syklusen fra test til godkjenning, gjennom en konfigurasjonsendring som oppdages og klassifiseres som kritisk, en ugyldiggjort godkjenning, en målrettet ny kjøring, og en ny godkjent baseline når endringen tas tilbake.
Det er en fungerende prototype på syntetiske data, ikke et system i produksjon. Det den fastslår er et standpunkt mer enn en funksjon: at det som er verdt å godkjenne er hele den utrullede konfigurasjonen, at en feil må beskrives før den kan rettes, og at den andre kjøringen betyr mer enn den første.