alva/felsokning/docs/SYSTEM-DESCRIPTION.de.md

Guidad Felsökning (Geführte Fehlersuche) — vollständige Systembeschreibung

Deutsche Übersetzung. Maßgeblich ist SYSTEM-DESCRIPTION.md (Englisch). Bei Widersprüchen gilt das englische Dokument.

Bezeichner im Code werden nicht übersetzt. Ereignistypen, Funktions- und Feldnamen, Dateipfade und Konfigurationsschlüssel sind im Code selbst schwedisch. Eine Übersetzung würde dieses Dokument gegenüber dem Repository unbrauchbar machen; sie stehen daher wörtlich, mit deutscher Erläuterung, wo die Bedeutung nicht offensichtlich ist.

Ein eigenständiges Referenzdokument. Alles Folgende stammt aus dem Code in felsokning/ (Branch claude/guidad-felsokning-vision-1mnx7f), nicht aus Plänen oder Absichten. Wo etwas nicht existiert, wird das ausdrücklich gesagt.

Zuletzt mit dem Code abgeglichen: Commit 1bb4031, 04.08.2026.

---

0. Zusammenfassung in dreißig Sekunden

Guidad Felsökning ist eine SaaS-Plattform für Kfz-Werkstätten. Sie führt eine Technikerin oder einen Techniker durch eine strukturierte Fehlersuche, verlangt für jede Aussage einen Nachweis und erzeugt eine nachvollziehbare Dokumentation, die mit der Kundschaft, einer Versicherung oder der nächsten Schicht geteilt werden kann.

Der tragende Gedanke ist negativ, nicht positiv formuliert: Das System stellt eine Hypothese niemals als festgestellten Fehler dar. Das ist keine Richtlinie in einem Dokument — es ist codiert, getestet, und es blockiert Abläufe. Fehlt der Nachweis, steht dort „Evidens saknas" (Nachweis fehlt), nicht eine qualifizierte Vermutung.

Technisch: ein ausschließlich anfügendes Ereignisprotokoll (append-only) ist die einzige Wahrheitsquelle. Alles andere — die Fallansicht, das Briefing, der Kundenbericht, das Qualitätstor, die Statistik — ist eine reine Projektion des Protokolls und lässt sich jederzeit neu erzeugen.

Client	React 18 + TypeScript + Vite + Tailwind + zustand + react-router
Backend	Zwei Node-Dienste (plattform, ai-orkester), reines node:http, minimale Abhängigkeiten
Datenbank	PostgreSQL (Aurora Serverless v2), append-only durch Datenbank-Trigger erzwungen
Modell	Claude, serverseitiges Routing pro Aufgabe
Infrastruktur	AWS + EKS, 126 Terraform-Ressourcen in zwei Schichten
Git & CI	Selbst gehostetes Gitea + Actions-Runner auf eigenem EKS — kein GitHub im Betriebspfad
Tests	120 vitest-Tests + Integrationstest gegen echtes Postgres
Sprache im Code	Schwedisch (Bezeichner, Kommentare, Commit-Nachrichten)

---

1. Produktprinzipien

Diese fünf sind Invarianten, keine Empfehlungen. Jedes hat eine Entsprechung im Code und in einem Test.

1.1 Keine Hypothese wird als festgestellter Fehler dargestellt

Hypothesen sind ein eigener Ereignistyp (hypotes) mit verpflichtender Zuverlässigkeitsstufe und können niemals die Stufe hog (hoch) annehmen — niva: Exclude<Tillforlitlighet, "hog">; das Typsystem verbietet es. Im Kundenbericht sind sie ausdrücklich als nicht verifiziert gekennzeichnet. Das Qualitätstor hat dafür eine eigene Zeile.

Die Formulierung bei fehlgeschlagener Reproduktion lautet „kunde inte reproduceras under de förhållanden som rådde" („konnte unter den herrschenden Bedingungen nicht reproduziert werden") — niemals „Fehler festgestellt" oder „kein Fehler gefunden". Das ist sowohl in den Projektionen als auch im Basis-Prompt des Orchesters codiert.

1.2 Ein Häkchen ist kein Nachweis

Jeder Prüfpunkt jeder Methodik trägt eine Mindestanforderung: matvarde (Messwert) | kommentar (Beobachtung) | foto (Foto). Eine Messung kann ohne Wert nicht als erledigt markiert werden; eine Fotoprüfung nicht ohne Bild. Will die Technikerin etwas überspringen, ist eine dokumentierte Ausnahme mit einem Grund aus einer festen Liste erforderlich.

Festgeschrieben durch den Test „varje kontroll kräver bevis — en kryssruta är inte evidens".

1.3 Das Protokoll ist append-only, bis ganz nach unten

Es gibt keine Update- oder Delete-Operationen in der API, und die Datenbank hat Trigger, die sie auch dann abweisen, wenn jemand die Anwendung umgeht. Ein Test sucht im Servercode aktiv nach update/delete gegen die Ereignistabelle und schlägt fehl, wenn sie auftauchen.

Folge: Eine falsche Angabe wird durch ein neues Ereignis korrigiert, niemals dadurch, dass die alte verschwindet. Die Historie ist das, was der Dokumentation im Streitfall ihren Wert gibt.

1.4 Terminologie

In der Oberfläche und in der Kundenkommunikation heißt es das System, die Analyse, die Bewertung, die Entscheidungsunterstützung — nicht „KI", sofern nicht technisch nötig. Das Produkt wird als evidenzbasiertes Diagnosesystem / intelligente Entscheidungsunterstützung beschrieben.

Der Grund ist kommerziell und erkenntnistheoretisch zugleich: Wer als Werkstattkunde „KI" hört, hört „Vermutung". Wer als Sachbearbeiterin einer Versicherung „KI-Bewertung" in einer Dokumentation liest, gewichtet sie niedriger.

1.5 Die Freigabegrenze ist eine Positivliste

Was die Organisation verlassen darf, wird positiv aufgezählt, je Stufe. Ein neuer Ereignistyp ist damit intern, bis ihn jemand aktiv freigibt. Ein Test verlangt, dass jeder Typ des Domänenmodells eingestuft ist — wird einer vergessen, schlägt der Build fehl, statt dass er nach außen gelangt.

---

2. Das Domänenmodell — das Ereignisprotokoll

app/src/felsokning/domain.ts (281 Zeilen).

Ein Fall besteht aus: Identität + Metadaten + einer geordneten Liste von Protokolleinträgen. Jeder Eintrag trägt id, tidpunkt (Zeitpunkt), tekniker (Techniker) und ein handelse (Ereignis).

