alva/felsokning/docs/PANELGRANSKNING-2026-08.md

Panelgranskning · ALVA 3.2

Simulerad expertpanel · 2026-08-06 · ALVA-DOC-0005

Detta är en intern stresstest-övning, inte ett verkligt branschutlåtande. Panelens säten är rollbeskrivningar. Ingen namngiven organisation har deltagit, granskat eller uttalat sig om produkten, och dokumentet får inte spridas som om så vore fallet. Värdet ligger i kritiken, inte i avsändaren.

Varje fynd nedan är kontrollerat mot koden. Där panelen påstår något om systemets beteende står filen. Där panelen gissar står det att den gissar.

---

0. Vad som faktiskt granskades

Version	ALVA 3.2 (services/gemensam/version.mjs)
Kodbas	Vite/React-klient, node:http-tjänster, PostgreSQL
Provning	750 enhetstester, 186 integrationskontroller mot riktig Postgres, e2e-genomgång som stänger fyra ärenden, designtest över hela ytan
Metodikbibliotek	16 metodiker (services/gemensam/metodiker.mjs)
Språk	10, engelska som källspråk

Panelen har läst källkod, inte demonstrationer. Det är avsiktligt: en demonstration visar det som fungerar.

---

1. Ordförande — inledning och avgränsning

Innan sakfrågorna vill jag slå fast vad vi bedömer, eftersom panelen annars kommer att prata förbi varandra hela dagen.

ALVA är inte ett diagnossystem i den mening branschen använder ordet. Det ställer inga diagnoser, rangordnar inga felkällor och räknar inga sannolikheter. Det är ett process- och evidenssystem: det tvingar fram en viss ordning, kräver att varje påstående bär underlag, och vägrar stänga ett ärende som inte gör det.

Det betyder att jämförelsen "bättre än dagens OEM-system" är fel ställd. Ett OEM-system är en kunskapskälla. Det här är en kravställare på dokumentationen. De konkurrerar inte; frågan är om de går att kombinera.

Om vi håller isär de två sakerna blir mötet användbart. Om vi inte gör det kommer märkesrepresentanterna att döma ut produkten för att den inte kan något de aldrig påstått att den kan.

---

2. Enskilda utlåtanden

2.1 Teknisk chef — volymtillverkare personbil (VW-sätet)

Jag har gått rakt på det som avgör om vi kan använda det här: kopplingen till våra egna procedurer finns inte.

Metodikbiblioteket är sexton handskrivna procedurer. VIBRATION börjar med att fotografera fyra hjul och mäta kast. Det är rimligt allmänt hantverk, men det är inte vår procedur, det följer inte våra TSB:er, och det uppdateras inte när vi ändrar oss. GENERISK är ett strukturellt skyddsnät — den fungerar för allt just för att den inte vet något.

Vad som saknas, konkret:

• Ingen bindning till OEM-procedur. Ett steg kan inte referera "TSB 2026-14 rev 3". Det finns inget fält för det.
• Inga gränsvärden. matvarde bär beskrivning, varde, enhet (services/gemensam/handelser.mjs). Ingenting jämförs mot ett börvärde. "38 g obalans mot tillverkarens gräns på 10 g" är fritext teknikern skrivit. Systemet vet inte vad gränsen är och kan därför inte upptäcka att teknikern har fel om den.
• Ingen fordonsidentifiering mot vår data. VIN registreras men slås inte upp mot modellår, motorkod eller kampanjstatus.

Det som däremot är bättre än vårt eget system: loggen. Vår verkstadsdokumentation är fritext i en arbetsorder. Här är den strukturerad, serverdaterad och oföränderlig. Det hade jag velat ha.

Mina tre förbättringar

1. Inför ett normativt referens-fält på steg och kontroll — dokumenttyp, identitet, revision — så att en procedur kan spåras till sin källa och ogiltigförklaras när källan revideras.
2. Inför gränsvärden som data: matvarde ska kunna bära borvarde, undre, ovre, kalla och giltigFor (VIN-intervall/modellår). Utan det är E4 en siffra utan innebörd.
3. Öppna metodikbiblioteket för OEM-levererat innehåll med signatur, på samma sätt som regelpaketet redan hanteras (REGELPAKET_STATUS). Signeringsmekanismen finns; den behöver bara peka på metodiker också.

---

2.2 Teknisk chef — premiumtillverkare personbil (Volvo-sätet)

Jag instämmer i VW-sätets kritik men vill vara tydlig med att den träffar innehållet, inte konstruktionen. Konstruktionen är starkare än jag väntade mig.

Det som imponerar:

• Kvalitetsgrinden ligger på servern (services/gemensam/grind.mjs, anropad från server.mjs). Klienten har ingen egen åsikt. Det betyder att en verkstad inte kan stänga ett ärende genom att kringgå gränssnittet. I vårt eget system är motsvarande kontroll en klientvalidering, och den kringgås.
• Mätarställningen måste vara fotograferad, inte inskriven. Ett foto är E2, en siffra E1. Det är en liten regel med stor verkan i garantiärenden.
• Mätdonet slås upp i ett register. Kalibreringen härleds, den påstås inte. Det var enligt versionsloggen tidigare ett påstående klienten gjorde om sig själv — att man rättat det är ett gott tecken på granskningskultur.

Min invändning är en annan och den är allvarlig: "signaturen" vid avslut är teknikerns eget namn som text.

skicka({ typ: "arende_avslutat", signatur: anvandare, ... })

