> ## Documentation Index > Fetch the complete documentation index at: https://docs.ferrufino-tech-solutions.com/llms.txt > Use this file to discover all available pages before exploring further. # Kernkonzepte > Workspaces, Cases, Evidence, Reviews, Taxonomy und Rollen — die sechs Ideen, die du verstehen musst, um FTS zu nutzen. Wenn du diese sechs Konzepte verstehst, bist du produktiv in FTS. Jedes Feature im Produkt baut darauf auf. ## 1. Organisation und Workspace Eine **Organisation** repräsentiert dein Unternehmen in FTS. Sie besitzt das Abonnement, die Abrechnungsbeziehung und die globalen Einstellungen. Ein **Workspace** ist ein Container innerhalb einer Organisation. Er enthält Cases, Mitglieder und eine Taxonomy. Denke an ihn als Projekt, Werk, Produktlinie oder Abteilung — was auch immer für dein Team Sinn ergibt. Die Trennlinie verläuft um die **Organisation**, nicht um den Workspace. Daten einer Organisation sind strikt von denen jeder anderen Organisation getrennt. **Innerhalb** einer Organisation gilt das nicht: Wer Mitglied der Organisation ist, sieht **alle** ihre Workspaces — eine Einladung je Workspace gibt es nicht, Einladungen gelten immer für die ganze Organisation. Eine frühere Fassung dieses Kastens versprach das Gegenteil („kann nichts in Workspace B sehen, es sei denn, er wird explizit eingeladen"); das war falsch. ## 2. Case Ein **Case** ist die atomare Wissenseinheit in FTS. Jeder Case hat: * Einen **Titel**. Ein eigenes Zusammenfassungsfeld gibt es nicht * Drei Textfelder — **Beobachtung / Symptome**, **Ursache** und **Lösung**. Pflicht ist nur das erste. Es sind **einfache Textfelder, kein Rich-Text**: Markdown wird nicht gerendert, Code-Blöcke, Tabellen und eingebettete Bilder gibt es nicht. Bilder hängen Sie stattdessen als Nachweis an * Einen **Schweregrad** und eine **Kategorie** aus der Taxonomie * Einen **Zustand** (`Draft`, `In Review`, `Verified`, `Published`, `Deprecated`) * **Tags** aus einer Liste, die die **ganze Organisation** teilt — hier stand bis zum 06.08.2026 „aus der Workspace-Taxonomie"; eine Taxonomie je Arbeitsbereich gibt es nicht (`TaxonomyConfig` ist auf die Organisation geschlüsselt, `model Tag` trägt überhaupt keine Zuordnung) * Angehängte **Evidence** * Ein vollständiges **Audit-Trail** (wer hat wann was gemacht) * Optionale **Verlinkungen** zu anderen Cases (für Muster, Abhängigkeiten, Follow-ups) Die Löschfunktion löscht einen Fall nicht wirklich: sie setzt seinen Status auf **„Archiviert"**, er bleibt lesbar und sein Verlauf bleibt vollständig. **Eine Verschiebe-Funktion gibt es nicht** — ein Fall lässt sich nicht in einen anderen Arbeitsbereich verschieben, und „Archiviert" ist kein dritter Zustand neben dem Enum-Wert `DEPRECATED`, sondern genau dieser unter seinem deutschen Namen. Das ist kritisch für regulierte Branchen und für langfristige Wissensbewahrung. ## 3. Evidence **Evidence** ist eine Datei, die an einen Case gehängt wird und die Behauptungen darin stützt. Angenommen werden genau zwei Arten: **Bilder** (JPEG, PNG, GIF, WebP) bis 5 MB und **PDFs** bis 20 MB — ein CAD-Screenshot oder ein eingescannter Bericht geht also, ein Video oder eine Tabellendatei nicht. Evidence wird in einem sicheren EU-gehosteten Object-Store gespeichert und per Referenz an den Case gebunden, nicht eingebettet — damit der Case-Datensatz schlank und schnell bleibt. Ab dem Tarif Team führt FTS automatisch OCR auf Bild- und PDF-Evidence aus, und du kannst den erkannten Text am Nachweis selbst lesen. **Durchsuchbar ist er nicht.** Eine frühere Fassung dieser Seite sagte, der extrahierte Text werde neben dem Case-Body indexiert und man könne nach einem Wort suchen, das nur auf einem Foto einer handschriftlichen Notiz stand — beides trifft nicht zu. Der Volltext-Index besteht aus genau vier Feldern (Titel, Beobachtung, Ursache, Lösung), und der Text hinter der semantischen Suche ergänzt diese vier nur um Kategorie, Schweregrad und Tags. Wer einen Fall über etwas wiederfinden will, das nur im Bild steht, schreibt es in den Fließtext des Falls. ## 4. Review-Workflow Cases durchlaufen einen leichtgewichtigen, aber strikten Review, bevor sie zur „Wahrheit" werden: ``` Draft → In Review → Verified → Published → (Deprecated) ``` Die fünf Namen oben sind die Werte aus `enum CaseStatus`. In der deutschen Oberfläche heißen sie **„Entwurf"**, **„In Prüfung"**, **„Verifiziert"**, **„Veröffentlicht"** und **„Archiviert"** — genau so stehen sie im Statusfilter. * **„Entwurf"** ist, wo du schreibst. **Allein bist du dabei nicht:** ein Entwurf ist für jedes Mitglied deiner Organisation sichtbar und über die Suche auffindbar. Eine Sichtbarkeitseinstellung je Fall gibt es nicht. * **„In Prüfung"** heißt, der Fall liegt zur Prüfung vor. **Bearbeiten blockiert dieser Status nicht** — kein Status tut das. Wer speichert, setzt den Fall auf „Entwurf" zurück, und er muss erneut geprüft werden. * **„Verifiziert"** heißt, dass ein zweites Augenpaar die Fakten bestätigt hat. * **„Veröffentlicht"** ist die freigegebene, kanonische Fassung. Sichtbar war der Fall auch vorher schon; was dieser Status ändert, ist die Verbindlichkeit. * **„Archiviert"** ist, wie du einen Fall außer Dienst stellst, ohne ihn zu löschen. Er verschwindet aus Liste und Suche und bleibt im Verlauf erhalten. Jeder Statusübergang wird mit Zeitstempel und verantwortlichem User im Audit-Log festgehalten. ## 5. Taxonomy Eine **Taxonomy** ist das strukturierte Vokabular, das deine Organisation zur Klassifikation von Cases nutzt. Es besteht aus genau drei Listen, und alle Workspaces der Organisation teilen sie sich: * **Arbeitsbereichstypen** — wofür ein Workspace steht (`testbed`, `production_line`, `lab`, `field`) * **Schweregrade** — wie schwerwiegend der Case ist (`critical`, `high`, `medium`, `low`) * **Kategorien** — die Art des Problems (`hardware`, `software`, `process`, `configuration`, `other`) Admins bearbeiten diese drei Listen unter **Einstellungen → Taxonomie-Konfiguration** — das setzt zusätzlich den Tarif **Team** oder **Enterprise** voraus; im Starter-Tarif gelten die oben genannten mitgelieferten Werte. **Sie fügen Werte hinzu und entfernen sie. Umbenennen, Zusammenführen und Zurückziehen gibt es nicht.** Eine frühere Fassung dieser Seite nannte vier Dimensionen — Bauteil, Fehlermode, Standort und Severity — und versprach, dass das Umbenennen eines Tags jeden Case aktualisiert, der es verwendet. Beides trifft nicht zu. Wird ein Wert aus einer Liste entfernt, ändert das nichts an Cases, die ihn bereits tragen: Der gespeicherte Wert bleibt unverändert stehen und wird lediglich nicht mehr zur Auswahl angeboten. Tags sind eine getrennte, flache Liste und lassen sich ebenfalls nicht umbenennen — ein Tag wird jeweils einem einzelnen Case hinzugefügt oder von ihm entfernt. ## 6. Rollen und Berechtigungen FTS nutzt drei Rollen, und sie hängen an der Organisation: | Rolle | Darf | | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Operator** | Eigene Cases anlegen und bearbeiten, Evidence anhängen, Cases zum Review schicken. | | **Reviewer** | Alles was ein Operator darf, plus jeden Case der Organisation entscheiden — **Verifizieren ✓** oder **Änderungen anfordern**. Ein „Reject" gibt es nicht. | | **Admin** | Alles was ein Reviewer darf, plus Mitglieder, Taxonomy, Vorlagen und Einstellungen verwalten. | Rollen gelten **je Organisation**, nicht je Workspace: eine Person hat genau eine Rolle, und die gilt in jedem Workspace dieser Organisation. Jemand kann also **nicht** in einem Workspace Admin und in einem anderen nur Operator sein. ## Wie alles zusammenpasst ``` Organisation (dein Unternehmen, Abrechnung) └─ Workspace (Projekt/Team/Standort) ├─ Mitglieder (mit Rollen) ├─ Taxonomy (Tags) └─ Cases ├─ Body + Status ├─ Evidence ├─ Tags ├─ Reviews └─ Audit-Log ``` Sobald du dieses mentale Modell hast, ist der Rest des Produkts nur Werkzeug, um jede dieser Dinge schneller, sauberer und sicherer zu machen. Spiele einen echten Fehlerbericht Schritt für Schritt durch.