2.1 Sämtliche Ereignistypen

Typ	Inhalt	Rolle
objekt_identifierat	objekt (Kennzeichen/FIN, Marke, Modell, Motor …)	Worum es geht
arbetsorder_skannad	falt[] + Anhang	Ausgelesener Auftrag (intern)
felbeskrivning	text	Die Worte der Kundschaft, wörtlich
arendetyp_satt	arendetyp	Garantie / Versicherung / Kunde — wählt Regelpaket
fraga_besvarad	stegId, frageId, fraga, svar	Symptomfragen der Methodik
kontroll_utford	stegId, kontrollId, text, resultat?, undantag?	Verifizierter Prüfpunkt
observation	text	Was beobachtet wurde — nicht was vermutet wird
matvarde	beskrivning, varde, enhet?	Messung (E4)
hypotes	text, niva (nie hog)	Arbeitshypothese (intern)
foto	beskrivning + Anhang	Bildnachweis (E2)
video	beskrivning + Anhang	Bewegtbildnachweis (E3)
matarstallning	lage (ein/aus), varde + Anhang	Kilometerstand ein/aus
historik_kontrollerad	kontrollerad, kommentar?	Servicehistorie
reproducering	status (ja/delvis/nej), beskrivning	Symptomverifizierung
felorsak	strukturierte Ursachenanalyse	Ursache, Kategorie, Grundlage
atgardsforslag	Vorschlag mit Begründung	Was getan werden sollte
kundbeslut	genehmigt/abgelehnt, Kanal	Entscheidung der Kundschaft
atgard_utford	ausgeführte Arbeit	Was tatsächlich getan wurde
kvalitetskontroll	Prüfung nach der Reparatur	Ist das Symptom weg?
kommentar	text	Freie Notiz
kategori_byte	kategori	Zeiterfassung (intern)
inaktivitet_forklarad	text, minuter	Warum es stillstand
overlamning	fran, till?	Schichtübergabe
ansvarig_satt	ansvarig	Umverteilung durch die Leitung (intern)
ai_svar	klassifizierte rader[], Modellname	Antwort der Entscheidungsunterstützung (intern)
export_skapad	format, version	Der Export protokolliert sich selbst
arende_avslutat	signatur?	Unterschrift der Technikerin

2.2 Anhänge sind inhaltsadressiert

foto, video, matarstallning und arbetsorder_skannad sind Schnittmengentypen mit Bilaga (Anhang):

export interface Bilaga {
  bilagaId?: string;
  bilagaHash?: string;   // SHA-256
  dataUrl?: string;      // bleibt für immer — das Protokoll ist append-only
}

Der Inhalt liegt außerhalb des Protokolls (S3 oder Datenbank), der Hash aber im Protokoll. Beim Lesen wird der Hash geprüft; stimmt er nicht, wird 409 zurückgegeben. Die Bedeutung: Wird ein Bild im Speicher ausgetauscht, fällt das auf, und das Protokoll kann belegen, dass das ursprüngliche Bild ein anderes war.

dataUrl bleibt im Typ, weil ältere Einträge es eingebettet enthalten — und das Protokoll lässt sich nicht umschreiben.

---

3. Die Methodik-Engine

Seit der jüngsten Änderung sind Engine und Inhalt getrennt:

• metodik.ts (171 Zeilen) — Typen, Methodikauswahl, Ableitung des nächsten Schritts.
• metodiker.ts (899 Zeilen) — die sechzehn Methodiken.

Die Bibliothek kann wachsen, ohne dass die Engine sich ändert.

3.1 Die Methodikbibliothek

Schritt-IDs sind Code und bleiben schwedisch. symptom = Symptom, visuell = Sichtprüfung, matningar = Messungen, provkorning = Probefahrt, sakerhet = Sicherheit, avlasning = Auslesen, glapp = Spiel, packning = Dichtung.

id	Name (im Code)	Bereich	Schritte	Prüfungen
vibration	Vibration under körning	Räder und Auswuchtung	symptom → visuell → kontroller → provkorning	19
bromsar	Bromssystem	Fahrwerk	symptom → visuell → matningar → system	14
styrning_fjadring	Styrning och fjädring	Fahrwerk	symptom → visuell → glapp → installning	11
elsystem	Elsystem och strömförsörjning	Elektrik	symptom → visuell → matningar → rela → funktionstest	12
start_laddning	Start- och laddningssystem	Elektrik	symptom → batteri → start → laddning → krypstrom	15
motor_drift	Motorgång och effekt	Motor	symptom → felkoder → mekanik → tandning_bransle → provkorning	16
kylsystem	Kylsystem och överhettning	Motor	symptom → visuell → matningar → packning	12
drivlina	Växellåda och drivlina	Antrieb	symptom → visuell → matningar → provkorning	10
avgas_emission	Avgassystem och emissioner	Motor	symptom → avlasning → matningar → orsak	12
klimat	Klimatanläggning	Komfort	symptom → visuell → matningar → styrning	11
hogvolt	Högvoltsystem — elbil och hybrid	Hochvolt	sakerhet → symptom → avlasning → laddning	16
diagnos_natverk	Felkoder och kommunikation	Diagnose	symptom → grund → buss → koder	10
lackage	Läckage	Sonstiges	symptom → visuell → metod	8
missljud	Missljud	Sonstiges	symptom → inspelning → lokalisering	7
adas	Förarassistans och kalibrering	Diagnose	symptom → forutsattningar → kalibrering	9
generisk	Generell strukturerad felsökning	Sonstiges	symptom → visuell → grundkontroller → funktionstest	9

Deutsche Namen: Vibration während der Fahrt · Bremsanlage · Lenkung und Federung · Elektrik und Stromversorgung · Start- und Ladesystem · Motorlauf und Leistung · Kühlsystem und Überhitzung · Getriebe und Antriebsstrang · Abgas und Emissionen · Klimaanlage · Hochvoltsystem (E-Auto/Hybrid) · Fehlercodes und Kommunikation · Leckage · Störgeräusche · Fahrerassistenz und Kalibrierung · generische strukturierte Fehlersuche.

3.2 Drei Regeln, durch Tests festgeschrieben

1. Jede Prüfung hat eine Mindestanforderung. Messwert, Foto oder Beobachtung.
2. Jede Methodik beginnt damit, das Symptom zu verifizieren, nie mit der Instandsetzung. Die Worte der Kundschaft werden erst dann zum verifizierten Symptom, wenn sie reproduziert wurden.
3. Wo die Arbeit jemanden verletzen kann, steht der Sicherheitsschritt an erster Stelle. Nur sakerhet darf symptom vorausgehen — der Test lässt genau diese Ausnahme zu und keine andere.