Händelsens anvandare och tidpunkt sätts visserligen av servern ur verifierad token — det är korrekt gjort och bättre än branschsnittet. Men fältet som heter signatur tillför ingenting och ser ut att tillföra något. I ett garantiärende som bestrids är det skillnad på "systemet noterade vem som var inloggad" och "teknikern signerade". Det första har ni. Det andra påstår ni.

Mina tre förbättringar

1. Ta bort signatur-fältet eller gör det till en riktig signatur. Mellanläget är det sämsta: ett fält som inbjuder en jurist att tro något som inte gäller.
2. Kedja händelserna kryptografiskt. Manipulationsskyddet vilar i dag på databastriggrar (infra/postgres-init.sql). Triggrar skyddar mot applikationen, inte mot den som har databasen. En hashkedja per ärende flyttar skyddet från behörighet till matematik.
3. Kvalificerad tidsstämpling (RFC 3161) på avslutet. Serverns klocka är er egen klocka. I en tvist är det motpartens invändning.

---

2.3 Teknisk chef — global volymtillverkare (Toyota-sätet)

Två observationer, en positiv och en som är ett hinder för oss.

Det positiva: språkhanteringen är den mest genomtänkta jag sett i det här segmentet. Att metodens struktur — fasnamn, statusord — är oföränderlig över språk är exakt rätt. En revisor ska kunna läsa en rumänsk och en japansk rapport utan att veta vilket språk verkstaden arbetar på. Och att systemet vägrar tyst falla tillbaka på engelska för procedurtext, utan i stället märker den som ogranskad, är en disciplin jag önskar att vi själva hade.

Hindret: ingen procedurtext är fackgranskad på något språk. Det står i klartext i services/gemensam/metodiker.mjs — texten är skriven på svenska och översatt till engelska, inte läst av en fackman på målspråket. De nio andra språken är märkta granskat: false.

Jag vill understryka att jag uppskattar att det står där. De flesta leverantörer hade inte skrivit det. Men det betyder att vi inte kan rekommendera systemet till våra verkstäder i något land i dag. En säkerhetsinstruktion — "mät och dokumentera spänningsfrihet före ingrepp" — får inte vara en oöversedd översättning.

Mina tre förbättringar

1. Skilj metodikinnehållet från plattformen och versionera det separat. Plattformen kan då släppas medan innehållet granskas per marknad, i stället för att allt väntar på det långsammaste.
2. Inför granskningsstatus per metodik och språk, inte per språk. I dag är granskat en flagga på hela språket. En verkstad ska kunna använda de fyra procedurer som är granskade utan att spärras av de tolv som inte är det.
3. Definiera vad "granskad" betyder: av vem, mot vad, hur ofta omprövad. En flagga utan definition blir en kryssruta någon fyller i.

---

2.4 Teknisk chef — tunga fordon (Scania-sätet)

Ni har byggt för personbil i verkstad. Vi arbetar i fält, på en lastbil som står still och kostar femtusen kronor i timmen.

Det som fungerar för oss:

• Offline-läget. Klientens klocka kastas inte bort utan bevaras som registrerad_tidpunkt bredvid serverns mottagningstid. Glappet blir synligt. Den detaljen visar att någon tänkt på fältarbete.
• Överlämningen. Att ett ärende kan lämnas vidare med härledd sammanfattning är precis vad ett skiftbyte kräver.

Det som inte fungerar:

• Ingen uppetidsdimension. Vi optimerar inte för korrekt diagnos utan för fordon i drift. Systemet har ingen uppfattning om att en provisorisk åtgärd som får ekipaget till nästa verkstad kan vara rätt beslut. Grinden känner "åtgärd utförd" och "ingen åtgärd utförd med skäl" — inte "temporär åtgärd, definitiv åtgärd planerad".
• Ingen flottdimension. lokalFordonshistorik är organisationens egna ärenden. En åkare med hundra ekipage vill se mönster över flottan, inte över verkstaden.
• Kvalitetskontrollen förutsätter provkörning. Det går inte alltid.

Mina tre förbättringar

1. Inför atgard_provisorisk som egen händelsetyp med obligatorisk uppföljningspunkt. En provisorisk åtgärd som dokumenteras som definitiv är en säkerhetsrisk; en som inte går att dokumentera alls blir odokumenterad.
2. Låt fordonshistoriken vara fordonets, inte verkstadens — med ägarens samtycke som grind. Krypto-shreddingen ger er redan mekaniken.
3. Ge grinden en dimension för "kunde inte verifieras på plats" som är skild från "verifierades inte". Vi har inte alltid en provbana.

---

2.5 Sveriges Fordonsverkstäders Förening

Jag talar för de små. Två anställda, en lyft, ingen IT-avdelning.

Först det goda: systemet fungerar utan inloggning i lokalt läge, och låsning vid utebliven betalning stänger aldrig läsning eller export (services/gemensam/abonnemang.mjs — behorighet() returnerar lasa och exportera sant i varje tillstånd). Det där är ovanligt hederligt. De flesta leverantörer tar loggen som gisslan. Att ni inte gör det är skälet till att jag över huvud taget lyssnar.

Sedan invändningen, och den är den viktigaste jag har: grinden kommer att upplevas som ett hinder, och då kringgås den.

Räkna på det. Ett normalt ärende kräver, enligt genomgången, 60–76 interaktioner. Ett enkelt fel — en trasig glödlampa — går genom samma grind som ett intermittent elfel. Slutsatsen kräver fyra fält, varav motiveringen minst 40 tecken med orsakssamband. En verkstad med tolv ärenden om dagen kommer att lära sig skriva fyrtio tecken som passerar filtret.

Och filtret är svagt: det är en ordlista över icke-svar (services/gemensam/sprak/ord.mjs). "Relätkontakten var bränd eftersom den var sliten" passerar — den innehåller "eftersom" och är lagom lång. Den säger ingenting.

