diff --git a/DATENMODELL.md b/DATENMODELL.md
new file mode 100644
index 0000000..1c03903
--- /dev/null
+++ b/DATENMODELL.md
@@ -0,0 +1,124 @@
+# Datenmodell & Struktur
+
+## Entity-Relationship-Modell (ERM)
+
+Das Datenmodell basiert auf vier Hauptentitäten: `User`, `Ticket`, `Room` und `Comment`.
+
+```mermaid
+erDiagram
+    USER ||--o{ TICKET : "erstellt / own"
+    USER ||--o{ COMMENT : "verfasst"
+    USER }|--|{ ROOM : "betreut (supervises)"
+    ROOM ||--o{ TICKET : "beinhaltet"
+    TICKET ||--o{ COMMENT : "hat"
+
+    USER {
+        Long id PK
+        String email
+        String password
+        String role
+        String firstname
+        String lastname
+        String theme
+    }
+
+    ROOM {
+        Long id PK
+        String name
+    }
+
+    TICKET {
+        Long id PK
+        String title_de
+        String title_en
+        String description_de
+        String description_en
+        String status
+        LocalDateTime createdAt
+        Long user_id FK
+        Long room_id FK
+    }
+
+    COMMENT {
+        Long id PK
+        String text
+        LocalDateTime createdAt
+        Long user_id FK
+        Long ticket_id FK
+    }
+```
+
+### Beziehungen Erklärung
+1.  **User - Ticket (1:N)**: Ein Benutzer kann viele Tickets erstellen. Ein Ticket gehört immer genau einem Benutzer (Ersteller).
+2.  **User - Comment (1:N)**: Ein Benutzer kann viele Kommentare verfassen.
+3.  **User - Room (N:M)**: Ein Benutzer (z.B. Raumbetreuer) kann für mehrere Räume zuständig sein. Ein Raum kann von mehreren Benutzern betreut werden. Diese Beziehung wird über eine Join-Tabelle `user_rooms` abgebildet.
+4.  **Room - Ticket (1:N)**: Ein Ticket bezieht sich immer auf einen spezifischen Raum. In einem Raum können viele Tickets gemeldet werden.
+5.  **Ticket - Comment (1:N)**: Ein Ticket kann mehrere Kommentare enthalten (Diskussionsverlauf).
+
+---
+
+## Klassendiagramm (Backend Entitäten)
+
+Die Implementierung im Spring Boot Backend (`de.itsolutions.ticketsystem.entity`) spiegelt das ERM wider.
+
+```mermaid
+classDiagram
+    class User {
+        -Long id
+        -String name_firstname
+        -String name_lastname
+        -String email
+        -String password
+        -String role
+        -String theme
+        -List~Room~ supervisedRooms
+        +getId()
+        +getName()
+        +getEmail()
+        +getRole()
+    }
+
+    class Ticket {
+        -Long id
+        -String title_de
+        -String title_en
+        -String description_de
+        -String description_en
+        -String status
+        -LocalDateTime createdAt
+        -User owner
+        -Room room
+        +getTitle()
+        +getDescription()
+        +getStatus()
+        +getOwner()
+    }
+
+    class Room {
+        -Long id
+        -String name
+        +getId()
+        +getName()
+    }
+
+    class Comment {
+        -Long id
+        -String text
+        -LocalDateTime createdAt
+        -User author
+        -Ticket ticket
+        +getText()
+        +getAuthor()
+    }
+
+    User "1" --> "*" Ticket : owner
+    User "1" --> "*" Comment : author
+    User "*" --> "*" Room : supervisedRooms
+    Room "1" --> "*" Ticket : room
+    Ticket "1" --> "*" Comment : comments
+```
+
+### Anmerkungen zur Implementierung
+*   **Mehrsprachigkeit**: Die Entität `Ticket` speichert Titel und Beschreibung sowohl in Deutsch (`_de`) als auch in Englisch (`_en`), um Mehrsprachigkeit direkt auf Datenbankebene zu unterstützen.
+*   **Sicherheit**: Das Passwort im `User` Objekt wird gehasht gespeichert (BCrypt).
+*   **Zeitstempel**: `createdAt` Felder werden automatisch bei der Instanziierung (`LocalDateTime.now()`) gesetzt.
diff --git a/SYSTEM_UEBERSICHT.md b/SYSTEM_UEBERSICHT.md
new file mode 100644
index 0000000..0e64fa8
--- /dev/null
+++ b/SYSTEM_UEBERSICHT.md
@@ -0,0 +1,52 @@
+# Systemübersicht & Verwendete Technologien
+
+## Frontend
+Das Frontend wurde als moderne Single-Page-Application (SPA) entwickelt und setzt auf folgende Technologien:
+
+*   **Framework**: Next.js 16 (React 19)
+    *   Sprache: TypeScript
+    *   Routing: App Router
+*   **Styling**: Tailwind CSS
+    *   Komponentenbibliothek: Shadcn UI (basiert auf Radix UI)
+    *   Icons: Lucide React
+*   **State & Form Management**:
+    *   React Hook Form (Formularvalidierung)
+    *   Zod (Schema-Validierung)
+*   **Authentifizierung**: NextAuth.js
+*   **Visualisierung**: Recharts (Diagramme)
+*   **Datum/Zeit**: Date-fns
+
+## Backend
+Das Backend ist als RESTful API konzipiert und basiert auf dem Spring Boot Framework:
+
+*   **Framework**: Spring Boot 3.2.2
+    *   Sprache: Java 21
+*   **Sicherheit**: Spring Security (JWT / Session Handling, CORS Konfiguration)
+*   **Datenbankzugriff**: Spring Data JPA (Hibernate)
+*   **Tools**: Lombok (zur Reduzierung von Boilerplate-Code)
+*   **Build Tool**: Maven
+
+## Datenbank
+Als Datenbank kommt ein relationales Datenbankmanagementsystem zum Einsatz:
+
+*   **System**: PostgreSQL 16 (Betrieb via Docker)
+*   **Name**: `ticketsystem`
+*   **Verbindung**: JDBC
+
+## Probleme & Lösungen
+
+### CORS (Cross-Origin Resource Sharing)
+Ein wesentliches Problem während der Entwicklung war die CORS-Konfiguration (`Cross-Origin Resource Sharing`).
+
+*   **Problem**: Da Frontend (z.B. `localhost:3000`) und Backend (z.B. `localhost:8080` oder Docker-Netzwerk) auf unterschiedlichen Origins laufen, blockierten Browser standardmäßig die API-Anfragen des Frontends aus Sicherheitsgründen.
+*   **Lösung**: Implementierung einer globalen CORS-Konfiguration im Backend (`SecurityConfig.java`).
+    *   Es wurde eine `CorsConfigurationSource` definiert.
+    *   Explizite Freigabe der erlaubten Origins:
+        *   `http://localhost:3000` (Lokale Entwicklung)
+        *   `https://projekt.lona-development.org` (Produktion Frontend)
+        *   `https://projektbackend.lona-development.org` (Produktion Backend)
+    *   Erlaubte HTTP-Methoden: `GET`, `POST`, `PUT`, `PATCH`, `DELETE`, `OPTIONS`.
+    *   Credentials (`setAllowCredentials(true)`) wurden aktiviert, um Authentifizierungs-Cookies/Header zuzulassen.
+
+### Weitere Herausforderungen
+*   **Docker Networking**: Konfiguration der Kommunikation zwischen Frontend- und Backend-Containern über das interne Docker-Netzwerk (`ticketsystem-network`), während das Frontend teilweise auch clientseitig (im Browser des Users) auf die API zugreifen muss. Die Lösung bestand darin, Umgebungsvariablen für API-URLs flexibel zu gestalten (`NEXT_PUBLIC_API_URL`).