diff --git a/src/core/DigitalData.TaskFlow.Application/README.md b/src/core/DigitalData.TaskFlow.Application/README.md
new file mode 100644
index 0000000..d57e531
--- /dev/null
+++ b/src/core/DigitalData.TaskFlow.Application/README.md
@@ -0,0 +1,41 @@
+# DigitalData.TaskFlow.Application
+
+Dieses Projekt enthaelt die Use-Case-Schicht der Anwendung.
+
+## Zweck
+
+Die Application-Schicht orchestriert fachliche Anwendungsfaelle. Sie nimmt Requests entgegen, validiert diese, ruft Domain-nahe Abstraktionen auf und liefert strukturierte Ergebnisse zurueck.
+
+## Aktueller Inhalt
+
+- `DependencyInjection.cs`
+  - Registriert zentrale Application-Dienste:
+    - MediatR
+    - FluentValidation
+    - AutoMapper
+  - Bindet `MediatR`-Optionen inklusive Lizenzschluessel.
+- `Options/`
+  - `MediatROptions`: Konfiguration fuer MediatR (z. B. `LuckyPennySoftLicenseKey`).
+
+## Geplante Inhalte (naechste Phasen)
+
+- `Features/`
+  - Queries/Commands fuer Workflows, Closing und Documents.
+- `Validators/`
+  - FluentValidation-Regeln pro Request.
+- `Common/Behaviors/`
+  - Pipeline-Behavior (z. B. zentrale Request-Validierung).
+- `Common/Interfaces/`
+  - Repository-Abstraktionen fuer Datenzugriff.
+- `Mappings/`
+  - AutoMapper-Profile zwischen Infrastrukturmodellen und Domainmodellen.
+
+## Architektur-Regeln
+
+- Keine direkten SQL- oder EF-Core-Aufrufe.
+- Keine HTTP-spezifischen Controller-Abhaengigkeiten.
+- Kommunikation nach aussen nur ueber Interfaces.
+
+## Rolle im Gesamtsystem
+
+Diese Schicht ist der zentrale Ausfuehrungspunkt fuer Use-Cases und verbindet die API-Schicht mit Domain und Infrastructure, ohne Technologie-Details nach oben durchzureichen.
diff --git a/src/core/DigitalData.TaskFlow.Domain/README.md b/src/core/DigitalData.TaskFlow.Domain/README.md
new file mode 100644
index 0000000..c7a151b
--- /dev/null
+++ b/src/core/DigitalData.TaskFlow.Domain/README.md
@@ -0,0 +1,33 @@
+# DigitalData.TaskFlow.Domain
+
+Dieses Projekt bildet den fachlichen Kern von `DigitalData.TaskFlow`.
+
+## Zweck
+
+Die Domain-Schicht enthaelt ausschließlich fachliche Modelle und Begriffe. Hier wird beschrieben, **was** das System fachlich darstellt, nicht **wie** Daten gelesen/geschrieben werden.
+
+## Aktueller Inhalt
+
+- `Common/`
+  - `ApiEnvelope<T>`: Standard-Response-Huelle mit `Meta` und `Data`.
+  - `MetaEntry`: Einzelner Meta-Eintrag (`Code`, `Message`).
+- `Enums/`
+  - `MetaCode`: Fachliche Status-Codes (z. B. `Ok`, `NoAccess`, `AlreadyClosed`).
+- `Workflows/`
+  - Modelle fuer den Endpoint `GET /workflows/{wisagid}`.
+  - Enthalten Quellblock-Struktur (`SourceBlock`, `FerdinandSourceBlock`, `ContractsSourceBlock`) und Untermodelle (`ProfileItem`, `WorkflowListingItem`, `ApprovalItem`, `DocumentReferenceItem`, `ClosingMethodItem`, `RejectionReasonItem`).
+- `Closing/`
+  - Modelle fuer den Endpoint `POST /workflows/{wisagid}/{source}/{processid}/closing`.
+  - `CloseWorkflowDecision` (Eingabe), `CloseWorkflowResult` (Ergebnis).
+- `Documents/`
+  - `DocumentBinaryResult` fuer den Endpoint `GET /documents/{id}`.
+
+## Architektur-Regeln
+
+- Keine EF-Core-, HTTP-, SQL- oder Infrastruktur-Abhaengigkeiten.
+- Keine Controller- oder Middleware-Logik.
+- Modelle bleiben in PascalCase; technische DB-Namensabweichungen werden spaeter in Infrastructure gemappt.
+
+## Warum diese Schicht wichtig ist
+
+Die Domain stellt eine stabile, technologieunabhaengige Sprache bereit. Dadurch koennen API, Application und Infrastructure getrennt entwickelt werden, ohne den fachlichen Vertrag zu verlieren.
diff --git a/src/infrastructure/DigitalData.TaskFlow.Infrastructure/README.md b/src/infrastructure/DigitalData.TaskFlow.Infrastructure/README.md
new file mode 100644
index 0000000..42c8c94
--- /dev/null
+++ b/src/infrastructure/DigitalData.TaskFlow.Infrastructure/README.md
@@ -0,0 +1,37 @@
+# DigitalData.TaskFlow.Infrastructure
+
+Dieses Projekt implementiert technische Integrationen der Anwendung.
+
+## Zweck
+
+Die Infrastructure-Schicht setzt die in Application definierten Abstraktionen konkret um. Dazu gehoeren Datenbankzugriffe (EF Core, Stored Procedures) und spaeter ggf. DMS- oder externe Service-Anbindungen.
+
+## Aktueller Inhalt
+
+- `DependencyInjection.cs`
+  - Einstiegspunkt fuer die Registrierung technischer Dienste.
+- `Options/`
+  - Platz fuer Infrastruktur-spezifische Optionen (falls benoetigt).
+
+## Geplante Inhalte (naechste Phasen)
+
+- `Persistence/`
+  - `TaskFlowDbContext` mit SQL-Server-Konfiguration.
+  - Entity-Konfigurationen inklusive Feld-Mapping (DB-Namen -> PascalCase-Modelle).
+- `Repositories/`
+  - Implementierungen fuer:
+    - Workflow-Lesezugriff (u. a. `PRCUST_F19_GET_LISTING_DATA`)
+    - Workflow-Closing (Write-Procedure)
+    - Dokument-Binary-Zugriff
+- `Persistence/Models/`
+  - Keyless Modelle fuer Procedure-Ergebnisse.
+
+## Architektur-Regeln
+
+- Keine Controller- oder HTTP-Logik.
+- Keine fachliche Regel-Definition; nur technische Umsetzung.
+- SQL-Zugriff stets parameterisiert und sicher.
+
+## Rolle im Gesamtsystem
+
+Infrastructure kapselt alle externen Abhaengigkeiten. Dadurch bleibt die Application-Schicht testbar und von Technologie-Details entkoppelt.
diff --git a/src/presentation/DigitalData.TaskFlow.API/README.md b/src/presentation/DigitalData.TaskFlow.API/README.md
new file mode 100644
index 0000000..06d3395
--- /dev/null
+++ b/src/presentation/DigitalData.TaskFlow.API/README.md
@@ -0,0 +1,44 @@
+# DigitalData.TaskFlow.API
+
+Dieses Projekt stellt die HTTP-Schnittstelle fuer externe Konsumenten bereit.
+
+## Zweck
+
+Die API-Schicht nimmt HTTP-Requests entgegen, leitet diese an die Application-Schicht weiter und liefert standardisierte Responses zurueck.
+
+## Aktueller Inhalt
+
+- `Program.cs`
+  - Startpunkt der ASP.NET-Core-Anwendung.
+  - Registriert Application- und Infrastructure-Dienste.
+  - Enthält Grundkonfiguration fuer Controller und OpenAPI/Swagger.
+- `appsettings.json`
+  - Allgemeine Runtime-Konfiguration (Logging, ConnectionString, MediatR-Lizenz, Swagger-Optionen).
+- `Controllers/`
+  - Zielordner fuer HTTP-Controller (aktuell noch leer).
+- `Options/`
+  - API-spezifische Konfigurationsmodelle (z. B. `SwaggerOptions`).
+
+## Geplante Inhalte (naechste Phasen)
+
+- Controller fuer:
+  - `GET /workflows/{wisagid}`
+  - `POST /workflows/{wisagid}/{source}/{processid}/closing`
+  - `GET /documents/{id}`
+- Middleware fuer:
+  - FluentValidation-Fehlerbehandlung
+  - Generelle Exception-Behandlung
+- OpenAPI-Dokumentation:
+  - Swagger in Development, optional in Production
+  - Firmen-/Produkt-Metadaten
+  - Scalar als alternative UI
+
+## Architektur-Regeln
+
+- Keine direkte SQL- oder EF-Core-Logik im Controller.
+- Transport-spezifische Aufgaben bleiben in API; fachliche Verarbeitung erfolgt in Application.
+- Einheitliches Response-Schema gemaess Ticket-Vorgabe (`meta.code`, `meta.message`).
+
+## Rolle im Gesamtsystem
+
+Die API ist das Eingangstor fuer externe Systeme (z. B. fabrik19) und sorgt fuer stabile, versionierbare und gut dokumentierte Endpunkte.