Mina tre förbättringar

1. Gradera grinden efter ärendets tyngd. Ett ärende utan garanti-, försäkrings- eller säkerhetsdimension behöver inte samma bevisbörda. Regelpaketet kan redan styra krav per ärendetyp — utnyttja det åt andra hållet också.
2. Mät den faktiska tiden i drift och publicera den. Ni har arbetstid per kategori i loggen. Om ALVA kostar sju minuter per ärende ska det stå, inte gissas.
3. Gör om icke-svarsfiltret till något som inte går att lära sig kringgå — eller ta bort det och var ärliga med att slutsatsen granskas av människor. Ett filter som ser strängt ut men släpper igenom skräp är sämre än inget filter, för det invaggar handläggaren i tron att texten är kontrollerad.

---

2.6 Oberoende verkstadskedja

Vi driver fyrtio anläggningar och allbilsverkstad. För oss är frågan inte metodik utan drift.

• Tjänsten är en node:http-process mot en Postgres. Ingen kö, ingen läsreplika, ingen partitionering. Det duger till pilot. Det duger inte till fyrtio anläggningar med samtidig synk var femtonde sekund.
• Terraform finns men har enligt dokumentationen aldrig körts. Då vet ni inte att den fungerar.
• Ingen SSO. Vi har fyrahundra tekniker i ett Entra-ID. Fyrahundra separata lösenord är ett säkerhetsproblem, inte en bekvämlighetsfråga.
• Ingen roll mellan tekniker och administratör som passar en kedjestruktur. Vi behöver regionchef som ser flera organisationer.

Det som däremot är starkt: hyresgästisolering är provad (integrationstestet innehåller ett uttryckligt "motspelande hyresgäst"-fall). Det är fler leverantörer som påstår det än som testar det.

Mina tre förbättringar

1. OIDC/SAML mot företagsidentitet, med rollmappning från identitetsleverantören. Utan det kommer vi inte att införa systemet.
2. Koncernnivå över organisation, med läsbehörighet och statistik men inte skrivbehörighet i ärenden.
3. Belastningsprov med publicerad siffra. "Klarar N samtidiga ärenden på M anläggningar" — annars är skalbarhet en åsikt.

---

2.7 Garantiansvarig — fordonstillverkare

Jag är den som ska betala eller neka. Min måttstock är: kan jag fatta ett beslut på det här underlaget utan att ringa verkstaden?

Svaret är: oftare än i dag, men inte alltid.

Det som gör underlaget bättre än allt jag får i dag:

• ALVA-RULE-200. Fyra fält: vad som konstaterats, vilken evidens som bär det, vad som uteslutits och varför, vad som kvarstår osäkert. Det tredje fältet är det som saknas i varje verkstadsprotokoll jag någonsin läst. En felsökning utan uteslutna alternativ är en gissning som råkade stämma, och i dag kan jag inte se skillnaden.
• Obemötta hypoteser härleds ur loggen. Den som skrivit ned en misstanke och landat i något annat måste säga varför den föll bort. Det är den enskilt starkaste funktionen i produkten.
• Retentionen följer ärendetypen — 120 månader för garanti. Och det finns ett arv för ärenden som öppnades innan ärendetyperna bytte språk, vilket betyder att någon tänkt på att uppslaget kan missa. Det gör man inte om man inte tagit frågan på allvar.

Det som hindrar mig:

• Säkerhetsnivån är teknikerns egen bedömning. sakerhet: hog | medel | lag väljs med en knapp. Det är ett självskattat värde som ser ut som en mätning. Jag kan inte prissätta det.
• Ingen koppling till reservdel. Ett garantiärende handlar till slut om en artikel. Systemet vet inte vilken.
• Ingen oberoende bekräftelse. Allt underlag kommer från den part som har ett ekonomiskt intresse av utfallet.

Mina tre förbättringar

1. Härled säkerhetsnivån i stället för att fråga efter den — ur evidensgrad, antal oberoende källor och om symptomet reproducerats och verifierats borta. Låt teknikern sänka den, aldrig höja den.
2. Koppla åtgärd till artikelnummer och gör kopplingen obligatorisk vid garantiärendetyp. Regelpaketet kan uttrycka det redan i dag.
3. Inför en maskinläsbar exportprofil för garantianspråk — inte PDF, utan ett schema vi kan ta emot maskinellt. Ni har openapi.yaml; det här är nästa steg.

---

2.8 Försäkringsbolag — maskinskada och skadereglering

Jag ansluter mig till garantiansvarigs kritik av den självskattade säkerhetsnivån och lägger till min egen vinkel.

Systemet vägrar avsiktligt ge sannolikheter. Försäkringsvillkorsmodulen "returnerar avsiktligt inget fält som liknar ett utslag" (services/gemensam/forsakring.mjs). Garantimodulen svarar inom, utanfor eller oklart, och saknad data ger alltid oklart, aldrig utanfor.

Jag är kluven. Som riskbedömare vill jag ha ett tal. Som den som blir stämd när talet är fel inser jag att ni har rätt. Ett system som säger "87 % sannolikhet för maskinskada" kommer att citeras i domstol av båda parter, och ingen kommer att kunna förklara var talet kom ifrån. Att avstå är den mognare hållningen och jag noterar den.

Min verkliga invändning gäller bevisvärdet i fotot.

Fotot skalas ned via canvas, vilket tar bort all metadata inklusive GPS. Det är motiverat och testat (bildmetadata.test.ts) — jag vill inte veta var kundens bil stod. Men följden är att fotot inte bär någon uppgift om när eller var det togs. capture="environment" är en hint till webbläsaren, inte en spärr; ett galleribildval passerar.

