alva/docs/moduler/evidensmotor.md

Modul: Evidensmotorn (ECM — Evidence & Compliance Matrix)

Version: ECM v2.0 · ECM är ett eget subsystem — inte en tabell i databasen — och motorn som styr hela plattformen: den avgör vilken dokumentation som krävs, när dokumentation saknas, vilken bevisnivå som uppnåtts, vilka regler som gäller och om ett ärende kan avslutas. Systemet kan aldrig skriva en slutsats som ECM inte har godkänt.

Regelbiblioteket är versionshanterat och skilt från applikationslogiken (src/felsokning/ecm.ts); vyerna anropar bara motorns rena funktioner.

De sex motorerna

1. Evidence Engine

Katalogiserar all bevisning ur händelseloggen. Varje evidenspost får id, tidpunkt, tekniker, kategori, evidensnivå, sammanfattning och innehållshash — samma post ger alltid samma hash, och den append-only-låsta loggen (databastriggers) gör varje ändringsförsök omöjligt.

Nivå	Typ	Bevisvärde
E0	Inget underlag	0 %
E1	Teknikerns observation	Lågt
E2	Foto	Medel
E3	Video	Högt
E4	Mätvärde	Högt
E5	Diagnosdata/dokument	Mycket högt
E6	Flera oberoende källor	Högsta

2. Rule Engine

Dokumentationskraven: metodikens krav-fält per kontroll plus de automatiska reglerna — kan det fotograferas → begär foto; låter det → video med ljud; rör det sig → video; mäts det → mätvärde; visar en display informationen → fota displayen; finns ett dokument → fota dokumentet. Undantagsorsakerna ("Underlag kan inte tas fram") ligger här.

3. Compliance Engine

Ärendetypen styr vilka regler som gäller utöver metodiken. Ärendetyp väljs i identitetsraden och loggas (arendetyp_satt):

Ärendetyp	Extra krav (v2.0)
Garanti	Miltal dokumenterat · servicehistorik kontrollerad · claim-/garantinummer
Goodwill	Miltal · servicehistorik
Försäkring	Skadenummer · bildbevis
Reklamation	Historik och tidigare försök kontrollerade
Begagnatgaranti	Miltal

ECM Knowledge Library är implementerat: reglerna är deklarativa data (krav-typ, inte kod) och distribueras från plattformen via GET /api/ecm/regler (services/plattform/ecm-regler.json — i klustret utbytbar via ConfigMap och miljövariabeln ECM_REGLER_FIL). Klienten hämtar paketet vid sidladdning, cachar det och faller tillbaka till sitt inbyggda standardpaket offline; trasiga paket och okända krav-typer filtreras. Regelpaketets version följer med i varje spårbarhetspaket. Nya regler — garantivillkor per tillverkare, försäkringsbolagens krav, reklamationslagstiftning, OEM-kontrollpunkter — läggs till i driften utan att applikationen byggs om.

4. Validation Engine

Inga påståenden utan underlag, i tre lager: (a) orkesterns grundprompt — aldrig "OK/kontrollerad/inga fel/åtgärdad" utan evidens, i stället "Evidens saknas" plus begäran om rätt underlag; (b) projektionerna — hypoteser kan aldrig bli konstaterade fel; (c) kvalitetsgrinden nedan.

5. Completion Engine

Kvalitetsgrinden före slutrapport/avslut — utskriften är spärrad tills alla obligatoriska rader är gröna:

Kontroll	Krav
Fordons-/objektidentifiering verifierad	Obligatorisk
Arbetsorder inläst	Rekommenderas
Fordonshistorik kontrollerad eller motiverad	Obligatorisk
Ingående mätarställning dokumenterad	Obligatorisk
Kundens felbeskrivning verifierad	Rekommenderas
Utgående mätarställning	Obligatorisk vid avslut
Metodikens kontroller: evidens eller dokumenterat undantag	Obligatorisk
Foton för fotokrävande kontroller	Obligatorisk
Ärendetypens compliance-krav	Obligatoriska
Evidensnivå över E0	Obligatorisk

6. Traceability Engine

Varje export bär ett spårbarhetspaket: ECM-version, ärendetyp, evidensnivå, grindstatus per regel-id och samtliga evidensposter med hash. Tillsammans med loggen kan varje slutsats härledas: vilken bild → vilken mätning → vilken tekniker → vilken regel → vilken regelverksversion → när.

Pre-Diagnostic Validation