hogvolt ist die einzige Methodik mit Sicherheitsschritt. Sie verlangt die Befähigung, den dokumentiert entnommenen Servicestecker (Foto), die Wartezeit nach Herstellerangabe, die gemessene Spannungsfreiheit (ein Messwert — kein Ja auf eine Frage) und die Schutzausrüstung. Der Test prüft, dass der Schritt an erster Stelle steht, dass spanningsfrihet einen Messwert verlangt und dass die Beschreibung das Wort „livsfarlig" (lebensgefährlich) enthält.

Der Grund ist einfach: Diese Arbeit kann tödlich sein. Ein Häkchen genügt dort nicht.

3.3 Auswahl der Methodik

Früher eine Regex-Kette mit drei Ausgängen. Jetzt punktbewertetes Stichwort-Matching:

export function metodikPoang(metodik: Metodik, text: string): number
export function valjMetodik(felbeskrivning: string): Metodik

• Punktzahl = Summe der Längen der treffenden Stichwörter. Ein längeres — also spezifischeres — Wort wiegt schwerer. traktionsbatteri (16) schlägt batteri.
• Kurze Wörter (≤3 Zeichen) treffen als ganzes Wort, längere als Wortstamm. Sonst hätte "ac" das Wort acceleration getroffen und eine Vibration wäre in der Klimaanlage gelandet.
• Bei Gleichstand gewinnt das in der Bibliothek zuerst stehende Element → die Auswahl ist stabil über Läufe hinweg.
• Kein Treffer → generisk.

Eine Falle, die in der Entwicklung tatsächlich zugeschlagen hat: Die Stichwörter müssen Wortstämme sein, keine fertig gebeugten Wörter. Die schwedische Flexion tilgt oft ein e: filter → filtret, weshalb "partikelfilter" den Text, den eine Technikerin wirklich schreibt, nie trifft. Dasselbe gilt für regenerering → regenererar, misständning → misständer, skrammel → skramlar. Die Bibliothek verwendet daher partikelfilt, regenerer, misständ, skram.

(Für eine Lokalisierung: Das ist eine Eigenschaft der schwedischen Morphologie. Im Deutschen entsteht dieselbe Problemklasse durch Komposita — Partikelfilter steckt in Dieselpartikelfilter, aber Bremse nicht am Wortanfang von Feststellbremse. Ein lokalisierter Stichwortsatz muss gegen denselben Test validiert und nicht Wort für Wort übersetzt werden.)

Die Auswahl ist eine Fragenreihenfolge, keine Diagnose. Sie entscheidet, wo gesucht wird, nicht was defekt ist. Trifft nichts zu, ist generisk die ehrliche Antwort — strukturell vollständig und besser als eine Vermutung.

3.4 Nächster Schritt

export function nastaSteg(arende: Arende, metodik: Metodik): NastaSteg

Rein aus dem Protokoll abgeleitet: die erste unbeantwortete Frage, danach die erste nicht ausgeführte Prüfung, in der Reihenfolge der Methodik. Keine verborgene Zustandsmaschine — dasselbe Protokoll ergibt immer denselben nächsten Schritt.

3.5 Zum Anspruch „alles abdecken"

Das lässt sich nicht ehrlich versprechen, und die Dokumentation behauptet es auch nicht. Möglich ist, die Systeme des Fahrzeugs systematisch abzudecken und generisk als strukturell vollständiges Auffangnetz für das Unvorhergesehene zu belassen.

---

4. ECM v2.0 — die Evidenz- und Regel-Engine

app/src/felsokning/ecm.ts (749 Zeilen). Sechs Engines:

4.1 Evidence Engine

Evidenzstufen, aus dem Protokoll abgeleitet:

Stufe	Bedeutung
E0	Keine Grundlage
E1	Beobachtung der Technikerin
E2	Foto
E3	Video
E4	Messwert
E5	Diagnosedaten / Dokument
E6	Mehrere unabhängige Quellen

Die Evidenzstufe eines Falls ist die höchste, die die Grundlage trägt. Sie wird in der Oberfläche angezeigt und wandert mit dem Export mit.

Inhalts-Hash: innehallsHash() ist ein deterministischer FNV-1a über den Evidenzinhalt. Dieselbe Grundlage ⇒ derselbe Hash, unabhängig von Maschine oder Zeitpunkt. Damit ist der Export nachträglich überprüfbar.

4.2 Rule Engine

• ORSAKSKATEGORIER — feste Liste von Ursachenkategorien (ergibt vergleichbare Statistik über den Fuhrpark).
• UNDANTAGSORSAKER — feste Liste für „warum dies nicht getan wurde".
• UNDERLAGSKALLOR — worauf eine Schlussfolgerung beruht.
• INGEN_ATGARD_ORSAKER, KUNDKANALER (Kundenkanäle).
• granskaAvvikelse() — markiert Text, der als Feststellung formuliert ist, ohne gedeckt zu sein.

Feste Listen statt Freitext sind eine bewusste Entscheidung: Freitext lässt sich nicht aggregieren, und die Fuhrparkstatistik ist eines der echten Aktiva des Produkts.

4.3 Compliance Engine

ARENDETYPER (Fallarten) bestimmt, welches Regelpaket gilt. Ein Garantiefall verlangt Claim-Nummer und Servicehistorie; ein Versicherungsfall Schadennummer und Bildnachweis; ein Kundenfall weniger. Die Pakete sind Daten (ecm-regler.json, ausliefbar über /api/ecm/regler) — neue Anforderungen brauchen kein neues Release.

4.4 Validation Engine — Vordiagnostik

Bevor die Fehlersuche beginnen darf: Objektidentifizierung verifiziert, Auftrag eingelesen, Fahrzeughistorie geprüft oder begründet, eingehender Kilometerstand dokumentiert, Fehlerbeschreibung der Kundschaft verifiziert, frühe Beobachtungen bearbeitet.

4.5 Completion Engine — das Qualitätstor

Die größte Einzelfunktion (kvalitetsgrind, ~240 Zeilen). Der Fall kann nicht abgeschlossen werden, bevor jede Zeile grün oder begründet ist:

• Fahrzeughistorie geprüft oder begründet
• Eingehender/ausgehender Kilometerstand dokumentiert
• Fehlerbeschreibung der Kundschaft verifiziert
• Symptomverifizierung: reproduziert oder als nicht reproduzierbar dokumentiert
• Ursachenanalyse dokumentiert
• Maßnahme dokumentiert oder begründet
• Entscheidung der Kundschaft zum Vorschlag erfasst
• Arbeit trotz abgelehntem Vorschlag ausgeführt (sofern zutreffend)
• Qualitätskontrolle durchgeführt — Symptom verifiziert
• Prüfungen der Methodik: Nachweis oder dokumentierte Ausnahme
• Fotos vorhanden für fotopflichtige Prüfungen
• Schlussfolgerung der Technikerin unterschrieben
• Hypothesen als nicht verifiziert ausgewiesen
• Regelpaket der Fallart erfüllt (Claim / Schadennummer / Kilometerstand / Historie)

4.6 Traceability Engine

sparbarhetspaket() — die gesamte Beweiskette in einem strukturierten Objekt: was behauptet wird, worauf es beruht, wer es dokumentiert hat und wann.

---

5. Symptomverifizierung (SVP)

Ein eigenes Prinzip, weil es die schärfste Kante des Produkts zur Wirklichkeit ist.

Die Beschreibung der Kundschaft ≠ ein festgestellter Fehler.

1. Die Beschreibung wird wörtlich dokumentiert (felbeskrivning).
2. Sie wird über die Symptomfragen der Methodik präzisiert — wann, wo, wie, nie „was ist kaputt".
3. Sie wird reproduziert, mit drei möglichen Ausgängen:
   • Ja — mit dokumentierten Bedingungen.
   • Teilweise — was sich nachstellen ließ und was nicht.
   • Nein — verpflichtende Begründung.

Die Beweiskette des Berichts trennt vier Dinge, die sonst vermischt werden: die Beschreibung der Kundschaft, die verifizierte Beobachtung, die Ursachenanalyse und die empfohlene Maßnahme.

---

6. Der Client

app/src/felsokning/ + app/src/pages/felsokning/.

Modul	Zeilen	Verantwortung
ArendeSida.tsx	2433	Die Fallansicht. Dreispaltiges Layout am Schreibtisch
metodiker.ts	899	Die Methodikbibliothek
ecm.ts	749	Regel- und Evidenz-Engine
NyttArende.tsx	497	Fallanlage, Auftragsscan
Arendelista.tsx	399	Dashboard: Zähler, Filter
projektioner.ts	356	Alle Ansichten als reine Funktionen des Protokolls
ai.ts	305	Clientseite des Orchesters, Prompt-Bau, Antwort-Parsing
plattform.ts	296	API-Client gegen die selbst gehostete Plattform
DelatArendeVy.tsx	283	Geteilte Ansicht (Kunde/Partner/intern)
domain.ts	281	Ereignistypen
Installningar.tsx	281	Organisation, Benutzer, Integrationen
Oversikt.tsx	238	Ansicht für die Werkstattleitung
demo.ts	200	Demofall mit 1 Std. 35 Min. Historie
ui.tsx	174	Industrielle Werkstattoberfläche
metodik.ts	171	Die Methodik-Engine
synk.ts	141	Konfliktfreies Zusammenführen von Ereignissen
ikoner.tsx	132	Eigene SVG-Linienicons (keine Emojis)
streckkod.ts	131	Barcode-/FIN-Erfassung
store.ts	106	zustand-Store
bilagor.ts	96	Upload + Blob-URL-Cache
installningar.ts	86	Organisationseinstellungen
Bilagevisning.tsx	69	<Bild> / <Klipp>
Mikrofon.tsx / rost.ts	66 / 65	Spracherkennung
format.ts	48	Fotoskalierung u. a.

6.1 Die Projektionen

objekt · felbeskrivning · ansvarig · arendeidentitet · arAvslutat
lokalFordonshistorik · utfordaKontroller · ejKontrollerat
observationer · hypoteser · foton · videor
tidsfordelning · formateraTid · tillforlitlighet
brief · overlamningstext · tidsfordelningsRader · sistaAktivitet