Det betyder i klartext: ett foto på en annan bils mätarställning går igenom. Kravet att mätarställningen ska fotograferas — som jag i övrigt anser är produktens skarpaste enskilda regel — vilar alltså på teknikerns hederlighet, inte på bevisning.

Mina tre förbättringar

1. Försegla bilden vid upptagningen: hasha pixeldata i klienten, låt servern signera hashen tillsammans med sin egen mottagningstid. Ni får integritet utan att återinföra GPS. Säg sedan uttryckligen i rapporten vad fotot bevisar — innehållets oföränderlighet sedan mottagandet, inte upptagningsomständigheten.
2. Egen kameravy i stället för filväljare där det är tekniskt möjligt.
3. Inför korsreferens mot mätarställningens rimlighet: en utgående mätarställning lägre än den ingående, eller en som avviker kraftigt mot fordonets historik, ska flaggas. Ni har historiken.

---

2.9 Besiktningsingenjör

Min fråga är enkel: kan ett ALVA-ärende ersätta eller komplettera en teknisk kontroll?

Svar: nej, och det bör det inte heller.

En besiktning är en oberoende kontroll mot ett fastställt regelverk. ALVA-ärendet är verkstadens egen dokumentation av sitt eget arbete. Att den är välordnad gör den inte oberoende. Om ett ALVA-ärende började väga vid teknisk kontroll skulle incitamentet att skriva det snyggt uppstå omedelbart.

Däremot ser jag ett underlagsvärde: vid en efterkontroll är ett dokumenterat åtgärdsförlopp med evidens bättre än en kvittotext.

En sak vill jag ha noterad i protokollet, och den är obekväm för datasäkerhetsspecialisten: krypto-shreddingen kan förstöra underlag som behövs. När nyckeln förstörs maskeras fälten permanent. Det är rätt mot dataskyddsförordningen. Men om ett fordon senare visar sig ha ett säkerhetsrelaterat fel som spåras till en åtgärd, och identifieringen är raderad på begäran, finns kopplingen inte längre.

Mina tre förbättringar

1. Skilj i modellen på personuppgift och fordonsuppgift. Ett VIN är kopplat till ett fordon, inte primärt till en person. I dag raderas de tillsammans.
2. Definiera ett undantag för säkerhetsrelaterade fel där kopplingen fordon–åtgärd bevaras även efter radering av personuppgifter, med rättslig grund angiven i modellen.
3. Om systemet någon gång ska väga vid teknisk kontroll krävs oberoende verifiering av minst mätdonens kalibrering mot ackrediterat organ. I dag matas kalibreringsdatum in av organisationen själv.

---

2.10 Konsumentrepresentant

Jag är förvånad. Det här är det första verkstadssystem jag granskat som faktiskt är byggt med kunden i åtanke.

• Kundens besked på åtgärdsförslaget måste registreras innan arbetet utförs, och arbete utfört trots avböjt förslag är ett hårt hinder, inte en varning. Det är precis den tvisten jag ser oftast.
• Beskedet registreras med kanal — telefon, på plats, e-post, delningslänk — så det går att härleda till ett faktiskt samtal.
• Delningsnivåerna filtreras på servern. Kunden ser det kunddelbara, partnern ser hypoteser märkta som overifierade. Filtreringen sker inte i webbläsaren, vilket betyder att den faktiskt gäller.
• Rapporten säger uttryckligen att den är härledd ur loggen och redovisar observationer "utan slutsatser som saknar stöd".

Mina invändningar:

• Kunden har ingen egen kopia. Delningslänken kan återkallas av verkstaden. I en tvist är det motparten som äger bevisningen.
• Ingen tidsstämplad kvittens till kunden. Att kunden godkänt syns i verkstadens logg, som verkstaden kontrollerar.
• Språket i kunddelningen är samma tekniska språk som teknikern läser. "Symptom verification: reproduced" betyder ingenting för en bilägare.

Mina tre förbättringar

1. Låt kundens besked generera en oåterkallelig kvittens till kundens e-post eller telefon i samma ögonblick — utanför verkstadens kontroll.
2. Ge kunden rätt till en export av sitt ärende som inte kan återkallas.
3. Skriv en kundvy på kundspråk. Ni har redan skiljelinjen mellan struktur och innehåll; det här är ett tredje register, inte ett fjärde språk.

---

2.11 Professor i fordonsdiagnostik

Jag vill lyfta panelen från funktionslistan till den fråga uppdraget faktiskt ställer: är arbetsflödet reproducerbart?

Svaret är preciserat, och preciseringen är hela poängen:

Processen är reproducerbar. Slutsatsen är det inte.

Två tekniker som får samma fordon kommer att gå genom samma steg, tvingas dokumentera samma evidenstyper och passera samma grind. De kan ändå landa i olika slutsatser, och systemet stoppar ingen av dem. Grinden prövar närvaron av underlag, inte korrektheten i resonemanget (services/gemensam/grind.mjs).

Det är inte ett fel. Det är en ärlig avgränsning, och den är rätt: ett system som påstod sig kunna avgöra vilken av två motiverade slutsatser som är sann skulle ljuga. Men den måste stå i specen, för annars kommer den att läsas som ett löfte om diagnostisk samstämmighet.

Två metodologiska anmärkningar:

• Hypoteser får bara vara medel eller lag i händelseschemat. En hypotes kan alltså aldrig vara starkt understödd utan att bli en slutsats. Det är en klok tvingande konstruktion — den hindrar en misstanke från att glida över till fastställd orsak utan att passera verifiering. Jag hade inte förutsett den och jag gillar den.
• Orsakskategorierna är en sluten lista om femton poster — normalt slitage, materialutmattning, tillverkningsfel och så vidare. Det ger jämförbar statistik. Men listan blandar orsaksmekanism (materialutmattning, korrosion) med orsaksursprung (tillverkningsfel, felaktig tidigare reparation). Två dimensioner i en lista ger statistik som inte går att tolka.

Mina tre förbättringar

1. Dela orsakskategorierna i två oberoende dimensioner: mekanism och ursprung. Ett tillverkningsfel som yttrar sig som materialutmattning är i dag två kryss i samma lista.
2. Skriv in avgränsningen "process, inte utfall" i den normativa texten, som en definierad egenskap med en definierad mätmetod — annars kommer någon att mäta samstämmighet och kalla systemet misslyckat.
3. Inför strukturerad mellanteknikervalidering: låt en andra tekniker kunna granska ett stängt ärende och registrera instämmande eller avvikande bedömning. Då kan samstämmigheten mätas i stället för antas.

---

2.12 Specialist — människa–maskin-interaktion

Jag har gått igenom skärmbilderna och gränssnittskoden och jag ska vara rakt på sak: den kognitiva belastningen är för hög i pre-diagnostiken, och den är fel fördelad.

Vad jag ser på en 390 px-skärm i ett ärendes första läge: en identitetsrad med åtta fält, en flikrad med fyra flikar, en tidskategorirad med sju, en kryssruta-lista med fyra öppna punkter, och sedan fyra frågeblock under varandra — historik, mätarställning, felbeskrivningsverifiering, tidiga observationer. Elva beslutspunkter innan arbetet börjar.

Det är designat som ett formulär, inte som ett arbetsflöde. Ett arbetsflöde visar ett beslut i taget.

Samtidigt vill jag ge beröm åt saker som är ovanligt väl gjorda:

• Bristerna visas under fältet medan man skriver, inte som ett felmeddelande efter Spara. Att bli nekad efter att ha skrivit klart är det som gör obligatoriska fält förhatliga, och ni har undvikit det.
• Statusen anges alltid med ord, aldrig enbart med färg.
• Ingen rörelse. Inga animationer, inga övergångar. I en miljö med visuellt brus är det rätt beslut.
• Grindens hinder visas medan arbetet pågår, vid den tidpunkt då de fortfarande går att åtgärda — inte vid avslutsknappen.

När blir guidningen för styrande? Den blir det när teknikern redan vet vad felet är. En erfaren tekniker som ser en lossnad balansvikt med blotta ögat måste ändå gå genom symptomverifiering, fyra hjulfoton och kastmätning. Systemet har ingen väg för "jag ser orsaken, här är beviset".

Mina tre förbättringar

1. Ett beslut per skärm i pre-diagnostiken. Elva punkter samtidigt är en formulärvy; guidning är sekventiell.
2. Inför en direktväg för konstaterad orsak: teknikern lämnar evidens och slutsats direkt, och systemet räknar baklänges vilka kontroller som därmed är obehövliga och vilka som kvarstår. Grindens krav bevaras, ordningen släpps.
3. Mät faktiskt. Ni har interaktionsräkning i genomgången (60–76 per ärende). Sätt ett tak per ärendetyp och låt det falla bygget när det överskrids, precis som ni gjort med färgpaletten. Ni har visat att ni kan låsa design med test — gör det med interaktionsbudget också.

---

2.13 Specialist — datasäkerhet

Jag har granskat detta hårdare än jag brukar, eftersom mycket ser bra ut och det är då man missar saker.

Det som håller:

• Krypto-shredding med kuvertkryptering. Per-subjektsnycklar, inlindade under en huvudnyckel som ligger utanför databasen. Radering sker genom att nyckeln förstörs; loggen förblir append-only. Det är den korrekta lösningen på konflikten mellan artikel 17 och oföränderlig logg, och den är ovanlig.
• Utan huvudnyckel maskeras uppgiften och anropet går ändå igenom. Att systemet inte kraschar utan degraderar till maskering är rätt: en otillgänglig nyckel ska inte göra hela organisationens historik oläsbar.
• Härkomst sätts av servern. anvandare och tidpunkt är serverägda fält som avvisas om klienten skickar dem.
• Append-only genomdrivet i databasen, inte i applikationen.
• EXIF och GPS tas bort genom omritning, och egenskapen är låst med test som läser vägen och inte bara utfallet.
• Åtkomstlogg och raderingar är också append-only.

Det som inte håller:

1. Ingen kryptografisk kedja. Manipulationsskyddet är behörighetsbaserat. Den som har superuser på databasen kan släppa en trigger. En hashkedja per ärende gör efterhandsändring upptäckbar även för den som äger databasen. För ett system vars hela värde är bevisvärde är detta den viktigaste bristen jag hittar.
2. Ingen extern förankring. Även en hashkedja är verkstadens egen. Ett dagligt rotvärde till en oberoende part — eller kvalificerad tidsstämpling — kostar nästan ingenting och flyttar bevisbördan.
3. Ingen hotmodell och ingen mappning mot regelverk. Jag hittar inget dokument som säger vem angriparen antas vara. För ett system som ska bli branschstandard krävs mappning mot ISO/IEC 27001, och för fordonsanknytning ISO/SAE 21434 och UNECE R155.
4. Inget kryptografiskt agilitetsschema. Vilka algoritmer, vilken nyckelrotation, vad händer när AES-GCM ska bytas? En logg som ska läsas om tio år behöver det.

Mina tre förbättringar

