Flyg- och rymdindustri
Säkerhetskritisk sign-off och luftvärdighetsspårbarhet lämnar inget utrymme för ett granskningssteg som inte kan rekonstrueras senare. Den här sidan anger hur ett sådant arbetsflöde skulle planeras och köras på inTheEU Assist, inte en registrering av en slutförd implementering.
Hur arbetsflödet skulle struktureras
En dokument- eller processgranskning skulle planeras som en ordnad sekvens av steg, var och en med en definierad omfattning: analys, utarbetande, sign-off. Hela sekvensen skulle hashas innan exekvering, så planen som en granskande ingenjör godkänner är kryptografiskt bunden till vad systemet faktiskt utför. Det finns inget utrymme för den körda sekvensen att glida från den som granskades.
Ett skede som flaggats som kräver sign-off skulle inte fortsätta till nästa steg förrän ett uttryckligt, undertecknat godkännande från den ansvariga ingenjören eller kvalitetsgranskaren registreras mot det.
Där mänskligt godkännande sitter
Varje avloggningspunkt i sekvensen skulle vara gated bakom ett uttryckligt mänskligt godkännande, inte en allmän tillåtelse för att arbetsflödet ska köras. Dokumentet för det godkännandet, vem som undertecknade, i vilket skede, mot vilken version av dokumentet, skulle kunna verifieras oberoende av en revisor som endast innehar den relevanta publika nyckeln, utan att behöva ha tillgång till säljarens system.
Vad detta bygger på idag och vad det inte gör
Den stegvisa godkännandestrukturen, hashningen på plannivå som binder en godkänd sekvens till dess utförande och den offline-verifierbara signerade revisionsspåret är fungerande delar av plattformen. Vad är inte en del av detta: någon förbyggd luftvärdighetsbedömning eller säkerhetsanalysmodell. Ingenjörs- och kvalitetsteam förblir auktoriteten om vad en sign-off betyder; plattformen gör att sign-off kan bevisas, på plats, så länge som dokumentet behövs.
En del av arkitekturen som ligger till grund för denna funktionsuppsättning är dokumenterad i ansökningar som fortfarande pågår. Den här sidan beskriver vad plattformen är designad för att göra, på en nivå som är lämplig för att planera en pilot, inte en implementeringsspecifikation.
Plattformsfunktioner och gränssnitt är föremål för ständiga förbättringar. Beskrivningarna i den här guiden kanske inte återspeglar den exakta layouten eller ordalydelsen för den senaste versionen.