diff --git a/diagrams/04_use_case_diagram.md b/diagrams/04_use_case_diagram.md
index 5bb386c..530f8f6 100644
--- a/diagrams/04_use_case_diagram.md
+++ b/diagrams/04_use_case_diagram.md
@@ -57,19 +57,19 @@ flowchart LR
     User --> UC13
 
     style User fill:#ff5a00,color:#fff,stroke:#333
-    style UC1 fill:#e0f2fe,stroke:#0284c7
-    style UC2 fill:#e0f2fe,stroke:#0284c7
-    style UC3 fill:#e0f2fe,stroke:#0284c7
-    style UC4 fill:#fef3c7,stroke:#d97706
-    style UC5 fill:#fef3c7,stroke:#d97706
-    style UC6 fill:#fef3c7,stroke:#d97706
-    style UC7 fill:#fef3c7,stroke:#d97706
-    style UC8 fill:#dcfce7,stroke:#16a34a
-    style UC9 fill:#dcfce7,stroke:#16a34a
-    style UC10 fill:#fce7f3,stroke:#db2777
-    style UC11 fill:#fce7f3,stroke:#db2777
-    style UC12 fill:#fce7f3,stroke:#db2777
-    style UC13 fill:#f3e8ff,stroke:#9333ea
+    style UC1 fill:#e0f2fe,color:#000,stroke:#000000
+    style UC2 fill:#e0f2fe,color:#000,stroke:#000000
+    style UC3 fill:#e0f2fe,color:#000,stroke:#000000
+    style UC4 fill:#fef3c7,color:#000,stroke:#000000
+    style UC5 fill:#fef3c7,color:#000,stroke:#000000
+    style UC6 fill:#fef3c7,color:#000,stroke:#000000
+    style UC7 fill:#fef3c7,color:#000,stroke:#000000
+    style UC8 fill:#dcfce7,color:#000,stroke:#000000
+    style UC9 fill:#dcfce7,color:#000,stroke:#000000
+    style UC10 fill:#fce7f3,color:#000,stroke:#000000
+    style UC11 fill:#fce7f3,color:#000,stroke:#000000
+    style UC12 fill:#fce7f3,color:#000,stroke:#000000
+    style UC13 fill:#f3e8ff,color:#000,stroke:#000000
 ```
 
 ---
@@ -99,22 +99,22 @@ flowchart TB
     R1 -->|"timeout"| R3([Return Pending Status])
     UC9 -->|"«include»"| V4
 
-    style UC8 fill:#dcfce7,stroke:#16a34a
-    style UC9 fill:#dcfce7,stroke:#16a34a
-    style V1 fill:#f1f5f9,stroke:#64748b
-    style V2 fill:#f1f5f9,stroke:#64748b
-    style V3 fill:#f1f5f9,stroke:#64748b
-    style V4 fill:#f1f5f9,stroke:#64748b
-    style W1 fill:#fef9c3,stroke:#ca8a04
-    style W2 fill:#fef9c3,stroke:#ca8a04
-    style W3 fill:#fef9c3,stroke:#ca8a04
-    style W4 fill:#fef9c3,stroke:#ca8a04
-    style W5 fill:#fef9c3,stroke:#ca8a04
-    style W6 fill:#fef9c3,stroke:#ca8a04
-    style W7 fill:#fef9c3,stroke:#ca8a04
-    style R1 fill:#f1f5f9,stroke:#64748b
-    style R2 fill:#f1f5f9,stroke:#64748b
-    style R3 fill:#f1f5f9,stroke:#64748b
+    style UC8 fill:#dcfce7,color:#000,stroke:#16a34a
+    style UC9 fill:#dcfce7,color:#000,stroke:#16a34a
+    style V1 fill:#f1f5f9,color:#000,stroke:#64748b
+    style V2 fill:#f1f5f9,color:#000,stroke:#64748b
+    style V3 fill:#f1f5f9,color:#000,stroke:#64748b
+    style V4 fill:#f1f5f9,color:#000,stroke:#64748b
+    style W1 fill:#fef9c3,color:#000,stroke:#ca8a04
+    style W2 fill:#fef9c3,color:#000,stroke:#ca8a04
+    style W3 fill:#fef9c3,color:#000,stroke:#ca8a04
+    style W4 fill:#fef9c3,color:#000,stroke:#ca8a04
+    style W5 fill:#fef9c3,color:#000,stroke:#ca8a04
+    style W6 fill:#fef9c3,color:#000,stroke:#ca8a04
+    style W7 fill:#fef9c3,color:#000,stroke:#ca8a04
+    style R1 fill:#f1f5f9,color:#000,stroke:#64748b
+    style R2 fill:#f1f5f9,color:#000,stroke:#64748b
+    style R3 fill:#f1f5f9,color:#000,stroke:#64748b
 ```
 
 ---
@@ -254,7 +254,7 @@ graph LR
     style Java fill:#f89820,color:#000
     style TS fill:#3178c6,color:#fff
     style CS fill:#68217a,color:#fff