1. Hashkedja per ärende, med rotvärdet i avslutshändelsen.
2. Extern förankring av rotvärdet — kvalificerad tidsstämpling räcker.
3. Publicerad hotmodell och regelverksmappning. Utan den kan ingen säkerhetsavdelning i branschen godkänna ett införande, oavsett hur bra koden är.

---

2.14 Specialist — utbildning av fordonstekniker

Det här är produktens starkaste sida och jag tror att ni underskattar den.

En lärling lär sig i dag felsökning genom att titta på en erfaren tekniker. Det som överförs är slutsatser, inte resonemang — och resonemanget är yrket. ALVA gör resonemanget synligt och obligatoriskt:

• Fyra namngivna frågor med olika adressat i stället för en fritextruta.
• Hypoteser måste bemötas, inte glömmas.
• Skillnaden mellan observation och slutsats är kodad i gränssnittet ("Fotografera samtliga hjul. Skilj på observation och slutsats.").
• Evidensgraderna E0–E6 lär ut ett begrepp branschen saknar ord för.
• Den ärliga vägen finns: orsaken kunde inte fastställas, och varför. Att systemet har en väg för "jag vet inte" som inte är en lögn är pedagogiskt det viktigaste i hela produkten.

Mina invändningar:

• Ingen återkoppling. Lärlingen får veta att grinden inte är passerad, inte att resonemanget var svagt. Systemet dömer form, inte innehåll — vilket professorn redan konstaterat — men i utbildning är det innehållet som ska tränas.
• Ingen övningsdata. Det finns ett demoärende. Ett utbildningsläge behöver hundra, med känt facit.
• Ingen progression. En lärling och en mästare möter samma grind.

Mina tre förbättringar

1. Utbildningsläge med facit. Kända ärenden där systemet efteråt kan visa vad som faktiskt var fel och var resonemanget avvek. Det är den funktion som skulle göra produkten till branschstandard i yrkesutbildningen inom tre år.
2. Handledarvy: en instruktör som ser flera lärlingars ärenden och kan kommentera resonemanget, inte bara utfallet.
3. Koppla evidensmodellen till yrkesutbildningens mål. Om E-graderna kom in i utbildningsplanen kommer nästa generation tekniker att tänka i dem oavsett vilket system de sedan använder — och det, inte licensintäkten, är den verkliga standardiseringsvägen.

---

3. Diskussion

Ordföranden: Låt oss ta de tre punkter där panelen är oense.

---

Den självskattade säkerhetsnivån.

Garantiansvarig: Härled den. Ett självskattat värde som ser ut som en mätning är värre än inget värde.

Professorn: Var försiktig. Om den härleds ur evidensgrad blir den ett mått på dokumentationsmängd, inte på diagnostisk säkerhet. En teknikers välgrundade osäkerhet är information; en formel som räknar foton är det inte.

Garantiansvarig: Då låt formeln sätta taket och teknikern sänka. Ingen kan påstå högre säkerhet än underlaget bär, men den som vet mer om fordonets historia får sänka.

Professorn: Det accepterar jag. Asymmetrin är poängen.

Ordföranden: Noterat som panelens gemensamma rekommendation.

---

Fotots bevisvärde mot integritet.

Datasäkerhet: Jag försvarar EXIF-borttagningen. Delningsvyn går till försäkringsbolag och partners. GPS i den vyn är en läcka som ingen bett om.

Försäkring: Jag begär ingen GPS. Jag begär att veta att bilden togs vid det tillfälle loggen påstår.

Datasäkerhet: Då är vi överens, och lösningen är billig: hasha i klienten, låt servern signera hash och mottagningstid. Ni får en förseglad bild utan en enda personuppgift.

Försäkring: Med tillägget att rapporten då måste säga vad förseglingen bevisar. "Oförändrad sedan mottagandet" är inte "tagen på detta fordon", och den skillnaden kommer en motpartsjurist att hitta.

Ordföranden: Enighet. Detta är panelens tekniskt mest konkreta rekommendation.

---

Grindens tyngd.

Verkstadsföreningen: Gradera den. Annars kringgås den.

Garantiansvarig: Gradera den inte. Undantaget blir regeln inom ett år.

Verkstadsföreningen: Ni betalar inte för de sju minuterna.

Garantiansvarig: Vi betalar för de ärenden där underlaget inte håller, och det är dyrare.

HMI-specialisten: Ni argumenterar om fel sak. Problemet är inte kravnivån utan ordningen. Elva beslutspunkter på en skärm känns som mycket arbete även när det är lite. Samma krav, ett i taget, känns som ett flöde. Mät interaktioner innan ni sänker krav.

Verkstadsföreningen: Om ni kan visa att samma krav tar hälften så lång tid drar jag tillbaka mitt förslag.

Ordföranden: Panelen rekommenderar att ordningen åtgärdas först och kravnivån omprövas därefter, mot mätdata.

---

Toyota-sätet, avslutande: Jag vill ha en sak i protokollet. Panelen har ägnat en förmiddag åt att hitta fel och hittat riktiga fel. Men vi har inte hittat ett enda ställe där systemet påstår något som inte är sant. Ogranskad metodik står som ogranskad. Osäker garantibedömning står som oklar. Demonstrationsytor står som demonstration. Att ett uppslag som missar ska ge det försiktigaste utfallet är skrivet som en regel, inte som en förhoppning.

Det är sällsynt, och det är den egenskap som gör att jag anser att produkten är värd att bygga vidare på trots allt vi räknat upp.

---

4. Betyg