Ingen felsökning påbörjas förrän grundkontrollerna är genomförda eller dokumenterat motiverade — metodiken låses upp först därefter:

1. Fordonshistorik — kontrollerad (tidigare arbeten, återkommande fel, TSB, kampanjer; relevanta samband kan noteras som orsakskedja) eller Nej med obligatorisk orsak → kvalitetsvarning.
2. Ingående mätarställning — instrumentpanelen fotograferas; bildtolkningen föreslår värdet, teknikern bekräftar. Fotot blir den officiella ingående mätarställningen.
3. Kundens felbeskrivning verifierad — ytterligare symptom dokumenteras som separata observationer, aldrig hopblandade med kundens beskrivning.
4. Tidiga observationer — reparationsspår, modifieringar, skador, läckage m.m. dokumenteras med foto/observation, eller kvitteras "inga ytterligare".

Utgående mätarställning fotograferas inför avslut och blir obligatorisk i grinden när ärendet stängs. Rapporten visar in/ut.

Symptom Verification Protocol (SVP)

Ett fel diagnostiseras aldrig direkt från en vag kundbeskrivning. Kedjan är alltid: dokumenterats → förtydligats → reproducerats eller dokumenterats som ej reproducerbart.

• Kundens beskrivning registreras ordagrant vid ärendestart och verifieras i pre-diagnostiken; nya symptom blir separata observationer.
• Förtydligandet sker genom metodikens symptomfrågor (när/var/hur/ förhållanden/frekvens — generiska metodiken har hela SVP-frågesetet).
• Reproducering (Ja/Delvis/Nej) dokumenteras innan avslut: Ja kräver hur och under vilka förhållanden; Delvis vad som kunde respektive inte kunde återskapas; Nej kräver motivering. Systemet skriver aldrig "felet konstaterat" utan reproducering eller annan verifiering — i stället: "Kundens beskrivning kunde inte reproduceras under de förhållanden som rådde vid undersökningen." (kodat även i orkesterns grundprompt).
• Rapportens beviskedja skiljer alltid: kundens beskrivning → verifierad observation → felorsaksanalys → rekommenderad åtgärd.

Felorsaksanalys (Root Cause Analysis)

Ett ärende avslutas aldrig med enbart "komponent defekt, byt komponent". Varje konstaterat fel kräver fyra obligatoriska svar:

1. Konstaterad avvikelse — kvalitetsregeln avvisar generella formuleringar ("trasig", "defekt", "sliten", "behöver bytas") utan förklaring.
2. Mest sannolik orsak — en eller flera kategorier (normalt slitage, materialutmattning, tillverkningsfel, bristande underhåll, felaktig tidigare reparation, yttre påverkan, korrosion, överhettning, modifiering … samt Okänd orsak, som kräver motivering).
3. Underlag — minst en evidenskälla, och källan valideras mot loggen: "Foto" godtas bara om ett foto faktiskt finns.
4. Säkerhetsnivå — hög/medel/låg; vid medel/låg krävs vilka ytterligare kontroller som skulle stärka bedömningen.

Avslutsknappen är spärrad tills SVP + felorsaksanalys är dokumenterade, och kvalitetsgrinden gör båda obligatoriska när ärendet stängs. Efter tusentals ärenden ger orsakskategorierna dessutom flottdata: vilka komponenter fallerar av slitage, vilka efter tidigare reparationer, vilka tyder på konstruktionsproblem.

Ärendeidentitet (Case Identity & Vehicle Context)

Fordonsobjektet är den röda tråden: identiteten registreras en gång (normalt via arbetsorderskanningen, som nu även läser claim-/garantinummer och skadenummer) och återanvänds sedan överallt:

• Identitetsrad i arbetsytan — AO, claim, skadenummer, fordon, regnr, VIN, miltal, ansvarig tekniker + ärendetypsval.
• Live Share — låst panel överst med fordon, referenser och status, härledd ur det nivåfiltrerade underlaget.
• Slutrapportens första sida — Ärendeinformation + Fordonsinformation automatiskt.
• Exporten — identitet + spårbarhetspaket i varje JSON.

Terminologi

Produkten beskrivs aldrig som en "AI-app" utan som ett evidensbaserat diagnossystem / intelligent beslutsstöd. I användargränssnitt och dokument används systemet, analysen, bedömningen, tolkningen, bildtolkningen, beslutsstödet, regelmotorn — inte "AI", om det inte är tekniskt nödvändigt.