-    style Python fill:#3776ab,color:#fff
-    style Node fill:#339933,color:#fff
+    style Python fill:#3776ab,color:#000
+    style Node fill:#339933,color:#000
     style RB fill:#ff5a00,color:#fff
 ```
diff --git a/diagrams/07_design_patterns.md b/diagrams/07_design_patterns.md
index 8de4597..ef2ad2f 100644
--- a/diagrams/07_design_patterns.md
+++ b/diagrams/07_design_patterns.md
@@ -29,7 +29,9 @@ A comprehensive catalog of all **design patterns**, **architectural patterns**,
 **Location:** `backend/processSubmission/processSubmission.go`
 
 ### What It Does
-Defines a family of algorithms (one per programming language), encapsulates each one, and makes them interchangeable. The `SubmissionService` delegates compilation/preparation to whichever strategy is registered for the requested language.
+Defines a **family of interchangeable algorithms** (one per programming language) and lets the system **select the right one at runtime** based on the user's input. The `SubmissionService` does NOT decide how to compile — it delegates that decision to whichever strategy is registered for the requested language.
+
+> **Key Difference from Factory:** Strategy is about **choosing a behavior at runtime**. Factory is about **constructing objects**. Strategy answers *"How should I compile this?"* — Factory answers *"How do I build the service that compiles?"*
 
 ### Interface
 
@@ -51,17 +53,20 @@ type LanguageStrategy interface {
 | `PythonStrategy` | Python | `python3` (interpreted) | `processSubmission.go` |
 | `NodeStrategy` | Node.js | `node` (interpreted) | `processSubmission.go` |
 
-### How It's Used
+### How It's Used (Runtime Selection)
 
 ```go
-strategy, exists := s.registry.Get(req.Language)  // O(1) lookup
-cmd, args, err := strategy.Prepare(ws, req.SourceCode)
+// At runtime, the user sends language = "python"
+// Strategy Pattern SELECTS the right algorithm:
+strategy, exists := s.registry.Get(req.Language)  // O(1) lookup → PythonStrategy
+cmd, args, err := strategy.Prepare(ws, req.SourceCode)  // Runs PythonStrategy.Prepare()
 results := s.runner.RunBatch(cmd, args, ...)
 ```
 
 ### Why
 - **Open/Closed Principle** — Adding a new language (e.g., Rust) means creating a new struct implementing `LanguageStrategy` and registering it. Zero changes to `ProcessSubmission()`.
 - **Eliminates switch/case** — The old approach used a giant switch block; the Strategy Pattern replaces it with polymorphic dispatch.
+- **Runtime polymorphism** — The same `Prepare()` call behaves differently depending on which strategy was selected.
 
 ---
 
@@ -276,7 +281,11 @@ The `judge` package defines pure data structures with no business logic. It serv
 **Location:** `backend/processSubmission/processSubmission.go`, `backend/auth/`
 
 ### What It Does
-Constructor functions create and configure complex objects:
+Factory functions **construct and wire up objects** with their dependencies. They handle the *creation* step — allocating structs, injecting dependencies, and returning ready-to-use instances.
+
+> **Key Difference from Strategy:** Factory is about **building objects at startup**. Strategy is about **selecting behavior at runtime**. Factory answers *"How do I assemble this service?"* — Strategy answers *"Which algorithm should I run?"*
+
+### All Factories
 
 | Factory | Creates | Configures |
 |---------|---------|-----------|
@@ -286,9 +295,34 @@ Constructor functions create and configure complex objects:
 | `NewUserRepository(db)` | `UserRepository` | Injects database connection |
 | `NewAPIKeyAuthMiddleware(svc)` | `APIKeyAuthMiddleware` | Injects API key service |
 
+### How It's Used (Object Construction)
+
+```go
+// At startup — Factory creates the objects:
+registry := NewDefaultRegistry()                           // Factory builds the registry
+runner := &DefaultRunner{}                                  // Factory builds the runner
+storage := &LocalTempStorageAdapter{BaseDir: "/dev/shm"}    // Factory builds storage
+svc := NewSubmissionService(runner, registry, storage)      // Factory wires everything
+
+// Later at runtime — Strategy selects the algorithm:
+strategy, _ := svc.registry.Get("python")                   // ← This is Strategy, not Factory
+strategy.Prepare(ws, sourceCode)                            // ← Strategy executes
+```
+
+### Factory vs Strategy — Side-by-Side
+
+| Aspect | Factory Pattern | Strategy Pattern |
+|--------|----------------|------------------|
+| **Purpose** | Create & wire objects | Select & execute algorithms |
+| **When** | At startup / initialization | At runtime per request |
+| **Question** | *"How do I build this?"* | *"Which one should I run?"* |
+| **Example** | `NewSubmissionService(...)` | `registry.Get("python")` |
+| **Category** | Creational | Behavioral |
+
 ### Why
 - **Dependency Injection** — All dependencies are passed in explicitly. No hidden globals.
-- **Testability** — In tests, you can pass mock implementations.
+- **Testability** — In tests, you can pass mock implementations (e.g., a mock `BatchRunner` into `NewSubmissionService()`).
+- **Single place for wiring** — All construction logic is centralized in `New*()` functions, not scattered across the codebase.
 
 ---
 
@@ -364,9 +398,9 @@ graph TB
     Repository --> ServiceLayer
     DomainModel --> ProducerConsumer
 
-    style Strategy fill:#ff5a00,color:#fff
-    style Repository fill:#2563eb,color:#fff
-    style ProducerConsumer fill:#16a34a,color:#fff
-    style Singleton fill:#dc2626,color:#fff
-    style Chain fill:#7c3aed,color:#fff
+    style Strategy fill:#ff5a00,color:#000
+    style Repository fill:#2563eb,color:#000
+    style ProducerConsumer fill:#16a34a,color:#000
+    style Singleton fill:#dc2626,color:#000
+    style Chain fill:#7c3aed,color:#000
 ```