Skala 1–10. Kolumnerna: TI teknisk innovation · DK diagnoskvalitet · AN användbarhet · SÄ säkerhet · SK skalbarhet · OEM OEM-anpassning · VN verkstadsnytta · UV utbildningsvärde · ST standardiserbarhet · KP kommersiell potential.

Säte	TI	DK	AN	SÄ	SK	OEM	VN	UV	ST	KP
Ordförande	8	6	6	8	5	4	7	9	7	7
Volymtillverkare personbil	7	5	6	8	5	3	7	8	6	6
Premiumtillverkare personbil	8	6	7	7	5	4	8	8	7	7
Global volymtillverkare	8	5	7	8	5	3	7	9	7	6
Tunga fordon	7	5	6	8	4	3	6	8	6	6
Fordonsverkstädernas förening	7	6	5	8	5	4	6	8	6	7
Oberoende verkstadskedja	7	6	6	7	3	4	7	8	6	7
Garantiansvarig	8	7	6	7	5	4	8	8	7	8
Försäkringsbolag	8	7	6	7	5	4	8	8	7	8
Besiktningsingenjör	7	6	6	8	5	4	6	8	6	6
Konsumentrepresentant	8	6	6	8	5	4	7	8	7	7
Professor	9	6	6	8	5	4	7	10	8	7
HMI-specialist	8	6	5	8	5	4	6	9	7	7
Datasäkerhet	8	6	6	7	5	4	7	8	6	7
Utbildningsspecialist	8	6	6	8	5	4	7	10	8	8
Medel	7,7	6,0	6,0	7,7	4,8	3,8	6,9	8,5	6,7	7,0

Läsanvisning. Två tal förklarar hela bilden. Utbildningsvärde 8,5 är det högsta någon produkt fått av den här panelen, och det beror på en enda egenskap: systemet gör resonemanget obligatoriskt och synligt. OEM-anpassning 3,8 är det lägsta, och det beror på en enda egenskap: metodikinnehållet är inte tillverkarnas.

Det är samma observation sedd från två håll. Produkten är stark där den handlar om hur man tänker och svag där den handlar om vad man ska göra med en viss bil.

---

5. Slutrapport

5.1 Är produkten redo för pilotdrift?

Ja, med tre villkor.

Systemet är påtagligt mer genomarbetat än vad panelen väntade sig av en produkt i det här skedet. Serverauktoritativ grind, oföränderlig logg med serverbunden härkomst, krypto-shredding, provad hyresgästisolering och en provningsapparat som faktiskt kör mot riktig databas — det är pilotmässigt.

Villkoren:

1. Metodikinnehållet måste fackgranskas för de procedurer piloten använder. Inte alla sexton; de som faktiskt körs. Säkerhetsstegen i högvoltsmetodiken är inte förhandlingsbara.
2. signatur-fältet tas bort eller görs riktigt. Ett fält som ser ut som en signatur får inte finnas i en pilot vars data kan komma att åberopas.
3. Piloten mäter. Interaktioner per ärende, tid per ärende, andel ärenden som nekas avslut och varför. Utan mätning blir utvärderingen en tyckandeövning.

5.2 Är den redo för nationell implementering?

Nej. Inte i närheten, och skälen är inte kvalitetsbrister utan avsaknad av förutsättningar:

• Ingen företagsidentitet (OIDC/SAML), ingen koncernstruktur.
• Ingen belastningsprovning; infrastrukturkoden aldrig körd.
• Ingen mappning mot ISO/IEC 27001, ISO/SAE 21434 eller UNECE R155.
• Ingen OEM-datakoppling, inga gränsvärden, ingen artikelkoppling.
• Ingen kryptografisk kedja och ingen extern förankring av loggen.

Panelen bedömer detta som 12–24 månaders arbete, varav den tekniska delen är den mindre.

5.3 Kan den ligga till grund för en ny svensk standard?

Ja — men inte produkten. Modellen.

Detta är panelens viktigaste slutsats och den måste läsas noggrant.

ALVA är i dag en implementation, inte en specifikation. Det finns specdokument, men de lever inne i kodbasen som kommentarer och docs/-filer, och de är inte separerbara från just den här koden. En standard kräver tre saker som saknas:

1. Ett normativt dokument som beskriver modellen oberoende av implementation — händelseschema med utvidgningsregler, evidensgrader E0–E6 med definitioner, grindens regler uttryckta som prövbara påståenden, och de invarianta strukturorden.
2. En konformanstestsvit som en tredje part kan köra mot sin egen implementation. Ni har 750 tester, men de testar er kod.
3. Minst två oberoende implementationer. En standard med en implementation är en produktbeskrivning.

Det som är standardiserbart, och som panelen anser bör standardiseras, är:

• Evidensmodellen E0–E6. Branschen saknar ord för skillnaden mellan en teknikers påstående och en mätning med spårbart mätdon. Detta är produktens mest överförbara idé.
• ALVA-RULE-200:s fyra fält, särskilt kravet på uteslutna alternativ. Panelen är enig om att detta är den enskilt största förbättringen av verkstadsdokumentation som lagts fram.
• Kravet att härkomst sätts av mottagande system, aldrig av klienten.
• Principen att ett uppslag som missar ska ge det försiktigaste utfallet.
• Skillnaden mellan invariant struktur och översatt innehåll.

Det som inte bör standardiseras är metodikinnehållet. Procedurer hör hemma hos tillverkaren. En standard som föreskriver hur man felsöker en vibration kommer att vara felaktig för något fordon och föråldrad inom två år.

Panelens formulering av en möjlig standard: "Krav på dokumentation, evidensgradering och avslutsvillkor vid guidad fordonsdiagnostik." Alltså en standard för bevisningen, inte för diagnostiken.

