Claude
bfed5dbd7f
Regelmotorn är nu plattformens styrande subsystem — systemet kan inte skriva en slutsats som ECM inte godkänt. Sex motorer (src/felsokning/ecm.ts): - Evidence: evidensposter ur loggen med nivå E0–E6, tekniker och deterministisk innehållshash - Rule: dokumentationskrav + undantagsregeln med obligatorisk orsak - Compliance: ärendetypen (garanti/goodwill/försäkring/reklamation/ begagnatgaranti …) styr extra krav — claim, skadenummer, historik, miltal, bildbevis - Validation: "Evidens saknas" i stället för antaganden (orkesterns grundprompt + projektioner + grind) - Completion: utökad kvalitetsgrind som spärrar slutrapporten - Traceability: spårbarhetspaket (regelversion, grindstatus per regel-id, evidensposter med hash) i varje export Pre-Diagnostic Validation — metodiken låses upp först när: - fordonshistoriken kontrollerats (eller motiverats: kvalitetsvarning), med orsakskedja för tidigare arbeten - ingående mätarställning fotograferats (bildtolkningen föreslår värdet) - kundens felbeskrivning verifierats - tidiga observationer hanterats Utgående mätarställning fotograferas inför avslut och blir obligatorisk i grinden när ärendet stängs. Ärendeidentitet (Case Identity): fordonsobjektet utökat med VIN, miltal, AO-, claim- och skadenummer (läses ur arbetsordern) — registreras en gång, synligt i identitetsraden i arbetsytan (med ärendetypsval), låst panel i Live Share, slutrapportens första sida och exporten. 49 vitest-tester; integrationstest och OpenAPI-validering gröna. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012EQg3rJsrQ1ZNTvkzmQAtt
128 lines
5.6 KiB
Markdown
128 lines
5.6 KiB
Markdown
# 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 |
|
|
|
|
Här ansluter det framtida **ECM Knowledge Library**: serverdistribuerade,
|
|
versionerade regelpaket (garantivillkor per tillverkare, försäkringsbolagens
|
|
krav, reklamationslagstiftning, OEM-kontrollpunkter) som laddas dynamiskt
|
|
utan appändring.
|
|
|
|
### 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.
|
|
|
|
## Ä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.
|