Alles reine Funktionen von Arende. ejKontrollerat („noch nicht geprüft") ist die, die in der Praxis am meisten Zeit spart: Was beim Schichtwechsel Doppelarbeit verursacht, ist das, wovon niemand aufgeschrieben hat, dass es niemand getan hat.

6.2 Gestaltungssprache

Eine an ETKA angelehnte Werkstattoberfläche: flache hellgraue Flächen (#ECECEC/#F7F7F7), scharfe Kanten, tiefes Marineblau als Primärfarbe, dichte Typografie (11–15 px), rechteckige Schaltflächen (max. 4 px Radius), Werkzeugleiste ~44 px. Eigene Linienicons statt Emojis; Status als Farbpunkte.

Das Motiv: Die Technikerin trägt Handschuhe, steht in einem lauten Raum und hat keine Zeit für eine luftige Consumer-Oberfläche.

6.3 Lokaler Betrieb

Ohne Anmeldung arbeitet die App gegen localStorage. Die Methodik führt allein, das Orchester ist aus. Der Status steht im Fallkopf. Bei der Anmeldung werden lokale Ereignisse mit denen des Servers zusammengeführt — konfliktfrei je Ereignis-ID, getestet.

---

7. Backend

7.1 services/plattform (1210 Zeilen)

Reines node:http. Einzige Abhängigkeit ist pg.

API-Pfade:

GET  /halsa                        Gesundheitsprüfung
GET  /api/openapi.yaml
POST /api/auth/registrera          legt Organisation + Systemadministrator an
POST /api/auth/logga-in            Anmeldung
POST /api/auth/logga-ut-alla       erhöht token_version → alle Sitzungen enden
GET  /api/anvandare                Benutzer; nur Admin
POST /api/anvandare
POST /api/anvandare/{id}/avaktivera | /aktivera
GET  /api/organisation
GET/PUT /api/organisation/installningar
GET  /api/ecm/regler               Regelpakete als Daten
GET/POST /api/arenden              Fälle
POST /api/arenden/{id}/handelser   append-only
POST /api/arenden/{id}/bilagor     Anhänge
GET  /api/bilagor/{id}             Hash beim Lesen geprüft
GET  /api/fordon/{identifierare}/historik
GET  /api/statistik/felorsaker     Ursachenstatistik
GET  /api/oversikt                 Leitungsansicht
GET  /api/delad/{kod}              geteilt, nach Stufe gefiltert
POST /api/delad/{kod}/beslut       Kundenentscheidung ohne Anmeldung
GET  /api/delad/{kod}/bilagor/{id} stufengefiltert
GET  /api/integrationer/leverantorer
GET/PUT/DELETE /api/integrationer/{leverantor}
POST /api/integrationer/{leverantor}/uppslag

Es gibt keine Update- oder Delete-Pfade auf Falldaten. Mit Absicht.

Sicherheitsfunktionen im Dienst:

ursprungFor · forTataForsok · kallaFor · inloggningSparrad · loggaForsok
skapaJwt · verifieraJwt · kontoGiltigt · kravAuth · arendeIOrg
integrationsNyckel · kryptera · dekryptera · maskera
arPrivatAdress · pekarInat · gorUppslag · skickaBilaga · synligaTyper

7.2 services/ai-orkester (400 Zeilen)

Besitzt den Claude-Schlüssel. Der Client hat ihn nie. Routing pro Aufgabe:

Aufgabe	Modell	Effort	Vision
handledning (Begleitung in Echtzeit)	claude-sonnet-5	medium	—
granskning (Tiefenprüfung)	claude-opus-5	high	—
sammanfattning (Übergabezusammenfassung)	claude-sonnet-5	low	—
metodikval (Klassifizierung)	claude-haiku-4-5	(keiner — das Modell nimmt den Parameter nicht)	—
instrumentavlasning (Instrumentenablesung)	claude-sonnet-5	low	✔
dokumenttolkning (Dokumentenauswertung)	claude-sonnet-5	low	✔

Alle Antworten sind schemagebunden (json_schema). Der Basis-Prompt codiert die Regeln: „Erfinde niemals Fakten", „niemals eine Hypothese als festgestellten Fehler", „ERFORDERT Verifizierung". Bei abgelehnter Anfrage erfolgt automatischer Rückfall auf ein Reservemodell. Das antwortende Modell wird in jedem ai_svar-Ereignis protokolliert — die Grundlage muss nachträglich prüfbar sein.

Der Methodikkatalog wird aus einer einzigen Liste (METODIK_KATALOG) gebaut, die sowohl das enum des Schemas als auch die Aufzählung im Prompt erzeugt. Ein Test vergleicht ihn mit der Bibliothek des Clients: Driften die Listen auseinander, liefert der Klassifikator eine ID, die der Client nicht kennt, und die Auswahl fiele stillschweigend auf generisch zurück. Jetzt schlägt stattdessen der Test fehl.

7.3 services/gemensam/observation.mjs (166 Zeilen)

Tracing und Metriken ohne neue Abhängigkeiten. Die Dienste haben bewusst fast keine Abhängigkeiten; ein OpenTelemetry-SDK mit dreißig Paketen hereinzuholen, um vier Dinge zu messen, wäre die falsche Abwägung. Stattdessen zwei Standards, die beide nur Text auf stdout sind:

• W3C Trace Context — traceparent läuft durch die ganze Kette mit (Client → Plattform → Orchester).
• CloudWatch EMF — strukturiertes JSON, aus dem CloudWatch selbst Metriken zieht. Kein Agent, kein SDK, nichts, was still ausfallen kann.

spårFrån(Header) · traceparent(Spur) · starta(Name, Spur)
  → .mät(Teilname, Arbeit) · .ms() · .delar()
logga(Stufe, Meldung, Felder) · mätvärde(Name, Wert, Einheit, Dim, Extra)
avsluta(Span, { status, väg, extra })

Was gemessen wird, ergab sich aus einer Frage: Was will man um drei Uhr nachts wissen, wenn etwas langsam ist? Die Antwort ist wohin die Zeit ging — nicht wie viele Aufrufe erfolgten. Daher delar() („Teile"): die Datenbank, der Modellaufruf, der Objektspeicher, der Anbieter der Kundschaft, mit Anzahl und Summe je Teil in derselben Protokollzeile.

mät() misst auch, wenn die Arbeit eine Ausnahme wirft — sonst sähen Fehler wie null Zeit aus.

Dimensionen werden bewusst knapp gehalten. Jede eindeutige Kombination ist eine eigene, kostenpflichtige Zeitreihe; Organisation, Fall und Spur-ID dürfen daher nie zu Dimensionen werden — sie sind gewöhnliche Felder. Festgeschrieben durch einen Test, der org, organisation, arende, spårId, anvandare unter den Dimensionen ausdrücklich verbietet.

---

8. Sicherheit

Schutz	Umsetzung
Mandantentrennung	Alle Fallabfragen sind organisationsgebunden (arendeIOrg); integrationsgetestet gegen echtes Postgres
Rollen	tekniker / arbetsledare / admin (Techniker / Werkstattleitung / Admin), im JWT und als Datenbank-Check
JWT-Claims	{ sub, namn, org, roll, tv } — tv = token_version
Sofortiger Entzug	kontoGiltigt() prüft aktiv + token_version bei jeder authentifizierten Anfrage. Eine gültige Signatur genügt nicht
Globale Abmeldung	/api/auth/logga-ut-alla erhöht token_version → alle ausgestellten Tokens verfallen sofort
Passwörter	bcrypt über gen_salt('bf') in der Datenbank
Anmeldesperre	15-Minuten-Fenster; max. 10 Versuche je Konto, 30 je Quelle. Probabilistisch aufgeräumt (2 % je Schreibvorgang), um einen Cron-Job zu vermeiden
Verschlüsselung im Ruhezustand	AES-256-GCM für die Integrationszugänge der Kundschaft; geheime Felder werden in API-Antworten immer maskiert
SSRF-Abwehr	arPrivatAdress() + pekarInat(): 10/8, 127/8, 169.254/16, 172.16–31, 192.168/16, 100.64/10, ::1, fc/fd, fe80, ::ffff:. DNS wird aufgelöst, bevor der Aufruf erfolgt; .local/.internal blockiert. Notausgang TILLAT_INTERNA_UPPSLAG für Testumgebungen
CORS	TILLATNA_URSPRUNG-Positivliste; der Ursprung wird einmal je Anfrage gesetzt
Integrität von Anhängen	SHA-256 im Protokoll, beim Lesen geprüft → 409 bei Abweichung
Append-only in der Datenbank	Trigger before update or delete auf felsokning_handelser und felsokning_arenden
Pod-Härtung	IMDSv2 verpflichtend, Hop-Limit 1 → Pods können die IAM-Rolle des Knotens nicht ausleihen
IRSA	Jedes Service-Konto hat eine eigene Rolle; die Knoten teilen keine Rechte
Getrennte IAM-Rollen	bygg (Build) darf nach ECR veröffentlichen, aber den Cluster nicht anfassen; drift (Betrieb) darf den Cluster anfassen, aber keine Images veröffentlichen
Netzwerkrichtlinie	Eingehend standardmäßig verboten; explizite _ut-Regeln (ausgehend) je Dienst
Datenbankzugriff	Nur von den Cluster-Knoten, in einer Subnetzschicht ohne Route nach draußen

8.1 Datenbankschema

organisationer · anvandare · inloggningsforsok
felsokning_arenden · felsokning_handelser
bilagor · bilage_innehall
delningar · integrationer

(Organisationen · Benutzer · Anmeldeversuche · Fälle · Ereignisse · Anhänge · Anhangsinhalte · Freigaben · Integrationen)

---

9. Live Share — Freigabestufen

Drei Stufen, serverseitige Filterung:

Stufe	Sieht
kund (Kundschaft)	22 Ereignistypen: Objekt, Fehlerbeschreibung, Fragen, Prüfungen, Beobachtungen, Messwerte, Fotos, Videos, Kommentare, Übergaben, Maßnahmen, Qualitätskontrolle …
partner	Alles, was die Kundschaft sieht + hypotes (als nicht verifiziert gekennzeichnet)
intern	Volle Einsicht — keine Filterung

Niemals außerhalb der Organisation: kategori_byte, hypotes, ai_svar, ansvarig_satt, arbetsorder_skannad.

export function synligaTyper(niva) {
  if (niva === "intern") return null;           // volle Einsicht
  return niva === "partner" ? DELBART_PARTNER : DELBART_KUND;
}

Links sind widerrufbar. Die öffentliche Freigabeseite (/felsokning/delad/:kod) verlangt keine Anmeldung und pollt für Live-Aktualisierung. Die Kundschaft kann ihre Entscheidung direkt in der Ansicht abgeben (POST /api/delad/{kod}/beslut).

Warum eine Positivliste: Eine Negativliste muss aktualisiert werden, sobald ein neuer Ereignistyp hinzukommt — und genau das wird vergessen. Eine Positivliste macht aus „vergessen" ein „intern", und das ist der sichere Ausgang.

---

10. Markenspezifische Anbindungen

Anbieter sind Daten, kein Code (integrationer.json, als ConfigMap über INTEGRATIONER_FIL einhängbar). Neue Marken erfordern keinen Neubau.

id	Anbieter
generisk_vin	Beliebiger FIN-Dienst über HTTP
vag_erwin	Volkswagen Group erWin (VW, Audi, Škoda, SEAT)
volvo_vida	Volvo VIDA
fordonsregister	Kennzeichen → Fahrzeug

Jeder Anbieter deklariert seine Felder, welche geheim sind (verschlüsselt + maskiert) und wie die Antwort auf die Domänenfelder abgebildet wird (marke, modell, arsmodell, motor, vaxellada — Marke, Modell, Baujahr, Motor, Getriebe).

Abfragen laufen durch den SSRF-Schutz — eine Kundin kann einen „Anbieter" also nicht auf interne Adressen des Clusters richten.

---

11. Visual-first

Die Kamera ist die Integrationsschicht. Was auf einem Bildschirm oder einem Instrument steht, wird fotografiert und ausgewertet, statt angebunden zu werden.

• Auftragsscan ist der Hauptweg bei der Fallanlage. Sonnet 5 (Vision) liest Kunden-, Fahrzeug- und Werkstattangaben unabhängig vom Layout, mit einer Konfidenz je Feld:

  • 🟢 ≥95 % automatisch übernommen
  • 🟡 80–95 % zum Durchlesen markiert
  • 🔴 <80 % erfordert aktive Bestätigung

  Die Technikerin prüft also nur die unsicheren Felder. Visuelle Kontrolle mit dem Dokument neben den Feldern; ein Klick markiert die ungefähre Position.

• Instrumentenablesung — Foto eines Diagnosebildschirms oder Instruments → strukturierte Werte.

Das Motiv ist kommerziell: Eine Anbindung je Werkstattsystem bedeutet einen Vertriebszyklus je Kunde. Eine Kamera funktioniert sofort gegen alles.

---

12. Infrastruktur

Zwei Terraform-Schichten. Die Basis läuft selten, die Arbeitslastschicht oft.

12.1 infra/aws — die Basis (91 Ressourcen)

Bereich	Inhalt
Netz	1 VPC, 3 Subnetzschichten × 3 Zonen: öffentlich (nur ALB + NAT), privat (Knoten, keine öffentlichen Adressen), Daten (Aurora, überhaupt keine Route nach draußen). VPC-Endpunkte: S3 (Gateway); ECR, Logs, Secrets Manager, STS, ELB (Interface) → der Verkehr verlässt das Netz nie
Cluster	EKS, arm64-Knoten, IRSA über OIDC-Provider, IMDSv2 Hop-Limit 1, alle fünf Control-Plane-Logs an
Daten	Aurora PostgreSQL Serverless v2, PITR sekundengenau, KMS mit eigenem Schlüssel, sslmode=require
Objektspeicher	S3 für Anhänge: SSE-KMS, öffentlicher Zugriff blockiert, TLS verpflichtend, Versionierung an. Die Plattformrolle darf lesen und schreiben — aber nie löschen
Registry	ECR mit unveränderlichen Tags + Schwachstellen-Scan
Geheimnisse	Secrets Manager; nur von der Plattformrolle über IRSA lesbar
Rollen	9 IAM-Rollen, darunter die getrennten bygg / drift
Domäne	Route 53 + ACM mit DNS-Validierung
Beobachtbarkeit	7 Alarme, 1 Dashboard, 3 Log-Gruppen, SNS-Topic

Die Alarme — wenige, aber die vorhandenen bedeuten etwas. Ein Alarm, auf den niemand reagiert, bringt Menschen bei, Alarme zu ignorieren.

• Aurora-CPU > 85 % über drei Perioden (die Skalierungsgrenze könnte erreicht sein)
• Aurora freier lokaler Speicher < 5 GiB
• Backup-Alter — treat_missing_data = "breaching". Fehlt der Messwert, gibt es keine Sicherung. Ein Backup, von dem man glaubt, es gäbe es, ist schlimmer als keines.
• Weniger Knoten als das gewünschte Minimum
• Antwortzeit p95 > 3 s über drei Perioden — nicht der Mittelwert, der verdeckt, dass jede zwanzigste Technikerin unzumutbar lange wartet
• Serverfehler (Summe > 5)
• Das Modell lehnt ab (deutet auf unerwartete Eingaben hin, nicht auf einen Betriebsfehler)

12.2 infra/terraform — die Arbeitslast (35 Ressourcen)

Liest die Basis über terraform_remote_state; wiederholt nichts.

kubernetes_namespace_v1        denna, gitea
kubernetes_service_account_v1  plattform (IRSA), drift, runner
kubernetes_deployment_v1       plattform, orkester, web
kubernetes_service_v1          plattform, orkester, web
kubernetes_horizontal_pod_autoscaler_v2  × 3
kubernetes_pod_disruption_budget_v1      × 3
kubernetes_ingress_v1          denna, gitea
kubernetes_network_policy_v1   neka_allt_in, tjanster_in, dns_ut,
                               plattform_ut, orkester_ut, web_ut
kubernetes_manifest            hemlighetskalla, hemligheter (External Secrets)
helm_release                   lastbalanserare (ALB), external_secrets,
                               cloudwatch, metrics, gitea
aws_route53_record             denna

karta.tf (117 Zeilen) erzeugt eine lesbare Karte des gesamten Betriebsbildes: terraform output karta.

12.3 Git und CI — vollständig selbst gehostet

Eine ausdrückliche Produktentscheidung: kein GitHub im Betriebspfad. Gitea + Actions-Runner laufen auf eigenem EKS. .gitea/workflows/felsokning.yml:

Job	Inhalt
test-och-bygg	vitest run, typkontroll, eslint, vite build
tjanster	eslint auf den Diensten, Integrationstest gegen echtes Postgres, swagger-cli validate
terraform	fmt -check -recursive, init -backend=false, validate
publicera	Nur auf main, nur wenn das Obige durchlief. Baut drei Images, taggt mit dem Commit-SHA, schiebt in die eigene ECR. OIDC, kein statischer Schlüssel
driftsatt	Manuell (workflow_dispatch) mit explizitem Image-Tag

Die Inbetriebnahme ist bewusst ein eigener Schritt: Ein Image in der Registry ist nicht dasselbe wie ein laufendes Image. Rollback = erneut mit dem vorherigen Tag ausführen.

Die API-Adresse des Clients wird beim Build eingebacken (Vite), das Image ist also umgebungsgebunden. Der Build-Kontext der Dienste ist felsokning/services, damit beide das gemeinsame Beobachtungsmodul erreichen, ohne es zu duplizieren.

---

13. Testen

120 vitest-Tests in 13 Dateien:

Datei	Anzahl	Schreibt fest
ecm.test.ts	32	Evidenzstufen, Regelpakete, Qualitätstor, Vordiagnostik
metodiker.test.ts	14	Bibliotheksstruktur, Methodikauswahl, Katalogparität mit dem Orchester
projektioner.test.ts	13	Ansichten als reine Funktionen, nächster Schritt
ai.test.ts	11	Orchesterparität, OpenAPI ↔ Server, append-only, Prompt-Regeln
observation.test.ts	10	Tracing, EMF-Format, verbotene Dimensionen
bilagor.test.ts	9	Inhalts-Hash, SigV4, Speicherschichtwahl
delning.test.ts	7	Die Positivliste deckt jeden Ereignistyp ab
integrationer.test.ts	7	Anbieterabfragen, SSRF-Schutz
demo.test.ts	4	Der Demofall ist reichhaltig genug zum Zeigen
installningar.test.ts	4	Organisationseinstellungen
streckkod.test.ts	4	FIN/Barcode
synk.test.ts	4	Konfliktfreies Zusammenführen
example.test.ts	1	—

Über die Unit-Tests hinaus:

• integrationstest.sh — der gesamte Ablauf gegen echtes Postgres: Organisationen, Rollen, der Append-only-Trigger, Trennung, Freigabe, Anhänge.
• SigV4 bitgenau gegen botocore quergeprüft (sigv4-referens.json).
• swagger-cli validate auf der OpenAPI-Spezifikation.
• Paritätstests zwischen Spezifikation ↔ Server, Client ↔ Orchester (× 2 Kopien), Domänenmodell ↔ Freigabeliste.

13.1 Die Prüfschleife vor jedem Commit

npx vitest run                    # 120 Tests
npm run typkontroll               # tsc --noEmit  (vite build prüft KEINE Typen)
npx eslint src/felsokning src/pages/felsokning
cd ../services && npx eslint .
npm run build
terraform fmt -check -recursive
# CI der Wurzel: lint · format:check · typecheck · test

typkontroll kam hinzu, nachdem zwei latente Abstürze (TextFalt und UNDANTAGSORSAKER ohne Import verwendet) an vite build vorbeigekommen waren — das transpiliert, prüft aber keine Typen.

---

14. Repository-Struktur

main ist ein npm-workspaces-Monorepo namens Semantika, das die Wurzel besitzt. Bei der Zusammenführung der beiden Produkte wurden beide behalten, mit je Baum getrennten Werkzeugketten — nicht dadurch, dass die Regeln einer Seite aufgeweicht wurden.

/                             Semantika (Workspaces-Wurzel)
├── apps/mobile/              Semantika
├── services/api/             Semantika
├── infra/                    Semantika
├── .github/workflows/ci.yml  Semantika  — unangetastet
│
├── .gitea/workflows/felsokning.yml      Guidad Felsökning (eigene CI)
└── felsokning/
    ├── app/                  Client (eigene package.json, eslint, vitest, tsconfig)
    ├── services/
    │   ├── plattform/
    │   ├── ai-orkester/
    │   └── gemensam/         observation.mjs (gemeinsam)
    ├── infra/
    │   ├── aws/              die Basis, 91 Ressourcen
    │   ├── terraform/        die Arbeitslast, 35 Ressourcen
    │   └── postgres-init.sql
    ├── docs/
    └── supabase/             Migrationen + Edge-Funktion (älterer Weg)

Zwei Betriebswege bestehen parallel: der selbst gehostete AWS-Stack (der gilt) und ein älterer Supabase-basierter (die Edge-Funktion felsokning-ai, Migrationen). Das Orchester existiert daher in zwei Kopien, durch Tests synchron gehalten.

---

15. Dokumentation im Repository

docs/VISION.md                          die Produktvision
docs/MASTER-PROMPT.md                   die Gründungsinstruktion
docs/MVP.md                             was gebaut ist, Funktion für Funktion
docs/DEMO.md                            Demoskript für Vorführungen
docs/DRIFT.md                           Betrieb
docs/SYSTEM-DESCRIPTION.md              Englisch — die maßgebliche Fassung
docs/SYSTEM-DESCRIPTION.sv.md           Schwedisch
docs/SYSTEM-DESCRIPTION.de.md           dieses Dokument
docs/SYSTEM-DESCRIPTION.da.md           Dänisch
docs/SYSTEM-DESCRIPTION.no.md           Norwegisch (Bokmål)
docs/exempel/vibration-vid-88-km-h.md   durchgerechnetes Beispiel
docs/moduler/                           acht Moduldokumente

---

16. Entwurfsentscheidungen und ihre Beweggründe

Zusammengestellt, weil der Beweggrund oft wichtiger ist als die Entscheidung.

Entscheidung	Beweggrund
Event Sourcing	Die Dokumentation muss im Streitfall halten. Die Historie ist der Wert
Append-only auch in der Datenbank	Die Anwendungsschicht lässt sich umgehen, der Trigger nicht
Positivliste für Freigaben	Ein vergessener Ereignistyp wird intern, nicht geleakt
Feste Ursachenkategorien	Freitext lässt sich nicht aggregieren; die Fuhrparkstatistik ist ein Aktivum
Serverseitiges Modell-Routing	Der Client darf den Schlüssel nie halten, und Routing muss sich ohne Release ändern lassen
Modell je Antwort protokolliert	Die Grundlage muss nachträglich prüfbar sein
Das Wort „KI" vermeiden	Die Kundschaft hört „Vermutung"; die Sachbearbeitung gewichtet niedriger
Visual-first	Eine Anbindung je Werkstattsystem = ein Vertriebszyklus je Kunde. Die Kamera funktioniert sofort
Anbieter als Daten	Eine neue Marke soll kein Release erfordern
Eigene Beobachtbarkeit, null Abhängigkeiten	30 Pakete, um 4 Dinge zu messen, ist die falsche Abwägung
Wenige EMF-Dimensionen	Jede Kombination ist eine kostenpflichtige Zeitreihe
p95 im Alarm, nicht der Mittelwert	Der Mittelwert verdeckt, dass jede zwanzigste Technikerin wartet
Alarm auf fehlende Backup-Daten	Ein geglaubtes Backup ist schlimmer als keines
Getrennte Build-/Betriebsrollen	Ein kompromittierter Build darf den Cluster nicht anfassen können
Manuelle Inbetriebnahme	Ein Image in der Registry ≠ ein laufendes Image
Unveränderliche ECR-Tags	Ein Tag muss morgen dasselbe bedeuten
Inhaltsadressierte Anhänge	Ein ausgetauschtes Bild muss auffallen, nicht unterstellt werden
Hash-Prüfung beim Lesen	Hashen beim Schreiben genügt nicht
Die S3-Rolle darf nicht löschen	Append-only muss auch für den Speicher gelten
Engine vom Inhalt getrennt	Die Bibliothek wächst; die Engine soll sich nicht ändern müssen
Punktbewertete Methodikauswahl	Regex-Ketten werden bei 16 Alternativen undurchschaubar
Stichwörter als Wortstämme	Die schwedische Flexion tilgt ein e — sonst trifft nichts
generisk als Rückfall	Ein ehrliches „wir wissen es nicht" schlägt eine Vermutung
Sicherheitsschritt zuerst bei Hochvolt	Diese Arbeit kann tödlich sein
Schwedisch im Code	Die Domäne ist schwedisch; Hin- und Herübersetzen verliert Präzision

---

17. Bekannte Grenzen und offene Punkte

Ausdrücklich nicht fertig:

• Zwei Orchester-Kopien (Supabase-Edge-Funktion + K8s-Dienst) werden durch Tests synchron gehalten, nicht durch gemeinsamen Code. Der Supabase-Weg ist der ältere und sollte abgelöst werden.
• ArendeSida.tsx hat 2433 Zeilen. Es funktioniert, ist aber die Datei, die am meisten kostet, wenn man sie ändert.
• terraform validate lässt sich lokal nicht ausführen (die ausgehende Netzwerkrichtlinie blockiert Provider-Downloads). Ersetzt durch terraform fmt plus eine eigene statische Referenzprüfung; die echte Validierung erfolgt in der CI.
• Der Claude-Schlüssel wird von Hand eingetragen, nach dem ersten apply — er liegt bewusst nicht im Terraform-State.
• postgres-init.sql wird manuell gegen die Datenbank ausgeführt, nachdem die Basis angewandt wurde.
• Kein automatischer Wiederherstellungstest des Backups. Der Alarm sagt, dass gesichert wird, nicht dass sich wiederherstellen lässt.
• Die Methodikbibliothek deckt nicht alles ab — und behauptet es auch nicht. generisk ist das Auffangnetz.
• Das eslint der Wurzel hat 20 vorbestehende Fehler in Semantikas eigenen Seiten (no-explicit-any), die nichts mit Guidad Felsökning zu tun haben.

---

18. Glossar

Die linke Spalte ist der Begriff, wie er in Code und Oberfläche erscheint.

Schwedisch	Deutsch
Ärende	Fall — ein Fehlersuchauftrag
Händelse / loggpost	Ereignis / Protokolleintrag — unteilbarer Eintrag im Append-only-Protokoll
Metodik	Methodik — strukturierter Fehlersuchablauf
Steg	Schritt — Phase einer Methodik (Symptom, Sichtprüfung, Messungen …)
Kontroll	Prüfung — einzelner Checklistenpunkt mit Mindestanforderung
Krav	Anforderung — matvarde / kommentar / foto
Undantag	Ausnahme — dokumentierter Grund, warum eine Prüfung entfiel
Brief	Briefing — verdichtetes Fallbild; eine Projektion
Kvalitetsgrind	Qualitätstor — Regelwerk, das vor dem Abschluss passiert werden muss
Evidensnivå	Evidenzstufe — E0–E6, die Beweiskraft der Grundlage
Reproducering	Reproduktion — Symptomverifizierung: ja / teilweise / nein
Felorsak	Fehlerursache — strukturierte Analyse mit Kategorie und Grundlage
Delning	Freigabe — externer Link mit Berechtigungsstufe
Orkester	Orchester — der Dienst, dem das Modell-Routing gehört
Spann / spår	Span / Spur — Zeitmessung bzw. W3C-Tracing
Bilaga	Anhang — inhaltsadressiertes Foto/Video/Dokument
Tekniker	Technikerin, Techniker
Arbetsledare	Werkstattleitung, Meister
Fordon	Fahrzeug
Mätvärde	Messwert
Felbeskrivning	Fehlerbeschreibung (die Worte der Kundschaft)
Arbetsorder	Werkstattauftrag
Mätarställning	Kilometerstand
Överlämning	Übergabe
Åtgärd	Maßnahme, Instandsetzung
Kundbeslut	Kundenentscheidung
Säkerhet	Sicherheit
Högvolt	Hochvolt