En sådan standard är realistisk att föra till CEN och därefter ISO. Den skulle sannolikt placeras nära ISO 18541-familjen men adressera något den inte täcker: vad verkstaden ska producera, inte vad tillverkaren ska tillhandahålla.

5.4 Vad måste förbättras först

Rangordnat efter vad som blockerar mest:

#	Åtgärd	Blockerar
1	Fackgranskning av metodikinnehåll, per metodik och språk	All användning utanför pilot
2	Riktig signatur + hashkedja + extern tidsstämpling	Garanti- och försäkringsanvändning
3	Normativ spec separerad från koden + konformanstestsvit	All standardisering
4	Gränsvärden som data, kopplade till fordonsidentitet	OEM-acceptans
5	Härledd säkerhetsnivå med teknikersänkning	Garantibeslut
6	Förseglat foto vid upptagning	Bevisvärde, bedrägeriminskning
7	Ett beslut per skärm i pre-diagnostiken	Införandegrad i verkstad
8	OIDC/SAML och koncernstruktur	Kedjeverkstad
9	Belastningsprovning med publicerad siffra	Nationell drift
10	Regelverksmappning (27001, 21434, R155)	Säkerhetsgodkännande

5.5 Vad panelen själv skulle lägga till

Funktioner som inte finns i produkten och som panelen anser att en nästa generations standard bör innehålla:

1. Utbildningsläge med facit och handledarvy. Panelens enskilt mest entusiastiska förslag. Ingen annan aktör gör detta, och det är den snabbaste vägen till att modellen blir branschpraxis — genom yrkesutbildningen, inte genom inköp.
2. Mellanteknikervalidering. Låt en andra tekniker registrera instämmande eller avvikande bedömning på ett stängt ärende. Då blir diagnostisk samstämmighet mätbar i stället för antagen, och panelen får svar på den fråga vi i dag bara kan resonera om.
3. Fordonsburen historik med ägarens samtycke. I dag är historiken verkstadens. Fordonets historik hör till fordonet och följer det mellan verkstäder. Krypto-shreddingen ger redan mekaniken för samtycke.
4. Negativa fynd som förstklassig data. Systemet dokumenterar vad som uteslöts — men bara i fritext i slutsatsen. Strukturerade negativa fynd är den mest undervärderade datamängden i branschen: de säger vad felet inte var, vilket är hälften av all diagnostisk information.
5. Återkallelse- och kampanjkoppling i pre-diagnostiken. Historikfrågan ställs redan och kan inte hoppas över; den borde besvaras av data.
6. Provisorisk åtgärd som egen händelsetyp med obligatorisk uppföljning — för tunga fordon och mobilt arbete.

---

6. Panelens sammanfattande omdöme

ALVA löser inte diagnostikens svåra problem, och gör inte anspråk på det. Vad produkten gör är att göra verkstadens resonemang synligt, strukturerat och svårt att fejka — och det är ett problem branschen har haft i femtio år utan att angripa.

Produkten är inte redo att bli en standard. Modellen bakom den är redo att bli utgångspunkten för en.

Panelen rekommenderar pilotdrift under de tre angivna villkoren, och att ett normativt arbete inleds parallellt med fokus på evidensmodellen och avslutsvillkoren — inte på metodikinnehållet.

Panelen noterar avslutningsvis att den under granskningen inte funnit något ställe där systemet påstår mer än det kan belägga. Det är ovanligt, och det är det som gör rekommendationen möjlig.

---

Bilaga A · Åtgärdat efter granskningen (ALVA 3.3)

Granskningen ovan är ett ögonblicksfoto av 3.2 och står orörd. Följande har åtgärdats efteråt; resten av åtgärdslistan gäller fortfarande.

Fynd	Åtgärd	Var
Ingen kryptografisk kedja (§2.13 p1)	Hashkedja per ärende, beräknad av servern vid insättning. Digest tas över den lagrade händelsen, så en ändrad rad upptäcks även om hashkolumnen lämnas orörd. Integrationstestet provar panelens hotmodell ordagrant: triggern släpps, en rad ändras som databasägare, triggern återskapas — verifieringen pekar ut raden.	services/gemensam/kedja.mjs, GET /api/arenden/{id}/kedja
Förseglingen (§2.13 p2, delvis)	Avslut förseglar kedjans rot med HMAC under FORSEGLING_NYCKEL, som aldrig finns i databasen. Förseglingen är engångs — triggern vägrar skriva om den. Extern förankring (RFC 3161) återstår.	skrivKedjat, skydda_arende
Signaturen är ett namn (§2.2 p1)	signatur skrivs ur verifierad token, klientens värde ignoreras. Fältet intygar nu exakt vad det kan intyga.	services/gemensam/handelser.mjs
Självskattad säkerhetsnivå (§2.7 p1, §3)	Nivån är ett tak härlett ur underlaget — hög kräver reproducerat symptom och spårbart mätvärde ur mätdonsregistret. Teknikern kan sänka, aldrig höja, precis som paneldiskussionen enades om. Grinden spärrar ett påstående över taket, och gränssnittet visar taket medan arbetet pågår i stället för vid avslutsknappen.	services/gemensam/sakerhet.mjs, grind.mjs
Vad fotot bevisar (§2.8, delvis)	Verifieringssvaret säger uttryckligen vad kedjan bevisar och inte: "Content unchanged since receipt … nothing about the time before receipt, nothing about accuracy." Klienthashning vid upptagning återstår.	GET /api/arenden/{id}/kedja

Provat med 766 enhetstester och 200 integrationskontroller mot riktig Postgres, inklusive sabotage med full databasbehörighet.