feat: complete book project — Riset Teknologi Informasi

Content: - 16 chapters (book/) across 4 Bagian - 32 diagram assets (assets/diagrams/) - Front/back matter (halaman judul, daftar isi/gambar/tabel, pustaka, glosarium, indeks, lampiran, tentang penulis) - 16 worksheets, 16 templates - Discussion modules (docs/) - BLUEPRINT, BOOK-SPEC, MASTER-ANCHOR, REFERENCES, PROJECT-TRACKER
2026-03-31 08:32:55 +07:00 · 2026-03-31 08:32:55 +07:00 · e1a89375cc
commit e1a89375cc
88 changed files with 46175 additions and 0 deletions
--- a/.gitignore
+++ b/.gitignore
@ -0,0 +1,5 @@
+# IDE / OS
+*.code-workspace
+.vscode/
+Thumbs.db
+.DS_Store
--- a/BLUEPRINT.md
+++ b/BLUEPRINT.md
@ -0,0 +1,402 @@
+# BLUEPRINT KONSOLIDASI — SELURUH BAB (M1–M16)
+
+> Dokumen ini merangkum blueprint setiap bab secara ringkas.
+> Gunakan sebagai peta navigasi saat menulis.
+> Detail lengkap ada di `docs/disscus04.md`.
+
+---
+
+## BAGIAN I — FOUNDATION (Thinking Phase)
+
+---
+
+### BAB 1 — Etika Penelitian, Validitas, dan Paradigma (M1)
+
+**CPMK:** CPMK01 | **CPL:** CPL03 | **Sub-CPMK:** 1.1
+
+**Signature Model:** Research Trust Model
+```
+Reality → Data → Processing → Analysis → Inference → Knowledge
+(setiap tahap membawa risiko distorsi; etika mengendalikan distorsi)
+```
+
+**Konsep Inti:**
+- Etika = penjaga validitas ilmiah (bukan sekadar moral)
+- Validitas: internal, external, construct
+- Research vs Engineering Validation
+- Kriteria kebenaran ilmiah
+- Paradigma: positivism, interpretivism, pragmatism
+- Posisi MK: positivist + design science
+
+**Case Study:**
+1. Basic: Manipulasi dataset ML — akurasi tinggi tapi data palsu
+2. Advanced: AI bias — model terlihat bagus tapi bias tersembunyi
+
+**Cognitive Traps:**
+1. "Angka tinggi = benar"
+2. "Data netral"
+3. "Jika jalan, maka benar"
+4. "Kegagalan tidak perlu dilaporkan"
+
+**Final Statement:**
+> "Penelitian bukan tentang mendapatkan hasil, tetapi tentang memastikan hasil tersebut dapat dipercaya."
+
+**Output Praktis:** Esai analisis kasus etika + posisi paradigma
+
+---
+
+### BAB 2 — Problem Formulation & System Context (M2)
+
+**CPMK:** CPMK01 | **CPL:** CPL03 | **Sub-CPMK:** 1.2
+
+**Signature Model:** Problem Formation Model + Problem Quality Model
+```
+Reality → Observed Issue (Symptom) → Diagnosed Problem → Researchable Problem → Measurable Variable
+
+Clarity → Measurability → Relevance → Testability → Impact
+```
+
+**Konsep Inti:**
+- Topic vs Problem vs Research Problem (hierarki)
+- Symptom vs Problem (akar masalah)
+- System thinking: Input→Process→Output→Outcome + Constraints + Stakeholders
+- Problem → Variable → Metric (transformasi)
+- 5 Kriteria: Specific, Measurable, Relevant, Testable, Real-world
+
+**Case Study:**
+1. Basic: Rekomendasi film — akurasi tinggi tapi user tidak puas
+2. Advanced: Fraud detection — 98% akurasi tapi fraud lolos (imbalance)
+
+**Cognitive Traps:**
+1. "Saya ingin menggunakan metode X"
+2. "Semakin kompleks semakin bagus"
+3. "Problem tidak perlu diukur"
+4. "Semua problem bisa diteliti"
+
+**Final Statement:**
+> "Penelitian tidak dimulai dari solusi, tetapi dari masalah yang dipahami secara mendalam dan dapat diuji secara ilmiah."
+
+**Output Praktis:** Problem statement (spesifik, measurable, konteks sistem)
+
+---
+
+### BAB 3 — Literature Review, Research Gap & Baseline (M3)
+
+**CPMK:** CPMK01 | **CPL:** CPL03 | **Sub-CPMK:** 1.3
+
+**Signature Model:** Research Positioning Model
+```
+Existing Studies → Method Comparison → Limitation Identification → Research Gap → Research Position → Contribution
+```
+
+**Konsep Inti:**
+- Literature review = positioning, bukan ringkasan
+- 4 jenis gap: Performance, Method, Data, Context
+- Baseline: relevan, representatif, state-of-the-art
+- Gap → RQ → Hypothesis → Experiment (bridge)
+- Strategi pencarian: IEEE, ACM, Scopus, boolean query
+
+**Case Study:**
+1. Basic: Image classification — banyak paper, gap tidak jelas
+2. Advanced: Deteksi penyakit — baseline lemah, kontribusi diragukan
+
+**Cognitive Traps:**
+1. "Semakin banyak referensi, semakin bagus"
+2. "Belum ada = gap"
+3. "Tidak perlu baseline"
+
+**Final Statement:**
+> "Literature review bukan tentang apa yang sudah diketahui, tetapi tentang apa yang belum diselesaikan dan bagaimana Anda mengisinya."
+
+**Output Praktis:** Tabel literatur + gap statement + baseline selection
+
+---
+
+### BAB 4 — Research Question, Contribution & Hypothesis (M4)
+
+**CPMK:** CPMK01 | **CPL:** CPL03 | **Sub-CPMK:** 1.4
+
+**Signature Model:** RQ Formation Model
+```
+Problem → Research Gap → Research Question → Hypothesis → Experiment Design
+```
+
+**Konsep Inti:**
+- RQ = instrumen pengarah eksperimen
+- 3 jenis RQ: Comparison, Improvement, Exploratory
+- Contribution: improvement, comparison, novel approach
+- Hypothesis: H0 (null) + H1 (alternative) — harus testable
+- RQ → Variable → Metric → Data → Analysis
+
+**Case Study:**
+1. Basic: RQ terlalu umum → tidak bisa diuji
+2. Advanced: RQ tanpa baseline → tidak ada pembanding
+
+**Cognitive Traps:**
+1. "RQ = judul dalam bentuk tanya"
+2. "RQ tidak perlu metric"
+3. "RQ bisa dijawab tanpa eksperimen"
+
+**Final Statement:**
+> "Research Question bukan sekadar pertanyaan, tetapi blueprint dari eksperimen yang akan dilakukan."
+
+**Output Praktis:** RQ (clear & testable) + contribution statement + hypothesis (H0/H1)
+
+---
+
+## BAGIAN II — MEASUREMENT & DESIGN (Designing Phase)
+
+---
+
+### BAB 5 — Metric, Measurement & Data (M5)
+
+**CPMK:** CPMK02 | **CPL:** CPL06 | **Sub-CPMK:** 2.1
+
+**Signature Model:** Measurement Alignment Model
+```
+Problem → Concept → Variable → Metric → Data → Result
+```
+
+**Konsep Inti:**
+- Concept → Metric (operationalization)
+- Jenis data: nominal, ordinal, interval, ratio
+- Metric selection: sesuai problem, representatif, sensitif
+- Multi-metric evaluation
+- Data quality: completeness, consistency, validity, representativeness
+
+**Case Study:**
+1. Basic: Accuracy tinggi, dataset imbalance → metric menipu
+2. Advanced: User satisfaction vs system metric → metric teknis ≠ user experience
+
+**Final Statement:**
+> "Penelitian yang baik bukan hanya mengukur, tetapi memastikan bahwa apa yang diukur benar-benar merepresentasikan realitas."
+
+**Output Praktis:** Definisi variabel + metrik + tipe data + justifikasi
+
+---
+
+### BAB 6 — System Design sebagai Experimental Artifact (M6)
+
+**CPMK:** CPMK02 | **CPL:** CPL06 | **Sub-CPMK:** 2.2
+
+**Signature Model:** System as Experiment Model
+```
+Research Question → Variable → System Component → Experimental Setup → Output (measured)
+```
+
+**Konsep Inti:**
+- Sistem bukan tujuan → alat uji hipotesis
+- Mapping RQ → system component
+- 4 prinsip: Traceability, Modularity, Controllability, Measurability
+- Control & isolation variabel
+
+**Case Study:**
+1. Basic: Model ML tidak bisa diuji (monolith, tidak modular)
+2. Advanced: Multiple feature change, no clear impact
+
+**Final Statement:**
+> "Dalam penelitian, sistem bukan dibangun untuk digunakan, tetapi untuk membuktikan sesuatu secara ilmiah."
+
+**Output Praktis:** Diagram arsitektur + mapping ke variabel eksperimen
+
+---
+
+### BAB 7 — Experimental Design & Validity (M7)
+
+**CPMK:** CPMK02 | **CPL:** CPL06 | **Sub-CPMK:** 2.3
+
+**Signature Model:** Experimental Validity Model
+```
+RQ → Hypothesis → Variable Design → Controlled Experiment → Data → Analysis → Conclusion (Validity Level)
+```
+
+**Konsep Inti:**
+- Eksperimen = menguji hubungan sebab-akibat (causality)
+- Korelasi ≠ kausalitas
+- 4 validitas: internal, external, construct, conclusion
+- Jenis eksperimen: comparison, ablation study, parameter study
+- Controlled experiment: ubah 1, kontrol sisanya
+
+**Case Study:**
+1. Basic: Eksperimen tanpa kontrol → semua variabel berubah
+2. Advanced: Baseline tidak fair → perbandingan bias
+
+**Final Statement:**
+> "Eksperimen bukan sekadar menjalankan sistem, tetapi membangun bukti yang dapat dipercaya."
+
+**Output Praktis:** Dokumen desain eksperimen lengkap (variabel, skenario, validity, baseline)
+
+---
+
+## BAGIAN III — EXECUTION (Executing Phase)
+
+---
+
+### BAB 8 — Proposal & Checkpoint / UTS
+
+**Catatan:** Bab ini bersifat integratif — merangkum Bab 1–7 ke dalam proposal.
+Konten utama: template proposal + rubrik penilaian + tips defense.
+
+---
+
+### BAB 9 — Implementation & Environment (M9)
+
+**CPMK:** CPMK03 | **CPL:** CPL06 | **Sub-CPMK:** 3.1
+
+**Signature Model:** Reproducible Implementation Model
+```
+Experiment Design → Implementation → Environment Setup → Execution Consistency → Reproducibility → Trustworthy Result
+```
+
+**Konsep Inti:**
+- Implementasi ≠ coding biasa → memastikan konsistensi & reproducibility
+- Environment control: hardware, software, dependency, OS
+- Repeatability vs Reproducibility
+- Dokumentasi wajib: setup, parameter, dataset
+- Best practice: version control, config logging, environment isolation
+
+**Output Praktis:** Dokumentasi setup + README eksperimen
+
+---
+
+### BAB 10 — Experiment Execution & Data Collection (M10)
+
+**CPMK:** CPMK03 | **CPL:** CPL06 | **Sub-CPMK:** 3.2
+
+**Signature Model:** Experiment Execution Pipeline
+```
+Design → Execution Plan → Controlled Execution → Data Collection → Data Logging → Dataset for Analysis
+```
+
+**Konsep Inti:**
+- Execution plan: skenario, jumlah run, variasi parameter
+- Multiple run wajib (bukan single run)
+- Data logging: ID, timestamp, parameter, result, environment
+- Konsistensi eksekusi
+
+**Output Praktis:** Log eksperimen + dataset mentah
+
+---
+
+### BAB 11 — Data Validation & Integrity (M11)
+
+**CPMK:** CPMK03 | **CPL:** CPL06 | **Sub-CPMK:** 3.3
+
+**Signature Model:** Data Trust Model
+```
+Raw Data → Data Cleaning → Consistency Check → Validation → Trusted Data → Analysis Ready
+```
+
+**Konsep Inti:**
+- 4 pilar data quality: accuracy, consistency, completeness, validity
+- Validation process: format → range → consistency → logic
+- Anomaly detection: outlier, missing, inconsistency
+- Data vs experiment alignment
+
+**Output Praktis:** Dataset tervalidasi + catatan anomali
+
+---
+
+## BAGIAN IV — ANALYSIS & SCIENTIFIC COMMUNICATION
+
+---
+
+### BAB 12 — Result Presentation & Visualization (M12)
+
+**CPMK:** CPMK04 | **CPL:** CPL03 | **Sub-CPMK:** 4.1
+
+**Signature Model:** Data → Insight Model
+```
+Validated Data → Structured Presentation → Visualization → Pattern Recognition → Insight
+```
+
+**Konsep Inti:**
+- Tabel (presisi) vs grafik (insight)
+- Mapping: tujuan → jenis visualisasi
+- Multi-metric presentation
+- Visualization bias: scale manipulation, selective data, misleading
+
+**Output Praktis:** Tabel + grafik + observasi awal
+
+---
+
+### BAB 13 — Data Preprocessing (M13)
+
+**CPMK:** CPMK04 | **CPL:** CPL03 | **Sub-CPMK:** 4.2
+
+**Signature Model:** Data Refinement Pipeline
+```
+Raw Data → Cleaning → Transformation → Normalization → Processed Data → Analysis Ready
+```
+
+**Konsep Inti:**
+- Cleaning: missing values, duplicates, errors
+- Transformation: encoding, aggregation, feature creation
+- Normalization & scaling
+- 4 prinsip: consistency, transparency, reproducibility, minimal distortion
+
+**Output Praktis:** Dataset bersih + dokumentasi preprocessing
+
+---
+
+### BAB 14 — Data Analysis, Interpretation & Failure Analysis (M14)
+
+**CPMK:** CPMK04 | **CPL:** CPL03 | **Sub-CPMK:** 4.3
+
+**Signature Model:** Data → Knowledge Model
+```
+Data → Analysis → Interpretation → Explanation → Knowledge
+```
+
+**Konsep Inti:**
+- Analysis vs interpretation ("apa yang terjadi" vs "mengapa terjadi")
+- Link wajib: result → RQ → hypothesis → conclusion
+- Failure analysis: kegagalan = sumber insight
+- Limitation: wajib diakui
+- Statistical + logical reasoning
+
+**Output Praktis:** Hasil analisis + interpretasi + failure analysis + limitation
+
+---
+
+### BAB 15 — Scientific Writing (M15)
+
+**CPMK:** CPMK05 | **CPL:** CPL02 | **Sub-CPMK:** 5.1
+
+**Signature Model:** Scientific Argument Flow
+```
+Problem → Gap → RQ → Method → Result → Analysis → Conclusion → Contribution
+```
+
+**Konsep Inti:**
+- Penulisan = menyusun argumen ilmiah (bukan dokumentasi)
+- IMRAD + extension
+- Logical flow: Why → What → How → Result → So What
+- Konsistensi antar bagian (problem↔RQ↔method↔result↔conclusion)
+- Writing quality: clarity, precision, conciseness, consistency
+
+**Output Praktis:** Laporan ilmiah lengkap (IMRAD)
+
+---
+
+### BAB 16 — Presentation & Defense (M16)
+
+**CPMK:** CPMK06 | **CPL:** CPL02 | **Sub-CPMK:** 6.1
+
+**Signature Model:** Scientific Defense Model
+```
+Research Work → Presentation → Questioning → Defense (Argumentation) → Evaluation → Acceptance
+```
+
+**Konsep Inti:**
+- Presentasi = simulasi peer-review langsung
+- Argumentation: claim + evidence + reasoning
+- Anticipating questions: problem, gap, method, metric, result
+- Handling questions: langsung, data-based, akui keterbatasan
+
+**Output Praktis:** Slide + defense argument + jawaban berbasis data
+
+---
+
+*Dokumen ini merupakan peta navigasi untuk seluruh proses penulisan buku.*
+*Terakhir diperbarui: 30 Maret 2026*
--- a/BOOK-SPEC.md
+++ b/BOOK-SPEC.md
@ -0,0 +1,262 @@
+# SPESIFIKASI BUKU & PANDUAN FORMAT
+
+> Dokumen ini mendefinisikan spesifikasi teknis buku dan standar format penulisan.
+> Semua penulis/kontributor WAJIB mengikuti panduan ini.
+
+---
+
+## 1. IDENTITAS BUKU
+
+| Aspek | Nilai |
+|-------|-------|
+| **Judul** | Riset Teknologi Informasi Berbasis OBE & Experimental Thinking |
+| **Subjudul** | Panduan Praktis Penelitian Eksperimental di Bidang Sistem Informasi |
+| **Kategori** | Buku Ajar / Textbook |
+| **Bahasa** | Bahasa Indonesia (istilah teknis dalam Bahasa Inggris) |
+| **Target Pembaca** | Mahasiswa S1 Teknologi Informasi / Sistem Informasi / Informatika |
+| **Level** | Undergraduate (semester 5–7) |
+| **Gaya** | Semi-formal academic (Academic–Practical Hybrid) |
+
+---
+
+## 2. SPESIFIKASI FISIK
+
+| Aspek | Nilai |
+|-------|-------|
+| **Ukuran** | B5 (17.6 cm × 25 cm) — standar buku ajar Indonesia |
+| **Target halaman** | 250–350 halaman |
+| **Target per bab** | 15–22 halaman (rata-rata ~18 halaman) |
+| **Jumlah bab** | 16 bab + front matter + back matter |
+| **Font body** | Times New Roman 12pt atau Palatino 11pt |
+| **Font heading** | Sans-serif (Calibri/Helvetica) |
+| **Spasi** | 1.5 |
+| **Margin** | Atas: 3cm, Bawah: 2.5cm, Kiri: 3cm, Kanan: 2.5cm |
+
+---
+
+## 3. STRUKTUR BUKU LENGKAP
+
+### FRONT MATTER
+```
+- Halaman judul
+- Halaman hak cipta & ISBN
+- Kata Pengantar
+- Panduan Penggunaan Buku
+- Daftar Isi
+- Daftar Gambar
+- Daftar Tabel
+```
+
+### ISI BUKU
+
+#### BAGIAN I — FOUNDATION (Thinking Phase)
+```
+Bab 1  — Etika Penelitian, Validitas, dan Paradigma
+Bab 2  — Problem Formulation & System Context
+Bab 3  — Literature Review, Research Gap & Baseline
+Bab 4  — Research Question, Contribution & Hypothesis
+```
+
+#### BAGIAN II — MEASUREMENT & DESIGN (Designing Phase)
+```
+Bab 5  — Metric, Measurement & Data
+Bab 6  — System Design sebagai Experimental Artifact
+Bab 7  — Experimental Design & Validity
+```
+
+#### BAGIAN III — EXECUTION (Executing Phase)
+```
+Bab 8  — Proposal & Checkpoint (UTS)
+Bab 9  — Implementation & Environment
+Bab 10 — Experiment Execution & Data Collection
+Bab 11 — Data Validation & Integrity
+```
+
+#### BAGIAN IV — ANALYSIS & SCIENTIFIC COMMUNICATION (Scientific Thinking Phase)
+```
+Bab 12 — Result Presentation & Visualization
+Bab 13 — Data Preprocessing
+Bab 14 — Data Analysis, Interpretation & Failure Analysis
+Bab 15 — Scientific Writing
+Bab 16 — Presentation & Defense
+```
+
+### BACK MATTER
+```
+- Lampiran A: Template Proposal Penelitian
+- Lampiran B: Template Laporan Akhir (IMRAD)
+- Lampiran C: Template Slide Defense
+- Lampiran D: Rubrik Penilaian (14 rubrik + Scientific Reasoning)
+- Lampiran E: Worksheet Mahasiswa (per bab)
+- Glosarium
+- Daftar Pustaka
+- Indeks
+- Tentang Penulis
+```
+
+---
+
+## 4. FORMAT PER BAB (TEMPLATE STRUKTUR)
+
+Setiap bab WAJIB mengikuti struktur berikut (urutan bisa sedikit fleksibel, tapi semua elemen harus ada):
+
+```
+[Nomor Bab]. [JUDUL BAB]
+
+    Ringkasan Bab (1 paragraf — apa yang akan dipelajari)
+
+    [Nomor].1  Pembuka / Narasi Pengantar
+               — Narasi semi-formal yang membangun konteks
+               — Berisi "opening bridge" dari bab sebelumnya
+
+    [Nomor].2  Signature Model
+               — 1 model visual utama bab ini
+               — Penjelasan setiap komponen
+               — Insight kunci
+
+    [Nomor].3  Definisi Kunci
+               — 2–4 definisi formal
+
+    [Nomor].4  Konsep Inti
+               — Deep explanation (bukan sekadar deskripsi)
+               — Subbab sesuai kebutuhan
+
+    [Nomor].5  Research vs Engineering Perspective
+               — Tabel perbandingan
+               — Insight
+
+    [Nomor].6  Research Reality
+               — 2–3 fenomena nyata
+               — Insight per fenomena
+
+    [Nomor].7  Cognitive Traps
+               — 3–4 kesalahan berpikir umum
+               — Penjelasan dan koreksi
+
+    [Nomor].8  Studi Kasus
+               — Case 1 (Basic): bad vs good approach
+               — Case 2 (Advanced): bad vs good approach
+
+    [Nomor].9  Template Praktis
+               — Template siap pakai mahasiswa
+
+    [Nomor].10 Mindmap Ringkasan
+               — Diagram ringkasan seluruh bab
+
+    [Nomor].11 Rangkuman
+               — Poin-poin utama bab
+               — "Closing bridge" ke bab berikutnya
+
+    [Nomor].12 Latihan & Refleksi
+               — 3–5 pertanyaan refleksi
+               — 1–2 latihan praktis
+
+    --- (Metadata internal, tidak dicetak) ---
+    AI-Ready Prompt
+    Final Statement
+```
+
+---
+
+## 5. PANDUAN GAYA PENULISAN
+
+### 5.1 Nada & Suara
+- **Semi-formal**: tidak terlalu kaku, tidak terlalu kasual
+- **Explanatory**: menjelaskan "mengapa", bukan hanya "apa"
+- **Engaging**: gunakan pertanyaan retoris, analogi, contoh nyata
+- **Authoritative**: ada dasar teori, ada referensi
+
+### 5.2 Contoh Nada yang Benar
+```
+❌ Terlalu formal:
+"Penelitian merupakan proses sistematis untuk memperoleh pengetahuan baru
+melalui metode ilmiah yang terstandar."
+
+❌ Terlalu kasual:
+"Jadi intinya, riset itu ya kayak eksperimen gitu lah."
+
+✅ Semi-formal (target):
+"Banyak mahasiswa mengira penelitian dimulai dari solusi.
+Padahal, penelitian selalu dimulai dari masalah yang belum selesai."
+```
+
+### 5.3 Istilah Teknis
+- Gunakan **Bahasa Indonesia** untuk narasi umum
+- Gunakan **Bahasa Inggris** untuk istilah teknis yang sudah umum:
+  - research question, baseline, metric, pipeline, reproducibility, dll.
+- Pada **kemunculan pertama** di setiap bab: tulis terjemahan dalam kurung
+  - Contoh: "validitas internal (*internal validity*)"
+- Konsisten sepanjang buku — gunakan Glosarium sebagai referensi
+
+### 5.4 Sitasi & Referensi
+- Format: **APA 7th Edition**
+- Sitasi dalam teks: (Creswell, 2018) atau Creswell (2018)
+- Setiap bab minimal 3–5 referensi
+- Daftar pustaka di akhir buku (bukan per bab)
+
+### 5.5 Gambar & Tabel
+- Setiap gambar: **Gambar [Bab].[Nomor]** — Caption di bawah
+- Setiap tabel: **Tabel [Bab].[Nomor]** — Caption di atas
+- Semua model signature → harus jadi Gambar (bukan text-based)
+- Mindmap → Gambar di akhir bab
+
+### 5.6 Highlight & Box
+Gunakan box/callout untuk:
+- **💡 Insight**: wawasan penting
+- **⚠️ Perhatian**: kesalahan umum / cognitive trap
+- **📌 Definisi**: definisi formal
+- **🔧 Template**: template praktis
+- **📊 Studi Kasus**: narasi case study
+
+---
+
+## 6. PANDUAN DIAGRAM & VISUAL
+
+### 6.1 Signature Model
+- Format: flowchart vertikal atau horizontal
+- Tool: Draw.io / Figma / Mermaid
+- Warna: konsisten per bagian buku
+  - Bagian I (Foundation): Biru
+  - Bagian II (Design): Hijau
+  - Bagian III (Execution): Orange
+  - Bagian IV (Analysis): Ungu
+- Font dalam diagram: sans-serif, minimal 10pt
+
+### 6.2 Mindmap
+- Format: radial atau tree
+- Maksimal 3 level kedalaman
+- Warna: mengikuti warna bagian
+
+### 6.3 Tabel Perbandingan
+- Selalu gunakan format tabel formal
+- Header: bold
+- Alternating row color (opsional, tergantung layout)
+
+---
+
+## 7. CHECKLIST PER BAB (SEBELUM DIANGGAP SELESAI)
+
+- [ ] Narasi pembuka ada dan kuat (bukan deskriptif)
+- [ ] Signature model ada (sebagai diagram, bukan text)
+- [ ] Definisi kunci lengkap
+- [ ] Konsep inti mendalam (bukan superfisial)
+- [ ] Research vs Engineering ada
+- [ ] Research Reality (2–3 fenomena)
+- [ ] Cognitive Traps (3–4 trap)
+- [ ] Case Study Basic (bad vs good)
+- [ ] Case Study Advanced (bad vs good)
+- [ ] Template praktis ada
+- [ ] Mindmap ada
+- [ ] Rangkuman ada
+- [ ] Latihan & refleksi ada
+- [ ] Opening bridge (dari bab sebelumnya)
+- [ ] Closing bridge (ke bab berikutnya)
+- [ ] Sitasi minimal 3–5 referensi
+- [ ] Lulus 3 Quality Gates (lihat Master Anchor)
+- [ ] Konsisten dengan Master Anchor
+- [ ] Istilah konsisten dengan Glosarium
+
+---
+
+*Dokumen ini berlaku untuk seluruh proses penulisan buku.*
+*Terakhir diperbarui: 30 Maret 2026*
--- a/21
+++ b/21
@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 mhbahara
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
--- a/MASTER-ANCHOR.md
+++ b/MASTER-ANCHOR.md
@ -0,0 +1,204 @@
+# MASTER ANCHOR — Buku Ajar Riset Teknologi Informasi
+
+> **Dokumen ini adalah referensi utama anti-drift.**
+> Baca sebelum menulis setiap bab. Validasi setiap konten terhadap dokumen ini.
+> Jika konten tidak lulus validasi → revisi atau buang.
+
+---
+
+## 1. IDENTITAS MATA KULIAH
+
+| Aspek | Nilai |
+|-------|-------|
+| **Nama Resmi** | Riset Teknologi Informasi |
+| **Identitas Akademik** | Applied Experimental Research in Information Systems & Software Engineering |
+| **Paradigma** | Positivist + Pragmatic (Design Science) |
+| **Level** | KKNI Level 6 (Sarjana) |
+| **Prasyarat Logis** | Metodologi Penelitian (Metopen) — sebagai prerequisite konseptual |
+
+---
+
+## 2. TUJUAN UTAMA
+
+> Pembaca mampu **merancang, menjalankan, dan mempertahankan eksperimen berbasis sistem** secara ilmiah.
+
+### Bukan:
+- ❌ Metodologi penelitian umum (itu Metopen)
+- ❌ Tutorial coding / development
+- ❌ Statistik teoritis / inferensial berat
+- ❌ Filsafat ilmu mendalam
+
+### Tetapi:
+- ✅ Experimental system research
+- ✅ Evidence-based engineering
+- ✅ Reproducible experiment
+- ✅ Applied quantitative research
+
+---
+
+## 3. RESEARCH PIPELINE (WAJIB TIDAK BERUBAH)
+
+```
+Problem → Gap → RQ → Hypothesis → Metric → Design →
+Experiment → Data → Analysis → Conclusion → Defense
+```
+
+Setiap bab harus berada **di dalam pipeline ini**. Jika konten tidak bisa dipetakan ke pipeline → konten tersebut drift.
+
+---
+
+## 4. LEARNING PHASES (4 FASE)
+
+| Fase | Nama | Minggu | Fokus |
+|------|------|--------|-------|
+| **Phase 1** | THINKING | M1–M4 | Problem → Gap → RQ → Hypothesis |
+| **Phase 2** | DESIGNING | M5–M7 | Metric → System → Experiment |
+| **Phase 3** | EXECUTING | M9–M12 | Implementation → Experiment → Data |
+| **Phase 4** | SCIENTIFIC THINKING | M13–M16 | Analysis → Writing → Defense |
+
+> M8 = UTS (Proposal Defense) — checkpoint, bukan fase baru.
+
+---
+
+## 5. BOUNDARY DENGAN METOPEN
+
+| Prinsip | Metopen | Riset TI |
+|---------|---------|----------|
+| Fokus | Konsep & desain metodologi | Eksekusi eksperimen sistem |
+| Paradigma | Umum (semua jenis) | Positivist + DSR |
+| Statistik | Teori & inferensial | Applied & interpretatif |
+| Literature | Konsep review | Praktik search & gap extraction |
+| Output | Desain penelitian | Eksperimen + paper + defense |
+
+**Rule praktis:**
+- ❌ "Explain what research is" → itu Metopen
+- ✅ "Show how to run experiment in system/software" → ini Riset TI
+
+---
+
+## 6. SIGNATURE MODELS (1 PER BAB — IDENTITAS BUKU)
+
+| Bab | Model | Fungsi |
+|-----|-------|--------|
+| 1 | **Research Trust Model** | Reality→Data→Processing→Analysis→Inference→Knowledge |
+| 2 | **Problem Formation Model** + **Problem Quality Model** | Symptom→Problem→Research Problem→Variable |
+| 3 | **Research Positioning Model** | Studies→Comparison→Limitation→Gap→Position→Contribution |
+| 4 | **RQ Formation Model** | Problem→Gap→RQ→Hypothesis→Experiment |
+| 5 | **Measurement Alignment Model** | Problem→Concept→Variable→Metric→Data→Result |
+| 6 | **System as Experiment Model** | RQ→Variable→System Component→Setup→Output |
+| 7 | **Experimental Validity Model** | RQ→Hypothesis→Variable→Controlled Experiment→Conclusion |
+| 9 | **Reproducible Implementation Model** | Design→Implementation→Environment→Consistency→Reproducibility |
+| 10 | **Experiment Execution Pipeline** | Design→Plan→Execution→Collection→Logging→Dataset |
+| 11 | **Data Trust Model** | Raw→Cleaning→Consistency→Validation→Trusted Data |
+| 12 | **Data → Insight Model** | Validated Data→Presentation→Visualization→Pattern→Insight |
+| 13 | **Data Refinement Pipeline** | Raw→Cleaning→Transformation→Normalization→Analysis Ready |
+| 14 | **Data → Knowledge Model** | Data→Analysis→Interpretation→Explanation→Knowledge |
+| 15 | **Scientific Argument Flow** | Problem→Gap→RQ→Method→Result→Analysis→Conclusion→Contribution |
+| 16 | **Scientific Defense Model** | Work→Presentation→Questioning→Defense→Evaluation→Acceptance |
+
+---
+
+## 7. QUALITY GATES (VALIDASI SETIAP BAB)
+
+Sebelum menganggap bab selesai, jawab 3 pertanyaan ini:
+
+### Gate 1 — Relevansi
+> "Apakah bab ini mendorong pembaca **berpikir**, bukan sekadar membaca?"
+
+### Gate 2 — Eksperimental
+> "Apakah bab ini mengarah ke **eksperimen**, bukan hanya teori?"
+
+### Gate 3 — Output
+> "Apakah bab ini menghasilkan **output penelitian nyata** (artefak, data, analisis)?"
+
+**Jika salah satu jawabannya "tidak" → bab sedang drift.**
+
+---
+
+## 8. CONTENT RULES
+
+### 8.1 Struktur Setiap Bab (WAJIB)
+1. Narasi pembuka (semi-formal, book-grade)
+2. Signature Model (diagram + penjelasan)
+3. Definisi kunci
+4. Konsep inti (deep, bukan deskriptif)
+5. Research vs Engineering perspective
+6. Research Reality (fenomena nyata)
+7. Cognitive Traps (kesalahan berpikir yang umum terjadi)
+8. Case Study — Basic (bad vs good)
+9. Case Study — Advanced (bad vs good)
+10. Template praktis
+11. Mindmap ringkasan
+12. AI-Ready Prompt (untuk scaling)
+13. Final Statement (kalimat penutup kuat)
+
+### 8.2 Batasan Konten
+- **Max 2 case study per bab** (basic + advanced)
+- **Max 4-5 cognitive traps** per bab
+- **1 signature model** per bab (tidak boleh lebih)
+- Setiap tambahan harus lulus **Rule of 3**:
+  1. Menguatkan konsep inti
+  2. Terhubung ke eksperimen
+  3. Bisa digunakan dalam praktik riset
+
+### 8.3 Gaya Penulisan
+- **Semi-formal academic** (mudah dibaca, tetap ilmiah)
+- Narasi mengalir, ada analogi
+- Terminologi presisi
+- Referensi tetap kuat (APA/IEEE)
+- Tidak terlalu opini tanpa dasar
+
+### 8.4 Transisi Antar Bab
+Setiap bab WAJIB punya:
+- **Opening bridge**: "Dari bab sebelumnya, kita sudah memahami..."
+- **Closing bridge**: "Dengan [konsep bab ini], kita siap melangkah ke..."
+
+---
+
+## 9. CPL YANG DIBEBANKAN
+
+| CPL | Deskripsi | Domain |
+|-----|-----------|--------|
+| **CPL01** | Sikap sesuai Pancasila, etis, bertanggung jawab, lifelong learning | Afektif |
+| **CPL02** | Menyusun karya ilmiah, komunikasi, kerja tim, kepemimpinan | Soft skills |
+| **CPL03** | Penalaran matematis, logis, kritis, sistematis (fundamental computing) | Kognitif |
+| **CPL06** | Desain & pengembangan aplikasi multi-platform, keberlanjutan, keamanan | Engineering |
+
+---
+
+## 10. CPMK MAPPING
+
+| CPMK | Fokus | CPL Utama | CPL Pendukung |
+|------|-------|-----------|---------------|
+| CPMK01 | Problem Framing | CPL03 | CPL06 |
+| CPMK02 | Experimental Design | CPL06 | CPL03 |
+| CPMK03 | Execution | CPL06 | — |
+| CPMK04 | Evaluation | CPL03 | CPL02 |
+| CPMK05 | Reporting | CPL02 | — |
+| CPMK06 | Defense | CPL02 | CPL03 |
+
+---
+
+## 11. CORE MESSAGE BUKU
+
+> **"Penelitian bukan tentang membuat sistem bekerja,
+> tetapi tentang membuktikan bahwa apa yang ditemukan benar, valid, dan dapat dipercaya."**
+
+---
+
+## 12. POSITIONING BUKU
+
+**Buku ini BUKAN:**
+- Buku metodologi penelitian (sudah banyak)
+- Buku tutorial coding (bukan tujuannya)
+- Buku statistik (itu domain Metopen/Statistika)
+
+**Buku ini ADALAH:**
+- Panduan berpikir sebagai peneliti eksperimental di bidang TI
+- Framework end-to-end: dari problem → defense
+- Training manual untuk menghasilkan penelitian yang **valid, reproducible, dan defensible**
+
+---
+
+*Dokumen ini adalah sumber kebenaran tunggal (single source of truth) untuk seluruh proses penulisan buku.*
+*Terakhir diperbarui: 30 Maret 2026*
--- a/PROJECT-TRACKER.md
+++ b/PROJECT-TRACKER.md
@ -0,0 +1,190 @@
+# PROJECT TRACKER — Riset Teknologi Informasi Book
+
+> **Last Updated:** 2026-03-31
+> **Current Phase:** Fase 4 — Final Polish & Publish (in progress)
+
+---
+
+## Status Legend
+
+| Emoji | Status |
+|-------|--------|
+| ⬜ | Not Started |
+| 🟡 | In Progress |
+| 🟢 | Draft Complete |
+| 🔵 | Reviewed |
+| ✅ | Final / Approved |
+
+---
+
+## Fase Overview
+
+| Fase | Nama | Status | Deliverable |
+|------|------|--------|-------------|
+| 0 | Preparation & Scaffolding | ✅ Complete | Anchor, Spec, Blueprint, Template, Tracker |
+| 1 | Gold Standard (1 Bab Pilot) | 🟢 Draft Complete | Bab 2 — Problem Formulation (full) |
+| 2 | Ekspansi Per-Bagian | <20> Draft Complete | 16 bab draft complete |
+| 3 | Cross-Chapter Integration | 🟢 Complete | Consistency, cross-references, flow |
+| 4 | Final Polish & Publish | <20> Draft Complete | Daftar Gambar/Tabel/Indeks, worksheets, consistency audit, author bio |
+
+---
+
+## Foundation Documents
+
+| Dokumen | Path | Status |
+|---------|------|--------|
+| Master Anchor | `MASTER-ANCHOR.md` | ✅ Complete |
+| Book Spec | `BOOK-SPEC.md` | ✅ Complete |
+| Blueprint | `BLUEPRINT.md` | ✅ Complete |
+| References | `REFERENCES.md` | ✅ Complete |
+| Writing Template | `templates/WRITING-TEMPLATE.md` | ✅ Complete |
+| Project Tracker | `PROJECT-TRACKER.md` | ✅ Complete |
+
+---
+
+## Front Matter
+
+| Item | File | Status | Notes |
+|------|------|--------|-------|
+| Halaman Judul | `book/front-matter/halaman-judul.md` | 🟢 | Nama penulis terisi, ISBN/penerbit TBD |
+| Kata Pengantar | `book/front-matter/kata-pengantar.md` | 🟢 | Draft complete |
+| Daftar Isi | `book/front-matter/daftar-isi.md` | 🟢 | Structure complete, halaman di Fase 4 |
+| Daftar Gambar | `book/front-matter/daftar-gambar.md` | 🟢 | 35 gambar dari 16 bab |
+| Daftar Tabel | `book/front-matter/daftar-tabel.md` | 🟢 | 18 tabel dari 16 bab |
+
+---
+
+## Bagian 1 — Foundation of Research Thinking (M1–M4)
+
+| Bab | Judul | File | Draft | Diagram | Review | Final |
+|-----|-------|------|-------|---------|--------|-------|
+| 1 | Research Mindset in IT | `book/bagian-1-foundation/bab-01-research-mindset.md` | 🟢 | 🟢 | ⬜ | ⬜ |
+| 2 | Problem Formulation | `book/bagian-1-foundation/bab-02-problem-formulation.md` | 🟢 | 🟢 | ⬜ | ⬜ |
+| 3 | Literature Gap & Positioning | `book/bagian-1-foundation/bab-03-literature-gap.md` | 🟢 | 🟢 | ⬜ | ⬜ |
+| 4 | Research Question, Contribution & Hypothesis | `book/bagian-1-foundation/bab-04-rq-hypothesis.md` | 🟢 | 🟢 | ⬜ | ⬜ |
+
+**Signature Models:**
+- Bab 1: Research Trust Model (Reality→Data→Processing→Analysis→Inference→Knowledge)
+- Bab 2: Problem Space Decomposition (PSM)
+- Bab 3: Gap-Map Matrix (Literature → Gap → RQ)
+- Bab 4: RQ Formation Model (Problem → Gap → RQ → Hypothesis → Experiment Design)
+
+---
+
+## Bagian 2 — Research Design & Planning (M5–M7)
+
+| Bab | Judul | File | Draft | Diagram | Review | Final |
+|-----|-------|------|-------|---------|--------|-------|
+| 5 | Metric, Measurement & Data | `book/bagian-2-design/bab-05-metrics-measurement.md` | 🟢 | 🟢 | ⬜ | ⬜ |
+| 6 | System Design sebagai Experimental Artifact | `book/bagian-2-design/bab-06-system-design.md` | 🟢 | 🟢 | ⬜ | ⬜ |
+| 7 | Experimental Design & Validity | `book/bagian-2-design/bab-07-experiment-design.md` | 🟢 | 🟢 | ⬜ | ⬜ |
+
+**Signature Models:**
+- Bab 5: Measurement Alignment Model (Problem → Concept → Variable → Metric → Data → Result)
+- Bab 6: System as Experiment Model (RQ → Variable → System Component → Setup → Output)
+- Bab 7: Experimental Validity Model (RQ → Hypothesis → Variable → Controlled Experiment → Conclusion)
+
+---
+
+## Bagian 3 — Research Execution (M9–M12)
+
+| Bab | Judul | File | Draft | Diagram | Review | Final |
+|-----|-------|------|-------|---------|--------|-------|
+| 8 | Proposal & Checkpoint | `book/bagian-3-execution/bab-08-proposal-checkpoint.md` | 🟢 | 🟢 | ⬜ | ⬜ |
+| 9 | Implementation & Environment | `book/bagian-3-execution/bab-09-implementation-environment.md` | 🟢 | 🟢 | ⬜ | ⬜ |
+| 10 | Experiment Execution & Data Collection | `book/bagian-3-execution/bab-10-experiment-execution.md` | 🟢 | 🟢 | ⬜ | ⬜ |
+| 11 | Data Validation & Integrity | `book/bagian-3-execution/bab-11-data-validation.md` | 🟢 | 🟢 | ⬜ | ⬜ |
+
+**Signature Models:**
+- Bab 8: Integration Map (Bab 1–7 → Proposal Document) — integrative chapter
+- Bab 9: Reproducible Implementation Model (Specification → Implementation → Dependency → Environment → Configuration → Reproducible System)
+- Bab 10: Experiment Execution Pipeline (Design → Execution Plan → Controlled Execution → Data Collection → Data Logging → Dataset for Analysis)
+- Bab 11: Data Trust Model (Raw Data → Data Cleaning → Consistency Check → Validation Process → Trusted Data)
+
+---
+
+## Bagian 4 — Analysis & Communication (M13–M16)
+
+| Bab | Judul | File | Draft | Diagram | Review | Final |
+|-----|-------|------|-------|---------|--------|-------|
+| 12 | Result Presentation & Visualization | `book/bagian-4-analysis/bab-12-result-presentation.md` | 🟢 | 🟢 | ⬜ | ⬜ |
+| 13 | Data Preprocessing | `book/bagian-4-analysis/bab-13-data-preprocessing.md` | 🟢 | 🟢 | ⬜ | ⬜ |
+| 14 | Data Analysis, Interpretation & Failure Analysis | `book/bagian-4-analysis/bab-14-data-analysis.md` | 🟢 | 🟢 | ⬜ | ⬜ |
+| 15 | Scientific Writing | `book/bagian-4-analysis/bab-15-scientific-writing.md` | 🟢 | 🟢 | ⬜ | ⬜ |
+| 16 | Presentation & Defense | `book/bagian-4-analysis/bab-16-presentation-defense.md` | 🟢 | 🟢 | ⬜ | ⬜ |
+
+**Signature Models:**
+- Bab 12: Result Presentation Model (Validated Data → Structured Presentation → Visualization → Pattern Recognition → Insight)
+- Bab 13: Data Refinement Pipeline (Raw Data → Cleaning → Transformation → Normalization → Processed Data → Analysis Ready)
+- Bab 14: Data → Knowledge Model (Data → Analysis → Interpretation → Explanation → Knowledge)
+- Bab 15: Scientific Argument Flow (Problem → Gap → RQ → Method → Result → Analysis → Conclusion → Contribution)
+- Bab 16: Scientific Defense Model (Research Work → Presentation → Questioning → Defense → Evaluation → Acceptance)
+
+---
+
+## Back Matter
+
+| Item | File | Status | Notes |
+|------|------|--------|-------|
+| Daftar Pustaka | `book/back-matter/daftar-pustaka.md` | 🟢 | 22 referensi, APA 7th, cross-ref per bab |
+| Glosarium | `book/back-matter/glosarium.md` | 🟢 | 60 istilah dari 16 bab |
+| Indeks | `book/back-matter/indeks.md` | 🟢 | ~90 entri, referensi per bab |
+| Lampiran: Templates | `book/back-matter/lampiran-templates.md` | 🟢 | 16 template (A.1–A.16) |
+| Lampiran: Worksheet | `book/back-matter/lampiran-worksheet.md` | 🟢 | 16 worksheet (B.1–B.16) |
+| Tentang Penulis | `book/back-matter/tentang-penulis.md` | 🟢 | Bio lengkap Helmi Bahar Alim |
+
+---
+
+## Assets
+
+| Kategori | Folder | Count Target | Done |
+|----------|--------|--------------|------|
+| Signature Model Diagrams | `assets/diagrams/` | 16 (1/bab) | 16 |
+| Mindmap Diagrams | `assets/diagrams/` | 16 (1/bab) | 16 |
+| Supplementary Figures | `assets/figures/` | ~30–50 | 0 |
+
+---
+
+## Worksheets
+
+| Worksheet | File | Status |
+|-----------|------|--------|
+| WS-01: Distorsi & Paradigma | `worksheets/ws-01-problem-statement.md` | 🟢 |
+| WS-02: Problem Statement | `worksheets/ws-02-literature-matrix.md` | 🟢 |
+| WS-03: Literature Mapping & Gap | `worksheets/ws-03-gap-analysis.md` | 🟢 |
+| WS-04: RQ & Hypothesis | `worksheets/ws-04-rq-formulation.md` | 🟢 |
+| WS-05: Variabel & Metrik | `worksheets/ws-05-hypothesis-builder.md` | 🟢 |
+| WS-06: System-Experiment Mapping | `worksheets/ws-06-research-design.md` | 🟢 |
+| WS-07: Experimental Design & Validity | `worksheets/ws-07-metric-definition.md` | 🟢 |
+| WS-08: Proposal Integration | `worksheets/ws-08-experiment-plan.md` | 🟢 |
+| WS-09: Implementation & Reproducibility | `worksheets/ws-09-data-collection-log.md` | 🟢 |
+| WS-10: Execution & Data Collection | `worksheets/ws-10-threat-checklist.md` | 🟢 |
+| WS-11: Data Validation | `worksheets/ws-11-reproducibility.md` | 🟢 |
+| WS-12: Result Presentation | `worksheets/ws-12-ethics-review.md` | 🟢 |
+| WS-13: Preprocessing | `worksheets/ws-13-stat-plan.md` | 🟢 |
+| WS-14: Analysis & Interpretation | `worksheets/ws-14-result-interpretation.md` | 🟢 |
+| WS-15: Scientific Writing | `worksheets/ws-15-paper-outline.md` | 🟢 |
+| WS-16: Presentation & Defense | `worksheets/ws-16-defense-prep.md` | 🟢 |
+
+---
+
+## Quality Gate Log
+
+| Gate | Scope | Date | Result | Notes |
+|------|-------|------|--------|-------|
+| Gate 1 (Anchor Check) | All 16 bab | 2026-03-31 | 🟢 Pass | Terminology consistent, no "mahasiswa" in body, color themes correct |
+| Gate 2 (Academic Rigor) | All 16 bab | 2026-03-31 | 🟢 Pass | All sections present, Daftar Pustaka in all bab, bridges verified |
+| Gate 3 (Pedagogical Flow) | All 16 bab | 2026-03-31 | 🟢 Pass | Cross-refs accurate, opening/closing bridges verified, Bab 7→8 bridge fixed |
+
+---
+
+## Decision Log
+
+| # | Date | Decision | Rationale |
+|---|------|----------|-----------|
+| 1 | — | Gold Standard = Bab 2 (Problem Formulation) | Rich content, uses PSM model, representative of all 13 sections |
+| 2 | — | Writing order: Bab 2 → 1 → 3 → 4 (Bagian 1) | Build forward from strongest chapter |
+
+---
+
+*Tracker ini di-update setiap kali ada progres pada bab, aset, atau quality gate.*
--- a/README.md
+++ b/README.md
@ -0,0 +1,114 @@
+# Riset Teknologi Informasi — Buku Ajar OBE
+
+> **Applied Experimental Research in Information Systems & Software Engineering**
+> Universitas Putra Bangsa (UPB), Kebumen — Fakultas Sains dan Teknologi, Program Studi Teknik Informatika
+
+---
+
+## Tentang Project Ini
+
+Project ini adalah repository pengembangan **buku ajar berbasis OBE** (Outcome-Based Education) untuk mata kuliah *Riset Teknologi Informasi*. Buku ini mengajarkan mahasiswa **cara menjalankan riset eksperimental** di bidang TI dan Software Engineering — bukan sekadar teori metodologi penelitian.
+
+**Paradigma:** Positivist + Pragmatic (Design Science Research)
+**Format:** B5 (17.6 cm × 25 cm), 250–350 halaman, 16 bab dalam 4 bagian
+
+---
+
+## Struktur Folder
+
+```
+rti-20252/
+├── MASTER-ANCHOR.md          # Single source of truth — anti-drift document
+├── BOOK-SPEC.md              # Spesifikasi teknis buku
+├── BLUEPRINT.md              # Consolidated blueprint 16 bab
+├── REFERENCES.md             # Master reference library (APA 7th)
+├── PROJECT-TRACKER.md        # Progress tracking semua deliverable
+├── README.md                 # ← Anda di sini
+│
+├── book/                     # Konten buku
+│   ├── front-matter/         # Halaman judul, kata pengantar, daftar isi/gambar/tabel
+│   ├── bagian-1-foundation/  # Bab 1–4: Foundation of Research Thinking (M1–M4)
+│   ├── bagian-2-design/      # Bab 5–7: Research Design & Planning (M5–M7)
+│   ├── bagian-3-execution/   # Bab 8–12: Research Execution (M9–M12)
+│   ├── bagian-4-analysis/    # Bab 13–16: Analysis & Communication (M13–M16)
+│   └── back-matter/          # Daftar pustaka, glosarium, indeks, lampiran
+│
+├── assets/
+│   ├── diagrams/             # Signature model & mindmap diagrams
+│   └── figures/              # Supplementary figures
+│
+├── templates/
+│   └── WRITING-TEMPLATE.md   # Template per-bab (copy untuk setiap bab baru)
+│
+├── worksheets/               # 16 worksheet praktis (1 per bab)
+│   ├── ws-01-problem-statement.md
+│   ├── ws-02-literature-matrix.md
+│   └── ... (ws-03 s/d ws-16)
+│
+├── rps/                      # RPS (Rencana Pembelajaran Semester) files
+│
+└── docs/                     # Dokumentasi diskusi
+    ├── disscus01.md          # Diskusi v1 — Draft awal RPS
+    ├── disscus02.md          # Diskusi v2 — Gap analysis 
+    ├── disscus03.md          # Diskusi v3 — Refinement
+    └── disscus04.md          # Diskusi v4 — Final consolidation
+```
+
+---
+
+## Struktur Buku
+
+| Bagian | Bab | Judul | Fase |
+|--------|-----|-------|------|
+| **1 — Foundation** | 1 | Research Mindset in IT | Thinking (M1–M4) |
+| | 2 | Problem Formulation | |
+| | 3 | Literature Gap & Positioning | |
+| | 4 | Systematic Literature Review | |
+| **2 — Design** | 5 | Research Question & Hypothesis | Designing (M5–M7) |
+| | 6 | Research Design Patterns | |
+| | 7 | Metrics & Measurement | |
+| **3 — Execution** | 8 | Experiment Setup & Toolchain | Executing (M9–M12) |
+| | 9 | Data Collection Strategies | |
+| | 10 | Validity & Threats | |
+| | 11 | Reproducibility & Replication | |
+| | 12 | Ethics in IT Research | |
+| **4 — Analysis** | 13 | Statistical Thinking for IT | Scientific Thinking (M13–M16) |
+| | 14 | Result Interpretation | |
+| | 15 | Writing & Presentation | |
+| | 16 | Defense & Argumentation | |
+
+---
+
+## Cara Memulai Menulis Bab
+
+1. Baca **MASTER-ANCHOR.md** untuk memahami boundary dan aturan
+2. Baca **BLUEPRINT.md** untuk detail konten bab yang akan ditulis
+3. Copy **templates/WRITING-TEMPLATE.md** ke folder bab yang sesuai
+4. Tulis mengikuti 13-section structure
+5. Validasi terhadap **BOOK-SPEC.md** (format & gaya)
+6. Cek referensi di **REFERENCES.md**
+7. Update **PROJECT-TRACKER.md** setelah selesai
+
+---
+
+## Research Pipeline (Immutable)
+
+```
+Problem → Gap → RQ → Hypothesis → Metric → Design → Experiment → Data → Analysis → Conclusion → Defense
+```
+
+> Setiap bab harus menjaga konsistensi dengan pipeline ini.
+
+---
+
+## Boundary Rule
+
+| ❌ Bukan Riset TI (Metopen) | ✅ Riset TI (buku ini) |
+|------------------------------|------------------------|
+| "Jelaskan apa itu riset" | "Show how to run experiment in system/software" |
+| Filosofi umum penelitian | Applied experimental research in IT/SE |
+| Metodologi generik | Design Science + Experimental SE |
+
+---
+
+*Last updated: Fase 0 — Preparation Complete*
--- a/REFERENCES.md
+++ b/REFERENCES.md
@ -0,0 +1,115 @@
+# REFERENSI AKADEMIK — Library Utama
+
+> Daftar referensi yang WAJIB digunakan dalam buku ini.
+> Setiap bab minimal merujuk 3–5 referensi dari daftar ini.
+> Format: APA 7th Edition.
+
+---
+
+## REFERENSI UTAMA (CORE REFERENCES)
+
+### Research Methodology & Design
+1. **Creswell, J. W., & Creswell, J. D. (2018).** *Research Design: Qualitative, Quantitative, and Mixed Methods Approaches* (5th ed.). SAGE Publications.
+   - **Digunakan di:** Bab 1 (paradigma), Bab 2 (problem), Bab 4 (RQ, hypothesis)
+   - **Konten:** Research philosophy, research design, RQ formulation
+
+2. **Creswell, J. W. (2012).** *Educational Research: Planning, Conducting, and Evaluating Quantitative and Qualitative Research* (4th ed.). Pearson.
+   - **Digunakan di:** Bab 4 (hypothesis), Bab 7 (experiment design)
+
+### Software Engineering Experimentation
+3. **Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., & Wesslén, A. (2012).** *Experimentation in Software Engineering*. Springer.
+   - **Digunakan di:** Bab 5 (metric), Bab 6 (design), Bab 7 (experiment), Bab 9–11 (execution)
+   - **Konten:** Controlled experiment, validity, variable design
+
+### Design Science Research
+4. **Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004).** Design Science in Information Systems Research. *MIS Quarterly*, 28(1), 75–105.
+   - **Digunakan di:** Bab 6 (system as artifact), Bab 7 (build-evaluate cycle)
+   - **Konten:** DSR framework, artifact evaluation
+
+5. **Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007).** A Design Science Research Methodology for Information Systems Research. *Journal of Management Information Systems*, 24(3), 45–77.
+   - **Digunakan di:** Bab 6, Bab 7
+
+### Experimental Validity
+6. **Shadish, W. R., Cook, T. D., & Campbell, D. T. (2002).** *Experimental and Quasi-Experimental Designs for Generalized Causal Inference*. Houghton Mifflin.
+   - **Digunakan di:** Bab 7 (validity), Bab 10–11 (execution, data)
+   - **Konten:** Internal/external/construct validity, threats
+
+### Literature Review
+7. **Webster, J., & Watson, R. T. (2002).** Analyzing the Past to Prepare for the Future: Writing a Literature Review. *MIS Quarterly*, 26(2), xiii–xxiii.
+   - **Digunakan di:** Bab 3 (literature review)
+
+8. **Kitchenham, B. (2004).** *Procedures for Performing Systematic Reviews*. Keele University Technical Report.
+   - **Digunakan di:** Bab 3 (SLR mindset, search strategy)
+
+### Scientific Writing
+9. **Day, R. A., & Gastel, B. (2016).** *How to Write and Publish a Scientific Paper* (8th ed.). Cambridge University Press.
+   - **Digunakan di:** Bab 15 (scientific writing, IMRAD)
+
+### Research Ethics
+10. **Resnik, D. B. (2020).** *The Ethics of Science: An Introduction* (2nd ed.). Routledge.
+    - **Digunakan di:** Bab 1 (etika penelitian)
+
+11. **ACM. (2018).** *ACM Code of Ethics and Professional Conduct.* Association for Computing Machinery.
+    - **Digunakan di:** Bab 1 (etika profesi)
+
+### Statistics (Applied)
+12. **Field, A. (2018).** *Discovering Statistics Using IBM SPSS Statistics* (5th ed.). SAGE Publications.
+    - **Digunakan di:** Bab 5 (data types), Bab 14 (analysis)
+    - **Konten:** Descriptive statistics, basic hypothesis testing
+
+### Data Science & Preprocessing
+13. **Han, J., Kamber, M., & Pei, J. (2012).** *Data Mining: Concepts and Techniques* (3rd ed.). Morgan Kaufmann.
+    - **Digunakan di:** Bab 13 (preprocessing), Bab 11 (data quality)
+
+### Scientific Presentation
+14. **Alley, M. (2013).** *The Craft of Scientific Presentations* (2nd ed.). Springer.
+    - **Digunakan di:** Bab 16 (presentation & defense)
+
+### Software Architecture
+15. **Bass, L., Clements, P., & Kazman, R. (2012).** *Software Architecture in Practice* (3rd ed.). Addison-Wesley.
+    - **Digunakan di:** Bab 6 (system architecture)
+
+---
+
+## REFERENSI PENDUKUNG (SUPPLEMENTARY)
+
+### OBE & Curriculum Design
+16. **Biggs, J., & Tang, C. (2011).** *Teaching for Quality Learning at University* (4th ed.). Open University Press.
+    - **Konten:** Constructive alignment, OBE
+
+17. **Anderson, L. W., & Krathwohl, D. R. (Eds.). (2001).** *A Taxonomy for Learning, Teaching, and Assessing: A Revision of Bloom's Taxonomy of Educational Objectives*. Longman.
+
+### Reproducibility & Open Science
+18. **National Academies of Sciences, Engineering, and Medicine. (2019).** *Reproducibility and Replicability in Science*. The National Academies Press.
+    - **Digunakan di:** Bab 9 (reproducibility)
+
+### Evidence-Based SE
+19. **Kitchenham, B. A., Budgen, D., & Brereton, P. (2015).** *Evidence-Based Software Engineering and Systematic Reviews*. CRC Press.
+
+---
+
+## MAPPING REFERENSI → BAB
+
+| Bab | Referensi Utama |
+|-----|----------------|
+| 1 | Creswell (2018), Resnik (2020), ACM (2018) |
+| 2 | Creswell (2018), Wohlin (2012) |
+| 3 | Webster & Watson (2002), Kitchenham (2004), Creswell (2018) |
+| 4 | Creswell (2018), Wohlin (2012) |
+| 5 | Wohlin (2012), Field (2018), Creswell (2018) |
+| 6 | Hevner et al. (2004), Bass et al. (2012), Peffers et al. (2007) |
+| 7 | Wohlin (2012), Shadish et al. (2002), Hevner et al. (2004) |
+| 8 | (integratif — semua referensi Bab 1–7) |
+| 9 | Wohlin (2012), NAS (2019) |
+| 10 | Wohlin (2012), Shadish et al. (2002) |
+| 11 | Shadish et al. (2002), Han et al. (2012) |
+| 12 | Field (2018), Day & Gastel (2016) |
+| 13 | Han et al. (2012), Field (2018) |
+| 14 | Field (2018), Wohlin (2012), Creswell (2018) |
+| 15 | Day & Gastel (2016), Creswell (2018) |
+| 16 | Alley (2013), Day & Gastel (2016) |
+
+---
+
+*Dokumen ini adalah referensi master untuk sitasi seluruh buku.*
+*Terakhir diperbarui: 30 Maret 2026*
--- a/assets/diagrams/bab-01-mindmap.md
+++ b/assets/diagrams/bab-01-mindmap.md
@ -0,0 +1,42 @@
+# Gambar 1.3 — Mindmap: Research Mindset in IT
+
+```mermaid
+mindmap
+  root((Research<br/>Mindset<br/>in IT))
+    Etika Penelitian
+      Kejujuran
+      Objektivitas
+      Keterbukaan
+      Akuntabilitas
+      ACM Code of Ethics
+    Validitas
+      Internal Validity
+        Confounding variables
+        Selection bias
+      External Validity
+        Generalizability
+        Sample representativeness
+      Construct Validity
+        Operationalisasi
+        Metrik yang tepat
+    Paradigma
+      Positivisme
+      Interpretivisme
+      Pragmatisme
+      Design Science Research
+    Posisi Riset TI
+      Positivist + DSR
+      Eksperimen terkontrol
+      Artefak sebagai instrumen
+    Research Trust Model
+      Reality
+      Data
+      Processing
+      Analysis
+      Inference
+      Knowledge
+    Mindset Peneliti
+      Curious
+      Critical
+      Systematic
+```
--- a/assets/diagrams/bab-01-research-trust-model.md
+++ b/assets/diagrams/bab-01-research-trust-model.md
@ -0,0 +1,24 @@
+# Gambar 1.1 — Research Trust Model
+
+```mermaid
+graph LR
+    A["🌍 <b>Reality</b><br/><i>Fenomena nyata</i>"]
+    B["📊 <b>Data</b><br/><i>Observasi & pengukuran</i>"]
+    C["⚙️ <b>Processing</b><br/><i>Cleaning & transformasi</i>"]
+    D["🔬 <b>Analysis</b><br/><i>Statistik & interpretasi</i>"]
+    E["💡 <b>Inference</b><br/><i>Kesimpulan</i>"]
+    F["📚 <b>Knowledge</b><br/><i>Kontribusi ilmiah</i>"]
+
+    A -->|"Sampling &<br/>measurement"| B
+    B -->|"Preprocessing"| C
+    C -->|"Statistical<br/>testing"| D
+    D -->|"Logical<br/>reasoning"| E
+    E -->|"Peer review &<br/>replication"| F
+
+    style A fill:#DBEAFE,stroke:#2563EB,color:#1E3A5F
+    style B fill:#BFDBFE,stroke:#2563EB,color:#1E3A5F
+    style C fill:#93C5FD,stroke:#2563EB,color:#1E3A5F
+    style D fill:#60A5FA,stroke:#2563EB,color:#FFFFFF
+    style E fill:#3B82F6,stroke:#2563EB,color:#FFFFFF
+    style F fill:#2563EB,stroke:#1D4ED8,color:#FFFFFF
+```
--- a/assets/diagrams/bab-02-mindmap.md
+++ b/assets/diagrams/bab-02-mindmap.md
@ -0,0 +1,45 @@
+# Diagram: Mindmap Bab 2 — Problem Formulation & System Context
+
+> **Gambar 2.3** — Mindmap Bab 2: Problem Formulation & System Context
+> **Color Scheme:** Bagian 1 — Biru (#2563EB gradient)
+
+```mermaid
+mindmap
+  root(("**Problem Formulation<br/>& System Context**"))
+    Quality Model
+      Specific
+      Measurable
+      Relevant
+      Testable
+      Real-world
+    Formation Model
+      Reality
+      Observed Issue
+      Diagnosed Problem
+      Researchable Problem
+      Measurable Variable
+    Hierarki
+      Topic
+      Problem
+      Research Problem
+    System Context
+      Input
+      Process
+      Output
+      Outcome
+      Constraints
+      Stakeholders
+    Transformasi
+      Problem → Variable
+      Variable → Metric
+    Cognitive Traps
+      Solution-first
+      Complexity bias
+      Unmeasurable
+      Non-researchable
+```
+
+---
+
+*Render: Mermaid CLI, VS Code Mermaid Preview, atau mermaid.live*
+*Output final: PNG/SVG untuk layout buku B5*
--- a/assets/diagrams/bab-02-problem-formation-model.md
+++ b/assets/diagrams/bab-02-problem-formation-model.md
@ -0,0 +1,29 @@
+# Diagram: Problem Formation Model (Bab 2)
+
+> **Gambar 2.1** — Problem Formation Model: Dari Realitas ke Variabel Terukur
+> **Color Scheme:** Bagian 1 — Biru (#2563EB gradient)
+
+```mermaid
+graph LR
+    A["🌍 <b>Reality</b><br/><i>Fenomena dunia nyata</i>"]
+    B["👁️ <b>Observed Issue</b><br/><i>Symptom</i>"]
+    C["🔍 <b>Diagnosed Problem</b><br/><i>Root Cause</i>"]
+    D["📐 <b>Researchable Problem</b><br/><i>Scoped & Bounded</i>"]
+    E["📏 <b>Measurable Variable</b><br/><i>Operationalized</i>"]
+
+    A -->|"Pengamatan"| B
+    B -->|"Analisis"| C
+    C -->|"Literature check"| D
+    D -->|"Operasionalisasi"| E
+
+    style A fill:#DBEAFE,stroke:#2563EB,color:#1E3A5F
+    style B fill:#93C5FD,stroke:#2563EB,color:#1E3A5F
+    style C fill:#60A5FA,stroke:#2563EB,color:#1E3A5F
+    style D fill:#3B82F6,stroke:#2563EB,color:#FFFFFF
+    style E fill:#2563EB,stroke:#1D4ED8,color:#FFFFFF
+```
+
+---
+
+*Render: Mermaid CLI, VS Code Mermaid Preview, atau mermaid.live*
+*Output final: PNG/SVG untuk layout buku B5*
--- a/assets/diagrams/bab-03-mindmap.md
+++ b/assets/diagrams/bab-03-mindmap.md
@ -0,0 +1,40 @@
+# Gambar 3.3 — Mindmap: Literature Review, Research Gap & Baseline
+
+```mermaid
+mindmap
+  root((Literature<br/>Gap &<br/>Positioning))
+    Literature Review
+      Concept-centric bukan author-centric
+      Sintesis bukan ringkasan
+      Positioning bukan formalitas
+    Search Strategy
+      Database primer
+        IEEE Xplore
+        ACM DL
+        Scopus
+      Boolean query design
+      Snowballing
+        Backward
+        Forward
+    Empat Jenis Gap
+      Performance Gap
+      Method Gap
+      Data Gap
+      Context Gap
+      Kombinasi gap paling kuat
+    Baseline Selection
+      Relevan
+      Representatif
+      State-of-the-Art
+    Research Positioning Model
+      Existing Studies
+      Method Comparison
+      Limitation Identification
+      Research Gap
+      Research Position
+      Contribution
+    Bridge ke RQ
+      Gap → RQ
+      RQ → Hypothesis
+      Hypothesis → Experiment
+```
--- a/assets/diagrams/bab-03-research-positioning-model.md
+++ b/assets/diagrams/bab-03-research-positioning-model.md
@ -0,0 +1,24 @@
+# Gambar 3.1 — Research Positioning Model
+
+```mermaid
+graph LR
+    A["📚 <b>Existing<br/>Studies</b><br/><i>Literatur relevan</i>"]
+    B["⚖️ <b>Method<br/>Comparison</b><br/><i>Analisis & sintesis</i>"]
+    C["🔍 <b>Limitation<br/>Identification</b><br/><i>Kelemahan studi</i>"]
+    D["🕳️ <b>Research<br/>Gap</b><br/><i>Celah pengetahuan</i>"]
+    E["📍 <b>Research<br/>Position</b><br/><i>Posisi Anda</i>"]
+    F["🎯 <b>Contribution</b><br/><i>Nilai tambah</i>"]
+
+    A -->|"Systematic<br/>search"| B
+    B -->|"Critical<br/>analysis"| C
+    C -->|"Gap<br/>formulation"| D
+    D -->|"Positioning<br/>statement"| E
+    E -->|"Justification"| F
+
+    style A fill:#DBEAFE,stroke:#2563EB,color:#1E3A5F
+    style B fill:#BFDBFE,stroke:#2563EB,color:#1E3A5F
+    style C fill:#93C5FD,stroke:#2563EB,color:#1E3A5F
+    style D fill:#60A5FA,stroke:#2563EB,color:#FFFFFF
+    style E fill:#3B82F6,stroke:#2563EB,color:#FFFFFF
+    style F fill:#2563EB,stroke:#1D4ED8,color:#FFFFFF
+```
--- a/assets/diagrams/bab-04-mindmap.md
+++ b/assets/diagrams/bab-04-mindmap.md
@ -0,0 +1,33 @@
+# Bab 4 — Mindmap: RQ, Contribution & Hypothesis (Gambar 4.3)
+
+```mermaid
+mindmap
+  root((RQ, Contribution<br/>& Hypothesis))
+    Research Question
+      Instrumen presisi bukan pertanyaan biasa
+      3 Jenis RQ
+        Comparison
+        Improvement
+        Exploratory
+      Harus mengandung variabel metrik konteks
+    Contribution Statement
+      Improvement
+      Comparison
+      Novel Approach
+      Harus terhubung dengan gap
+    Hypothesis
+      H0 Null Hypothesis
+      H1 Alternative Hypothesis
+      Falsifiable dan testable
+      Dirumuskan SEBELUM eksperimen
+    RQ Formation Model
+      Problem lalu Gap lalu RQ lalu Hypothesis lalu Experiment
+      Transformasi bukan progresi otomatis
+      Revisi mundur adalah bagian normal
+    Operationalization Chain
+      RQ lalu Variable lalu Metric lalu Data lalu Analysis
+    Cognitive Traps
+      RQ sama dengan judul ditambah tanda tanya
+      RQ tanpa metric
+      RQ tanpa eksperimen
+```
--- a/assets/diagrams/bab-04-rq-formation-model.md
+++ b/assets/diagrams/bab-04-rq-formation-model.md
@ -0,0 +1,21 @@
+# Bab 4 — RQ Formation Model (Gambar 4.1)
+
+```mermaid
+graph LR
+    A["🔍 <b>Research<br/>Problem</b><br/><i>Masalah terukur</i>"]
+    B["🕳️ <b>Research<br/>Gap</b><br/><i>Celah pengetahuan</i>"]
+    C["❓ <b>Research<br/>Question</b><br/><i>Pertanyaan presisi</i>"]
+    D["🎯 <b>Hypothesis</b><br/><i>H0 & H1</i>"]
+    E["⚙️ <b>Experiment<br/>Design</b><br/><i>Variabel & metrik</i>"]
+
+    A -->|"Gap<br/>identification"| B
+    B -->|"Question<br/>formulation"| C
+    C -->|"Prediction<br/>& testability"| D
+    D -->|"Operatio-<br/>nalization"| E
+
+    style A fill:#1e40af,stroke:#1e3a8a,color:#ffffff
+    style B fill:#1d4ed8,stroke:#1e40af,color:#ffffff
+    style C fill:#2563eb,stroke:#1d4ed8,color:#ffffff
+    style D fill:#3b82f6,stroke:#2563eb,color:#ffffff
+    style E fill:#60a5fa,stroke:#3b82f6,color:#ffffff
+```
--- a/assets/diagrams/bab-05-measurement-alignment-model.md
+++ b/assets/diagrams/bab-05-measurement-alignment-model.md
@ -0,0 +1,24 @@
+# Bab 5 — Measurement Alignment Model (Gambar 5.1)
+
+```mermaid
+graph LR
+    A["🔍 <b>Problem</b><br/><i>Masalah riset</i>"]
+    B["💭 <b>Concept</b><br/><i>Konsep abstrak</i>"]
+    C["📊 <b>Variable</b><br/><i>Variabel terukur</i>"]
+    D["📏 <b>Metric</b><br/><i>Satuan pengukuran</i>"]
+    E["📦 <b>Data</b><br/><i>Nilai observasi</i>"]
+    F["✅ <b>Result</b><br/><i>Temuan eksperimen</i>"]
+
+    A -->|"Abstraksi"| B
+    B -->|"Operasionalisasi"| C
+    C -->|"Kuantifikasi"| D
+    D -->|"Pengumpulan"| E
+    E -->|"Analisis"| F
+
+    style A fill:#D1FAE5,stroke:#059669,color:#064E3B
+    style B fill:#A7F3D0,stroke:#059669,color:#064E3B
+    style C fill:#6EE7B7,stroke:#059669,color:#064E3B
+    style D fill:#34D399,stroke:#059669,color:#FFFFFF
+    style E fill:#10B981,stroke:#047857,color:#FFFFFF
+    style F fill:#059669,stroke:#047857,color:#FFFFFF
+```
--- a/assets/diagrams/bab-05-mindmap.md
+++ b/assets/diagrams/bab-05-mindmap.md
@ -0,0 +1,36 @@
+# Bab 5 — Mindmap (Gambar 5.2)
+
+```mermaid
+mindmap
+  root(("**Bab 5**<br/>Metric, Measurement<br/>& Data"))
+    ("**Measurement<br/>Alignment Model**")
+      ("Problem → Concept")
+      ("Concept → Variable")
+      ("Variable → Metric")
+      ("Metric → Data")
+      ("Data → Result")
+    ("**Operasionalisasi**")
+      ("Konsep abstrak → terukur")
+      ("Keputusan desain")
+      ("Harus dijustifikasi")
+    ("**Jenis Data**")
+      ("Nominal")
+      ("Ordinal")
+      ("Interval")
+      ("Ratio")
+    ("**Pemilihan Metrik**")
+      ("Representatif")
+      ("Sensitif")
+      ("Feasible")
+      ("Multi-metric")
+    ("**Kualitas Data**")
+      ("Completeness")
+      ("Consistency")
+      ("Validity")
+      ("Representativeness")
+    ("**Cognitive Traps**")
+      ("Akurasi ≠ performa")
+      ("Terlalu banyak metrik")
+      ("Data ≠ relevansi")
+      ("Mean ≠ selalu tepat")
+```
--- a/assets/diagrams/bab-06-mindmap.md
+++ b/assets/diagrams/bab-06-mindmap.md
@ -0,0 +1,32 @@
+# Bab 6 — Mindmap (Gambar 6.2)
+
+```mermaid
+mindmap
+  root(("**Bab 6**<br/>System Design<br/>sebagai Artifact"))
+    ("**System as<br/>Experiment Model**")
+      ("RQ → Variable")
+      ("Variable → Component")
+      ("Component → Setup")
+      ("Setup → Output")
+    ("**Sistem = Alat Uji**")
+      ("Bukan produk")
+      ("Bukan tujuan akhir")
+      ("Instrumen pembuktian")
+    ("**4 Prinsip**")
+      ("Traceability")
+      ("Modularity")
+      ("Controllability")
+      ("Measurability")
+    ("**Mapping RQ →<br/>Komponen**")
+      ("IV → modul yang dimanipulasi")
+      ("DV → modul yang mengukur")
+      ("Kontrol → config yang dikunci")
+    ("**Isolasi Variabel**")
+      ("Modular architecture")
+      ("Config-driven execution")
+      ("Feature toggle")
+    ("**Cognitive Traps**")
+      ("Berfungsi ≠ terbukti")
+      ("Elegan ≠ eksperimentable")
+      ("Fitur tambahan = noise")
+```
--- a/assets/diagrams/bab-06-system-experiment-model.md
+++ b/assets/diagrams/bab-06-system-experiment-model.md
@ -0,0 +1,21 @@
+# Bab 6 — System as Experiment Model (Gambar 6.1)
+
+```mermaid
+graph LR
+    A["❓ <b>Research<br/>Question</b><br/><i>Apa yang diuji?</i>"]
+    B["📊 <b>Variable</b><br/><i>IV, DV, Control</i>"]
+    C["🔧 <b>System<br/>Component</b><br/><i>Modul & arsitektur</i>"]
+    D["⚙️ <b>Experimental<br/>Setup</b><br/><i>Konfigurasi & skenario</i>"]
+    E["📏 <b>Output</b><br/><i>Data terukur</i>"]
+
+    A -->|"Dekomposisi"| B
+    B -->|"Mapping"| C
+    C -->|"Konfigurasi"| D
+    D -->|"Eksekusi"| E
+
+    style A fill:#D1FAE5,stroke:#059669,color:#064E3B
+    style B fill:#A7F3D0,stroke:#059669,color:#064E3B
+    style C fill:#6EE7B7,stroke:#059669,color:#064E3B
+    style D fill:#34D399,stroke:#059669,color:#FFFFFF
+    style E fill:#059669,stroke:#047857,color:#FFFFFF
+```
--- a/assets/diagrams/bab-07-experimental-validity-model.md
+++ b/assets/diagrams/bab-07-experimental-validity-model.md
@ -0,0 +1,27 @@
+# Bab 7 — Experimental Validity Model (Gambar 7.1)
+
+```mermaid
+graph LR
+    A["❓ <b>RQ</b><br/><i>Apa yang diuji?</i>"]
+    B["🎯 <b>Hypothesis</b><br/><i>H0 & H1</i>"]
+    C["📊 <b>Variable<br/>Design</b><br/><i>IV, DV, Control</i>"]
+    D["⚙️ <b>Controlled<br/>Experiment</b><br/><i>Setup & skenario</i>"]
+    E["📦 <b>Data</b><br/><i>Hasil observasi</i>"]
+    F["📈 <b>Analysis</b><br/><i>Uji statistik</i>"]
+    G["✅ <b>Conclusion</b><br/><i>Validity Level</i>"]
+
+    A -->|"Prediksi"| B
+    B -->|"Operasionalisasi"| C
+    C -->|"Eksekusi"| D
+    D -->|"Pengumpulan"| E
+    E -->|"Pengujian"| F
+    F -->|"Interpretasi"| G
+
+    style A fill:#D1FAE5,stroke:#059669,color:#064E3B
+    style B fill:#A7F3D0,stroke:#059669,color:#064E3B
+    style C fill:#6EE7B7,stroke:#059669,color:#064E3B
+    style D fill:#34D399,stroke:#059669,color:#FFFFFF
+    style E fill:#10B981,stroke:#047857,color:#FFFFFF
+    style F fill:#059669,stroke:#047857,color:#FFFFFF
+    style G fill:#047857,stroke:#065F46,color:#FFFFFF
+```
--- a/assets/diagrams/bab-07-mindmap.md
+++ b/assets/diagrams/bab-07-mindmap.md
@ -0,0 +1,35 @@
+# Bab 7 — Mindmap (Gambar 7.2)
+
+```mermaid
+mindmap
+  root(("**Bab 7**<br/>Experimental Design<br/>& Validity"))
+    ("**Experimental<br/>Validity Model**")
+      ("RQ → Hypothesis")
+      ("Variable Design")
+      ("Controlled Experiment")
+      ("Data → Analysis")
+      ("Conclusion + Validity")
+    ("**Kausalitas**")
+      ("Korelasi ≠ Kausalitas")
+      ("Kovariansi")
+      ("Temporal precedence")
+      ("Eliminasi alternatif")
+    ("**4 Validitas**")
+      ("Internal")
+      ("External")
+      ("Construct")
+      ("Conclusion")
+    ("**Tipe Eksperimen**")
+      ("Comparison Study")
+      ("Ablation Study")
+      ("Parameter Study")
+    ("**Controlled<br/>Experiment**")
+      ("Ubah satu, kontrol sisanya")
+      ("Fair comparison")
+      ("Baseline yang valid")
+    ("**Cognitive Traps**")
+      ("Signifikan ≠ penting")
+      ("Banyak ≠ kuat")
+      ("H0 tidak ditolak ≠ gagal")
+      ("Baseline paper ≠ cukup")
+```
--- a/assets/diagrams/bab-08-integration-map.md
+++ b/assets/diagrams/bab-08-integration-map.md
@ -0,0 +1,27 @@
+# Bab 8 — Integration Map (Gambar 8.1)
+
+```mermaid
+graph LR
+    A["📋 <b>Problem &<br/>Domain</b><br/><i>Bab 1–2</i>"]
+    B["📚 <b>Literature &<br/>Gap</b><br/><i>Bab 3</i>"]
+    C["❓ <b>RQ &<br/>Hypothesis</b><br/><i>Bab 4</i>"]
+    D["📏 <b>Metrics &<br/>Measurement</b><br/><i>Bab 5</i>"]
+    E["🔧 <b>System<br/>Design</b><br/><i>Bab 6</i>"]
+    F["🧪 <b>Experiment<br/>Design</b><br/><i>Bab 7</i>"]
+    G["📄 <b>Proposal<br/>Document</b>"]
+
+    A --> G
+    B --> G
+    C --> G
+    D --> G
+    E --> G
+    F --> G
+
+    style A fill:#FFF7ED,stroke:#EA580C,color:#7C2D12
+    style B fill:#FFEDD5,stroke:#EA580C,color:#7C2D12
+    style C fill:#FED7AA,stroke:#EA580C,color:#7C2D12
+    style D fill:#FDBA74,stroke:#EA580C,color:#FFFFFF
+    style E fill:#FB923C,stroke:#C2410C,color:#FFFFFF
+    style F fill:#EA580C,stroke:#C2410C,color:#FFFFFF
+    style G fill:#7C2D12,stroke:#431407,color:#FFFFFF
+```
--- a/assets/diagrams/bab-08-mindmap.md
+++ b/assets/diagrams/bab-08-mindmap.md
@ -0,0 +1,29 @@
+# Bab 8 — Mindmap (Gambar 8.2)
+
+```mermaid
+mindmap
+  root(("**Bab 8**<br/>Proposal &<br/>Checkpoint"))
+    ("**Peta Integrasi**")
+      ("Problem & Domain → Proposal")
+      ("Literature & Gap → Proposal")
+      ("RQ & Hypothesis → Proposal")
+      ("Metrics → Proposal")
+      ("System & Experiment → Proposal")
+    ("**Struktur Proposal**")
+      ("Pendahuluan")
+      ("Tinjauan Pustaka")
+      ("Metodologi")
+      ("Rencana Kerja")
+      ("Daftar Pustaka")
+    ("**Rubrik Evaluasi**")
+      ("Relevansi & novelty")
+      ("Kejelasan RQ")
+      ("Kesesuaian metrik")
+      ("Desain eksperimen")
+      ("Feasibility")
+      ("Kualitas penulisan")
+    ("**Cognitive Traps**")
+      ("Komponen bagus ≠ proposal bagus")
+      ("Template ≠ konten")
+      ("Selesai ≠ siap")
+```
--- a/assets/diagrams/bab-09-mindmap.md
+++ b/assets/diagrams/bab-09-mindmap.md
@ -0,0 +1,26 @@
+# Bab 9 — Mindmap (Gambar 9.2)
+
+```mermaid
+mindmap
+  root(("**Bab 9**<br/>Implementation<br/>& Environment"))
+    ("**Reproducible<br/>Implementation Model**")
+      ("Specification → Code")
+      ("Dependency pinning")
+      ("Environment specification")
+      ("Configuration management")
+      ("Verification")
+    ("**Research vs Engineering**")
+      ("Exploratory code")
+      ("Configuration-driven")
+      ("Reproducibility first")
+    ("**Environment Control**")
+      ("Hardware documentation")
+      ("OS & driver version")
+      ("Dependency lock file")
+      ("Container/VM option")
+    ("**Cognitive Traps**")
+      ("Works on my machine")
+      ("Latest ≠ best")
+      ("Hardcode = debt")
+      ("Clean code ≠ goal")
+```
--- a/assets/diagrams/bab-09-reproducible-implementation-model.md
+++ b/assets/diagrams/bab-09-reproducible-implementation-model.md
@ -0,0 +1,24 @@
+# Bab 9 — Reproducible Implementation Model (Gambar 9.1)
+
+```mermaid
+graph LR
+    A["📋 <b>Specification</b><br/><i>Requirement docs</i>"]
+    B["💻 <b>Implementation</b><br/><i>Research code</i>"]
+    C["📦 <b>Dependency<br/>Management</b><br/><i>Lock & pin</i>"]
+    D["🖥️ <b>Environment<br/>Specification</b><br/><i>Hardware & OS</i>"]
+    E["📝 <b>Configuration<br/>Management</b><br/><i>Config files</i>"]
+    F["✅ <b>Reproducible<br/>System</b><br/><i>Siap eksperimen</i>"]
+
+    A -->|"Coding"| B
+    B -->|"Pinning"| C
+    C -->|"Dokumentasi"| D
+    D -->|"Konfigurasi"| E
+    E -->|"Verifikasi"| F
+
+    style A fill:#FFF7ED,stroke:#EA580C,color:#7C2D12
+    style B fill:#FFEDD5,stroke:#EA580C,color:#7C2D12
+    style C fill:#FED7AA,stroke:#EA580C,color:#7C2D12
+    style D fill:#FDBA74,stroke:#EA580C,color:#FFFFFF
+    style E fill:#FB923C,stroke:#C2410C,color:#FFFFFF
+    style F fill:#EA580C,stroke:#C2410C,color:#FFFFFF
+```
--- a/assets/diagrams/bab-10-experiment-execution-pipeline.md
+++ b/assets/diagrams/bab-10-experiment-execution-pipeline.md
@ -0,0 +1,24 @@
+# Bab 10 — Experiment Execution Pipeline (Gambar 10.1)
+
+```mermaid
+graph LR
+    A["📋 <b>Design</b><br/><i>Desain dari Bab 7</i>"]
+    B["📝 <b>Execution<br/>Plan</b><br/><i>Skenario & jadwal</i>"]
+    C["⚙️ <b>Controlled<br/>Execution</b><br/><i>Multiple run</i>"]
+    D["📦 <b>Data<br/>Collection</b><br/><i>Pencatatan output</i>"]
+    E["📊 <b>Data<br/>Logging</b><br/><i>ID, timestamp, param</i>"]
+    F["✅ <b>Dataset for<br/>Analysis</b><br/><i>Terstruktur & lengkap</i>"]
+
+    A -->|"Perencanaan"| B
+    B -->|"Eksekusi"| C
+    C -->|"Pencatatan"| D
+    D -->|"Strukturisasi"| E
+    E -->|"Validasi"| F
+
+    style A fill:#FFF7ED,stroke:#EA580C,color:#7C2D12
+    style B fill:#FFEDD5,stroke:#EA580C,color:#7C2D12
+    style C fill:#FED7AA,stroke:#EA580C,color:#7C2D12
+    style D fill:#FDBA74,stroke:#EA580C,color:#FFFFFF
+    style E fill:#FB923C,stroke:#C2410C,color:#FFFFFF
+    style F fill:#EA580C,stroke:#C2410C,color:#FFFFFF
+```
--- a/assets/diagrams/bab-10-mindmap.md
+++ b/assets/diagrams/bab-10-mindmap.md
@ -0,0 +1,31 @@
+# Bab 10 — Mindmap (Gambar 10.2)
+
+```mermaid
+mindmap
+  root(("**Bab 10**<br/>Experiment Execution<br/>& Data Collection"))
+    ("**Execution Pipeline**")
+      ("Design → Plan")
+      ("Plan → Execution")
+      ("Execution → Collection")
+      ("Collection → Logging")
+      ("Logging → Dataset")
+    ("**Multiple Run**")
+      ("≥ 5-10 run per skenario")
+      ("Seed berbeda per run")
+      ("Mean, std, CI")
+      ("Uji statistik")
+    ("**Data Logging**")
+      ("Run ID & timestamp")
+      ("Full configuration")
+      ("Semua metrik")
+      ("Execution metadata")
+    ("**Konsistensi**")
+      ("Background processes")
+      ("Caching effects")
+      ("Thermal throttling")
+      ("Checkpoint per run")
+    ("**Cognitive Traps**")
+      ("Single run ≠ bukti")
+      ("Run gagal ≠ dihapus")
+      ("Marathon ≠ efisien")
+```
--- a/assets/diagrams/bab-11-data-trust-model.md
+++ b/assets/diagrams/bab-11-data-trust-model.md
@ -0,0 +1,21 @@
+# Bab 11 — Data Trust Model (Gambar 11.1)
+
+```mermaid
+graph LR
+    A["📥 <b>Raw Data</b><br/><i>Log eksperimen</i>"]
+    B["🧹 <b>Data<br/>Cleaning</b><br/><i>Format & missing</i>"]
+    C["🔗 <b>Consistency<br/>Check</b><br/><i>Antar-run & antar-file</i>"]
+    D["✔️ <b>Validation<br/>Process</b><br/><i>4 pilar kualitas</i>"]
+    E["✅ <b>Trusted<br/>Data</b><br/><i>Siap analisis</i>"]
+
+    A -->|"Pembersihan"| B
+    B -->|"Pengecekan"| C
+    C -->|"Validasi"| D
+    D -->|"Sertifikasi"| E
+
+    style A fill:#FFF7ED,stroke:#EA580C,color:#7C2D12
+    style B fill:#FFEDD5,stroke:#EA580C,color:#7C2D12
+    style C fill:#FED7AA,stroke:#EA580C,color:#7C2D12
+    style D fill:#FB923C,stroke:#C2410C,color:#FFFFFF
+    style E fill:#EA580C,stroke:#C2410C,color:#FFFFFF
+```
--- a/assets/diagrams/bab-11-mindmap.md
+++ b/assets/diagrams/bab-11-mindmap.md
@ -0,0 +1,31 @@
+# Bab 11 — Mindmap (Gambar 11.2)
+
+```mermaid
+mindmap
+  root(("**Bab 11**<br/>Data Validation<br/>& Integrity"))
+    ("**Data Trust Model**")
+      ("Raw Data")
+      ("Data Cleaning")
+      ("Consistency Check")
+      ("Validation Process")
+      ("Trusted Data")
+    ("**4 Pilar Kualitas**")
+      ("Accuracy — range")
+      ("Consistency — format")
+      ("Completeness — jumlah")
+      ("Validity — logika")
+    ("**Proses Validasi**")
+      ("Format → Range")
+      ("Consistency → Logic")
+      ("Anomaly detection")
+      ("Data-experiment alignment")
+    ("**Anomaly Handling**")
+      ("Detect")
+      ("Investigate")
+      ("Document")
+      ("Decide")
+    ("**Cognitive Traps**")
+      ("Otomatis ≠ benar")
+      ("Outlier ≠ hapus")
+      ("Mean normal ≠ data benar")
+```
--- a/assets/diagrams/bab-12-data-insight-model.md
+++ b/assets/diagrams/bab-12-data-insight-model.md
@ -0,0 +1,21 @@
+# Bab 12 — Data → Insight Model (Gambar 12.1)
+
+```mermaid
+graph LR
+    A["📥 <b>Validated<br/>Data</b><br/><i>Dari Bab 11</i>"]
+    B["📋 <b>Structured<br/>Presentation</b><br/><i>Tabel & ringkasan</i>"]
+    C["📊 <b>Visualization</b><br/><i>Grafik & chart</i>"]
+    D["🔍 <b>Pattern<br/>Recognition</b><br/><i>Tren & anomali</i>"]
+    E["💡 <b>Insight</b><br/><i>Observasi awal</i>"]
+
+    A -->|"Strukturisasi"| B
+    B -->|"Visualisasi"| C
+    C -->|"Analisis visual"| D
+    D -->|"Formulasi"| E
+
+    style A fill:#F5F3FF,stroke:#7C3AED,color:#4C1D95
+    style B fill:#EDE9FE,stroke:#7C3AED,color:#4C1D95
+    style C fill:#DDD6FE,stroke:#7C3AED,color:#4C1D95
+    style D fill:#A78BFA,stroke:#6D28D9,color:#FFFFFF
+    style E fill:#7C3AED,stroke:#6D28D9,color:#FFFFFF
+```
--- a/assets/diagrams/bab-12-mindmap.md
+++ b/assets/diagrams/bab-12-mindmap.md
@ -0,0 +1,31 @@
+# Bab 12 — Mindmap (Gambar 12.2)
+
+```mermaid
+mindmap
+  root(("**Bab 12**<br/>Result Presentation<br/>& Visualization"))
+    ("**Data → Insight Model**")
+      ("Validated Data")
+      ("Structured Presentation")
+      ("Visualization")
+      ("Pattern Recognition")
+      ("Insight")
+    ("**Tabel**")
+      ("Self-contained")
+      ("Mean ± std")
+      ("Konsisten format")
+      ("Minimalis")
+    ("**Grafik**")
+      ("Bar chart — perbandingan")
+      ("Box plot — distribusi")
+      ("Line chart — tren")
+      ("Scatter — korelasi")
+    ("**Visualization Bias**")
+      ("Truncated axis")
+      ("Cherry-picked data")
+      ("Missing error bar")
+      ("3D distortion")
+    ("**Cognitive Traps**")
+      ("Grafik ≠ pengganti tabel")
+      ("Flat ≠ salah")
+      ("1 grafik ≠ semua pesan")
+```
--- a/assets/diagrams/bab-13-data-refinement-pipeline.md
+++ b/assets/diagrams/bab-13-data-refinement-pipeline.md
@ -0,0 +1,24 @@
+# Bab 13 — Data Refinement Pipeline (Gambar 13.1)
+
+```mermaid
+graph LR
+    A["📥 <b>Raw Data</b><br/><i>Dari eksperimen</i>"]
+    B["🧹 <b>Cleaning</b><br/><i>Missing, duplikat, error</i>"]
+    C["🔄 <b>Transformation</b><br/><i>Encoding, agregasi</i>"]
+    D["📐 <b>Normalization</b><br/><i>Scaling, standardisasi</i>"]
+    E["📦 <b>Processed<br/>Data</b><br/><i>Siap analisis</i>"]
+    F["✅ <b>Analysis<br/>Ready</b><br/><i>Terdokumentasi</i>"]
+
+    A -->|"Pembersihan"| B
+    B -->|"Transformasi"| C
+    C -->|"Normalisasi"| D
+    D -->|"Verifikasi"| E
+    E -->|"Dokumentasi"| F
+
+    style A fill:#F5F3FF,stroke:#7C3AED,color:#4C1D95
+    style B fill:#EDE9FE,stroke:#7C3AED,color:#4C1D95
+    style C fill:#DDD6FE,stroke:#7C3AED,color:#4C1D95
+    style D fill:#C4B5FD,stroke:#6D28D9,color:#4C1D95
+    style E fill:#A78BFA,stroke:#6D28D9,color:#FFFFFF
+    style F fill:#7C3AED,stroke:#6D28D9,color:#FFFFFF
+```
--- a/assets/diagrams/bab-13-mindmap.md
+++ b/assets/diagrams/bab-13-mindmap.md
@ -0,0 +1,31 @@
+# Bab 13 — Mindmap (Gambar 13.2)
+
+```mermaid
+mindmap
+  root(("**Bab 13**<br/>Data<br/>Preprocessing"))
+    ("**Refinement Pipeline**")
+      ("Raw Data → Cleaning")
+      ("Cleaning → Transformation")
+      ("Transformation → Normalization")
+      ("Normalization → Processed")
+      ("Processed → Analysis Ready")
+    ("**Cleaning**")
+      ("Missing values")
+      ("Duplikasi")
+      ("Format error")
+      ("Metode + justifikasi")
+    ("**Transformation**")
+      ("Encoding kategorikal")
+      ("Agregasi level")
+      ("Feature engineering")
+    ("**Normalization**")
+      ("Min-max scaling")
+      ("Z-score")
+      ("Robust scaling")
+      ("Hanya jika diperlukan")
+    ("**4 Prinsip**")
+      ("Consistency")
+      ("Transparency")
+      ("Reproducibility")
+      ("Minimal distortion")
+```
--- a/assets/diagrams/bab-14-data-knowledge-model.md
+++ b/assets/diagrams/bab-14-data-knowledge-model.md
@ -0,0 +1,21 @@
+# Bab 14 — Data → Knowledge Model (Gambar 14.1)
+
+```mermaid
+graph LR
+    A["📊 <b>Data</b><br/><i>Preprocessed</i>"]
+    B["🔬 <b>Analysis</b><br/><i>Statistik & uji</i>"]
+    C["🧠 <b>Interpretation</b><br/><i>Makna & konteks</i>"]
+    D["💬 <b>Explanation</b><br/><i>Mengapa & limitation</i>"]
+    E["💡 <b>Knowledge</b><br/><i>Kontribusi</i>"]
+
+    A -->|"Uji hipotesis"| B
+    B -->|"Kontekstualisasi"| C
+    C -->|"Refleksi"| D
+    D -->|"Generalisasi"| E
+
+    style A fill:#F5F3FF,stroke:#7C3AED,color:#4C1D95
+    style B fill:#EDE9FE,stroke:#7C3AED,color:#4C1D95
+    style C fill:#DDD6FE,stroke:#7C3AED,color:#4C1D95
+    style D fill:#A78BFA,stroke:#6D28D9,color:#FFFFFF
+    style E fill:#7C3AED,stroke:#6D28D9,color:#FFFFFF
+```
--- a/assets/diagrams/bab-14-mindmap.md
+++ b/assets/diagrams/bab-14-mindmap.md
@ -0,0 +1,30 @@
+# Bab 14 — Mindmap (Gambar 14.2)
+
+```mermaid
+mindmap
+  root(("**Bab 14**<br/>Analysis, Interpretation<br/>& Failure Analysis"))
+    ("**Analysis**")
+      ("Statistik deskriptif")
+      ("Uji hipotesis")
+      ("Effect size")
+      ("Confidence interval")
+    ("**Interpretation**")
+      ("Result → RQ → Conclusion")
+      ("Beyond p-value")
+      ("Perbandingan literatur")
+      ("Implikasi praktis")
+    ("**Failure Analysis**")
+      ("Ditolak ≠ gagal")
+      ("Investigasi penyebab")
+      ("Boundary condition")
+      ("Kegagalan → insight")
+    ("**Limitation**")
+      ("Internal validity")
+      ("External validity")
+      ("Construct validity")
+      ("Statistical limitation")
+    ("**Cognitive Traps**")
+      ("p < 0.05 ≠ penting")
+      ("p-hacking")
+      ("Limitation asal-asalan")
+```
--- a/assets/diagrams/bab-15-mindmap.md
+++ b/assets/diagrams/bab-15-mindmap.md
@ -0,0 +1,30 @@
+# Bab 15 — Mindmap (Gambar 15.2)
+
+```mermaid
+mindmap
+  root(("**Bab 15**<br/>Scientific<br/>Writing"))
+    ("**Argument Flow**")
+      ("Problem → Gap → RQ")
+      ("Method → Result")
+      ("Analysis → Conclusion")
+      ("Conclusion → Contribution")
+    ("**IMRAD**")
+      ("Introduction: Why")
+      ("Method: How")
+      ("Results: What")
+      ("Discussion: So what")
+      ("Conclusion: Therefore")
+    ("**Logical Flow**")
+      ("Within paragraph")
+      ("Between paragraphs")
+      ("Between sections")
+      ("Across paper")
+    ("**Writing Quality**")
+      ("Clarity — mudah dipahami")
+      ("Precision — tepat & spesifik")
+      ("Conciseness — tanpa redundansi")
+    ("**Cognitive Traps**")
+      ("Panjang ≠ lengkap")
+      ("Intro bukan ditulis pertama")
+      ("Discussion ≠ ulang Results")
+```
--- a/assets/diagrams/bab-15-scientific-argument-flow.md
+++ b/assets/diagrams/bab-15-scientific-argument-flow.md
@ -0,0 +1,30 @@
+# Bab 15 — Scientific Argument Flow (Gambar 15.1)
+
+```mermaid
+graph LR
+    A["❗ <b>Problem</b><br/><i>Masalah & motivasi</i>"]
+    B["🔍 <b>Gap</b><br/><i>Apa yang belum</i>"]
+    C["❓ <b>RQ</b><br/><i>Pertanyaan riset</i>"]
+    D["🔧 <b>Method</b><br/><i>Cara menjawab</i>"]
+    E["📊 <b>Result</b><br/><i>Temuan</i>"]
+    F["🧠 <b>Analysis</b><br/><i>Interpretasi</i>"]
+    G["📝 <b>Conclusion</b><br/><i>Jawaban & batasan</i>"]
+    H["💡 <b>Contribution</b><br/><i>Apa yang baru</i>"]
+
+    A -->|"Justifikasi"| B
+    B -->|"Fokus"| C
+    C -->|"Desain"| D
+    D -->|"Eksekusi"| E
+    E -->|"Interpretasi"| F
+    F -->|"Sintesis"| G
+    G -->|"Kontribusi"| H
+
+    style A fill:#F5F3FF,stroke:#7C3AED,color:#4C1D95
+    style B fill:#EDE9FE,stroke:#7C3AED,color:#4C1D95
+    style C fill:#DDD6FE,stroke:#7C3AED,color:#4C1D95
+    style D fill:#C4B5FD,stroke:#6D28D9,color:#4C1D95
+    style E fill:#A78BFA,stroke:#6D28D9,color:#FFFFFF
+    style F fill:#A78BFA,stroke:#6D28D9,color:#FFFFFF
+    style G fill:#7C3AED,stroke:#6D28D9,color:#FFFFFF
+    style H fill:#6D28D9,stroke:#4C1D95,color:#FFFFFF
+```
--- a/assets/diagrams/bab-16-mindmap.md
+++ b/assets/diagrams/bab-16-mindmap.md
@ -0,0 +1,30 @@
+# Bab 16 — Mindmap (Gambar 16.2)
+
+```mermaid
+mindmap
+  root(("**Bab 16**<br/>Presentation<br/>& Defense"))
+    ("**Defense Model**")
+      ("Research Work")
+      ("Presentation")
+      ("Questioning")
+      ("Defense")
+      ("Evaluation")
+    ("**Slide Design**")
+      ("1 slide = 1 pesan")
+      ("Visual over text")
+      ("Build progression")
+      ("Max 10-12 konten")
+    ("**Argumentation**")
+      ("Claim")
+      ("Evidence")
+      ("Reasoning")
+    ("**Handling Questions**")
+      ("Langsung jawab")
+      ("Data-based")
+      ("Jujur & akui batas")
+      ("Anticipatory defense")
+    ("**Cognitive Traps**")
+      ("Presentasi ≠ seluruh paper")
+      ("Indah ≠ efektif")
+      ("Tidak tahu ≠ gagal")
+```
--- a/assets/diagrams/bab-16-scientific-defense-model.md
+++ b/assets/diagrams/bab-16-scientific-defense-model.md
@ -0,0 +1,24 @@
+# Bab 16 — Scientific Defense Model (Gambar 16.1)
+
+```mermaid
+graph LR
+    A["📄 <b>Research<br/>Work</b><br/><i>Paper/laporan</i>"]
+    B["🎤 <b>Presentation</b><br/><i>Penyampaian</i>"]
+    C["❓ <b>Questioning</b><br/><i>Tanya audiens</i>"]
+    D["🛡️ <b>Defense</b><br/><i>Argumentasi</i>"]
+    E["📋 <b>Evaluation</b><br/><i>Penilaian</i>"]
+    F["✅ <b>Acceptance</b><br/><i>Pengakuan</i>"]
+
+    A -->|"Penyajian"| B
+    B -->|"Interaksi"| C
+    C -->|"Respons"| D
+    D -->|"Justifikasi"| E
+    E -->|"Keputusan"| F
+
+    style A fill:#F5F3FF,stroke:#7C3AED,color:#4C1D95
+    style B fill:#EDE9FE,stroke:#7C3AED,color:#4C1D95
+    style C fill:#DDD6FE,stroke:#7C3AED,color:#4C1D95
+    style D fill:#C4B5FD,stroke:#6D28D9,color:#4C1D95
+    style E fill:#A78BFA,stroke:#6D28D9,color:#FFFFFF
+    style F fill:#7C3AED,stroke:#6D28D9,color:#FFFFFF
+```
--- a/book/back-matter/daftar-pustaka.md
+++ b/book/back-matter/daftar-pustaka.md
@ -0,0 +1,83 @@
+# Daftar Pustaka
+
+> **Format:** APA 7th Edition | **Sorting:** Alphabetical by first author
+> Dikompilasi dari semua referensi per-bab (Bab 1–16).
+
+---
+
+ACM. (2018). *ACM Code of Ethics and Professional Conduct.* Association for Computing Machinery.
+
+Alley, M. (2013). *The Craft of Scientific Presentations* (2nd ed.). Springer.
+
+Anscombe, F. J. (1973). Graphs in Statistical Analysis. *The American Statistician*, 27(1), 17–21.
+
+Bass, L., Clements, P., & Kazman, R. (2012). *Software Architecture in Practice* (3rd ed.). Addison-Wesley.
+
+Cohen, J. (1988). *Statistical Power Analysis for the Behavioral Sciences* (2nd ed.). Lawrence Erlbaum.
+
+Creswell, J. W. (2012). *Educational Research: Planning, Conducting, and Evaluating Quantitative and Qualitative Research* (4th ed.). Pearson.
+
+Creswell, J. W., & Creswell, J. D. (2018). *Research Design: Qualitative, Quantitative, and Mixed Methods Approaches* (5th ed.). SAGE Publications.
+
+Few, S. (2012). *Show Me the Numbers: Designing Tables and Graphs to Enlighten* (2nd ed.). Analytics Press.
+
+Field, A. (2018). *Discovering Statistics Using IBM SPSS Statistics* (5th ed.). SAGE Publications.
+
+Glasman-Deal, H. (2020). *Science Research Writing: For Non-Native Speakers of English* (2nd ed.). World Scientific.
+
+Han, J., Kamber, M., & Pei, J. (2012). *Data Mining: Concepts and Techniques* (3rd ed.). Morgan Kaufmann.
+
+Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design Science in Information Systems Research. *MIS Quarterly*, 28(1), 75–105.
+
+Kitchenham, B. (2004). *Procedures for Performing Systematic Reviews*. Keele University Technical Report TR/SE-0401.
+
+Kuhn, M., & Johnson, K. (2013). *Applied Predictive Modeling*. Springer.
+
+Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007). A Design Science Research Methodology for Information Systems Research. *Journal of Management Information Systems*, 24(3), 45–77.
+
+Resnik, D. B. (2020). *The Ethics of Science: An Introduction* (2nd ed.). Routledge.
+
+Shadish, W. R., Cook, T. D., & Campbell, D. T. (2002). *Experimental and Quasi-Experimental Designs for Generalized Causal Inference*. Houghton Mifflin.
+
+Toulmin, S. E. (2003). *The Uses of Argument* (Updated ed.). Cambridge University Press.
+
+Tufte, E. R. (2001). *The Visual Display of Quantitative Information* (2nd ed.). Graphics Press.
+
+Webster, J., & Watson, R. T. (2002). Analyzing the Past to Prepare for the Future: Writing a Literature Review. *MIS Quarterly*, 26(2), xiii–xxiii.
+
+Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., & Wesslén, A. (2012). *Experimentation in Software Engineering*. Springer.
+
+Zobel, J. (2014). *Writing for Computer Science* (3rd ed.). Springer.
+
+---
+
+### Referensi per Bab
+
+| Referensi | Bab |
+|-----------|-----|
+| ACM (2018) | 1 |
+| Alley (2013) | 16 |
+| Anscombe (1973) | 12 |
+| Bass et al. (2012) | 6 |
+| Cohen (1988) | 14 |
+| Creswell (2012) | 1, 4, 7 |
+| Creswell & Creswell (2018) | 1, 2, 3, 4, 5, 8 |
+| Few (2012) | 12 |
+| Field (2018) | 5, 7, 10, 14 |
+| Glasman-Deal (2020) | 15, 16 |
+| Han et al. (2012) | 11, 13 |
+| Hevner et al. (2004) | 1, 2, 6, 7, 9 |
+| Kitchenham (2004) | 3 |
+| Kuhn & Johnson (2013) | 13 |
+| Peffers et al. (2007) | 2, 6, 7, 8 |
+| Resnik (2020) | 1 |
+| Shadish et al. (2002) | 1, 2, 4, 7, 10, 11, 14 |
+| Toulmin (2003) | 16 |
+| Tufte (2001) | 12 |
+| Webster & Watson (2002) | 3 |
+| Wohlin et al. (2012) | 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 13, 14, 15 |
+| Zobel (2014) | 15 |
+
+---
+
+<!-- STATUS: 🟢 Complete -->
--- a/book/back-matter/glosarium.md
+++ b/book/back-matter/glosarium.md
@ -0,0 +1,222 @@
+# Glosarium
+
+> Dikompilasi dari section "Definisi Kunci" setiap bab.
+> Disusun alfabet berdasarkan istilah Indonesia.
+
+---
+
+## A
+
+**Accuracy Data** (*Data Accuracy*)
+: Nilai data yang direkam mencerminkan nilai sebenarnya dari fenomena yang diukur. (Bab 11)
+
+**Anticipatory Defense** (*Pertahanan Antisipatif*)
+: Proses mengidentifikasi pertanyaan potensial sebelum presentasi dan menyiapkan jawaban berbasis bukti. (Bab 16)
+
+**Artifact** (*Artefak*)
+: Objek yang dirancang dan dibangun secara sengaja untuk menguji hipotesis riset — bukan produk akhir, melainkan instrumen eksperimen. (Bab 6)
+
+## B
+
+**Baseline**
+: Metode, algoritma, atau pendekatan pembanding yang diambil dari literatur sebagai acuan performa. (Bab 3)
+
+## C
+
+**Claim-Evidence-Reasoning (CER)**
+: Framework argumentasi ilmiah: klaim didukung bukti data, dihubungkan oleh penalaran logis. (Bab 16)
+
+**Completeness Data** (*Kelengkapan Data*)
+: Semua data yang direncanakan dalam execution plan tersedia — tidak ada run yang hilang atau variabel yang kosong tanpa penjelasan. (Bab 11)
+
+**Consistency Data** (*Konsistensi Data*)
+: Keseragaman format, skala, dan representasi di seluruh dataset. (Bab 11)
+
+**Construct Validity** (*Validitas Konstruk*)
+: Sejauh mana variabel yang diukur benar-benar merepresentasikan konsep yang dimaksud oleh peneliti. (Bab 5, 7)
+
+**Conclusion Validity** (*Validitas Kesimpulan*)
+: Sejauh mana kesimpulan statistik yang ditarik dari data benar-benar didukung oleh bukti numerik. (Bab 7)
+
+**Contribution Statement** (*Pernyataan Kontribusi*)
+: Deskripsi eksplisit tentang apa yang akan diketahui setelah riset selesai — gap mana yang diisi dan bagaimana. (Bab 4)
+
+## D
+
+**Data Cleaning** (*Pembersihan Data*)
+: Proses menangani missing values, duplikasi, dan format error dalam dataset mentah. (Bab 13)
+
+**Data Log** (*Catatan Data*)
+: Catatan terstruktur dari setiap run eksperimen yang mencatat parameter, waktu, dan hasil. (Bab 10)
+
+**Data Transformation** (*Transformasi Data*)
+: Proses mengubah representasi data — termasuk encoding kategorikal, agregasi, dan feature engineering. (Bab 13)
+
+**Defense** (*Pertahanan Ilmiah*)
+: Proses mempertahankan keputusan riset melalui sesi tanya-jawab menggunakan bukti dan argumentasi logis. (Bab 16)
+
+**Dependency** (*Dependensi*)
+: Komponen eksternal (library, framework, model pre-trained) yang dibutuhkan kode untuk berjalan. (Bab 9)
+
+## E
+
+**Environment Specification** (*Spesifikasi Lingkungan*)
+: Deskripsi lengkap hardware, software, dan dependency yang diperlukan untuk mereproduksi eksperimen. (Bab 9)
+
+**Etika Penelitian** (*Research Ethics*)
+: Prinsip kejujuran, objektivitas, keterbukaan, dan akuntabilitas dalam seluruh proses riset. (Bab 1)
+
+**Execution Plan** (*Rencana Eksekusi*)
+: Rencana konkret bagaimana eksperimen akan dijalankan — urutan skenario, jumlah run, parameter, dan prosedur. (Bab 10)
+
+**External Validity** (*Validitas Eksternal*)
+: Sejauh mana temuan eksperimen bisa digeneralisasi ke konteks, populasi, atau kondisi lain. (Bab 7)
+
+## F
+
+**Failure Analysis** (*Analisis Kegagalan*)
+: Proses sistematis menginvestigasi mengapa hipotesis ditolak atau hasil tidak sesuai harapan — mengidentifikasi boundary conditions dan penyebab. (Bab 14)
+
+## H
+
+**Hypothesis** (*Hipotesis*)
+: Prediksi spesifik tentang hubungan antar-variabel yang bisa diuji secara empiris, dirumuskan dalam pasangan H₀ (null) dan H₁ (alternatif). (Bab 4)
+
+## I
+
+**IMRAD**
+: Struktur standar paper ilmiah: Introduction, Method, Results, and Discussion. (Bab 15)
+
+**Internal Validity** (*Validitas Internal*)
+: Sejauh mana hubungan kausal yang diobservasi benar-benar berasal dari manipulasi variabel independen, bukan faktor lain. (Bab 7)
+
+**Interpretation** (*Interpretasi*)
+: Proses menghubungkan hasil analisis statistik dengan research question, konteks literatur, dan implikasi praktis. (Bab 14)
+
+## K
+
+**Kausalitas** (*Causality*)
+: Hubungan sebab-akibat yang memerlukan tiga syarat: kovariansi, temporal precedence, dan eliminasi alternatif. (Bab 7)
+
+**Konsistensi Internal** (*Internal Consistency*)
+: Keselarasan antar-bagian paper — istilah, variabel, RQ, dan temuan harus konsisten dari awal hingga akhir. (Bab 15)
+
+## L
+
+**Limitation** (*Batasan*)
+: Pengakuan eksplisit tentang batasan generalizability dan validitas riset — mencakup internal, external, construct, dan statistical. (Bab 14)
+
+**Literature Review** (*Tinjauan Pustaka*)
+: Proses sistematis mengidentifikasi, mengevaluasi, dan mensintesis studi-studi yang relevan untuk memposisikan riset. (Bab 3)
+
+**Logical Flow** (*Alir Logis*)
+: Koherensi argumen antar-kalimat, antar-paragraf, antar-bagian, dan antar-bab dalam tulisan ilmiah. (Bab 15)
+
+## M
+
+**Masalah Riset** (*Research Problem*)
+: Celah atau kontradiksi dalam pengetahuan yang memerlukan investigasi empiris. (Bab 2)
+
+**Metrik** (*Metric*)
+: Satuan pengukuran kuantitatif yang diturunkan dari operasionalisasi variabel. (Bab 5)
+
+**Minimal Distortion** (*Distorsi Minimal*)
+: Prinsip preprocessing: ubah data sesedikit mungkin — hanya lakukan transformasi yang diperlukan untuk analisis. (Bab 13)
+
+**Multiple Run** (*Pengulangan*)
+: Menjalankan setiap skenario eksperimen lebih dari satu kali (dengan seed berbeda) untuk menangkap variabilitas. (Bab 10)
+
+## N
+
+**Normalization** (*Normalisasi*)
+: Proses menyeragamkan skala variabel agar comparable — misalnya min-max scaling atau z-score standardization. (Bab 13)
+
+## O
+
+**Observasi Awal** (*Preliminary Observation*)
+: Pola yang terlihat dari visualisasi data sebelum dikonfirmasi oleh uji statistik formal. (Bab 12)
+
+**Operasionalisasi** (*Operationalization*)
+: Transformasi konsep abstrak menjadi variabel terukur yang bisa diobservasi dan dikuantifikasi. (Bab 5)
+
+## P
+
+**Paradigma Penelitian** (*Research Paradigm*)
+: Kerangka filosofis (ontologi dan epistemologi) yang mendasari cara peneliti memandang realitas dan pengetahuan. (Bab 1)
+
+**Precision** (*Ketepatan*)
+: Penggunaan istilah yang tepat dan tanpa ambiguitas dalam tulisan ilmiah. (Bab 15)
+
+**Problem Statement** (*Pernyataan Masalah*)
+: Formulasi tertulis masalah riset yang mencakup konteks, gap, dan signifikansi. (Bab 2)
+
+## R
+
+**Repeatability** (*Keterulangan*)
+: Kemampuan mendapatkan hasil yang sama ketika eksperimen diulang oleh peneliti yang sama dalam environment yang sama. (Bab 9)
+
+**Reproducibility** (*Reprodusibilitas*)
+: Kemampuan mendapatkan hasil yang sama ketika eksperimen diulang oleh orang lain dalam environment yang berbeda. (Bab 9)
+
+**Research Gap** (*Celah Penelitian*)
+: Celah dalam pengetahuan ilmiah yang belum dijawab oleh studi yang ada — bisa berupa performance, method, data, atau context gap. (Bab 3)
+
+**Research Mindset** (*Pola Pikir Riset*)
+: Pola pikir yang menuntut bukti empiris dan mengevaluasi setiap klaim secara kritis. (Bab 1)
+
+**Research Position** (*Posisi Penelitian*)
+: Pernyataan eksplisit tentang perbedaan riset dari studi-studi sebelumnya. (Bab 3)
+
+**Research Question (RQ)** (*Pertanyaan Riset*)
+: Pertanyaan spesifik dengan variabel dan metrik eksplisit yang menjadi fokus investigasi eksperimental. (Bab 4)
+
+**Run Traceability** (*Ketertelusuran Run*)
+: Kemampuan menghubungkan setiap data point ke run spesifik yang menghasilkannya. (Bab 10)
+
+## S
+
+**Scientific Presentation** (*Presentasi Ilmiah*)
+: Penyampaian riset secara lisan menggunakan slide dengan prinsip "1 slide = 1 pesan." (Bab 16)
+
+**Skala Pengukuran** (*Measurement Scale*)
+: Empat level pengukuran — nominal, ordinal, interval, ratio — yang menentukan operasi statistik yang valid. (Bab 5)
+
+**Statistical Analysis** (*Analisis Statistik*)
+: Proses pengujian hipotesis menggunakan uji statistik, effect size, dan confidence interval. (Bab 14)
+
+**Structured Presentation** (*Penyajian Terstruktur*)
+: Penyajian data eksperimen dalam bentuk tabel yang terorganisasi dengan format konsisten. (Bab 12)
+
+**System Context** (*Konteks Sistem*)
+: Deskripsi lingkungan sistem meliputi input, process, output, outcome, constraints, dan stakeholders. (Bab 2)
+
+## T
+
+**Topik Riset** (*Research Topic*)
+: Area bidang umum yang menjadi starting point sebelum dipertajam menjadi masalah riset. (Bab 2)
+
+**Traceability** (*Ketertelusuran*)
+: Hubungan yang bisa ditelusuri antara RQ, variabel, komponen sistem, dan output. (Bab 6)
+
+## V
+
+**Validitas** (*Validity*)
+: Sejauh mana hubungan antara variabel mencerminkan realitas — bukan artefak dari desain yang cacat. (Bab 1)
+
+**Validitas Logis** (*Logical Validity*)
+: Data konsisten dengan desain eksperimen — variabel dependen berada dalam range yang masuk akal. (Bab 11)
+
+**Variable Isolation** (*Isolasi Variabel*)
+: Prinsip "ubah satu, kontrol sisanya" — hanya variabel independen yang berubah antar-kondisi. (Bab 6)
+
+**Visualization** (*Visualisasi*)
+: Representasi grafis data untuk mengungkap pola dan tren yang sulit terlihat dari tabel numerik. (Bab 12)
+
+**Visualization Bias** (*Bias Visualisasi*)
+: Distorsi persepsi yang disebabkan oleh desain grafik — truncated axis, cherry-picked data, missing error bar. (Bab 12)
+
+---
+
+**Total: 60 istilah dari 16 bab**
+
+<!-- STATUS: 🟢 Complete -->
--- a/book/back-matter/indeks.md
+++ b/book/back-matter/indeks.md
@ -0,0 +1,173 @@
+# Indeks
+
+> Indeks disusun berdasarkan konsep utama.
+> Angka merujuk pada nomor bab tempat konsep dibahas secara substantif.
+
+---
+
+## A
+
+- **Accuracy** → lihat *Validitas Data*
+- **Analisis data** — 12, 14
+- **Analisis kegagalan** (*failure analysis*) — 14
+- **APA 7th Edition** — 15
+- **Artefak** (*artifact*) — 6, 9
+- **Argumentasi ilmiah** — 15, 16
+
+## B
+
+- **Baseline** — 3, 5, 7
+- **Bias visualisasi** — 12
+
+## C
+
+- **Claim-Evidence-Reasoning (CER)** — 16
+- **Completeness** → lihat *Validitas Data*
+- **Conclusion validity** — 7, 14
+- **Confounding variable** — 7
+- **Construct validity** — 5, 7
+- **Contribution statement** — 4
+- **Cross-validation** — 14
+
+## D
+
+- **Data cleaning** — 13
+- **Data collection** — 10
+- **Data log** — 10
+- **Data preprocessing** — 13
+- **Data transformation** — 13
+- **Data trust** — 11
+- **Defense** (*pertahanan ilmiah*) — 16
+- **Dependency** — 9
+- **Desain eksperimen** — 7
+- **Distorsi minimal** — 13
+
+## E
+
+- **Effect size** — 14
+- **Environment specification** — 9
+- **Etika penelitian** — 1
+- **Execution plan** — 10
+- **Eksperimen** — 7, 10
+- **External validity** — 7
+
+## F
+
+- **Failure analysis** — 14
+- **Feature engineering** — 13
+
+## G
+
+- **Gap** → lihat *Research Gap*
+- **Generalizability** — 7, 14
+
+## H
+
+- **Hipotesis** (*hypothesis*) — 4, 7, 14
+- **H₀ dan H₁** — 4, 14
+
+## I
+
+- **IMRAD** — 15
+- **Internal consistency** — 15
+- **Internal validity** — 7
+- **Interpretasi** — 14
+- **Isolasi variabel** — 6, 7
+
+## K
+
+- **Kausalitas** (*causality*) — 7
+- **Konsistensi data** — 11
+- **Konteks sistem** (*system context*) — 2
+
+## L
+
+- **Limitation** (*batasan*) — 14
+- **Literature review** — 3
+- **Logical flow** — 15
+
+## M
+
+- **Masalah riset** (*research problem*) — 2
+- **Metrik** (*metric*) — 5
+- **Mindset riset** — 1
+- **Missing value** — 13
+- **Multiple run** — 10
+
+## N
+
+- **Normalisasi** (*normalization*) — 13
+- **Null hypothesis** → lihat *Hipotesis*
+
+## O
+
+- **Observasi awal** — 12
+- **Operasionalisasi** (*operationalization*) — 5
+- **Outlier** — 13
+
+## P
+
+- **p-value** — 14
+- **Paradigma penelitian** — 1
+- **Paper ilmiah** — 15
+- **Precision** (*ketepatan bahasa*) — 15
+- **Problem statement** — 2
+- **Proposal** — 8
+
+## R
+
+- **Randomization** — 7
+- **Repeatability** — 9
+- **Reproducibility** — 9
+- **Research gap** — 3
+- **Research mindset** — 1
+- **Research position** — 3
+- **Research question (RQ)** — 4
+- **Result presentation** — 12
+- **Run traceability** — 10
+
+## S
+
+- **Scientific presentation** — 16
+- **Seed** (*random seed*) — 10
+- **Signifikansi statistik** — 14
+- **Skala pengukuran** — 5
+- **Statistical analysis** — 14
+- **Structured presentation** — 12
+- **System context** — 2
+- **System design** — 6
+
+## T
+
+- **Threat to validity** — 7, 14
+- **Topik riset** — 2
+- **Traceability** — 6, 10
+- **Transformasi data** — 13
+- **Tufte, Edward** — 12
+
+## U
+
+- **Uji statistik** — 14
+
+## V
+
+- **Validitas** (*validity*) — 1, 7
+- **Validitas data** — 11
+- **Validitas konstruk** → lihat *Construct Validity*
+- **Validitas logis** — 11
+- **Variabel dependen** — 5, 7
+- **Variabel independen** — 5, 7
+- **Variable isolation** — 6, 7
+- **Visualisasi** — 12
+
+## W
+
+- **Wohlin et al.** — 1, 3, 4, 5, 6, 7, 9, 10, 11, 12, 13, 14, 15, 16
+
+---
+
+**Total: ~90 entri indeks dari 16 bab**
+
+> *Nomor halaman akan menggantikan nomor bab pada tahap layout final.*
+
+<!-- STATUS: 🟢 Complete -->
--- a/book/back-matter/lampiran-templates.md
+++ b/book/back-matter/lampiran-templates.md
@ -0,0 +1,561 @@
+# Lampiran A — Kumpulan Template Praktis
+
+> Template-template dari setiap bab dikumpulkan di sini untuk referensi cepat.
+> Setiap template merujuk ke bab asalnya untuk konteks dan penjelasan lengkap.
+
+---
+
+## Daftar Template
+
+| # | Nama Template | Dari Bab | Bagian |
+|---|---------------|----------|--------|
+| A.1 | Research Mindset Self-Assessment | Bab 1 | I |
+| A.2 | Problem Statement Builder | Bab 2 | I |
+| A.3 | Literature Mapping & Gap Identification | Bab 3 | I |
+| A.4 | RQ-Contribution-Hypothesis | Bab 4 | I |
+| A.5 | Definisi Variabel, Metrik & Justifikasi | Bab 5 | II |
+| A.6 | Mapping RQ ke Arsitektur Sistem | Bab 6 | II |
+| A.7 | Desain Eksperimen Lengkap | Bab 7 | II |
+| A.8 | Integration Checklist (Proposal Checkpoint) | Bab 8 | III |
+| A.9 | Dokumentasi Setup Eksperimen | Bab 9 | III |
+| A.10 | Execution Plan & Data Log | Bab 10 | III |
+| A.11 | Data Validation Checklist | Bab 11 | III |
+| A.12 | Result Presentation Plan | Bab 12 | IV |
+| A.13 | Preprocessing Documentation Log | Bab 13 | IV |
+| A.14 | Analysis & Interpretation Report | Bab 14 | IV |
+| A.15 | Paper Structure Checklist | Bab 15 | IV |
+| A.16 | Defense Preparation Sheet | Bab 16 | IV |
+
+---
+
+> **Catatan penggunaan:**
+> Setiap template dirancang untuk diisi secara progresif seiring kemajuan riset. Template dari Bagian I (Bab 1–4) menghasilkan fondasi yang digunakan oleh template Bagian II (Bab 5–7), dan seterusnya. Untuk konteks lengkap, penjelasan setiap field, dan contoh pengisian, rujuk ke section "Template Praktis" di bab masing-masing.
+
+---
+
+## A.1 — Research Mindset Self-Assessment (Bab 1)
+
+```
+Nama Peneliti    : ____________________
+Tanggal          : ____________________
+
+1. Ketika membaca klaim "metode X 95% akurat":
+   - Pertanyaan pertama saya: ____________________
+   - Data apa yang saya butuhkan untuk memverifikasi: ____________________
+
+2. Posisi paradigma:
+   - Pendekatan saya: [ ] Positivis  [ ] Interpretivis  [ ] Design Science  [ ] Mixed
+   - Alasan: ____________________
+
+3. Identifikasi distorsi:
+   - Asumsi tersembunyi dalam riset saya: ____________________
+   - Sumber bias potensial: ____________________
+   - Langkah mitigasi: ____________________
+
+4. Komitmen etika:
+   - Data yang saya tidak akan manipulasi: ____________________
+   - Batasan yang saya akui sejak awal: ____________________
+```
+
+---
+
+## A.2 — Problem Statement Builder (Bab 2)
+
+```
+PROBLEM STATEMENT BUILDER
+
+Domain & Konteks
+  Domain   : ____________________
+  Konteks  : ____________________
+
+System Context
+  Input       : ____________________
+  Process     : ____________________
+  Output      : ____________________
+  Outcome     : ____________________
+  Constraints : ____________________
+  Stakeholders: ____________________
+
+Fenomena → Problem
+  Fenomena yang diamati             : ____________________
+  Gejala (symptom) yang terukur     : ____________________
+  Masalah yang didiagnosis          : ____________________
+  Masalah riset (researchable)      : ____________________
+  Variabel yang terukur             : ____________________
+
+Problem Quality Check
+  [  ] Clarity — Apakah satu orang membaca akan paham?
+  [  ] Measurability — Apakah ada metrik kuantitatif?
+  [  ] Relevance — Apakah penting untuk domain?
+  [  ] Testability — Apakah bisa gagal?
+  [  ] Impact — Apakah ada kontribusi jika terjawab?
+
+Problem Statement (1 paragraf):
+  ____________________
+```
+
+---
+
+## A.3 — Literature Mapping & Gap Identification (Bab 3)
+
+```
+LITERATURE MAPPING
+
+Topik      : ____________________
+Database   : ____________________
+Query      : ____________________
+Tahun      : ____________________
+Hasil awal : ____ paper → Screening → ____ paper final
+
+Literature Matrix (concept-centric):
+
+| Study | Tahun | Method | Data | Result | Limitation |
+|-------|-------|--------|------|--------|------------|
+|       |       |        |      |        |            |
+|       |       |        |      |        |            |
+
+Pola yang ditemukan:
+  Metode dominan     : ____________________
+  Dataset umum       : ____________________
+  Limitasi berulang  : ____________________
+
+GAP IDENTIFICATION
+
+Gap 1: [Jenis: performance / method / data / context]
+  Deskripsi : ____________________
+  Bukti     : ____________________
+  Signifikansi: ____________________
+
+Gap 2: [Jenis: ____]
+  Deskripsi : ____________________
+  Bukti     : ____________________
+  Signifikansi: ____________________
+
+Baseline Selection:
+| Baseline | Relevansi | Representatif | Source |
+|----------|-----------|---------------|--------|
+|          |           |               |        |
+|          |           |               |        |
+```
+
+---
+
+## A.4 — RQ-Contribution-Hypothesis (Bab 4)
+
+```
+RQ-CONTRIBUTION-HYPOTHESIS
+
+Gap Statement  : ____________________
+
+Research Question:
+  Tipe         : [ ] Comparison  [ ] Improvement  [ ] Exploratory
+  Formulasi    : ____________________
+  Variabel IV  : ____________________
+  Variabel DV  : ____________________
+  Metrik       : ____________________
+  Dataset      : ____________________
+  Baseline     : ____________________
+
+Quality Check RQ:
+  [  ] Variabel spesifik
+  [  ] Metrik jelas
+  [  ] Baseline ada
+  [  ] Konteks disebutkan
+  [  ] Memerlukan eksperimen (bukan hanya survei literatur)
+
+Contribution Statement:
+  Apa yang baru diketahui : ____________________
+  Jenis kontribusi        : [ ] Improvement  [ ] Comparison  [ ] Novel approach
+  Gap yang diisi          : ____________________
+
+Hypothesis Pair:
+  H₀ : ____________________
+  H₁ : ____________________
+  Threshold              : ____________________
+  Justifikasi threshold  : ____________________
+```
+
+---
+
+## A.5 — Definisi Variabel, Metrik & Justifikasi (Bab 5)
+
+```
+VARIABLE & METRIC DEFINITION
+
+Research Question: ____________________
+
+| Variabel | Tipe | Konsep | Metrik | Skala | Satuan | Cara Mengukur | Justifikasi |
+|----------|------|--------|--------|-------|--------|---------------|-------------|
+|          | IV   |        |        |       |        |               |             |
+|          | DV   |        |        |       |        |               |             |
+|          | CV   |        |        |       |        |               |             |
+
+Alignment Check:
+  RQ → Concept → Variable → Metric → Data → Result
+  [  ] Setiap langkah terdokumentasi
+  [  ] Tidak ada "lompatan logis"
+  [  ] Metrik mengukur apa yang dimaksud (construct validity)
+```
+
+---
+
+## A.6 — Mapping RQ ke Arsitektur Sistem (Bab 6)
+
+```
+SYSTEM-EXPERIMENT MAPPING
+
+Research Question: ____________________
+
+Variable → Component Mapping:
+| Variabel | Tipe | Komponen Sistem | Cara Manipulasi/Pengukuran |
+|----------|------|-----------------|---------------------------|
+|          | IV   |                 |                           |
+|          | DV   |                 |                           |
+|          | CV   |                 |                           |
+
+4 Prinsip Desain:
+  [  ] Traceability — Setiap komponen bisa ditelusuri ke variabel
+  [  ] Variable Isolation — IV bisa diubah tanpa mengubah CV
+  [  ] Measurement Integration — Pengukuran DV built-in
+  [  ] Reproducibility — Setup bisa direkonstruksi
+
+Experimental Setup:
+  Input data     : ____________________
+  Parameter      : ____________________
+  Output format  : ____________________
+```
+
+---
+
+## A.7 — Desain Eksperimen Lengkap (Bab 7)
+
+```
+EXPERIMENT DESIGN
+
+Research Question : ____________________
+Hypothesis        : ____________________
+Tipe Eksperimen   : [ ] Comparison  [ ] Ablation  [ ] Parameter
+
+Kondisi Eksperimen:
+| Kondisi | Deskripsi | IV Value | CV Settings |
+|---------|-----------|----------|-------------|
+| Control |           |          |             |
+| Treatment |         |          |             |
+
+Fairness Checklist:
+  [  ] Dataset identik untuk semua kondisi
+  [  ] Preprocessing setara
+  [  ] Tuning effort setara
+  [  ] Environment identik
+  [  ] Metrik evaluasi sama
+
+Threat Analysis:
+| Threat Type | Ancaman Spesifik | Mitigasi |
+|-------------|-----------------|----------|
+| Internal    |                 |          |
+| External    |                 |          |
+| Construct   |                 |          |
+| Conclusion  |                 |          |
+
+Statistical Plan:
+  Uji statistik   : ____________________
+  Justifikasi      : ____________________
+  Alpha            : ____________________
+  Effect size min  : ____________________
+```
+
+---
+
+## A.8 — Integration Checklist / Proposal Checkpoint (Bab 8)
+
+```
+PROPOSAL INTEGRATION CHECKLIST
+
+Koneksi Vertikal (Flow Atas-Bawah):
+  [  ] Problem → Gap: masalah terdokumentasi di literatur
+  [  ] Gap → RQ: pertanyaan menjawab gap spesifik
+  [  ] RQ → Hypothesis: hipotesis memprediksi jawaban
+  [  ] Hypothesis → Metric: metrik mengukur variabel dalam hipotesis
+  [  ] Metric → System: komponen sistem menghasilkan/mengukur metrik
+  [  ] System → Experiment: desain eksperimen menggunakan sistem
+
+Koneksi Horizontal (Konsistensi):
+  [  ] Istilah sama di semua bagian
+  [  ] Variabel yang disebut di RQ = variabel di hipotesis = metrik di desain
+  [  ] Scope tidak berubah dari masalah ke eksperimen
+
+Rubrik Self-Assessment:
+| Kriteria | 1 (Lemah) | 2 (Cukup) | 3 (Baik) | Skor |
+|----------|-----------|-----------|----------|------|
+| Koherensi |          |           |          |      |
+| Specificity |        |           |          |      |
+| Feasibility |        |           |          |      |
+| Rigor     |          |           |          |      |
+```
+
+---
+
+## A.9 — Dokumentasi Setup Eksperimen (Bab 9)
+
+```
+EXPERIMENT SETUP DOCUMENTATION
+
+Hardware:
+  CPU  : ____________________
+  RAM  : ____________________
+  GPU  : ____________________
+  Storage: ____________________
+
+Software:
+  OS      : ____________________
+  Runtime : ____________________
+  Framework: ____________________
+
+Dependencies:
+| Library | Version | Sumber | Hash/Checksum |
+|---------|---------|--------|---------------|
+|         |         |        |               |
+
+Konfigurasi:
+  Config file    : ____________________
+  Seed           : ____________________
+  Hyperparameters: ____________________
+
+Reproducibility Check:
+  [  ] Dependency terdokumentasi (requirements.txt / lock file)
+  [  ] Seed ditetapkan
+  [  ] Config di version control
+  [  ] README instruksi reproduksi
+```
+
+---
+
+## A.10 — Execution Plan & Data Log (Bab 10)
+
+```
+EXECUTION PLAN
+
+| Run # | Skenario | Seed | Parameter | Status | Waktu | Output File |
+|-------|----------|------|-----------|--------|-------|-------------|
+| 1     |          |      |           |        |       |             |
+| 2     |          |      |           |        |       |             |
+| ...   |          |      |           |        |       |             |
+
+Jumlah runs per skenario : ____
+Total runs               : ____
+
+DATA LOG (per run):
+  Run ID     : ____________________
+  Timestamp  : ____________________
+  Skenario   : ____________________
+  Input      : ____________________
+  Output     : ____________________
+  Anomali    : ____________________
+  Catatan    : ____________________
+```
+
+---
+
+## A.11 — Data Validation Checklist (Bab 11)
+
+```
+DATA VALIDATION CHECKLIST
+
+Completeness:
+  [  ] Semua skenario tercakup
+  [  ] Jumlah run sesuai rencana
+  [  ] Tidak ada file output yang hilang
+  Missing: ____ dari ____ data points
+
+Format Consistency:
+  [  ] Semua file format sama (CSV/JSON/...)
+  [  ] Header konsisten
+  [  ] Tipe data konsisten (numerik tetap numerik)
+
+Range & Logic:
+  [  ] Nilai dalam range yang masuk akal
+  [  ] Tidak ada waktu negatif
+  [  ] Akurasi 0–100%, bukan di luar range
+  Anomali ditemukan: ____________________
+
+Cross-Validation:
+  [  ] Run identik → hasil mendekati (tidak beda ordo magnitudo)
+  [  ] Trend konsisten dengan ekspektasi teori (jika ada)
+
+Keputusan:
+  [  ] Data siap analisis
+  [  ] Perlu cleaning (lihat Bab 13)
+  [  ] Perlu re-run (skenario: ____)
+```
+
+---
+
+## A.12 — Result Presentation Plan (Bab 12)
+
+```
+RESULT PRESENTATION PLAN
+
+Research Question: ____________________
+Metrik Utama     : ____________________
+
+Tabel Hasil:
+| Skenario | Metrik 1 (mean ± std) | Metrik 2 (mean ± std) | n |
+|----------|----------------------|----------------------|---|
+|          |                      |                      |   |
+
+Visualisasi yang Direncanakan:
+| # | Jenis Grafik | Pesan Utama | Metrik |
+|---|-------------|-------------|--------|
+| 1 |             |             |        |
+| 2 |             |             |        |
+
+Bias Check:
+  [  ] Y-axis mulai dari 0 (atau dijustifikasi)
+  [  ] Error bar/CI ditampilkan
+  [  ] Semua data disertakan (tidak cherry-picked)
+  [  ] Tidak menggunakan 3D tanpa alasan
+```
+
+---
+
+## A.13 — Preprocessing Documentation Log (Bab 13)
+
+```
+PREPROCESSING LOG
+
+Dataset          : ____________________
+Jumlah data awal : ____________________
+
+Cleaning:
+| Masalah | Jumlah Kasus | Penanganan | Justifikasi |
+|---------|-------------|------------|-------------|
+| Missing |             |            |             |
+| Duplikat|             |            |             |
+| Error   |             |            |             |
+
+Transformation:
+| Transformasi | Variabel | Detail | Alasan |
+|-------------|----------|--------|--------|
+|             |          |        |        |
+
+Normalization:
+  Metode    : ____________________
+  Alasan    : ____________________
+  Parameter : (dihitung dari: training set / seluruh data)
+
+Leakage Check:
+  [  ] Parameter normalisasi dari training set saja
+  [  ] Tidak ada informasi test set dalam preprocessing
+  [  ] Cross-validation dilakukan setelah split
+
+Jumlah data akhir: ____________________
+Script tersedia  : [ ] Ya → path: ____ | [ ] Belum
+```
+
+---
+
+## A.14 — Analysis & Interpretation Report (Bab 14)
+
+```
+ANALYSIS & INTERPRETATION
+
+1. Statistik Deskriptif:
+   | Skenario | Mean | Std | Median | Min | Max | n |
+   |----------|------|-----|--------|-----|-----|---|
+   |          |      |     |        |     |     |   |
+
+2. Uji Hipotesis:
+   Uji yang digunakan : ____________________
+   Justifikasi        : ____________________
+   Hasil: p = ____, effect size (d/r/η²) = ____
+   CI 95%             : [____, ____]
+
+3. Keputusan:
+   [  ] H₀ ditolak → H₁ diterima
+   [  ] H₀ tidak ditolak
+
+4. Interpretasi:
+   Hubungan ke RQ     : ____________________
+   Practical significance: ____________________
+   Perbandingan literatur: ____________________
+
+5. Limitation:
+   | Jenis | Ancaman | Dampak | Mitigasi |
+   |-------|---------|--------|----------|
+   |       |         |        |          |
+
+6. Failure Analysis (jika H₀ tidak ditolak):
+   Penyebab potensial: ____________________
+   Boundary condition : ____________________
+   Insight            : ____________________
+```
+
+---
+
+## A.15 — Paper Structure Checklist (Bab 15)
+
+```
+PAPER STRUCTURE CHECKLIST
+
+Title  : ____________________
+Target : [ ] Jurnal  [ ] Konferensi  [ ] Laporan
+
+Section Check:
+  [  ] Abstract — masalah, metode, hasil utama, kontribusi (max 250 kata)
+  [  ] Introduction — konteks → gap → RQ → kontribusi → struktur paper
+  [  ] Related Work — concept-centric, gap positioning
+  [  ] Method — reproducible: desain, variabel, metrik, setup, prosedur
+  [  ] Results — tabel + grafik + observasi (tanpa interpretasi)
+  [  ] Discussion — interpretasi, perbandingan, implikasi, limitation
+  [  ] Conclusion — jawaban RQ, kontribusi, future work
+
+Consistency Matrix:
+  [  ] RQ di Introduction = RQ di Method = RQ di Conclusion
+  [  ] Variabel di Method = variabel di Results
+  [  ] Klaim di Discussion didukung data di Results
+  [  ] Limitasi di Discussion diaddress di Conclusion/Future Work
+
+Writing Quality:
+  [  ] Clarity — mudah dipahami tanpa re-read
+  [  ] Precision — tidak ada istilah ambigu
+  [  ] Conciseness — tidak ada kalimat redundan
+```
+
+---
+
+## A.16 — Defense Preparation Sheet (Bab 16)
+
+```
+DEFENSE PREPARATION
+
+Slide Deck Plan:
+  Total slides : ____ (target: 10–12 konten + title/closing)
+  Time per slide: ~2 min
+  Total time    : ____ menit
+
+Slide Outline:
+| # | Pesan Utama | Visual | Waktu |
+|---|-------------|--------|-------|
+| 1 | Title       |        | 30s   |
+| 2 | Problem & Motivation |  | 2min  |
+| 3 | Research Gap |       | 2min  |
+| ...| ...        |        |       |
+
+Anticipatory Defense Matrix:
+| Kategori | Pertanyaan Potensial | Jawaban (data-based) |
+|----------|---------------------|---------------------|
+| Problem  |                     |                     |
+| Gap      |                     |                     |
+| Method   |                     |                     |
+| Results  |                     |                     |
+| Generalization |               |                     |
+
+Latihan:
+  Latihan 1: [tanggal] — [catatan timing & feedback]
+  Latihan 2: [tanggal] — [catatan timing & feedback]
+  Latihan 3: [tanggal] — [catatan timing & feedback]
+```
+
+---
+
+<!-- STATUS: 🟢 Complete -->
--- a/book/back-matter/lampiran-worksheet.md
+++ b/book/back-matter/lampiran-worksheet.md
@ -0,0 +1,275 @@
+# Lampiran B — Worksheet
+
+> Worksheet untuk latihan hands-on dari setiap bab.
+> Setiap worksheet mengacu ke section "Latihan & Refleksi" di bab masing-masing.
+
+---
+
+## Daftar Worksheet
+
+| # | Nama Worksheet | Dari Bab | Jumlah Latihan |
+|---|---------------|----------|----------------|
+| B.1 | Distorsi & Paradigma | Bab 1 | 3 latihan + 1 refleksi |
+| B.2 | Problem Statement | Bab 2 | 2 refleksi + 2 praktis |
+| B.3 | Literature Mapping & Gap | Bab 3 | 3 latihan + 1 refleksi |
+| B.4 | RQ & Hypothesis | Bab 4 | 3 latihan + 1 refleksi |
+| B.5 | Variabel & Metrik | Bab 5 | 3 latihan + 1 refleksi |
+| B.6 | System-Experiment Mapping | Bab 6 | 3 latihan + 1 refleksi |
+| B.7 | Experimental Design & Validity | Bab 7 | 3 latihan + 1 refleksi |
+| B.8 | Proposal Integration | Bab 8 | 3 latihan + 1 refleksi |
+| B.9 | Implementation & Reproducibility | Bab 9 | 3 latihan + 1 refleksi |
+| B.10 | Execution & Data Collection | Bab 10 | 3 latihan + 1 refleksi |
+| B.11 | Data Validation | Bab 11 | 3 latihan + 1 refleksi |
+| B.12 | Result Presentation | Bab 12 | 3 latihan + 1 refleksi |
+| B.13 | Preprocessing | Bab 13 | 3 latihan + 1 refleksi |
+| B.14 | Analysis & Interpretation | Bab 14 | 3 latihan + 1 refleksi |
+| B.15 | Scientific Writing | Bab 15 | 3 latihan + 1 refleksi |
+| B.16 | Presentation & Defense | Bab 16 | 3 latihan + 1 refleksi |
+
+---
+
+> **Cara penggunaan:**
+> Setiap worksheet terdiri dari 3 latihan progresif (dari dasar ke advanced) dan 1 pertanyaan refleksi.
+> Latihan dirancang untuk dikerjakan berurutan — output latihan sebelumnya menjadi input latihan berikutnya.
+> Untuk instruksi lengkap, rujuk ke section "Latihan & Refleksi" di bab masing-masing.
+
+---
+
+## B.1 — Distorsi & Paradigma (Bab 1)
+
+**Latihan 1 — Identifikasi Distorsi**
+Pilih satu paper riset di bidang TI yang mengklaim "metode X meningkatkan performa." Telusuri setiap tahap Research Trust Model (Reality → Data → Processing → Analysis → Inference → Knowledge). Di tahap mana potensi distorsi paling besar? Identifikasi minimal 2 distorsi spesifik.
+
+**Latihan 2 — Analisis Kasus Etika**
+Sebuah peneliti menemukan bahwa jika 3 data point outlier dihapus, hasil eksperimennya menjadi signifikan. Dengan outlier, hasilnya tidak signifikan. Apa yang seharusnya dilakukan? Analisis dari perspektif: (a) kejujuran ilmiah, (b) transparansi, (c) peer review.
+
+**Latihan 3 — Posisi Paradigma Anda**
+Tentukan paradigma riset yang paling sesuai dengan topik Anda: positivis, interpretivis, atau design science. Jelaskan: (a) mengapa paradigma tersebut sesuai, (b) bagaimana paradigma tersebut memengaruhi jenis data yang Anda kumpulkan, dan (c) apa limitasi paradigma tersebut.
+
+**Refleksi:** *"Sebelum membaca bab ini, apakah saya pernah mempertanyakan klaim '95% akurat'? Setelah memahami rantai distorsi, pertanyaan apa yang sekarang akan saya ajukan?"*
+
+---
+
+## B.2 — Problem Statement (Bab 2)
+
+**Refleksi 1:** Tuliskan topik riset Anda dalam satu kalimat. Sekarang bedakan: apakah itu masalah riset atau solusi yang disamarkan sebagai masalah? Jika itu solusi, mundur satu langkah — apa masalah yang mendasari?
+
+**Refleksi 2:** Identifikasi system context dari masalah Anda: input, process, output, outcome, constraints, stakeholders. Field mana yang paling sulit diisi? Mengapa?
+
+**Praktis 1:** Gunakan Problem Statement Builder (Template A.2) untuk merumuskan masalah riset Anda. Jalankan melalui Problem Formation Model: Reality → Symptom → Diagnosed Problem → Researchable Problem → Measurable Variable.
+
+**Praktis 2:** Evaluasi problem statement Anda menggunakan Problem Quality Model (5 kriteria: clarity, measurability, relevance, testability, impact). Minta satu rekan mengevaluasi secara independen — bandingkan skor.
+
+---
+
+## B.3 — Literature Mapping & Gap (Bab 3)
+
+**Latihan 1 — Concept-Centric Literature Table**
+Pilih satu topik riset TI. Cari 10 paper dari IEEE Xplore atau Google Scholar (2020–2025). Buatlah tabel literature mapping (Study, Method, Dataset, Result, Limitasi) — bukan ringkasan per paper. Identifikasi pola: metode apa yang dominan? Limitasi apa yang berulang?
+
+**Latihan 2 — Gap Identification**
+Dari tabel di Latihan 1, identifikasi minimal dua jenis gap (dari empat jenis: performance, method, data, context). Tuliskan gap statement yang spesifik dan berikan justifikasi mengapa gap tersebut penting.
+
+**Latihan 3 — Baseline Selection Challenge**
+Untuk gap yang diidentifikasi, pilih 3 baseline yang fair. Jelaskan untuk setiap baseline: (a) mengapa relevan, (b) mengapa representatif, dan (c) dari paper mana diambil. Evaluasi apakah baseline cukup kuat — atau apakah Anda melakukan "straw man comparison."
+
+**Refleksi:** *"Sebelum membaca bab ini, bagaimana cara saya membaca paper? Apakah saya merangkum atau menganalisis? Apa yang akan saya ubah?"*
+
+---
+
+## B.4 — RQ & Hypothesis (Bab 4)
+
+**Latihan 1 — Dari Gap ke RQ**
+Ambil gap statement dari Latihan 2 Worksheet B.3. Transformasikan menjadi research question yang memenuhi lima kriteria: variabel spesifik, metrik jelas, baseline ada, konteks disebutkan, dan memerlukan eksperimen. Tentukan jenis RQ-nya.
+
+**Latihan 2 — Contribution Statement**
+Untuk RQ dari Latihan 1, tulis contribution statement: (a) apa yang akan diketahui, (b) jenis contribution, dan (c) gap spesifik mana yang diisi.
+
+**Latihan 3 — Hypothesis Pair**
+Formulasikan pasangan H₀ dan H₁ dari RQ di Latihan 1. Tentukan threshold dan justifikasinya. Pastikan hipotesis bisa gagal — jika tidak bisa gagal, reformulasi.
+
+**Refleksi:** *"Apakah research question saya bisa dijawab dengan 'tergantung'? Jika ya, bagaimana saya membuatnya lebih spesifik?"*
+
+---
+
+## B.5 — Variabel & Metrik (Bab 5)
+
+**Latihan 1 — Operasionalisasi Lengkap**
+Dari RQ di Worksheet B.4, identifikasi semua variabel (IV, DV, CV). Untuk setiap variabel, lakukan operasionalisasi lengkap: konsep → variabel → metrik → skala → satuan → cara mengukur.
+
+**Latihan 2 — Construct Validity Check**
+Untuk setiap metrik dari Latihan 1, evaluasi: apakah metrik tersebut benar-benar mengukur konsep yang dimaksud? Identifikasi minimal satu threat terhadap construct validity dan usulkan mitigasi.
+
+**Latihan 3 — Metric Conflict**
+Jika ada dua DV yang berpotensi trade-off (misal accuracy vs speed), tentukan: (a) metrik mana yang primer, (b) metrik mana yang sekunder, dan (c) bagaimana menangani konflik saat satu metrik lebih baik tapi yang lain lebih buruk.
+
+**Refleksi:** *"Jika seseorang mempertanyakan 'apa buktinya bahwa metrik Anda mengukur apa yang Anda klaim?' — bisakah saya menjawab?"*
+
+---
+
+## B.6 — System-Experiment Mapping (Bab 6)
+
+**Latihan 1 — Mapping RQ ke Arsitektur**
+Ambil RQ dari Worksheet B.4 dan variabel dari Worksheet B.5. Petakan setiap variabel ke komponen sistem. Gambarkan diagram arsitektur yang menunjukkan mapping ini.
+
+**Latihan 2 — Evaluasi 4 Prinsip**
+Evaluasi arsitektur dari Latihan 1 terhadap 4 prinsip: traceability, variable isolation, measurement integration, reproducibility. Beri skor 1–3 per prinsip dan identifikasi yang perlu diperbaiki.
+
+**Latihan 3 — Sekenario "Bagaimana Jika"**
+Untuk sistem dari Latihan 1, jawab: (a) Jika dataset berubah, komponen mana yang harus dimodifikasi? (b) Jika metrik ditambah satu, apa yang berubah? (c) Jika baseline baru ditambahkan, apakah arsitektur mendukung tanpa redesign?
+
+**Refleksi:** *"Apakah sistem yang saya bangun adalah produk yang kebetulan diujikan, atau instrumen yang sengaja dirancang untuk menguji hipotesis?"*
+
+---
+
+## B.7 — Experimental Design & Validity (Bab 7)
+
+**Latihan 1 — Identifikasi Ancaman Validitas**
+Pilih satu paper riset eksperimental. Identifikasi ancaman validitas untuk keempat jenis (internal, external, construct, conclusion). Untuk setiap ancaman, usulkan langkah mitigasi spesifik.
+
+**Latihan 2 — Desain Perbandingan yang Fair**
+Ambil RQ dari Worksheet B.4. Rancang comparison study dengan minimal dua kondisi. Isi Template A.7 secara lengkap. Pastikan fairness checklist terpenuhi seluruhnya.
+
+**Latihan 3 — Kausalitas vs Korelasi**
+Dari desain di Latihan 2, evaluasi: apakah desain Anda bisa mendukung klaim kausal? Periksa tiga syarat kausalitas: kovariansi, temporal precedence, eliminasi alternatif. Jika ada yang lemah, perbaiki desain.
+
+**Refleksi:** *"Jika reviewer bertanya 'bagaimana Anda tahu ini bukan kebetulan?' — apakah desain eksperimen saya memberikan jawaban yang meyakinkan?"*
+
+---
+
+## B.8 — Proposal Integration (Bab 8)
+
+**Latihan 1 — Integration Map**
+Ambil output Worksheet B.2–B.7 (problem statement, gap, RQ, hipotesis, metrik, arsitektur, desain eksperimen). Susun ke dalam satu dokumen proposal menggunakan Template A.8. Periksa setiap koneksi di peta integrasi.
+
+**Latihan 2 — Self-Assessment**
+Evaluasi proposal dari Latihan 1 menggunakan rubrik (koherensi, specificity, feasibility, rigor). Beri skor per kriteria dan identifikasi dua kriteria dengan skor terendah. Buat rencana perbaikan.
+
+**Latihan 3 — Peer Review**
+Tukar proposal dengan rekan. Gunakan integration checklist (Template A.8) untuk mengevaluasi. Tandai setiap item yang belum terpenuhi dan berikan rekomendasi.
+
+**Refleksi:** *"Jika proposal saya dievaluasi bukan dari panjangnya, melainkan dari koherensi koneksi antar-bagian — apakah ia akan lulus?"*
+
+---
+
+## B.9 — Implementation & Reproducibility (Bab 9)
+
+**Latihan 1 — Environment Audit**
+Dari sistem yang dirancang di Worksheet B.6, dokumentasikan setup lengkap menggunakan Template A.9. Pastikan setiap dependency memiliki versi spesifik.
+
+**Latihan 2 — Reproducibility Test**
+Minta satu rekan mereproduksi setup dari dokumentasi Latihan 1 — tanpa penjelasan lisan. Catat: apa yang berhasil, apa yang gagal, berapa lama setup. Perbaiki dokumentasi berdasarkan feedback.
+
+**Latihan 3 — Configuration Versioning**
+Buat repository (Git) untuk kode eksperimen. Pastikan: (a) konfigurasi terpisah dari kode, (b) setiap eksperimen bisa dijalankan ulang dari commit tertentu, (c) README berisi instruksi reproduksi minimal.
+
+**Refleksi:** *"Jika laptop saya hilang besok, bisakah saya merekonstruksi seluruh eksperimen dari dokumentasi yang ada?"*
+
+---
+
+## B.10 — Execution & Data Collection (Bab 10)
+
+**Latihan 1 — Execution Plan Lengkap**
+Dari desain eksperimen di Worksheet B.7, buat execution plan (Template A.10): semua skenario, jumlah run per skenario (minimal 5), seed untuk setiap run, parameter, dan format output.
+
+**Latihan 2 — Pilot Run & Anomaly**
+Jalankan 1 pilot run untuk skenario utama. Verifikasi: (a) output sesuai format, (b) data point lengkap, (c) waktu eksekusi masuk akal. Catat anomali yang ditemukan.
+
+**Latihan 3 — Data Integrity Check**
+Setelah pilot run, periksa: apakah setiap data point bisa ditelusuri ke run yang menghasilkannya? Apakah file output lengkap? Buat laporan singkat data integrity.
+
+**Refleksi:** *"Jika saya mengklaim '30 run per skenario' — bisakah saya menunjukkan 30 file output yang masing-masing bisa ditelusuri ke run spesifik?"*
+
+---
+
+## B.11 — Data Validation (Bab 11)
+
+**Latihan 1 — Completeness Check**
+Dari execution plan di Worksheet B.10, simulasikan bahwa 2 run hilang (timeout). Buatlah laporan completeness check: berapa data point diharapkan, berapa yang ada, mana yang hilang, dan apa penanganannya.
+
+**Latihan 2 — Anomaly Investigation**
+Diberikan dataset simulasi di mana satu skenario menunjukkan outlier (performa 10x lebih baik dari rata-rata). Investigasi: apakah ini bug, cache effect, atau genuine result? Dokumentasikan langkah investigasi dan keputusan.
+
+**Latihan 3 — Full Validation Report**
+Gabungkan Template A.11 dengan hasil Latihan 1 dan 2. Tulis data validation report lengkap yang mencakup: completeness, consistency, range check, dan keputusan final (data siap analisis / perlu cleaning / perlu re-run).
+
+**Refleksi:** *"Jika reviewer meminta raw data dan log eksperimen — apakah saya bisa menyediakannya dalam 10 menit?"*
+
+---
+
+## B.12 — Result Presentation (Bab 12)
+
+**Latihan 1 — Tabel Hasil**
+Dari data eksperimen (atau data simulasi), buat tabel hasil: setiap baris satu skenario, kolom berisi metrik (mean ± std), jumlah run, ranked. Pastikan tabel self-contained.
+
+**Latihan 2 — Visualisasi Multi-Metrik**
+Sajikan data dari Latihan 1 menggunakan minimal 2 jenis grafik berbeda. Untuk setiap grafik, nyatakan: pesan utamanya, mengapa jenis grafik dipilih, dan observasi awal.
+
+**Latihan 3 — Bias Detection**
+Review visualisasi dari Latihan 2. Identifikasi apakah ada visualization bias: truncated axis, missing error bar, cherry-picked data. Perbaiki jika ditemukan.
+
+**Refleksi:** *"Jika grafik saya dilihat tanpa caption — apakah pesannya tetap jelas? Jika tidak, grafik perlu diperbaiki."*
+
+---
+
+## B.13 — Preprocessing (Bab 13)
+
+**Latihan 1 — Missing Value Strategy**
+Diberikan dataset simulasi dengan 5% missing values. Terapkan tiga strategi (listwise deletion, mean imputation, flag & report). Bandingkan: apakah rata-rata berubah? Apakah kesimpulan perbandingan berubah?
+
+**Latihan 2 — Preprocessing Pipeline**
+Buat script preprocessing lengkap (bahasa bebas) untuk dataset eksperimen. Script harus mencakup: cleaning, encoding (jika perlu), normalisasi (jika perlu). Dokumentasikan setiap langkah sebagai komentar.
+
+**Latihan 3 — Leakage Detection**
+Review pipeline dari Latihan 2. Identifikasi apakah ada potensi data leakage. Jika ada, perbaiki. Jika tidak, jelaskan mengapa tidak.
+
+**Refleksi:** *"Jika saya menghapus satu baris data — bisakah saya menjelaskan mengapa, dan apakah orang lain akan setuju?"*
+
+---
+
+## B.14 — Analysis & Interpretation (Bab 14)
+
+**Latihan 1 — From Data to Decision**
+Dari data yang sudah di-preprocess (Worksheet B.13), hitung: statistik deskriptif, lakukan uji hipotesis yang sesuai, hitung effect size, dan interpretasi confidence interval. Isi Template A.14.
+
+**Latihan 2 — Beyond p-Value**
+Untuk hasil dari Latihan 1: (a) apa artinya secara praktis (bukan hanya statistik)? (b) Apakah perbedaannya cukup besar untuk bermakna di lapangan? (c) Bagaimana dibandingkan dengan temuan serupa di literatur?
+
+**Latihan 3 — Failure Analysis**
+Jika hipotesis ditolak, investigasi: (a) apakah ada boundary condition? (b) Apakah kegagalan mengungkap insight baru? Jika hipotesis diterima, identifikasi: (a) limitation apa yang mengurangi kekuatan klaim? (b) Apa yang tidak bisa disimpulkan?
+
+**Refleksi:** *"p < 0.05 artinya apa secara konkret? Jika efeknya sangat kecil meski signifikan — apakah masih berarti?"*
+
+---
+
+## B.15 — Scientific Writing (Bab 15)
+
+**Latihan 1 — IMRAD Outline**
+Dari hasil riset (Worksheet B.1–B.14), buat outline paper IMRAD lengkap: setiap section dengan 3–5 bullet point konten utama. Tentukan target kata per section.
+
+**Latihan 2 — Consistency Matrix**
+Buat matriks konsistensi: setiap baris = RQ, kolom = Introduction / Method / Results / Discussion / Conclusion. Isi setiap sel dengan apa yang dikatakan tentang RQ tersebut di section itu. Periksa apakah konsisten.
+
+**Latihan 3 — Paragraph-Level Flow**
+Pilih satu section (Discussion). Tulis 3 paragraf pertama. Untuk setiap paragraf, tandai: kalimat topik, bukti pendukung, transisi ke paragraf berikutnya. Evaluasi: apakah flow-nya logis?
+
+**Refleksi:** *"Jika saya membaca paper saya sebagai reviewer yang skeptis — di mana saya akan berhenti dan berkata 'ini tidak convincing'?"*
+
+---
+
+## B.16 — Presentation & Defense (Bab 16)
+
+**Latihan 1 — Slide Deck**
+Susun slide deck 10–12 slide konten dari paper Anda. Prinsip: 1 slide = 1 pesan, visual > text, build progression. Isi Template A.16.
+
+**Latihan 2 — Anticipatory Defense**
+Untuk setiap kategori pertanyaan (problem, gap, method, results, generalization), formulasikan 1 pertanyaan potensial dan siapkan jawaban berbasis data. Gunakan framework CER: Claim-Evidence-Reasoning.
+
+**Latihan 3 — Presentasi & Feedback**
+Presentasikan slide deck dari Latihan 1 di depan rekan (atau rekam diri sendiri). Minta feedback pada: timing, kejelasan narasi, dan slide yang membingungkan. Perbaiki berdasarkan feedback.
+
+**Refleksi:** *"Bisakah saya menjelaskan inti riset saya dalam 2 menit tanpa slide — dan tetap meyakinkan?"*
+
+---
+
+<!-- STATUS: 🟢 Complete -->
--- a/book/back-matter/tentang-penulis.md
+++ b/book/back-matter/tentang-penulis.md
@ -0,0 +1,35 @@
+# Tentang Penulis
+
+---
+
+**Helmi Bahar Alim, S.Kom., M.Kom.**
+
+Helmi Bahar Alim adalah dosen tetap di Fakultas Sains dan Teknologi, Universitas Putra Bangsa (UPB), Kebumen, sejak tahun 2024. Bidang riset yang ditekuninya meliputi Geographic Information Systems (GIS), Microservices, Cloud Systems, Secure Distributed Computing, dan Smart Transportation. Ia aktif mempublikasikan hasil penelitian di jurnal nasional dan internasional, termasuk topik data mining untuk prediksi wisatawan serta desain infrastruktur digital berbasis AI untuk pariwisata geopark.
+
+Sebelum menjadi dosen, Helmi membangun karier profesional selama lebih dari 9 tahun di industri software engineering. Sebagai Head of Unit — Software Engineering di PT Akar Inti Teknologi, Jakarta, ia memimpin tim teknis untuk proyek strategis berskala nasional, termasuk integrasi sistem dengan Single Sign-On (SSO) untuk 700+ outlet PT Fast Food Indonesia (KFC). Sebelumnya, ia menjabat Product Owner & Technical Leader di PT Aino Indonesia, Yogyakarta, memimpin tim lintas-fungsi 24 orang dalam membangun platform transportasi cerdas Acasia 2.0 dari nol (1.056 manday) — dengan capaian menekan bug kritis pasca-rilis lebih dari 99% melalui penerapan framework tata kelola teknis yang komprehensif.
+
+Helmi menyelesaikan pendidikan Sarjana Komputer (S.Kom.) dari UIN Sunan Kalijaga, Yogyakarta (2016) dengan penelitian tugas akhir tentang Sistem Informasi Geografis Jalan dan Jembatan, serta Magister Komputer (M.Kom.) dari institusi yang sama (2023) dengan tesis berjudul *Optimasi Estimasi Volume Sistem Menggunakan Pendekatan Komponen Fungsional*. Kombinasi pengalaman akademik dan intensitas industri di software engineering memberinya perspektif unik tentang bagaimana riset eksperimental seharusnya diterapkan dalam konteks Teknologi Informasi — bukan sekadar teori metodologi, melainkan praktik yang terukur, reproducible, dan berdampak.
+
+Buku ini ditulis dari keyakinan bahwa kemampuan riset eksperimental bukan hanya milik akademisi. Setiap praktisi TI yang ingin membuat keputusan berbasis bukti — apakah itu membandingkan algoritma, mengevaluasi arsitektur, atau mengukur dampak perubahan sistem — membutuhkan pola pikir dan metode yang sama ketatnya dengan riset ilmiah.
+
+---
+
+**Afiliasi:**
+Fakultas Sains dan Teknologi
+Universitas Putra Bangsa (UPB), Kebumen
+
+**Email:** helmibahara@gmail.com
+**Google Scholar:** scholar.google.com/citations?user=lOK0aDQAAAAJ
+
+---
+
+### Publikasi Terpilih
+
+- Alim, H. B. (2025). AI-Integrated Public Digital Infrastructure for Geopark Tourism: Empowering MSMEs through Smart Mobility and Data-Driven Governance. *Journal of Informatics Management and Information Technology (JIMAT)*.
+- Ikhsanuddin, R. M., Alim, H. B., & Bilqisth, S. C. (2025). Penerapan Data Mining Untuk Prediksi Jumlah Kunjungan Wisatawan di Kebumen Menggunakan Metode Regresi Linier Sederhana. *Technology and Informatics Insight Journal*, 4(1), 1–6.
+- Alim, H. B. (2023). *Optimasi Estimasi Volume Sistem Menggunakan Pendekatan Komponen Fungsional* [Tesis Magister, UIN Sunan Kalijaga].
+- Alim, H. B. (2016). *Sistem Informasi Geografis Jalan dan Jembatan di Kabupaten Wonogiri* [Skripsi, UIN Sunan Kalijaga].
+
+---
+
+<!-- STATUS: 🟢 Complete -->
--- a/book/bagian-1-foundation/bab-01-research-mindset.md
+++ b/book/bagian-1-foundation/bab-01-research-mindset.md
@ -0,0 +1,512 @@
+# Bab 1 — Research Mindset in IT
+
+> **Sub-CPMK:** Sub-CPMK 1.1 — Membedakan pola pikir engineering vs research
+> **CPMK:** CPMK01 — Menunjukkan pemahaman paradigma riset dalam TI
+> **CPL Utama:** CPL03 (Penalaran logis, kritis, sistematis)
+> **CPL Pendukung:** CPL01 (Etis, bertanggung jawab)
+> **Fase:** Thinking (M1–M4)
+
+---
+
+## Ringkasan Bab
+
+Bab ini membahas fondasi berpikir yang membedakan peneliti dari engineer. Riset bukan semata soal membuat sesuatu bekerja, melainkan soal memastikan apa yang ditemukan benar, valid, dan dapat dipercaya. Tiga pilar utama — etika sebagai penjaga integritas ilmiah, validitas sebagai standar kebenaran, dan paradigma sebagai lensa epistemologis — membentuk kerangka berpikir *Curious → Critical → Systematic* yang mendasari seluruh proses riset.
+
+---
+
+## 1.1 Pembuka
+
+Seorang developer menyelesaikan proyek: sistem deteksi plagiarisme berbasis NLP. Input teks, output persentase kemiripan. Demo lancar, hasilnya terlihat menjanjikan.
+
+Lalu muncul pertanyaan dari reviewer: "Bagaimana Anda membuktikan bahwa angka 87% itu benar-benar menunjukkan plagiarisme, bukan sekadar kesamaan topik? Apa baseline-nya? Apakah hasilnya konsisten jika diuji pada 1.000 dokumen dari domain berbeda? Bagaimana Anda memastikan proses pengumpulan data tidak bias?"
+
+Pertanyaan-pertanyaan ini menandai batas antara dua peran: **engineer** yang membangun sistem berfungsi, dan **peneliti** yang membuktikan bahwa apa yang dibangun benar, valid, dan layak dipercaya oleh komunitas ilmiah. Perbedaan ini menjadi titik tolak buku ini.
+
+Mata kuliah Riset Teknologi Informasi tidak mengajarkan cara membuat sistem — itu sudah dipelajari di mata kuliah lain. Yang diajarkan di sini adalah cara berpikir sebagai peneliti: bertanya dengan tajam, mengukur dengan presisi, menyimpulkan dengan jujur. Kemampuan ini bukan bawaan, melainkan mindset yang dilatih.
+
+Buku ini mencakup seluruh pipeline penelitian: merumuskan masalah (Bab 2), menavigasi literatur (Bab 3), merancang eksperimen (Bab 6–7), hingga mempertahankan temuan di hadapan penguji (Bab 16). Bab pertama ini membangun fondasinya.
+
+Pertanyaan utama bab ini: apa yang membedakan "membangun sistem yang bekerja" dari "menghasilkan pengetahuan yang dapat dipercaya"?
+
+---
+
+## 1.2 Research Trust Model
+
+Konsep sentral bab ini adalah **Research Trust Model** — rantai kepercayaan dalam proses penelitian. Setiap tahap membawa risiko distorsi; etika dan validitas bertugas mengendalikan distorsi tersebut.
+
+**Gambar 1.1** — Research Trust Model: Rantai Kepercayaan dari Realitas ke Pengetahuan
+
+```mermaid
+graph LR
+    A["🌍 <b>Reality</b><br/><i>Fenomena nyata</i>"]
+    B["📊 <b>Data</b><br/><i>Observasi & pengukuran</i>"]
+    C["⚙️ <b>Processing</b><br/><i>Cleaning & transformasi</i>"]
+    D["🔬 <b>Analysis</b><br/><i>Statistik & interpretasi</i>"]
+    E["💡 <b>Inference</b><br/><i>Kesimpulan</i>"]
+    F["📚 <b>Knowledge</b><br/><i>Kontribusi ilmiah</i>"]
+
+    A -->|"Sampling &<br/>measurement"| B
+    B -->|"Preprocessing"| C
+    C -->|"Statistical<br/>testing"| D
+    D -->|"Logical<br/>reasoning"| E
+    E -->|"Peer review &<br/>replication"| F
+
+    style A fill:#DBEAFE,stroke:#2563EB,color:#1E3A5F
+    style B fill:#BFDBFE,stroke:#2563EB,color:#1E3A5F
+    style C fill:#93C5FD,stroke:#2563EB,color:#1E3A5F
+    style D fill:#60A5FA,stroke:#2563EB,color:#FFFFFF
+    style E fill:#3B82F6,stroke:#2563EB,color:#FFFFFF
+    style F fill:#2563EB,stroke:#1D4ED8,color:#FFFFFF
+```
+
+Pengetahuan ilmiah tidak muncul langsung dari realitas. Ia melewati enam tahap transformasi, masing-masing dengan potensi distorsi:
+
+1. **Reality** — Fenomena dunia nyata yang menjadi objek penelitian. Bisa berupa perilaku pengguna, performa sistem, atau pola data.
+2. **Data** — Representasi realitas yang ditangkap melalui observasi dan pengukuran. Di sinilah distorsi pertama terjadi: sampling bias, measurement error, atau instrumen yang tidak dikalibrasi.
+3. **Processing** — Tahap membersihkan dan mentransformasi data mentah. Keputusan tentang bagaimana menangani missing values, outliers, atau normalisasi bisa mengubah makna data secara signifikan.
+4. **Analysis** — Penerapan metode statistik atau analitik terhadap data yang telah diproses. Pemilihan metode yang salah atau pelanggaran asumsi statistik bisa menghasilkan kesimpulan yang menyesatkan.
+5. **Inference** — Penarikan kesimpulan dari hasil analisis. Ini adalah lompatan logis yang paling rentan: apakah hasil analisis benar-benar menjawab research question, atau hanya menjawab pertanyaan yang berbeda?
+6. **Knowledge** — Kontribusi yang diterima oleh komunitas ilmiah setelah melewati peer review dan replikasi. Hanya klaim yang bertahan dari scrutiny ilmiah yang menjadi pengetahuan.
+
+Setiap transisi dalam model ini adalah titik rawan distorsi. Etika memastikan tidak ada distorsi yang disengaja. Validitas memastikan distorsi yang tidak disengaja bisa dideteksi dan diminimalkan. Tanpa keduanya, pengetahuan yang dihasilkan tidak bisa dipercaya.
+
+---
+
+## 1.3 Definisi Kunci
+
+> 📌 **Research Mindset**
+> Pola pikir yang menuntut bukti, mempertanyakan asumsi, dan mengevaluasi klaim berdasarkan validitas — bukan hanya fungsionalitas. Dalam konteks TI, research mindset membedakan "apakah sistem bekerja?" (engineering) dari "apakah klaim tentang sistem ini benar?" (research).
+
+> 📌 **Etika Penelitian (*Research Ethics*)**
+> Seperangkat prinsip dan standar perilaku yang mengatur bagaimana penelitian dilakukan, meliputi kejujuran dalam pelaporan data, penghormatan terhadap partisipan, transparansi metodologi, dan penghindaran fabrikasi serta falsifikasi (Resnik, 2020). Dalam riset TI, etika juga mencakup penggunaan data yang bertanggung jawab dan keadilan algoritmik.
+
+> 📌 **Validitas (*Validity*)**
+> Derajat sejauh mana kesimpulan penelitian mencerminkan realitas yang sebenarnya. Shadish et al. (2002) mendefinisikan tiga jenis utama: internal validity (apakah hubungan kausal benar?), external validity (apakah temuan bisa digeneralisasi?), dan construct validity (apakah kita mengukur apa yang seharusnya diukur?).
+
+> 📌 **Paradigma Penelitian (*Research Paradigm*)**
+> Kerangka filosofis yang mendasari asumsi tentang realitas (ontologi), cara mengetahui (epistemologi), dan metode yang digunakan (metodologi). Tiga paradigma utama: positivisme, interpretivisme, dan pragmatisme (Creswell & Creswell, 2018).
+
+---
+
+## 1.4 Konsep Inti
+
+### 1.4.1 Etika: Penjaga Validitas Ilmiah, Bukan Sekadar Moral
+
+Etika penelitian sering diasosiasikan dengan persetujuan (*informed consent*), privasi data, atau plagiarisme. Itu memang bagian dari etika, tapi baru permukaannya.
+
+Dalam riset eksperimental, etika punya peran lebih mendasar: menjaga validitas. Ketika peneliti membuang outlier "karena mengganggu hasil," memilih metode statistik yang menghasilkan p-value paling rendah, atau hanya melaporkan eksperimen yang berhasil — ia mendistorsi kebenaran yang sedang dicari. Itu bukan sekadar pelanggaran moral; itu pelanggaran terhadap prinsip ilmiah itu sendiri.
+
+Resnik (2020) mengidentifikasi beberapa prinsip etika kunci dalam penelitian:
+
+- **Kejujuran (*Honesty*)** — Melaporkan data, metode, dan hasil apa adanya. Tidak membuat data (fabrikasi), mengubah data (falsifikasi), atau mengklaim karya orang lain (plagiarisme).
+- **Objektivitas (*Objectivity*)** — Menghindari bias dalam desain, analisis, dan interpretasi. Menggunakan metode yang transparan dan dapat direplikasi.
+- **Keterbukaan (*Openness*)** — Membagikan data, kode, dan metode agar peneliti lain bisa memverifikasi dan mereplikasi.
+- **Akuntabilitas (*Accountability*)** — Bertanggung jawab atas seluruh proses penelitian, termasuk kegagalan.
+
+ACM Code of Ethics (2018) menambahkan dimensi khusus untuk bidang komputasi:
+
+- Menghindari bahaya (*avoid harm*) — termasuk bias algoritmik
+- Menghormati privasi (*respect privacy*) — terutama dalam pengolahan data pengguna
+- Jujur dan dapat dipercaya (*be honest and trustworthy*) — dalam pelaporan hasil
+
+Etika bukan aturan eksternal yang membatasi penelitian. Etika adalah mekanisme internal yang menjamin kualitasnya. Penelitian tanpa etika mungkin menghasilkan angka, tapi angka tanpa integritas bukan pengetahuan.
+
+### 1.4.2 Validitas: Tiga Pilar Kebenaran Ilmiah
+
+Jika etika memastikan proses penelitian jujur, **validitas** memastikan hasilnya benar. Shadish et al. (2002) mendefinisikan tiga jenis validitas yang menjadi standar dalam riset eksperimental:
+
+**Internal Validity** — Apakah hubungan kausal yang diklaim benar-benar ada? Jika Anda mengklaim "algoritma A lebih cepat dari B," apakah perbedaan kecepatan benar-benar disebabkan oleh algoritma — atau ada faktor lain (confounding variable) seperti perbedaan hardware, ukuran dataset, atau kondisi jaringan?
+
+**External Validity** — Apakah temuan bisa digeneralisasi ke konteks lain? Jika eksperimen dilakukan pada dataset 1.000 record dari satu domain, apakah hasilnya berlaku untuk 1 juta record dari domain berbeda? External validity adalah tentang batas-batas di mana kesimpulan masih berlaku.
+
+**Construct Validity** — Apakah kita mengukur apa yang seharusnya diukur? Jika Anda mengklaim mengukur "kepuasan pengguna" menggunakan task completion rate, apakah metrik tersebut benar-benar merepresentasikan kepuasan? Mungkin pengguna menyelesaikan task tapi merasa frustrasi sepanjang proses. Construct validity memastikan bahwa operasionalisasi variabel sesuai dengan konsep yang dimaksud.
+
+**Tabel 1.1** — Tiga Jenis Validitas dan Ancamannya dalam Riset TI
+
+| Jenis Validitas | Pertanyaan Kunci | Ancaman Umum | Contoh di TI |
+|-----------------|------------------|--------------|-------------|
+| Internal | Apakah X benar-benar menyebabkan Y? | Confounding variable, selection bias | Hardware berbeda antar grup eksperimen |
+| External | Apakah hasil berlaku di konteks lain? | Sampel terlalu kecil/spesifik | Eksperimen hanya pada satu dataset |
+| Construct | Apakah kita mengukur hal yang benar? | Metrik tidak merepresentasikan konsep | Accuracy sebagai proxy untuk kualitas rekomendasi |
+
+Ketiga validitas ini saling terkait. Riset yang memiliki internal validity tinggi tapi external validity rendah belum bisa diklaim sebagai pengetahuan umum. Riset yang memiliki external validity tinggi tapi construct validity rendah mungkin mengukur hal yang salah di banyak konteks. Peneliti yang kompeten menyeimbangkan ketiganya melalui desain eksperimen yang cermat (Wohlin et al., 2012).
+
+### 1.4.3 Paradigma: Lensa Epistemologis
+
+Sebelum melakukan riset, setiap peneliti — sadar atau tidak — membawa asumsi tentang bagaimana dunia bekerja dan bagaimana pengetahuan diperoleh. Asumsi ini disebut **paradigma**.
+
+Creswell dan Creswell (2018) mengidentifikasi tiga paradigma utama:
+
+**Positivisme** — Realitas itu objektif dan bisa diukur. Pengetahuan diperoleh melalui observasi sistematis, pengukuran, dan pengujian hipotesis. Hubungan kausal bisa diidentifikasi melalui eksperimen terkontrol. Ini adalah paradigma dominan dalam sains eksperimental.
+
+**Interpretivisme** — Realitas itu subjektif dan dikonstruksi oleh pengalaman individu. Pengetahuan diperoleh melalui pemahaman mendalam (*understanding*), bukan pengukuran. Metode utama: wawancara, observasi partisipatif, analisis tematik. Paradigma ini dominan dalam riset kualitatif.
+
+**Pragmatisme** — Paradigma tidak perlu bersifat dogmatis. Yang penting adalah memilih pendekatan yang paling efektif untuk menjawab research question yang dihadapi. Creswell (2012) menjelaskan bahwa pragmatisme memungkinkan peneliti menggabungkan metode kuantitatif dan kualitatif.
+
+### 1.4.4 Posisi Mata Kuliah: Positivist + Design Science
+
+Lalu, di mana posisi mata kuliah Riset Teknologi Informasi?
+
+Mata kuliah ini mengambil posisi **positivist** dengan diperkuat oleh **Design Science Research** (DSR). Artinya:
+
+- Kita percaya bahwa fenomena TI bisa diukur secara objektif (positivist)
+- Kita menggunakan eksperimen terkontrol sebagai metode utama (positivist)
+- Kita juga membangun artefak (sistem, algoritma, framework) sebagai bagian dari riset (DSR)
+- Artefak bukan tujuan akhir — artefak adalah **instrumen** untuk menguji hipotesis (Hevner et al., 2004)
+
+**Gambar 1.2** — Paradigm Positioning: Posisi Riset TI dalam Lanskap Paradigma
+
+```mermaid
+graph TB
+    P["<b>Paradigma Penelitian</b>"]
+    POS["<b>Positivisme</b><br/><i>Objektif, terukur,<br/>eksperimen</i>"]
+    INT["<b>Interpretivisme</b><br/><i>Subjektif, mendalam,<br/>kualitatif</i>"]
+    PRA["<b>Pragmatisme</b><br/><i>Problem-driven,<br/>mixed-methods</i>"]
+    DSR["<b>Design Science<br/>Research</b><br/><i>Artefak + evaluasi</i>"]
+    RTI["🎯 <b>RISET TI</b><br/><i>Positivist +<br/>Design Science</i>"]
+
+    P --> POS
+    P --> INT
+    P --> PRA
+    POS --> RTI
+    PRA -.->|"DSR bridge"| DSR
+    DSR --> RTI
+
+    style P fill:#DBEAFE,stroke:#2563EB,color:#1E3A5F
+    style POS fill:#3B82F6,stroke:#2563EB,color:#FFFFFF
+    style INT fill:#93C5FD,stroke:#2563EB,color:#1E3A5F
+    style PRA fill:#93C5FD,stroke:#2563EB,color:#1E3A5F
+    style DSR fill:#60A5FA,stroke:#2563EB,color:#FFFFFF
+    style RTI fill:#2563EB,stroke:#1D4ED8,color:#FFFFFF
+```
+
+Implikasi praktis dari posisi ini:
+
+- Setiap klaim harus didukung **bukti kuantitatif** (data, metrik, statistik)
+- Setiap eksperimen harus memiliki **variabel terkontrol** dan **baseline pembanding**
+- Artefak yang dibangun harus **dievaluasi secara rigorous**, bukan hanya didemonstrasikan
+- Kontribusi diukur dari **pengetahuan baru** yang dihasilkan, bukan dari artefak itu sendiri
+
+Kesalahpahaman yang umum: riset dianggap selesai saat sistem dibangun. Dalam paradigma positivist + DSR, membangun sistem baru langkah awal. Evaluasi rigorous terhadap sistem itulah yang menghasilkan kontribusi ilmiah.
+
+### 1.4.5 Curious → Critical → Systematic: Tiga Mode Berpikir Peneliti
+
+Seluruh konsep di atas — etika, validitas, paradigma — bermuara pada satu hal: **bagaimana seorang peneliti berpikir**. Kita bisa merangkumnya dalam tiga mode berpikir yang saling berurutan:
+
+**Curious (Ingin Tahu)** — Kemampuan untuk melihat fenomena dan bertanya "mengapa?" Bukan menerima status quo, tapi mempertanyakannya. Seseorang yang melihat model ML dengan akurasi 98% dan langsung bertanya "Tapi bagaimana dengan kelas minoritas? Apakah metrik ini menyembunyikan masalah?" sedang menerapkan rasa ingin tahu ilmiah.
+
+**Critical (Kritis)** — Kemampuan untuk mengevaluasi klaim berdasarkan bukti, bukan otoritas atau popularitas. "Paper ini mengklaim metode X lebih baik — tapi datasetnya hanya 200 record, dan tidak ada controlled experiment. Apakah klaim ini valid?" Berpikir kritis berarti menolak menerima klaim hanya karena diterbitkan.
+
+**Systematic (Sistematis)** — Kemampuan untuk merancang investigasi yang terstruktur, reproducible, dan falsifiable. Bukan menguji coba secara acak, melainkan merancang eksperimen dengan variabel yang jelas, baseline yang tepat, dan metrik yang terukur.
+
+Ketiga mode ini bukan pilihan — ketiganya harus ada secara berurutan. Rasa ingin tahu tanpa sikap kritis menghasilkan research question yang naif. Sikap kritis tanpa pendekatan sistematis menghasilkan kritik tanpa solusi. Dan pendekatan sistematis tanpa rasa ingin tahu menghasilkan eksperimen yang teknis sempurna tapi tidak menjawab pertanyaan yang penting.
+
+---
+
+## 1.5 Research vs Engineering
+
+**Tabel 1.2** — Perbandingan Perspektif Research vs Engineering dalam Mindset
+
+| Aspek | Engineering Mindset | Research Mindset |
+|-------|-------------------|-----------------|
+| **Tujuan utama** | Membuat sistem yang bekerja | Menghasilkan pengetahuan yang valid |
+| **Pertanyaan khas** | "Bagaimana membuatnya jalan?" | "Apakah klaim ini benar dan bisa dibuktikan?" |
+| **Ukuran sukses** | Sistem berfungsi, client puas | Hipotesis terjawab, temuan tervalidasi |
+| **Kegagalan** | Harus dihindari | Harus dilaporkan (negative result = kontribusi) |
+| **Deadline** | Waktu delivery | Kebenaran temuan (jangan terburu-buru menyimpulkan) |
+| **Validasi** | Testing (unit, integration, UAT) | Experimental validation + statistical significance |
+
+Dalam engineering, kegagalan harus diperbaiki sebelum deploy. Dalam research, kegagalan — hipotesis yang ditolak — sama berharganya dengan keberhasilan, karena keduanya menambah pengetahuan. Peneliti yang hanya melaporkan hasil positif melakukan *publication bias*, salah satu masalah terbesar dalam sains modern.
+
+---
+
+## 1.6 Research Reality
+
+### Fenomena 1 — "HARKing: Hypothesizing After Results are Known"
+
+Fenomena ini terjadi ketika peneliti merumuskan hipotesis **setelah** melihat data — lalu menyajikannya seolah-olah hipotesis tersebut sudah ada sejak awal. Contoh: seorang peneliti menjalankan eksperimen membandingkan 5 algoritma. Hanya satu yang menghasilkan perbedaan signifikan. Di laporan, ia menulis seolah-olah sejak awal hipotesisnya adalah tentang algoritma tersebut saja.
+
+Mengapa ini berbahaya? Karena jika Anda menguji 5 hipotesis pada data yang sama, probabilitas menemukan satu hasil "signifikan" secara kebetulan meningkat drastis (masalah *multiple comparisons*). HARKing memberikan ilusi certainty dari apa yang sebenarnya adalah temuan kebetulan. Ini bukan hanya masalah statistik — ini pelanggaran etika.
+
+### Fenomena 2 — "Metric Gaming: Optimizing the Wrong Thing"
+
+Di dunia TI, kita terbiasa dengan optimization. Tapi dalam riset, optimization tanpa pemahaman terhadap apa yang dioptimasi bisa berbahaya. Seorang peneliti yang fokus meningkatkan accuracy dari 95% ke 97% pada model klasifikasi mungkin sedang mengoptimasi metrik yang **tidak relevan dengan masalah sebenarnya** — misalnya, pada dataset imbalanced di mana precision atau recall lebih penting.
+
+Fenomena ini diperparah oleh budaya leaderboard dan benchmark dalam komunitas machine learning, di mana improvement 0.1% pada metrik tertentu dianggap sebagai kontribusi. Tanpa research mindset yang kuat, peneliti bisa terjebak mengejar angka alih-alih mengejar pemahaman.
+
+### Fenomena 3 — "Positive Result Bias"
+
+Jurnal dan konferensi cenderung menerbitkan hasil positif — eksperimen yang "berhasil." Akibatnya, banyak peneliti pemula merasa bahwa riset harus menghasilkan hasil positif. Padahal, menemukan bahwa "metode X **tidak** lebih baik dari Y dalam konteks Z" adalah kontribusi ilmiah yang sah dan penting. Bias ini menciptakan *file drawer problem* — ratusan studi dengan hasil negatif yang tidak pernah dipublikasikan, menyebabkan komunitas ilmiah overestimate terhadap efektivitas metode tertentu.
+
+Riset bukan demonstrasi — riset adalah investigasi. Hasilnya bisa positif, negatif, atau campuran. Yang menentukan kualitas riset bukan arah hasilnya, melainkan kekuatan bukti yang mendukungnya.
+
+---
+
+## 1.7 Cognitive Traps
+
+**Trap 1: "Angka Tinggi = Benar"**
+
+Akurasi 98%, precision 0.95, F1-score 0.92 — angka-angka ini terlihat mengesankan. Tapi tanpa konteks, angka tinggi bisa menyesatkan. Akurasi 98% pada dataset dengan 97% kelas mayoritas berarti model hampir tidak mendeteksi kelas minoritas. F1-score tinggi pada dataset sintetis tidak menjamin performa pada data real-world. Angka hanya bermakna dalam konteks validitas yang tepat (Shadish et al., 2002).
+
+**Trap 2: "Data itu Netral"**
+
+Data tidak pernah netral. Data selalu merupakan hasil keputusan: apa yang diukur, bagaimana diukur, siapa yang mengukur, kapan diukur. Dataset pelatihan untuk model AI membawa bias dari proses pengumpulannya — historical bias, sampling bias, measurement bias. Menganggap data netral berarti mengabaikan distorsi pada tahap pertama Research Trust Model: Reality → Data. Peneliti yang bertanggung jawab mempertanyakan asal-usul dan keterbatasan datanya (ACM, 2018).
+
+**Trap 3: "Jika Jalan, Maka Benar"**
+
+Ini bias engineering yang paling berbahaya ketika dibawa ke dunia riset. Sistem yang berjalan (functional) belum tentu menghasilkan pengetahuan yang valid. Demonstrasi ≠ validasi. Sistem rekomendasi yang menghasilkan output bukan bukti bahwa algoritma rekomendasinya efektif. Klaim semacam itu memerlukan eksperimen terkontrol, baseline pembanding, dan analisis statistik (Wohlin et al., 2012).
+
+**Trap 4: "Kegagalan Tidak Perlu Dilaporkan"**
+
+Contoh kasus: seorang peneliti menguji 3 algoritma dan hanya 1 yang menghasilkan perbedaan signifikan. Melaporkan hanya yang "berhasil" tanpa menyebutkan yang "gagal" adalah pelanggaran etika dan merusak reproducibility. Kegagalan memberikan informasi kritis tentang kondisi batas (*boundary conditions*) di mana sebuah metode tidak bekerja. Informasi ini sering lebih berharga daripada keberhasilan — mencegah peneliti lain mengulang kesalahan yang sama (Resnik, 2020).
+
+---
+
+## 1.8 Studi Kasus
+
+### Kasus 1 (Basic): "Manipulasi Dataset ML — Akurasi Tinggi tapi Data Palsu"
+
+**Konteks:**
+
+Seorang peneliti mengerjakan riset tentang klasifikasi sentimen review produk e-commerce. Dataset yang dikumpulkan dari scraping menghasilkan distribusi yang timpang: 85% positif, 15% negatif. Untuk "memperbaiki" distribusi, ia membuat data sintetis — menulis sendiri 200 review negatif palsu agar dataset menjadi 60:40. Model dilatih, akurasi mencapai 91%. Hasilnya terlihat impresif.
+
+**❌ Pendekatan Salah:**
+
+Peneliti tidak melaporkan bahwa 200 review negatif adalah buatan sendiri. Di laporan tertulis: "Dataset dikumpulkan dari platform e-commerce X sebanyak 1.500 review." Tidak ada penjelasan tentang data sintetis.
+
+Mengapa salah:
+
+- **Fabrikasi data** — menambahkan data yang tidak berasal dari sumber nyata tanpa transparansi
+- **Internal validity hancur** — model belajar pola dari teks buatan yang tidak merepresentasikan review nyata
+- **Construct validity dipertanyakan** — apakah model benar-benar belajar sentimen natural, atau pola linguistik dari satu penulis?
+- **Tidak reproducible** — peneliti lain tidak bisa mereplikasi karena data palsu tidak berasal dari populasi yang diklaim
+
+**✅ Pendekatan Benar:**
+
+Laporkan distribusi asli (85:15) secara transparan. Gunakan teknik yang established dan etis untuk menangani imbalance: SMOTE, oversampling, undersampling, atau cost-sensitive learning. Jelaskan setiap keputusan dan dampaknya terhadap hasil. Jika menambahkan data augmentasi, nyatakan secara eksplisit metode dan proporsinya.
+
+**Perbandingan:**
+
+| Aspek | Bad | Good |
+|-------|-----|------|
+| Transparansi | Data palsu tidak dilaporkan | Distribusi asli dan metode handling dijelaskan |
+| Etika | Fabrikasi (pelanggaran berat) | Augmentasi yang transparan dan justified |
+| Internal validity | Hancur (pola palsu) | Terjaga (metode terstandar) |
+| Reproducibility | Tidak bisa direplikasi | Bisa direplikasi oleh peneliti lain |
+
+Tidak ada shortcut yang etis dalam riset. Data yang "tidak sempurna" bukan alasan untuk fabrication — justru itulah yang harus dilaporkan. Keterbatasan data adalah bagian dari kontribusi ilmiah: menunjukkan pada peneliti lain di mana batas pengetahuan saat ini.
+
+---
+
+### Kasus 2 (Advanced): "AI Bias — Model Terlatih Bagus tapi Bias Tersembunyi"
+
+**Konteks:**
+
+Sebuah tim riset membangun model prediksi risiko kredit untuk perusahaan fintech. Model berbasis gradient boosting mencapai AUC-ROC 0.89 — performanya sangat baik secara agregat. Namun, saat dilakukan fairness audit per kelompok demografis, ditemukan bahwa false positive rate untuk kelompok etnis tertentu **3.2× lebih tinggi** dibandingkan kelompok mayoritas. Artinya, orang dari kelompok tersebut 3.2 kali lebih sering **salah ditolak** kreditnya.
+
+**❌ Pendekatan Salah:**
+
+Tim hanya melaporkan AUC-ROC agregat (0.89) dan menyimpulkan bahwa model "berperforma baik." Tidak ada analisis per-subgrup. Tidak ada fairness metric. Dalam paper, tidak disebutkan potensi bias karena dianggap "di luar scope penelitian."
+
+Mengapa salah:
+
+- **Etika dilanggar** — model yang digunakan dalam keputusan nyata (kredit) membawa dampak sosial langsung
+- **Construct validity gagal** — AUC-ROC secara agregat menyembunyikan disparitas antar-kelompok
+- **External validity dipertanyakan** — model mungkin hanya "berperforma baik" untuk kelompok mayoritas
+- **ACM Code of Ethics** dilanggar — prinsip "avoid harm" dan "be fair"
+
+**✅ Pendekatan Benar:**
+
+Lakukan evaluasi berlapis: (1) metrik agregat (AUC-ROC, accuracy), (2) metrik per kelompok demografis, dan (3) fairness metrics (demographic parity, equalized odds, predictive parity). Laporkan seluruh hasil secara transparan — termasuk disparitas. Jika bias terdeteksi, eksplorasi teknik mitigasi (resampling, adversarial debiasing, post-processing calibration) dan evaluasi trade-off antara performa dan fairness.
+
+**Perbandingan:**
+
+| Aspek | Bad | Good |
+|-------|-----|------|
+| Evaluasi | Hanya agregat | Agregat + per-subgrup + fairness metrics |
+| Transparansi | Bias tidak dilaporkan | Disparitas dilaporkan dan dianalisis |
+| Etika | ACM Code dilanggar | Prinsip fairness diterapkan |
+| Kontribusi | Klaim performa tanpa nuansa | Analisis trade-off performa vs fairness |
+
+Dalam riset AI/ML, evaluasi etis bukan pelengkap — ia bagian integral dari validitas. Model yang performanya "baik" secara agregat namun mendiskriminasi subgrup tertentu bukan model yang baik. Pertanyaan yang harus selalu muncul: "Baik untuk siapa?"
+
+---
+
+## 1.9 Template Praktis
+
+> 🔧 **Template: Research Mindset Self-Assessment**
+>
+> Gunakan template ini sebelum memulai riset untuk memastikan mindset Anda sudah benar.
+>
+> ```
+> RESEARCH MINDSET SELF-ASSESSMENT
+> ═══════════════════════════════════════════════════
+>
+> 1. CURIOUS — Rasa Ingin Tahu
+>    Fenomena yang menarik perhatian saya:
+>    _______________________________________________
+>    Pertanyaan "mengapa" yang saya ajukan:
+>    _______________________________________________
+>    Apakah pertanyaan ini belum terjawab
+>    di literatur? [Ya/Tidak]
+>
+> 2. CRITICAL — Sikap Kritis
+>    Klaim yang saya temukan tentang fenomena ini:
+>    _______________________________________________
+>    Apa bukti yang mendukung klaim tersebut?
+>    _______________________________________________
+>    Apa kelemahan bukti tersebut?
+>    _______________________________________________
+>    Apakah ada klaim alternatif yang masuk akal?
+>    _______________________________________________
+>
+> 3. SYSTEMATIC — Pendekatan Sistematis
+>    Bagaimana saya bisa menguji klaim ini
+>    secara empiris?
+>    _______________________________________________
+>    Variabel apa yang perlu diukur?
+>    _______________________________________________
+>    Baseline pembanding apa yang relevan?
+>    _______________________________________________
+>    Apakah eksperimen ini bisa direplikasi
+>    oleh orang lain? [Ya/Tidak]
+>    Jika tidak, apa yang kurang?
+>    _______________________________________________
+>
+> 4. ETHICS CHECK
+>    Data diperoleh secara etis?         [Ya/Tidak]
+>    Ada potensi bias dalam data/metode? [Ya/Tidak]
+>    Semua hasil akan dilaporkan?         [Ya/Tidak]
+>    Proses transparan dan reproducible?  [Ya/Tidak]
+>
+> 5. VALIDITY CHECK
+>    Internal: Confounding variables
+>    terkendali?                          [Ya/Tidak]
+>    External: Sampel cukup representatif?[Ya/Tidak]
+>    Construct: Metrik merepresentasikan
+>    konsep yang dimaksud?                [Ya/Tidak]
+>
+> ═══════════════════════════════════════════════════
+> Jika ada jawaban "Tidak" di section 4–5:
+> → perbaiki sebelum melanjutkan.
+> ```
+
+---
+
+## 1.10 Mindmap Bab 1
+
+**Gambar 1.3** — Mindmap: Research Mindset in IT
+
+```mermaid
+mindmap
+  root((Research<br/>Mindset<br/>in IT))
+    Etika Penelitian
+      Kejujuran
+      Objektivitas
+      Keterbukaan
+      Akuntabilitas
+      ACM Code of Ethics
+    Validitas
+      Internal Validity
+        Confounding variables
+        Selection bias
+      External Validity
+        Generalizability
+        Sample representativeness
+      Construct Validity
+        Operationalisasi
+        Metrik yang tepat
+    Paradigma
+      Positivisme
+      Interpretivisme
+      Pragmatisme
+      Design Science Research
+    Posisi Riset TI
+      Positivist + DSR
+      Eksperimen terkontrol
+      Artefak sebagai instrumen
+    Research Trust Model
+      Reality
+      Data
+      Processing
+      Analysis
+      Inference
+      Knowledge
+    Mindset Peneliti
+      Curious
+      Critical
+      Systematic
+```
+
+---
+
+## 1.11 Rangkuman
+
+1. **Research mindset** membedakan proses membangun sistem (engineering) dari proses menghasilkan pengetahuan yang valid (research). Keduanya bernilai — tetapi riset menuntut standar pembuktian yang lebih ketat.
+2. **Research Trust Model** menggambarkan rantai transformasi Reality → Data → Processing → Analysis → Inference → Knowledge. Setiap tahap membawa risiko distorsi yang harus dikendalikan.
+3. **Etika penelitian** bukan sekadar aturan moral — etika adalah penjaga validitas. Tanpa etika, seluruh rantai trust runtuh karena distorsi yang disengaja.
+4. **Validitas** memiliki tiga dimensi: internal (kausalitas benar?), external (bisa digeneralisasi?), dan construct (mengukur hal yang benar?). Ketiganya harus dipenuhi secara simultan.
+5. **Paradigma** menentukan lensa epistemologis. Mata kuliah ini mengambil posisi **positivist + Design Science Research**: artefak dibangun dan dievaluasi secara rigorous.
+6. Mindset peneliti terangkum dalam tiga mode: **Curious** (mempertanyakan), **Critical** (mengevaluasi bukti), **Systematic** (merancang investigasi terstruktur).
+7. Kegagalan adalah bagian dari riset — *negative results* sama berharganya dengan *positive results* karena keduanya menambah pengetahuan.
+
+---
+
+## 1.12 Latihan & Refleksi
+
+### Latihan 1 — Identifikasi Distorsi
+
+Perhatikan Research Trust Model. Untuk setiap tahap transisi (Reality→Data, Data→Processing, Processing→Analysis, Analysis→Inference, Inference→Knowledge), berikan **satu contoh konkret** distorsi yang bisa terjadi dalam riset sistem rekomendasi. Jelaskan bagaimana distorsi tersebut bisa dideteksi dan dicegah.
+
+### Latihan 2 — Analisis Kasus Etika
+
+Baca kasus berikut: *"Seorang peneliti mengembangkan model prediksi keberhasilan belajar berdasarkan data akademik. Model dilatih pada data 5 tahun terakhir dari satu universitas. Akurasi mencapai 82%. Peneliti mengklaim model bisa digunakan oleh semua universitas di Indonesia."*
+
+Identifikasi:
+- Pelanggaran etika (jika ada)
+- Ancaman terhadap internal, external, dan construct validity
+- Perbaikan yang diperlukan agar klaim menjadi valid
+
+### Latihan 3 — Posisi Paradigma Anda
+
+Pilih satu topik riset TI yang Anda minati. Jelaskan bagaimana topik tersebut akan didekati secara berbeda dari perspektif: (a) positivisme, (b) interpretivisme, (c) pragmatisme. Lalu argumentasikan mengapa pendekatan positivist + DSR paling sesuai (atau paling tidak sesuai) untuk topik Anda.
+
+### Refleksi
+
+> "Sebelum membaca bab ini, apa yang saya anggap sebagai 'riset' di bidang TI? Setelah membaca, apa yang berubah? Apakah ada asumsi saya yang perlu dikoreksi?"
+
+---
+
+Fondasi sudah diletakkan: etika sebagai penjaga, validitas sebagai standar, paradigma sebagai lensa. Pertanyaan berikutnya — dari mana penelitian dimulai? Bab 2 membahas keterampilan yang paling mendasar namun paling sering diabaikan: merumuskan masalah riset yang tajam, terukur, dan siap dieksperimenkan.
+
+> *"Penelitian bukan tentang mendapatkan hasil, tetapi tentang memastikan hasil tersebut dapat dipercaya."*
+
+---
+
+## Daftar Pustaka
+
+- ACM. (2018). *ACM Code of Ethics and Professional Conduct.* Association for Computing Machinery.
+- Creswell, J. W. (2012). *Educational Research: Planning, Conducting, and Evaluating Quantitative and Qualitative Research* (4th ed.). Pearson.
+- Creswell, J. W., & Creswell, J. D. (2018). *Research Design: Qualitative, Quantitative, and Mixed Methods Approaches* (5th ed.). SAGE Publications.
+- Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design Science in Information Systems Research. *MIS Quarterly*, 28(1), 75–105.
+- Resnik, D. B. (2020). *The Ethics of Science: An Introduction* (2nd ed.). Routledge.
+- Shadish, W. R., Cook, T. D., & Campbell, D. T. (2002). *Experimental and Quasi-Experimental Designs for Generalized Causal Inference*. Houghton Mifflin.
+- Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., & Wesslén, A. (2012). *Experimentation in Software Engineering*. Springer.
+
+---
+
+<!-- METADATA -->
+| Key | Value |
+|-----|-------|
+| Signature Model | Research Trust Model |
+| Sub-CPMK | 1.1 |
+| CPMK | CPMK01 |
+| CPL | CPL03, CPL01 |
+| Fase | Thinking |
+| Jumlah Referensi | 7 |
+| Studi Kasus | 2 (Basic: ML data fabrication, Advanced: AI bias) |
+| Cognitive Traps | 4 |
+| Quality Gate — Relevansi | ✅ Mendorong pembaca berpikir kritis tentang apa itu riset |
+| Quality Gate — Eksperimental | ✅ Mengarahkan ke pemahaman validitas eksperimen |
+| Quality Gate — Output | ✅ Esai analisis kasus etika + posisi paradigma |
+| Status | 🟢 Draft Complete |
--- a/book/bagian-1-foundation/bab-02-problem-formulation.md
+++ b/book/bagian-1-foundation/bab-02-problem-formulation.md
@ -0,0 +1,547 @@
+# Bab 2 — Problem Formulation & System Context
+
+> **Sub-CPMK:** 1.2 — Merumuskan masalah riset dari fenomena TI
+> **CPMK:** CPMK01 — Problem Framing
+> **CPL Utama:** CPL03 (Penalaran logis, kritis, sistematis)
+> **CPL Pendukung:** CPL06 (Desain & pengembangan)
+> **Fase:** Thinking (M1–M4)
+
+---
+
+## Ringkasan Bab
+
+Bab ini mengajarkan keterampilan paling mendasar namun paling sering diabaikan dalam riset: **merumuskan masalah**. Banyak penelitian gagal bukan karena metodenya lemah atau datanya kurang, melainkan karena masalah yang diteliti tidak pernah dirumuskan dengan jelas sejak awal. Kita akan belajar membedakan topik dari masalah, gejala dari akar masalah, dan — yang paling penting — mengubah masalah dunia nyata menjadi *researchable problem* yang bisa diukur, diuji, dan dibuktikan melalui eksperimen.
+
+---
+
+## 2.1 Pembuka
+
+Bab 1 membahas bahwa riset di bidang Teknologi Informasi bukan sekadar membangun sistem, melainkan membuktikan bahwa temuan benar, valid, dan dapat dipercaya. Mindset *Curious → Critical → Systematic* sudah tertanam. Pertanyaan berikutnya: dari mana penelitian dimulai?
+
+Jawabannya bukan dari metode. Bukan dari dataset. Bukan dari tool. Penelitian dimulai dari **masalah**.
+
+Namun, "masalah" dalam konteks riset berbeda jauh dari keluhan sehari-hari. Seseorang yang mengatakan "website kampus lambat" sedang mengutarakan keluhan. Seorang peneliti yang mengatakan "waktu respons server meningkat 340% saat concurrent user melebihi 500, dan belum ada studi yang mengevaluasi efektivitas caching strategy X pada arsitektur monolitik di lingkungan akademik" sedang merumuskan masalah riset. Perbedaannya? **Presisi, konteks, dan testability.**
+
+Dalam bidang Teknologi Informasi dan Software Engineering, masalah riset selalu terikat pada **sistem**. Sistem memiliki input, proses, output, outcome, constraints, dan stakeholders. Tanpa memahami konteks sistem, masalah hanya menjadi pernyataan abstrak yang tidak bisa dieksperimenkan. Karena itu, bab ini menggabungkan dua keterampilan: merumuskan masalah (*problem formulation*) dan memahami konteks sistem (*system context*).
+
+Sasarannya: mampu mengambil fenomena apa pun di dunia TI — dari performa aplikasi yang menurun, pengguna yang meninggalkan fitur, hingga model machine learning yang bias — lalu mengubahnya menjadi research problem yang jelas, terukur, dan siap diproposalkan.
+
+Pertanyaan utama bab ini: **Bagaimana mengubah pengamatan sehari-hari menjadi masalah riset yang bisa diuji secara ilmiah?**
+
+---
+
+## 2.2 Problem Formation Model & Problem Quality Model
+
+Bab ini memiliki dua model visual yang saling melengkapi. Model pertama menunjukkan **proses** transformasi dari pengamatan menjadi masalah riset. Model kedua menunjukkan **kriteria** yang harus dipenuhi agar masalah tersebut layak diteliti.
+
+### Problem Formation Model
+
+**Gambar 2.1** — Problem Formation Model: Dari Realitas ke Variabel Terukur
+
+```mermaid
+graph LR
+    A["🌍 <b>Reality</b><br/><i>Fenomena dunia nyata</i>"]
+    B["👁️ <b>Observed Issue</b><br/><i>Symptom</i>"]
+    C["🔍 <b>Diagnosed Problem</b><br/><i>Root Cause</i>"]
+    D["📐 <b>Researchable Problem</b><br/><i>Scoped & Bounded</i>"]
+    E["📏 <b>Measurable Variable</b><br/><i>Operationalized</i>"]
+
+    A -->|"Pengamatan"| B
+    B -->|"Analisis"| C
+    C -->|"Literature check"| D
+    D -->|"Operasionalisasi"| E
+
+    style A fill:#DBEAFE,stroke:#2563EB,color:#1E3A5F
+    style B fill:#93C5FD,stroke:#2563EB,color:#1E3A5F
+    style C fill:#60A5FA,stroke:#2563EB,color:#1E3A5F
+    style D fill:#3B82F6,stroke:#2563EB,color:#FFFFFF
+    style E fill:#2563EB,stroke:#1D4ED8,color:#FFFFFF
+```
+
+Model ini menggambarkan bahwa masalah riset tidak muncul begitu saja — ia melewati proses transformasi bertahap. Setiap tahap memiliki fungsi spesifik:
+
+1. **Reality** — Dunia nyata tempat fenomena terjadi. Bisa berupa lingkungan industri, kampus, aplikasi yang berjalan, atau interaksi pengguna dengan sistem.
+2. **Observed Issue (Symptom)** — Pengamatan awal terhadap sesuatu yang "tidak beres." Ini belum tentu masalah — bisa jadi hanya gejala. Contoh: "pengguna mengeluh aplikasi lambat."
+3. **Diagnosed Problem (Root Cause)** — Setelah investigasi, gejala ditelusuri ke akar masalah. Contoh: "query database tidak terindeks, menyebabkan full table scan pada tabel dengan 2 juta record."
+4. **Researchable Problem** — Masalah yang sudah di-*scope*, dibatasi, dan dihubungkan dengan gap di literatur. Bukan semua masalah bisa diteliti — hanya yang memiliki kontribusi ilmiah.
+5. **Measurable Variable** — Masalah yang telah ditransformasi menjadi variabel yang bisa diukur, dibandingkan, dan diuji secara statistik.
+
+Sebagian besar kegagalan riset pemula terjadi karena melompat langsung dari *Reality* ke *Measurable Variable* tanpa melewati tiga tahap di tengah. Hasilnya: variabel yang diukur tidak menjawab masalah yang sebenarnya.
+
+### Problem Quality Model
+
+**Gambar 2.2** — Problem Quality Model: 5 Kriteria Masalah Riset yang Layak
+
+```mermaid
+block-beta
+    columns 1
+    block:header:1
+        columns 1
+        H["<b>PROBLEM QUALITY MODEL</b>"]
+    end
+    block:criteria:1
+        columns 2
+        C1["<b>Clarity</b>"] C1D["Apakah masalah bisa dipahami<br/>tanpa ambiguitas oleh pembaca?"]
+        C2["<b>Measurability</b>"] C2D["Apakah masalah bisa diukur<br/>dengan metrik yang jelas?"]
+        C3["<b>Relevance</b>"] C3D["Apakah masalah penting bagi domain<br/>TI/SE dan memiliki gap di literatur?"]
+        C4["<b>Testability</b>"] C4D["Apakah masalah bisa diuji<br/>melalui eksperimen yang feasible?"]
+        C5["<b>Impact</b>"] C5D["Apakah solusi memberikan kontribusi<br/>nyata (praktis atau teoretis)?"]
+    end
+
+    style H fill:#2563EB,color:#FFFFFF,stroke:#1D4ED8
+    style C1 fill:#3B82F6,color:#FFFFFF,stroke:#2563EB
+    style C2 fill:#3B82F6,color:#FFFFFF,stroke:#2563EB
+    style C3 fill:#3B82F6,color:#FFFFFF,stroke:#2563EB
+    style C4 fill:#3B82F6,color:#FFFFFF,stroke:#2563EB
+    style C5 fill:#3B82F6,color:#FFFFFF,stroke:#2563EB
+    style C1D fill:#EFF6FF,color:#1E3A5F,stroke:#93C5FD
+    style C2D fill:#EFF6FF,color:#1E3A5F,stroke:#93C5FD
+    style C3D fill:#EFF6FF,color:#1E3A5F,stroke:#93C5FD
+    style C4D fill:#EFF6FF,color:#1E3A5F,stroke:#93C5FD
+    style C5D fill:#EFF6FF,color:#1E3A5F,stroke:#93C5FD
+```
+
+Kedua model bekerja bersamaan: Problem Formation Model menjawab **"bagaimana prosesnya?"**, sementara Problem Quality Model menjawab **"apakah hasilnya cukup baik?"**. Setiap researchable problem yang dihasilkan dari tahap formasi harus divalidasi terhadap lima kriteria kualitas ini sebelum dilanjutkan ke tahap berikutnya dalam research pipeline.
+
+Jika masalah riset tidak lulus kelima kriteria ini, ulangi proses formasi. Lebih baik menghabiskan satu minggu memperbaiki masalah daripada satu semester meneliti masalah yang salah.
+
+---
+
+## 2.3 Definisi Kunci
+
+**Topik Riset (*Research Topic*)**
+: Area atau bidang umum yang menjadi konteks penelitian. Topik belum memiliki pertanyaan spesifik dan tidak bisa diuji langsung. Contoh: "machine learning untuk deteksi anomali."
+
+**Masalah Riset (*Research Problem*)**
+: Pernyataan eksplisit tentang gap, kontradiksi, atau ketidakjelasan dalam pengetahuan yang ada, yang memerlukan investigasi ilmiah. Masalah riset harus spesifik, terukur, dan terikat pada konteks tertentu (Creswell & Creswell, 2018).
+
+**Problem Statement**
+: Formulasi tertulis dari masalah riset yang mencakup: konteks sistem, gap yang teridentifikasi, dampak masalah, dan mengapa masalah tersebut layak diteliti. Problem statement adalah "kontrak" antara peneliti dengan pembimbing dan penguji.
+
+**System Context**
+: Deskripsi lengkap tentang sistem tempat masalah berada, mencakup: input, proses, output, outcome, constraints, stakeholders, dan lingkungan operasional. Dalam riset TI, setiap masalah selalu terikat pada sistem tertentu (Hevner et al., 2004).
+
+---
+
+## 2.4 Konsep Inti
+
+### 2.4.1 Topic vs Problem vs Research Problem: Hierarki Ketajaman
+
+Salah satu kesalahan paling umum dalam riset adalah mencampuradukkan tiga konsep yang sebenarnya berbeda level kedalaman.
+
+**Topik** adalah wilayah. Seperti peta, topik menunjukkan "di mana Anda berada" secara umum. Contoh: *"Keamanan jaringan IoT."* Ini informatif, tapi tidak bisa diteliti — terlalu luas.
+
+**Masalah** (*problem*) adalah celah di dalam wilayah itu. Seperti lubang di jalan — Anda bisa menunjuknya dengan jelas. Contoh: *"Protokol MQTT pada perangkat IoT rumahan tidak mengenkripsi payload secara default, menyebabkan data sensor rentan terhadap man-in-the-middle attack."* Ini sudah spesifik, tapi belum tentu bisa diteliti.
+
+**Masalah riset** (*research problem*) adalah masalah yang sudah melewati tiga filter: (1) ada gap di literatur — belum ada atau belum cukup studi yang menjawab, (2) bisa ditransformasi menjadi variabel terukur, dan (3) bisa diuji melalui eksperimen yang feasible.
+
+Analoginya seperti ini:
+
+| Level | Analogi | Contoh TI |
+|-------|---------|-----------|
+| Topik | "Ada masalah di kota ini" | "Keamanan IoT" |
+| Masalah | "Jalan utama berlubang di KM 5" | "MQTT tidak terenkripsi pada IoT rumahan" |
+| Masalah Riset | "Lubang di KM 5 disebabkan oleh drainase yang gagal, dan belum ada studi tentang material X untuk kondisi ini" | "Belum ada studi yang membandingkan overhead TLS 1.3 vs DTLS pada MQTT di perangkat IoT resource-constrained (RAM < 64KB)" |
+
+Yang perlu dicatat: masalah riset memiliki tiga elemen yang tidak dimiliki masalah biasa — **gap** ("belum ada studi"), **variabel terukur** ("overhead"), dan **batasan konteks** ("resource-constrained, RAM < 64KB").
+
+### 2.4.2 Symptom vs Problem: Menggali Akar Masalah
+
+Dalam praktik riset TI, apa yang terlihat di permukaan bukan selalu masalah yang sebenarnya. Ada perbedaan penting antara **gejala** (*symptom*) dan **masalah** (*problem*).
+
+Gejala adalah apa yang **diamati**. Masalah adalah **mengapa** pengamatan itu terjadi.
+
+| Symptom (Gejala) | Diagnosed Problem (Akar Masalah) |
+|-------------------|----------------------------------|
+| "Aplikasi crash setiap 2 jam" | Memory leak pada modul caching yang tidak melakukan garbage collection |
+| "User meninggalkan halaman checkout" | Waktu loading halaman > 8 detik karena API call berurutan (sequential) |
+| "Model prediksi akurasinya 95% tapi bisnis tidak puas" | Model tidak menangkap kasus minority class (precision rendah pada kelas target) |
+| "Pengguna tidak menggunakan fitur forum di LMS" | UX path ke forum membutuhkan 5 klik dari landing page |
+
+Teknik untuk menggali akar masalah:
+
+1. **5 Whys** — Tanyakan "mengapa?" berulang kali hingga sampai ke root cause. Wohlin et al. (2012) menekankan bahwa dalam software engineering, gejala teknis seringkali memiliki akar pada keputusan desain (*design decision*) yang tidak dievaluasi.
+2. **Fishbone Diagram (Ishikawa)** — Klasifikasikan penyebab ke dalam kategori: Teknologi, Proses, Data, Manusia, Environment.
+3. **Triangulasi** — Konfirmasi root cause dari minimal dua sumber berbeda (log, user feedback, metric monitoring).
+
+### 2.4.3 System Thinking: Input → Process → Output → Outcome
+
+Dalam riset Teknologi Informasi, masalah tidak pernah berdiri sendiri — ia selalu terikat pada **sistem**. Pendekatan *Design Science Research* (Hevner et al., 2004; Peffers et al., 2007) menempatkan masalah riset dalam konteks artefak dan lingkungan. Untuk itu, kita perlu memahami sistem secara utuh.
+
+Setiap sistem TI dapat didekomposisi menjadi:
+
+| Komponen | Deskripsi | Contoh (Sistem Rekomendasi) |
+|----------|-----------|----------------------------|
+| **Input** | Data atau permintaan yang masuk ke sistem | User rating, item metadata, click history |
+| **Process** | Logika, algoritma, atau transformasi yang terjadi | Collaborative filtering, content-based filtering |
+| **Output** | Hasil langsung dari proses | Daftar 10 rekomendasi teratas |
+| **Outcome** | Dampak output terhadap pengguna/bisnis | User engagement, conversion rate, satisfaction |
+| **Constraints** | Batasan teknis, waktu, atau sumber daya | Latensi < 200ms, RAM ≤ 4GB, cold-start users |
+| **Stakeholders** | Pihak yang berkepentingan | End user, product owner, data team |
+
+Mengapa system thinking penting dalam formulasi masalah? Karena masalah riset yang baik selalu **terikat pada komponen sistem yang spesifik**. "Sistem rekomendasi tidak akurat" terlalu umum. "Output ranking dari collaborative filtering tidak mencerminkan preferensi pengguna baru (cold-start) karena kurangnya data historis (< 5 rating)" — ini terikat pada komponen spesifik: **output** (ranking), **process** (CF), **constraints** (cold-start, < 5 rating), dan **stakeholder** (pengguna baru).
+
+### 2.4.4 Problem → Variable → Metric: Transformasi Kunci
+
+Langkah transformasi dari masalah ke variabel yang terukur adalah titik kritis dalam riset. Banyak peneliti pemula mampu mengidentifikasi masalah, namun gagal pada langkah ini.
+
+**Prinsipnya sederhana: setiap pernyataan dalam masalah harus bisa diwujudkan menjadi sesuatu yang bisa diukur.**
+
+Perhatikan transformasi berikut:
+
+| Problem Statement | Variable | Metric | Alat Ukur |
+|-------------------|----------|--------|-----------|
+| "Algoritma A lebih lambat dari B" | Waktu eksekusi | Milidetik (ms) | Benchmark profiler |
+| "Model ML tidak adil terhadap grup tertentu" | Fairness (*demographic parity*) | Rasio prediksi positif antar-grup | Fairness toolkit (AIF360) |
+| "Pengguna tidak puas dengan antarmuka" | Usability (*satisfaction score*) | SUS score (0–100) | System Usability Scale questionnaire |
+| "Enkripsi menambah overhead pada IoT" | Resource consumption | CPU usage (%), RAM (KB), latency (ms) | Profiler, system monitor |
+
+Shadish et al. (2002) menekankan bahwa variabel harus memiliki **operational definition** — definisi yang cukup jelas sehingga peneliti lain bisa mengukur hal yang sama dengan cara yang sama dan mendapatkan hasil yang konsisten.
+
+### 2.4.5 Lima Kriteria Problem Statement yang Kuat
+
+Sebagai validasi akhir, evaluasi masalah riset Anda terhadap lima kriteria berikut:
+
+1. **Specific** — Apakah masalah cukup sempit? Bisa dijawab dalam satu studi?
+2. **Measurable** — Apakah ada metrik yang bisa mengukur masalah dan solusi?
+3. **Relevant** — Apakah masalah penting bagi komunitas riset atau industri TI?
+4. **Testable** — Apakah masalah bisa diuji melalui eksperimen?
+5. **Real-world** — Apakah masalah berasal dari fenomena nyata, bukan imajinasi?
+
+> 💡 **Insight:**
+> Kriteria ini bukan checklist untuk dicentang sekali, melainkan filter iteratif. Setiap kali Anda memperbaiki problem statement, jalankan kembali kelima filter ini.
+
+---
+
+## 2.5 Research vs Engineering
+
+**Tabel 2.1** — Perbandingan Perspektif Research vs Engineering dalam Problem Formulation
+
+| Aspek | Engineering | Research |
+|-------|------------|----------|
+| **Tujuan** | Menyelesaikan masalah (*solve*) | Memahami dan membuktikan (*understand & prove*) |
+| **Pertanyaan** | "Bagaimana membuat ini bekerja?" | "Mengapa pendekatan A lebih efektif dari B dalam konteks C?" |
+| **Masalah** | Bug, error, fitur yang belum ada | Gap dalam pengetahuan, ketidakpastian metode |
+| **Sukses diukur dari** | Sistem berjalan, client puas | Hipotesis terjawab, kontribusi tervalidasi |
+| **Scope** | Selesaikan semua yang perlu | Batasi scope agar bisa dibuktikan |
+| **Output** | Working system, deployment | Evidence, paper, replicable findings |
+
+Seorang engineer yang menemukan bug dan memperbaikinya sedang melakukan problem solving. Seorang peneliti yang menyelidiki *mengapa* kategori bug tertentu lebih sering muncul di arsitektur microservice dibanding monolith, lalu menguji hipotesisnya melalui eksperimen terkontrol, sedang melakukan research. Keduanya berangkat dari masalah — tapi sifat masalahnya berbeda.
+
+---
+
+## 2.6 Research Reality
+
+### Fenomena 1 — "Masalah yang Hilang di Tengah Jalan"
+
+Banyak laporan riset yang jika ditelusuri dari Bab 1 (Pendahuluan) ke Bab 3 (Metodologi), masalahnya "bermutasi." Di Bab 1, masalah yang diangkat adalah performa sistem. Tapi di Bab 3, yang diukur tiba-tiba usability. Ini terjadi karena problem statement di awal tidak cukup presisi — sehingga peneliti "mengikuti data yang tersedia" alih-alih "mencari data yang dibutuhkan." Fenomena ini disebut **problem drift**, dan merupakan salah satu penyebab paling umum revisi berulang saat sidang.
+
+### Fenomena 2 — "Solution-First Thinking"
+
+Di industri software, mentalitas "mulai dari solusi" sangat lazim dan bahkan dianggap efisien. Namun dalam riset, mentalitas ini berbahaya. Peneliti yang memulai dari "saya ingin membuat chatbot berbasis GPT" tanpa masalah yang jelas akan kesulitan di tahap validasi — karena tidak ada baseline, tidak ada metrik yang didefinisikan sejak awal, dan tidak ada kriteria kapan "berhasil" dan kapan "gagal."
+
+Creswell dan Creswell (2018) menegaskan: *"A research problem is a general issue, concern, or controversy addressed in research that narrows the topic."* Artinya, masalah selalu datang **sebelum** solusi.
+
+### Fenomena 3 — "Masalah yang Tidak Bisa Gagal"
+
+Beberapa peneliti pemula merumuskan masalah yang jawabannya sudah pasti — misalnya: "Apakah penerapan metode X dapat meningkatkan akurasi?" Jika metode X sudah terbukti di ratusan studi, maka pertanyaannya *trivial*. Riset yang baik harus memiliki kemungkinan untuk **gagal** — karena justru dari kemungkinan gagal itulah kontribusi ilmiah muncul. Jika hasilnya sudah pasti, itu bukan riset — itu demonstrasi.
+
+Riset yang baik dimulai dari masalah yang jawabannya belum pasti. Jika jawabannya sudah diketahui sebelum eksperimen, yang terjadi bukan investigasi melainkan konfirmasi.
+
+---
+
+## 2.7 Cognitive Traps
+
+**Trap 1: "Saya ingin menggunakan metode X"**
+
+Bentuk klasik *solution-first thinking*. Metode adalah alat — dipilih setelah masalah dan research question jelas, bukan sebelumnya. Peneliti yang memulai dari metode akan terjebak mencari masalah yang "cocok" dengan metode, alih-alih mencari metode yang tepat untuk masalah. Wohlin et al. (2012) menekankan bahwa pemilihan metode harus didorong oleh sifat masalah (*problem-driven*), bukan ketersediaan metode (*method-driven*).
+
+**Trap 2: "Semakin kompleks semakin bagus"**
+
+Masalah riset yang baik bukan yang paling kompleks, melainkan yang paling tajam. Peneliti pemula sering menambahkan variabel, memperluas scope, atau memilih algoritma rumit karena mengira kompleksitas = kualitas. Riset yang kuat justru berhasil menjawab pertanyaan sederhana namun penting dengan bukti yang solid. Occam's Razor berlaku: jangan menambah kompleksitas tanpa kebutuhan.
+
+**Trap 3: "Problem tidak perlu diukur"**
+
+Beberapa peneliti pemula menulis masalah dalam bentuk narasi panjang tanpa satupun metrik. "Sistem kurang optimal" — kurang optimal dibanding apa? Diukur dengan apa? Tanpa metrik, masalah hanya opini. Masalah riset harus bisa diterjemahkan ke dalam variabel terukur, atau ia bukan masalah riset — ia keluhan (Shadish et al., 2002).
+
+**Trap 4: "Semua problem bisa diteliti"**
+
+Tidak semua masalah adalah masalah riset. "Server kampus sering down" adalah masalah operasional — solusinya upgrade server, bukan riset. Masalah menjadi *researchable* hanya jika: (a) ada gap pengetahuan yang relevan, (b) jawabannya belum pasti, dan (c) penyelesaiannya menghasilkan kontribusi yang bisa direplikasi oleh peneliti lain.
+
+---
+
+## 2.8 Studi Kasus
+
+### Kasus 1 (Basic): "Sistem Rekomendasi Film — Akurasi Tinggi tapi User Tidak Puas"
+
+**Konteks:**
+
+Sebuah tim peneliti membangun sistem rekomendasi film menggunakan collaborative filtering. Hasil evaluasi menunjukkan RMSE (*Root Mean Square Error*) sebesar 0.87 — angka yang cukup baik menurut standar literatur. Namun, saat dilakukan user testing terhadap 30 pengguna, mayoritas menyatakan bahwa rekomendasi yang diberikan "membosankan" dan "sudah ditebak." Satisfaction score hanya 45/100.
+
+**❌ Pendekatan Salah (Bad Approach):**
+
+"Masalah: Sistem rekomendasi film menggunakan collaborative filtering belum optimal. Tujuan: Mengoptimalkan sistem rekomendasi film."
+
+Mengapa salah:
+- "Belum optimal" — dibanding apa? Tidak ada baseline.
+- "Mengoptimalkan" — mengoptimalkan metrik yang mana?
+- Problem tidak bisa diukur dan tidak bisa gagal.
+
+**✅ Pendekatan Benar (Good Approach):**
+
+"Masalah: Sistem rekomendasi berbasis collaborative filtering menghasilkan RMSE rendah (0.87) namun satisfaction score rendah (45/100). Perbedaan antara akurasi prediktif dan kepuasan pengguna mengindikasikan bahwa metrik evaluasi tradisional (RMSE) tidak cukup merepresentasikan kualitas rekomendasi dari perspektif pengguna. Belum ada studi yang mengevaluasi pengaruh penambahan diversity metric (Intra-List Diversity) terhadap trade-off antara akurasi dan kepuasan pengguna pada domain film."
+
+Mengapa benar:
+- Masalah spesifik dan terikat pada data (RMSE 0.87, satisfaction 45/100)
+- Ada kontradiksi yang jelas (akurasi bagus ↔ kepuasan rendah)
+- Ada gap ("belum ada studi yang mengevaluasi...")
+- Variabel terukur jelas (ILD, RMSE, satisfaction score)
+- Bisa diuji dan bisa gagal
+
+**Perbandingan:**
+
+| Aspek | Bad | Good |
+|-------|-----|------|
+| Specificity | "Belum optimal" | RMSE 0.87, satisfaction 45/100 |
+| Measurability | Tidak ada metrik | RMSE, ILD, satisfaction score |
+| Gap | Tidak disebutkan | "Belum ada studi yang..." |
+| Testability | Tidak jelas kapan selesai | Bisa dieksperimen (A/B test) |
+| Potential to fail | Tidak bisa gagal | Bisa: ILD mungkin tidak meningkatkan satisfaction |
+
+Akurasi teknis dan kepuasan pengguna adalah dua metrik berbeda. Masalah riset yang kuat mengidentifikasi kontradiksi antara dua metrik dan menyelidiki penyebabnya.
+
+---
+
+### Kasus 2 (Advanced): "Sistem Deteksi Fraud — 98% Akurasi tapi Fraud Tetap Lolos"
+
+**Konteks:**
+
+Sebuah perusahaan fintech mengimplementasikan model deteksi fraud berbasis Random Forest. Model mencapai overall accuracy 98.2%. Namun, departemen risk management melaporkan bahwa kerugian akibat fraud justru meningkat 15% dibanding kuartal sebelumnya. Investigasi menunjukkan bahwa dataset training sangat imbalanced: 97.8% transaksi legitimate, 2.2% fraud. Model "belajar" untuk hampir selalu memprediksi "legitimate" — dan tetap mendapat akurasi tinggi karena class distribution.
+
+**❌ Pendekatan Salah:**
+
+"Masalah: Sistem deteksi fraud menggunakan Random Forest memiliki akurasi 98% namun masih ada fraud yang lolos. Tujuan: Meningkatkan akurasi sistem deteksi fraud."
+
+Mengapa salah:
+- Masalah sebenarnya bukan akurasi — akurasinya sudah tinggi
+- Tidak mengidentifikasi root cause (class imbalance)
+- Metrik yang dipilih (accuracy) justru menyembunyikan masalah
+- "Meningkatkan akurasi" akan memperkuat bias yang sudah ada
+
+**✅ Pendekatan Benar:**
+
+"Masalah: Model deteksi fraud berbasis Random Forest menunjukkan accuracy 98.2% namun recall pada kelas fraud hanya 12.4% (sensitivity). Penyebab utama adalah class imbalance ratio 44.5:1 pada dataset training. Studi sebelumnya (Rahman et al., 2020; Chen et al., 2021) telah mengevaluasi SMOTE dan cost-sensitive learning secara terpisah, namun belum ada studi yang membandingkan efektivitas kombinasi keduanya terhadap recall dan precision pada dataset transaksi dengan imbalance ratio > 40:1. Penelitian ini bertujuan mengevaluasi apakah kombinasi SMOTE + cost-sensitive Random Forest secara signifikan meningkatkan recall kelas fraud tanpa menurunkan precision di bawah threshold operasional (≥ 70%)."
+
+Mengapa benar:
+- Mengidentifikasi root cause (class imbalance ratio 44.5:1)
+- Menggunakan metrik yang tepat (recall, precision) bukan accuracy
+- Gap jelas dan spesifik (kombinasi teknik belum diuji pada ratio > 40:1)
+- Threshold sukses didefinisikan (recall ↑ tanpa precision < 70%)
+- Bisa gagal: kombinasi mungkin tidak lebih baik dari teknik individual
+
+**Perbandingan:**
+
+| Aspek | Bad | Good |
+|-------|-----|------|
+| Root cause | Tidak teridentifikasi | Class imbalance ratio 44.5:1 |
+| Metrik | Accuracy (misleading) | Recall, Precision (appropriate) |
+| Gap | Tidak ada | Kombinasi teknik belum diuji pada extreme imbalance |
+| Threshold | Tidak ada | Precision ≥ 70% sebagai threshold operasional |
+| Falsifiability | Tidak bisa gagal | Kombinasi bisa saja tidak lebih baik |
+
+Dalam masalah domain-spesifik seperti fraud detection, pemilihan metrik evaluasi adalah bagian dari problem formulation. Akurasi tinggi pada dataset imbalanced justru bisa menjadi indikator masalah, bukan indikator kesuksesan. Peneliti yang cermat mempertanyakan metrik sebelum percaya pada angka.
+
+---
+
+## 2.9 Template Praktis
+
+> 🔧 **Template: Problem Statement Builder**
+>
+> Gunakan template ini untuk menyusun problem statement Anda. Isi setiap bagian secara berurutan.
+>
+> ```
+> PROBLEM STATEMENT
+> ═══════════════════════════════════════════════════
+>
+> 1. KONTEKS SISTEM
+>    Sistem/domain    : [Nama sistem/domain]
+>    Input            : [Apa yang masuk ke sistem]
+>    Process          : [Algoritma/metode yang digunakan]
+>    Output           : [Apa yang dihasilkan]
+>    Stakeholders     : [Siapa yang terdampak]
+>    Constraints      : [Batasan teknis/waktu/resources]
+>
+> 2. FENOMENA (Symptom)
+>    Apa yang diamati : [Deskripsi pengamatan]
+>    Bukti/data       : [Angka, log, feedback]
+>
+> 3. AKAR MASALAH (Diagnosed Problem)
+>    Root cause       : [Penyebab utama]
+>    Investigasi      : [Bagaimana root cause ditemukan]
+>
+> 4. GAP LITERATUR
+>    Studi terdahulu  : [Apa yang sudah diteliti]
+>    Celah            : [Apa yang belum diteliti]
+>
+> 5. MASALAH RISET (Researchable Problem)
+>    Statement        : [1-2 kalimat problem statement final]
+>
+> 6. VARIABEL TERUKUR
+>    Independent Var  : [Variabel yang dimanipulasi]
+>    Dependent Var    : [Variabel yang diukur]
+>    Metrik           : [Satuan ukuran]
+>    Alat ukur        : [Tool/instrument]
+>
+> 7. VALIDASI (Problem Quality Model)
+>    [ ] Specific     : [Ya/Tidak — jelaskan]
+>    [ ] Measurable   : [Ya/Tidak — jelaskan]
+>    [ ] Relevant     : [Ya/Tidak — jelaskan]
+>    [ ] Testable     : [Ya/Tidak — jelaskan]
+>    [ ] Real-world   : [Ya/Tidak — jelaskan]
+>
+> ═══════════════════════════════════════════════════
+> ```
+
+---
+
+## 2.10 Mindmap Ringkasan
+
+**Gambar 2.3** — Mindmap Bab 2: Problem Formulation & System Context
+
+```mermaid
+mindmap
+  root(("**Problem Formulation<br/>& System Context**"))
+    Quality Model
+      Specific
+      Measurable
+      Relevant
+      Testable
+      Real-world
+    Formation Model
+      Reality
+      Observed Issue
+      Diagnosed Problem
+      Researchable Problem
+      Measurable Variable
+    Hierarki
+      Topic
+      Problem
+      Research Problem
+    System Context
+      Input
+      Process
+      Output
+      Outcome
+      Constraints
+      Stakeholders
+    Transformasi
+      Problem → Variable
+      Variable → Metric
+    Cognitive Traps
+      Solution-first
+      Complexity bias
+      Unmeasurable
+      Non-researchable
+```
+
+---
+
+## 2.11 Rangkuman
+
+**Poin-poin utama bab ini:**
+
+1. **Penelitian dimulai dari masalah**, bukan dari metode atau solusi. Masalah harus dirumuskan secara eksplisit sebelum melangkah lebih jauh dalam research pipeline.
+
+2. **Problem Formation Model** menunjukkan bahwa masalah riset melewati lima tahap transformasi: Reality → Observed Issue → Diagnosed Problem → Researchable Problem → Measurable Variable. Setiap tahap tidak boleh dilompati.
+
+3. **Topic ≠ Problem ≠ Research Problem.** Topik adalah area umum, masalah adalah celah spesifik, dan masalah riset adalah celah yang memiliki gap literatur, variabel terukur, dan bisa dieksperimenkan.
+
+4. **Symptom ≠ Root Cause.** Apa yang terlihat di permukaan belum tentu masalah yang sebenarnya. Gunakan teknik 5 Whys, Fishbone, atau triangulasi untuk menggali akar masalah.
+
+5. **System context wajib ada.** Setiap masalah riset TI harus terikat pada sistem yang jelas: input, process, output, outcome, constraints, dan stakeholders.
+
+6. **Problem Quality Model** memberikan 5 kriteria validasi: Clarity, Measurability, Relevance, Testability, dan Impact. Kelimanya harus terpenuhi.
+
+7. **Transformasi Problem → Variable → Metric** adalah langkah kritis yang menghubungkan masalah abstrak dengan eksperimen konkret.
+
+Masalah yang terformulasi dengan baik membuka jalan ke tahap berikutnya. Bab 3 membahas bagaimana menempatkan masalah riset dalam konteks literatur yang ada, mengidentifikasi gap, dan memposisikan kontribusi secara tepat.
+
+> 🔥 **Final Statement:**
+> "Penelitian tidak dimulai dari solusi, tetapi dari masalah yang dipahami secara mendalam dan dapat diuji secara ilmiah."
+
+---
+
+## 2.12 Latihan & Refleksi
+
+### Pertanyaan Refleksi
+
+1. Pikirkan proyek riset yang pernah atau sedang Anda kerjakan. Apakah Anda memulai dari masalah atau dari solusi? Jika dari solusi, coba rumuskan ulang: apa masalah yang sebenarnya Anda coba selesaikan?
+
+2. Ambil satu topik TI yang Anda minati. Transformasikan dari level **topik** ke level **research problem** menggunakan hierarki Topic → Problem → Research Problem. Di mana hambatan terbesarnya?
+
+3. Mengapa akurasi 98% pada kasus deteksi fraud justru bisa menjadi indikator masalah? Apa pelajarannya tentang pemilihan metrik evaluasi?
+
+4. Apa perbedaan antara masalah yang "tidak bisa gagal" dengan masalah riset yang baik? Berikan satu contoh masing-masing dari domain TI.
+
+### Latihan Praktis
+
+1. **Problem Statement Exercise:** Pilih satu dari fenomena berikut, lalu susun problem statement lengkap menggunakan template di section 2.9:
+   - (a) Aplikasi e-commerce memiliki cart abandonment rate 73%
+   - (b) Chatbot customer service hanya bisa menjawab 40% pertanyaan dengan benar
+   - (c) Model prediksi churn pelanggan memiliki AUC 0.82 tapi false positive rate 35%
+
+2. **Root Cause Analysis:** Untuk problem statement yang Anda buat di latihan 1, lakukan analisis 5 Whys. Dokumentasikan setiap level "mengapa" dan identifikasi apakah akar masalah Anda sudah benar-benar root cause atau masih symptom.
+
+---
+
+## Daftar Pustaka
+
+- Creswell, J. W., & Creswell, J. D. (2018). *Research Design: Qualitative, Quantitative, and Mixed Methods Approaches* (5th ed.). SAGE Publications.
+- Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design Science in Information Systems Research. *MIS Quarterly*, 28(1), 75–105.
+- Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007). A Design Science Research Methodology for Information Systems Research. *Journal of Management Information Systems*, 24(3), 45–77.
+- Shadish, W. R., Cook, T. D., & Campbell, D. T. (2002). *Experimental and Quasi-Experimental Designs for Generalized Causal Inference*. Houghton Mifflin.
+- Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., & Wesslén, A. (2012). *Experimentation in Software Engineering*. Springer.
+
+---
+
+<!-- METADATA INTERNAL (tidak dicetak) -->
+
+### AI-Ready Prompt
+
+```
+Anda adalah asisten riset untuk peneliti di bidang Teknologi Informasi. Bantu mereka merumuskan masalah riset dari fenomena TI yang mereka amati. Gunakan Problem Formation Model (Reality → Symptom → Diagnosed Problem → Researchable Problem → Measurable Variable) dan validasi hasilnya terhadap Problem Quality Model (Clarity, Measurability, Relevance, Testability, Impact). Pastikan:
+1. Masalah terikat pada system context (Input/Process/Output/Outcome/Constraints/Stakeholders)
+2. Ada gap literatur yang teridentifikasi
+3. Variable dan metrik yang terukur
+4. Masalah bisa gagal (falsifiable)
+Gaya bahasa: semi-formal, penjelasan mendalam, contoh dari domain TI/SE.
+```
+
+### Referensi Bab Ini
+
+- Creswell, J. W., & Creswell, J. D. (2018). *Research Design: Qualitative, Quantitative, and Mixed Methods Approaches* (5th ed.). SAGE Publications.
+- Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design Science in Information Systems Research. *MIS Quarterly*, 28(1), 75–105.
+- Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007). A Design Science Research Methodology for Information Systems Research. *Journal of Management Information Systems*, 24(3), 45–77.
+- Shadish, W. R., Cook, T. D., & Campbell, D. T. (2002). *Experimental and Quasi-Experimental Designs for Generalized Causal Inference*. Houghton Mifflin.
+- Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., & Wesslén, A. (2012). *Experimentation in Software Engineering*. Springer.
+
+### Checklist Penyelesaian
+
+- [x] Narasi pembuka kuat (opening bridge dari Bab 1)
+- [x] Signature model (Problem Formation Model + Problem Quality Model)
+- [x] Definisi kunci lengkap (4 definisi)
+- [x] Konsep inti mendalam (5 sub-konsep)
+- [x] Research vs Engineering (tabel + insight)
+- [x] Research Reality (3 fenomena)
+- [x] Cognitive Traps (4 traps)
+- [x] Case Study Basic — Rekomendasi Film (bad vs good)
+- [x] Case Study Advanced — Fraud Detection (bad vs good)
+- [x] Template praktis (Problem Statement Builder)
+- [x] Mindmap ringkasan
+- [x] Rangkuman + closing bridge ke Bab 3
+- [x] Latihan & refleksi (4 refleksi + 2 praktis)
+- [x] Sitasi 5 referensi (Creswell, Wohlin, Shadish, Peffers, Hevner)
+- [x] Final Statement
+- [x] AI-Ready Prompt
+
+<!-- STATUS: 🟢 Draft Complete -->
--- a/book/bagian-1-foundation/bab-03-literature-gap.md
+++ b/book/bagian-1-foundation/bab-03-literature-gap.md
@ -0,0 +1,551 @@
+# Bab 3 — Literature Review, Research Gap & Baseline
+
+> **Sub-CPMK:** Sub-CPMK 1.3 — Mengidentifikasi gap dari literatur dan memposisikan riset
+> **CPMK:** CPMK01 — Problem Framing
+> **CPL Utama:** CPL03 (Penalaran logis, kritis, sistematis)
+> **CPL Pendukung:** CPL02 (Menyusun karya ilmiah)
+> **Fase:** Thinking (M1–M4)
+
+---
+
+## Ringkasan Bab
+
+Bab ini mengajarkan cara membaca literatur bukan untuk merangkum, melainkan untuk **memposisikan** riset Anda. Kita akan belajar membedakan empat jenis gap (performance, method, data, context), merancang strategi pencarian literatur yang sistematis, memilih baseline yang tepat, dan — yang paling penting — mengubah gap menjadi posisi kontribusi yang jelas. Di akhir bab ini, Anda akan mampu menyusun tabel literatur yang bukan sekadar daftar bacaan, melainkan **peta medan perang** yang menunjukkan di mana posisi Anda berdiri dan mengapa posisi itu layak dipertahankan.
+
+---
+
+## 3.1 Pembuka
+
+Bab 2 menunjukkan bahwa masalah riset yang baik harus spesifik, terukur, dan testable. Masalah sudah ada. Pertanyaannya sekarang: apakah masalah ini benar-benar layak diteliti?
+
+Untuk menjawabnya, perlu masuk ke ruang diskusi ilmiah yang lebih luas: literatur. Literatur bukan tumpukan paper yang harus dibaca dan dirangkum. Literatur adalah percakapan — percakapan global antar peneliti yang sudah berlangsung bertahun-tahun tentang topik tertentu. Tugas peneliti bukan mendengarkan percakapan itu secara pasif, melainkan menemukan titik di mana percakapan itu belum selesai, lalu mengisi kekosongan itu.
+
+Titik itulah yang disebut **research gap**: celah dalam pengetahuan yang belum dijawab secara memadai oleh studi-studi sebelumnya. Tanpa gap yang jelas, riset tidak memiliki justifikasi ilmiah — meski masalahnya menarik dan metodenya canggih.
+
+Namun menemukan gap saja tidak cukup. Anda juga harus memposisikan riset Anda: apa yang Anda lakukan berbeda dari studi sebelumnya? Mengapa pendekatan Anda menjanjikan? Dan apa baseline yang akan Anda gunakan sebagai pembanding? Webster dan Watson (2002) menekankan bahwa literature review yang baik bukan kronologi, melainkan **argumentasi terstruktur** tentang posisi Anda dalam lanskap ilmiah.
+
+Pertanyaan utama bab ini: bagaimana menemukan celah dalam pengetahuan yang ada dan memposisikan riset sebagai kontribusi yang bermakna?
+
+---
+
+## 3.2 Research Positioning Model
+
+Bab ini memiliki satu signature model — **Research Positioning Model** — yang menggambarkan proses transformasi dari studi-studi yang ada menjadi posisi riset yang jelas.
+
+**Gambar 3.1** — Research Positioning Model: Dari Studi Terdahulu ke Kontribusi
+
+```mermaid
+graph LR
+    A["📚 <b>Existing<br/>Studies</b><br/><i>Literatur relevan</i>"]
+    B["⚖️ <b>Method<br/>Comparison</b><br/><i>Analisis & sintesis</i>"]
+    C["🔍 <b>Limitation<br/>Identification</b><br/><i>Kelemahan studi</i>"]
+    D["🕳️ <b>Research<br/>Gap</b><br/><i>Celah pengetahuan</i>"]
+    E["📍 <b>Research<br/>Position</b><br/><i>Posisi Anda</i>"]
+    F["🎯 <b>Contribution</b><br/><i>Nilai tambah</i>"]
+
+    A -->|"Systematic<br/>search"| B
+    B -->|"Critical<br/>analysis"| C
+    C -->|"Gap<br/>formulation"| D
+    D -->|"Positioning<br/>statement"| E
+    E -->|"Justification"| F
+
+    style A fill:#DBEAFE,stroke:#2563EB,color:#1E3A5F
+    style B fill:#BFDBFE,stroke:#2563EB,color:#1E3A5F
+    style C fill:#93C5FD,stroke:#2563EB,color:#1E3A5F
+    style D fill:#60A5FA,stroke:#2563EB,color:#FFFFFF
+    style E fill:#3B82F6,stroke:#2563EB,color:#FFFFFF
+    style F fill:#2563EB,stroke:#1D4ED8,color:#FFFFFF
+```
+
+Kontribusi ilmiah tidak bisa diklaim begitu saja — ia dibangun melalui proses yang rigorous:
+
+1. **Existing Studies** — Kumpulan paper, jurnal, dan konferensi yang relevan dengan topik riset Anda. Tahap ini memerlukan strategi pencarian yang sistematis (database, keyword, boolean query).
+2. **Method Comparison** — Analisis kritis terhadap apa yang sudah dilakukan peneliti sebelumnya: metode apa yang digunakan, dataset apa, metrik apa, konteks apa. Bukan ringkasan — melainkan **sintesis perbandingan**.
+3. **Limitation Identification** — Identifikasi kelemahan, keterbatasan, atau asumsi yang belum diuji dari studi-studi terdahulu. Setiap studi pasti memiliki limitasi — tugas Anda menemukannya.
+4. **Research Gap** — Celah yang teridentifikasi dari kumpulan limitasi. Gap bukan satu limitasi tunggal, melainkan **pola** keterbatasan yang belum dijawab secara kolektif oleh studi-studi yang ada.
+5. **Research Position** — Pernyataan eksplisit tentang di mana Anda berdiri: apa yang membedakan riset Anda dari studi sebelumnya.
+6. **Contribution** — Nilai tambah yang dijanjikan: apa yang akan diketahui setelah riset Anda selesai yang sebelumnya belum diketahui?
+
+Literature review bukan kegiatan pasif. Jika setelah membaca 30 paper seseorang masih belum bisa mengatakan "inilah yang belum diselesaikan," ia belum melakukan literature review — ia hanya membaca.
+
+---
+
+## 3.3 Definisi Kunci
+
+**Literature Review**
+: Proses sistematis untuk mengidentifikasi, mengevaluasi, dan mensintesis studi-studi yang relevan dengan topik riset, dengan tujuan membangun argumentasi tentang posisi dan kontribusi riset yang akan dilakukan (Webster & Watson, 2002). Literature review bukan daftar bacaan — ia adalah peta intelektual.
+
+**Research Gap**
+: Celah dalam pengetahuan yang ada di mana pertanyaan penting belum terjawab secara memadai, atau di mana bukti yang ada masih tidak konsisten, tidak lengkap, atau belum diuji pada konteks tertentu. Gap adalah justifikasi utama mengapa riset perlu dilakukan.
+
+**Baseline**
+: Metode, model, atau pendekatan yang sudah ada dan digunakan sebagai titik pembanding (*benchmark*) untuk mengevaluasi kontribusi riset. Baseline harus relevan, representatif, dan idealnya merupakan state-of-the-art dalam domain yang sama (Wohlin et al., 2012).
+
+**Research Position**
+: Pernyataan eksplisit yang menjelaskan bagaimana riset berbeda dari dan membangun di atas studi-studi sebelumnya. Research position menjawab pertanyaan: "Di antara semua studi yang sudah ada, di mana posisi riset ini dan mengapa?"
+
+---
+
+## 3.4 Konsep Inti
+
+### 3.4.1 Literature Review = Positioning, Bukan Ringkasan
+
+Kesalahan paling umum dalam literature review adalah memperlakukan setiap paper sebagai item yang harus dirangkum. Hasilnya: daftar panjang paragraf yang dimulai dengan "Pada tahun 20XX, Penulis A melakukan penelitian tentang..." tanpa analisis dan tanpa sintesis.
+
+Webster dan Watson (2002) dengan tegas menyatakan bahwa literature review yang baik bersifat **concept-centric**, bukan **author-centric**. Artinya:
+
+| Author-Centric (❌) | Concept-Centric (✅) |
+|---------------------|----------------------|
+| "Penulis A (2020) menggunakan metode X..." | "Untuk masalah deteksi anomali, tiga pendekatan utama telah digunakan: X, Y, Z..." |
+| "Penulis B (2021) menemukan bahwa..." | "Perbandingan metode X dan Y menunjukkan trade-off antara..." |
+| Fokus pada **siapa** | Fokus pada **apa yang diketahui dan belum diketahui** |
+
+Dalam pendekatan concept-centric, literatur diorganisasi berdasarkan **tema, metode, atau variabel** — bukan berdasarkan kronologi atau penulis. Ini memungkinkan Anda untuk melihat pola, menemukan kontradiksi, dan mengidentifikasi gap secara lebih natural.
+
+Sebagai perbandingan untuk memperjelas perbedaan kedua pendekatan:
+
+### 3.4.2 Empat Jenis Research Gap
+
+Tidak semua gap diciptakan sama. Kitchenham (2004) dan pengalaman empiris dalam riset TI menunjukkan bahwa gap bisa dikategorikan menjadi empat jenis:
+
+**Gambar 3.2** — Empat Jenis Research Gap
+
+```mermaid
+block-beta
+    columns 1
+    block:header:1
+        columns 1
+        H["<b>EMPAT JENIS RESEARCH GAP</b>"]
+    end
+    block:gaps:1
+        columns 2
+        G1["🏎️ <b>Performance Gap</b>"] G1D["Metode yang ada belum mencapai<br/>performa yang memadai pada<br/>metrik tertentu"]
+        G2["🔧 <b>Method Gap</b>"] G2D["Pendekatan/algoritma tertentu<br/>belum pernah diterapkan<br/>pada masalah ini"]
+        G3["📊 <b>Data Gap</b>"] G3D["Studi yang ada menggunakan<br/>dataset terbatas atau tidak<br/>representatif"]
+        G4["🌍 <b>Context Gap</b>"] G4D["Temuan belum diuji pada<br/>konteks, domain, atau<br/>populasi yang berbeda"]
+    end
+
+    style H fill:#2563EB,color:#FFFFFF,stroke:#1D4ED8
+    style G1 fill:#3B82F6,color:#FFFFFF,stroke:#2563EB
+    style G2 fill:#3B82F6,color:#FFFFFF,stroke:#2563EB
+    style G3 fill:#3B82F6,color:#FFFFFF,stroke:#2563EB
+    style G4 fill:#3B82F6,color:#FFFFFF,stroke:#2563EB
+    style G1D fill:#EFF6FF,color:#1E3A5F,stroke:#93C5FD
+    style G2D fill:#EFF6FF,color:#1E3A5F,stroke:#93C5FD
+    style G3D fill:#EFF6FF,color:#1E3A5F,stroke:#93C5FD
+    style G4D fill:#EFF6FF,color:#1E3A5F,stroke:#93C5FD
+```
+
+Masing-masing jenis gap memiliki karakteristik tersendiri:
+
+**1. Performance Gap** — Metode yang ada belum cukup baik. Contoh: "Deteksi malware berbasis signature hanya mencapai detection rate 78% pada zero-day malware, sedangkan threshold operasional membutuhkan minimal 90%." Gap ini paling mudah diidentifikasi karena angkanya jelas — tetapi juga paling umum, sehingga kontribusi Anda harus cukup signifikan.
+
+**2. Method Gap** — Sebuah pendekatan belum pernah diterapkan pada masalah tertentu. Contoh: "Transformer-based NLP telah terbukti efektif untuk sentiment analysis dalam bahasa Inggris, namun belum ada studi yang menerapkan dan mengevaluasi pendekatan serupa untuk bahasa Indonesia dengan karakteristik morfologi aglutinasi." Method gap sering muncul dari transfer pengetahuan lintas domain.
+
+**3. Data Gap** — Studi yang ada menggunakan dataset yang terbatas, tidak realistis, atau tidak representatif. Contoh: "Seluruh studi tentang prediksi bug menggunakan dataset open-source (Mozilla, Eclipse), namun belum ada yang mengevaluasi pada codebase proprietary dengan karakteristik development process yang berbeda." Data gap menunjukkan bahwa klaim generalisasi dari studi sebelumnya belum teruji.
+
+**4. Context Gap** — Temuan dari satu konteks belum diverifikasi pada konteks lain. Contoh: "Studi tentang efektivitas code review dilakukan pada tim software besar (>50 developer), namun belum ada bukti apakah temuan yang sama berlaku pada tim startup (3–5 developer)." Context gap adalah ancaman langsung terhadap external validity.
+
+Gap terkuat biasanya adalah kombinasi dua jenis. Misalnya: "Method gap + Context gap" — pendekatan X belum diterapkan (method) pada domain Y (context). Kombinasi semacam ini menghasilkan posisi yang lebih unik dan defensible.
+
+### 3.4.3 Strategi Pencarian Literatur: Systematic, Bukan Acak
+
+Menemukan literatur yang relevan bukan soal mengetik keyword di Google Scholar dan berharap yang terbaik. Kitchenham (2004) mendefinisikan prinsip pencarian literatur yang sistematis:
+
+**Database Primer:**
+- **IEEE Xplore** — Fokus engineering dan computing
+- **ACM Digital Library** — Fokus computer science
+- **Scopus** — Multi-disiplin, terindeks ketat
+- **Google Scholar** — Cakupan luas, tapi perlu filter kualitas
+
+**Boolean Query Design:**
+
+Query pencarian harus dirancang secara eksplisit, bukan ad hoc. Contoh:
+
+```
+("anomaly detection" OR "outlier detection") 
+AND ("IoT" OR "Internet of Things") 
+AND ("deep learning" OR "neural network")
+AND (2019..2024)
+```
+
+Setiap keputusan pencarian — database mana, keyword apa, rentang tahun berapa — harus **didokumentasikan** agar reproducible. Jika Anda tidak bisa menjelaskan bagaimana Anda menemukan 30 paper yang Anda cite, Anda tidak bisa mengklaim bahwa literature review Anda sistematis.
+
+**Strategi Snowballing:**
+
+Selain pencarian database, gunakan dua teknik tambahan:
+- **Backward snowballing** — Telusuri referensi dari paper yang sudah ditemukan. Jika paper A mengutip paper B yang sangat relevan, baca paper B.
+- **Forward snowballing** — Cari paper yang mengutip paper kunci. Jika paper C (tahun 2019) sangat foundational, cari siapa yang mengutip paper C setelah 2019. Ini menunjukkan perkembangan terbaru.
+
+### 3.4.4 Baseline: Relevan, Representatif, State-of-the-Art
+
+Baseline adalah titik pembanding yang akan digunakan untuk mengevaluasi kontribusi Anda. Tanpa baseline, klaim "metode saya efektif" tidak memiliki makna — efektif **dibandingkan apa?**
+
+Tiga kriteria baseline yang baik:
+
+**1. Relevan** — Baseline harus menyelesaikan masalah yang sama atau sangat mirip dengan masalah riset Anda. Membandingkan model deteksi fraud Anda dengan model klasifikasi gambar bukan perbandingan yang valid.
+
+**2. Representatif** — Baseline harus merepresentasikan pendekatan yang umum digunakan (*common practice*) atau pendekatan terbaik yang tersedia (*state-of-the-art*). Membandingkan deep learning model Anda dengan Naive Bayes pada tahun 2025 untuk task yang kompleks bukan perbandingan yang fair.
+
+**3. State-of-the-Art (SOTA)** — Idealnya, setidaknya satu baseline harus merupakan pendekatan terbaru dan terbaik yang tersedia. Ini menunjukkan bahwa kontribusi Anda benar-benar melampaui apa yang sudah dicapai — bukan hanya melampaui metode lama.
+
+**Kesalahan umum dalam pemilihan baseline:**
+
+| Kesalahan | Masalah | Dampak |
+|-----------|---------|--------|
+| Baseline terlalu lemah | "Straw man comparison" | Kemenangan tidak bermakna |
+| Baseline tidak relevan | Comparing apples to oranges | Klaim kontribusi tidak valid |
+| Tidak ada baseline sama sekali | Tidak ada pembanding | Tidak tahu apakah metode Anda benar-benar lebih baik |
+| Baseline kadaluarsa | SOTA sudah bergerak | Kontribusi sudah irrelevant saat dipublikasi |
+
+Wohlin et al. (2012) menekankan bahwa pemilihan baseline bukan keputusan teknis semata — ia adalah keputusan **metodologis** yang mempengaruhi seluruh validitas eksperimen.
+
+### 3.4.5 Gap → RQ → Hypothesis → Experiment: Jembatan ke Tahap Berikutnya
+
+Gap yang teridentifikasi bukan tujuan akhir. Gap harus ditransformasi menjadi **research question** yang actionable, lalu menjadi **hipotesis** yang testable, dan akhirnya menjadi **eksperimen** yang executable. Ini adalah bridge menuju Bab 4 dan seterusnya.
+
+Perhatikan rantai transformasi:
+
+| Tahap | Contoh |
+|-------|--------|
+| **Gap** | "Belum ada studi yang membandingkan BERT vs GPT-2 untuk klasifikasi intent pada chatbot bahasa Indonesia" |
+| **RQ** | "Apakah BERT menghasilkan F1-score yang lebih tinggi dibandingkan GPT-2 dalam klasifikasi intent pada dataset chatbot bahasa Indonesia?" |
+| **Hypothesis** | "H₁: BERT menghasilkan F1-score signifikan lebih tinggi dari GPT-2 pada dataset chatbot bahasa Indonesia (α = 0.05)" |
+| **Experiment** | Controlled experiment: 2 model × 1 dataset × 5-fold cross-validation × Wilcoxon signed-rank test |
+
+Setiap tahap mempersempit scope: dari pertanyaan umum (gap) menjadi rencana aksi yang spesifik (experiment). Jika gap Anda tidak bisa ditransformasi ke RQ yang jelas — mungkin gap tersebut belum cukup spesifik.
+
+---
+
+## 3.5 Research vs Engineering
+
+**Tabel 3.1** — Perbandingan Perspektif Research vs Engineering dalam Literature & Gap
+
+| Aspek | Engineering | Research |
+|-------|------------|----------|
+| **Tujuan baca literatur** | Mencari solusi yang sudah ada | Memahami apa yang belum terjawab |
+| **Cara membaca paper** | Tutorial, how-to, implementasi | Metode, limitasi, gap |
+| **Jumlah paper** | Secukupnya untuk menyelesaikan masalah | Komprehensif dan sistematis |
+| **Baseline** | Framework/library terpopuler | State-of-the-art yang rigorous |
+| **Dokumentasi pencarian** | Tidak diperlukan | Wajib (reproducible) |
+| **Tujuan akhir** | Working solution | Posisi kontribusi yang justified |
+
+Seorang engineer membaca Stack Overflow untuk menemukan jawaban. Seorang peneliti membaca paper untuk menemukan pertanyaan yang belum dijawab. Keduanya membaca — tapi dengan tujuan yang berlawanan.
+
+---
+
+## 3.6 Research Reality
+
+### Fenomena 1 — "Literature Review sebagai Formalitas"
+
+Di banyak laporan riset, Bab 2 (Tinjauan Pustaka) ditulis sebagai formalitas — daftar konsep yang di-*copy-paste* dari textbook tanpa analisis kritis. "Machine learning adalah cabang dari artificial intelligence..." — informasi ini benar, tapi tidak memiliki nilai sebagai literature review. Literature review bukan tempat mendefinisikan konsep dasar. Literature review adalah tempat menunjukkan bahwa Anda **memahami lanskap riset** dan tahu di mana kontribusi Anda.
+
+Creswell (2018) menegaskan bahwa fungsi literature review adalah membangun **kerangka argumentasi**: mengapa masalah ini penting, apa yang sudah dicoba, apa yang belum berhasil, dan mengapa pendekatan Anda menjanjikan.
+
+### Fenomena 2 — "'Belum Ada Penelitian yang...' Tanpa Bukti Pencarian"
+
+Kalimat ini sering muncul di proposal: "Belum ada penelitian yang membahas..." Namun, klaim "belum ada" hanya valid jika didukung oleh **bukti pencarian yang sistematis**. Sudahkah IEEE Xplore, ACM DL, dan Scopus ditelusuri? Dengan keyword apa? Rentang tahun berapa? Berapa total paper yang di-*screen*?
+
+Tanpa bukti pencarian, "belum ada penelitian" bisa berarti tiga hal: (1) benar-benar belum ada, (2) ada tapi tidak ditemukan, atau (3) ada tapi dalam bahasa/database yang tidak ditelusuri. Pembimbing dan reviewer yang berpengalaman akan langsung mempertanyakan klaim ini.
+
+### Fenomena 3 — "Baseline yang Dipilih untuk Dimenangkan"
+
+Beberapa peneliti secara sadar memilih baseline yang lemah agar metode mereka terlihat lebih baik. Membandingkan deep learning model 2024 dengan decision tree sederhana tanpa justifikasi, lalu mengklaim "metode kami 25% lebih baik." Ini adalah bentuk **intellectual dishonesty** yang merusak kredibilitas seluruh riset. Baseline harus dipilih secara fair — jika state-of-the-art menggunakan pendekatan Y, Anda harus membandingkan dengan Y, bukan dengan Z yang sudah pasti lebih lemah.
+
+Kekuatan kontribusi berbanding lurus dengan kekuatan baseline yang dikalahkan. Mengalahkan baseline lemah = kontribusi lemah. Mengalahkan state-of-the-art (atau menunjukkan performa setara dengan biaya lebih rendah) = kontribusi kuat.
+
+---
+
+## 3.7 Cognitive Traps
+
+**Trap 1: "Semakin Banyak Referensi, Semakin Bagus"**
+
+Kuantitas referensi tidak menentukan kualitas literature review. 50 paper yang diringkas tanpa analisis bernilai lebih rendah dari 15 paper yang disintesis secara kritis. Yang penting bukan berapa banyak yang dibaca, melainkan seberapa dalam pola, kontradiksi, dan gap dipahami dari apa yang dibaca. Webster dan Watson (2002) menyarankan mengorganisasi literatur berdasarkan konsep, bukan menumpuk referensi.
+
+**Trap 2: "Belum Ada = Gap"**
+
+"Belum ada penelitian tentang deteksi kucing menggunakan quantum computing" — apakah ini gap? Secara teknis memang belum ada. Tapi gap yang valid harus punya justifikasi: mengapa celah ini penting untuk diisi? Apakah ada alasan ilmiah atau praktis yang masuk akal? Gap tanpa justifikasi bukan gap — ia hanya kekosongan yang tidak perlu diisi. Kitchenham (2004) menekankan bahwa gap harus terhubung dengan masalah nyata dan research question yang bermakna.
+
+**Trap 3: "Tidak Perlu Baseline"**
+
+"Saya membuat sistem baru, jadi tidak ada yang perlu dibandingkan." Keliru. Setiap riset memerlukan pembanding — jika bukan metode yang persis sama, setidaknya pendekatan yang menyelesaikan masalah serupa. Bahkan untuk sesuatu yang benar-benar novel, perbandingan tetap bisa dilakukan dengan: (a) solusi manual, (b) random baseline, (c) simple heuristic, atau (d) closest existing approach. Tanpa baseline, klaim "metode saya efektif" tidak bisa divalidasi (Wohlin et al., 2012).
+
+---
+
+## 3.8 Studi Kasus
+
+### Kasus 1 (Basic): "Image Classification — Banyak Paper, Gap Tidak Jelas"
+
+**Konteks:**
+
+Seorang peneliti tertarik meneliti klasifikasi gambar untuk identifikasi tanaman obat menggunakan convolutional neural network (CNN). Ia menemukan 40+ paper tentang klasifikasi gambar tanaman. Semua hasil menunjukkan akurasi di atas 90%. Pertanyaannya: jika semua metode sudah bagus, apa yang perlu diteliti?
+
+**❌ Pendekatan Salah:**
+
+Peneliti menulis literature review dengan merangkum setiap paper satu per satu: "Penulis A (2019) menggunakan ResNet dan mendapat akurasi 92%... Penulis B (2020) menggunakan VGG-16 dan mendapat akurasi 94%..." Di akhir review, ditulis: "Belum ada penelitian yang menggunakan MobileNet untuk klasifikasi tanaman obat." Ini diklaim sebagai gap.
+
+Mengapa salah:
+- Literature review bersifat author-centric, bukan concept-centric
+- "Belum ada yang menggunakan MobileNet" bukan gap yang bermakna — mengapa MobileNet penting?
+- Tidak ada analisis limitasi dari studi sebelumnya
+- Gap tidak terhubung dengan masalah nyata
+
+**✅ Pendekatan Benar:**
+
+Langkah 1 — Organisasi literatur berdasarkan **konsep**:
+
+| Aspek | Findings dari Literatur |
+|-------|------------------------|
+| **Arsitektur** | ResNet, VGG, InceptionV3 → semua akurasi >90% pada lab dataset |
+| **Dataset** | Mayoritas menggunakan dataset terkontrol (in-lab, background seragam) |
+| **Kondisi real-world** | Hanya 2 dari 40 studi menguji pada foto field (pencahayaan bervariasi, background kompleks) |
+| **Deployment** | Tidak ada studi yang mengevaluasi performa pada perangkat mobile (latency, model size) |
+
+Langkah 2 — Identifikasi gap:
+
+"Studi yang ada menunjukkan bahwa akurasi klasifikasi tanaman obat sudah tinggi (>90%) pada dataset lab. Namun, terdapat **data gap**: hanya 5% studi yang menggunakan dataset field dengan variasi pencahayaan dan background natural. Selain itu, terdapat **context gap**: tidak ada studi yang mengevaluasi trade-off antara akurasi dan resource efficiency (model size, inference latency) untuk deployment pada perangkat mobile Android dengan RAM ≤ 3GB."
+
+Langkah 3 — Posisi kontribusi:
+
+"Penelitian ini memposisikan diri pada intersection data gap + context gap: mengevaluasi performa model lightweight (MobileNetV3, EfficientNet-Lite) terhadap dataset field tanaman obat, dengan metrik evaluasi yang mencakup akurasi, inference latency, dan model size pada perangkat Android target."
+
+**Perbandingan:**
+
+| Aspek | Bad | Good |
+|-------|-----|------|
+| Organisasi | Author-centric (kronologis) | Concept-centric (tematik) |
+| Gap | "Belum ada yang pakai X" (method gap lemah) | Data gap + context gap (kombina kuat) |
+| Justifikasi | Tidak ada — hanya karena belum ada | Jelas — real-world deployment needs |
+| Baseline | Tidak disebutkan | ResNet, VGG, InceptionV3 (dari literatur) |
+| Kontribusi | Menerapkan X (application report) | Evaluasi trade-off pada konteks baru (riset) |
+
+Ketika semua studi sudah menunjukkan hasil bagus, gap bukan tentang metode baru yang lebih bagus — gap mungkin tentang konteks yang belum diuji atau dataset yang belum realistis. Literatur yang "sudah lengkap" di satu dimensi sering memiliki celah di dimensi lain.
+
+---
+
+### Kasus 2 (Advanced): "Deteksi Penyakit — Baseline Lemah, Kontribusi Diragukan"
+
+**Konteks:**
+
+Sebuah tim riset membangun model deep learning untuk deteksi penyakit paru-paru dari citra X-ray. Model berbasis DenseNet-121 mencapai AUC-ROC 0.94. Di paper, tim mengklaim "metode kami outperform semua baseline." Namun, saat reviewer dan penguji memeriksa lebih detail...
+
+**❌ Pendekatan Salah:**
+
+Baseline yang digunakan: Logistic Regression, SVM, dan Random Forest — semua metode tradisional yang sudah diketahui kurang optimal untuk image classification. Tidak ada baseline deep learning (misalnya ResNet atau EfficientNet). Di literature review, tim hanya meng-cite 8 paper dan tidak ada yang diterbitkan setelah 2019.
+
+Mengapa salah:
+- **Baseline terlalu lemah** — membandingkan deep learning dengan ML tradisional untuk task visual
+- **Straw man comparison** — hasilnya pasti menang, bukan karena metode bagus tapi karena baseline tidak fair
+- **Literatur tidak up-to-date** — ada kemungkinan SOTA sudah melewati 0.94 AUC-ROC
+- **Pencarian tidak sistematis** — 8 paper tidak cukup untuk klaim "outperform semua"
+
+**✅ Pendekatan Benar:**
+
+Langkah 1 — Systematic search:
+
+```
+Database: PubMed, IEEE Xplore, arXiv
+Query: ("chest X-ray" OR "CXR") AND ("disease detection" OR 
+        "diagnosis") AND ("deep learning" OR "CNN")
+Period: 2019–2024
+Result: 127 papers → 45 after title/abstract screening → 
+        22 included after full-text review
+```
+
+Langkah 2 — Literature mapping table:
+
+| Study | Method | Dataset | AUC-ROC | Limitasi |
+|-------|--------|---------|---------|----------|
+| Author A (2022) | ResNet-50 | ChestX-ray14 | 0.91 | Single dataset, no external validation |
+| Author B (2023) | EfficientNet-B4 | CheXpert | 0.93 | High computational cost, no mobile deployment study |
+| Author C (2023) | Vision Transformer | MIMIC-CXR | 0.95 | Requires large training data, no few-shot evaluation |
+
+Langkah 3 — Gap dan posisi:
+
+"Studi terbaru mencapai AUC-ROC 0.91–0.95 pada deteksi penyakit paru dari CXR. Namun, terdapat **context gap**: seluruh studi menggunakan dataset dari negara maju (USA, UK) dan belum ada evaluasi pada dataset CXR dari rumah sakit Indonesia dengan karakteristik peralatan X-ray yang berbeda. Selain itu, terdapat **performance gap** pada skenario few-shot: belum ada studi yang mengevaluasi performa model ketika data training terbatas (<500 sampel per kelas) — skenario yang realistis untuk rumah sakit daerah."
+
+Langkah 4 — Fair baseline selection:
+
+Baseline: ResNet-50 (2022), EfficientNet-B4 (2023), ViT (2023) — semua merupakan SOTA dari literatur.
+
+**Perbandingan:**
+
+| Aspek | Bad | Good |
+|-------|-----|------|
+| Pencarian | Ad hoc, 8 paper | Systematic, 22 included dari 127 |
+| Baseline | ML tradisional (unfair) | SOTA deep learning (fair) |
+| Gap | Implied, tidak eksplisit | Eksplisit: context gap + performance gap |
+| Claim | "Outperform semua" (overclaim) | "Evaluasi pada konteks baru" (measured claim) |
+| Reproducibility | Search strategy tidak didokumentasikan | Query, database, dan screening process didokumentasikan |
+
+Kekuatan riset bukan ditentukan oleh seberapa tinggi angka performa, melainkan oleh seberapa fair dan rigorous perbandingannya. Mengalahkan baseline fair dengan margin kecil bernilai lebih tinggi daripada mengalahkan baseline lemah dengan margin besar.
+
+---
+
+## 3.9 Template Praktis
+
+> 🔧 **Template: Literature Mapping & Gap Identification**
+>
+> Gunakan template ini untuk menyusun literature review yang terstruktur.
+>
+> ```
+> LITERATURE MAPPING & GAP IDENTIFICATION
+> ═══════════════════════════════════════════════════
+>
+> 1. SEARCH STRATEGY
+>    Database         : [IEEE / ACM / Scopus / PubMed / ...]
+>    Query            : [Boolean query lengkap]
+>    Period           : [Tahun mulai — tahun akhir]
+>    Total found      : [Jumlah paper ditemukan]
+>    After screening  : [Jumlah paper setelah screening]
+>    Included         : [Jumlah paper final]
+>
+> 2. LITERATURE MAPPING TABLE
+>    ┌─────────┬────────┬────────┬────────┬──────────┐
+>    │ Study   │ Method │ Dataset│ Result │ Limitasi │
+>    ├─────────┼────────┼────────┼────────┼──────────┤
+>    │ [...]   │ [...]  │ [...]  │ [...]  │ [...]    │
+>    └─────────┴────────┴────────┴────────┴──────────┘
+>
+> 3. GAP IDENTIFICATION
+>    Gap Type         : [Performance / Method / Data /
+>                        Context / Kombinasi]
+>    Gap Statement    : [Pernyataan gap yang spesifik]
+>    Evidence         : [Bukti dari literatur yang
+>                        mendukung eksistensi gap]
+>    Justification    : [Mengapa gap ini penting
+>                        untuk diisi]
+>
+> 4. RESEARCH POSITION
+>    Posisi           : [Di mana riset Anda berdiri
+>                        relatif terhadap studi lain]
+>    Perbedaan utama  : [Apa yang membedakan dari
+>                        studi terdahulu]
+>    Kontribusi       : [Apa yang akan diketahui
+>                        setelah riset selesai]
+>
+> 5. BASELINE SELECTION
+>    ┌───────────┬───────────┬───────────────────────┐
+>    │ Baseline  │ Justifi-  │ Source                │
+>    │           │ kasi      │                       │
+>    ├───────────┼───────────┼───────────────────────┤
+>    │ [...]     │ [...]     │ [Paper reference]     │
+>    └───────────┴───────────┴───────────────────────┘
+>
+> ═══════════════════════════════════════════════════
+> Checklist:
+> [ ] Gap terhubung dengan masalah di Bab 2?
+> [ ] Baseline relevan, representatif, & SOTA?
+> [ ] Search strategy terdokumentasi?
+> [ ] Gap bisa ditransformasi menjadi RQ?
+> ```
+
+---
+
+## 3.10 Mindmap Bab 3
+
+**Gambar 3.3** — Mindmap: Literature Review, Research Gap & Baseline
+
+```mermaid
+mindmap
+  root((Literature<br/>Gap &<br/>Positioning))
+    Literature Review
+      Concept-centric bukan author-centric
+      Sintesis bukan ringkasan
+      Positioning bukan formalitas
+    Search Strategy
+      Database primer
+        IEEE Xplore
+        ACM DL
+        Scopus
+      Boolean query design
+      Snowballing
+        Backward
+        Forward
+    Empat Jenis Gap
+      Performance Gap
+      Method Gap
+      Data Gap
+      Context Gap
+      Kombinasi gap paling kuat
+    Baseline Selection
+      Relevan
+      Representatif
+      State-of-the-Art
+    Research Positioning Model
+      Existing Studies
+      Method Comparison
+      Limitation Identification
+      Research Gap
+      Research Position
+      Contribution
+    Bridge ke RQ
+      Gap → RQ
+      RQ → Hypothesis
+      Hypothesis → Experiment
+```
+
+---
+
+## 3.11 Rangkuman
+
+1. **Literature review** bukan ringkasan studi — ia adalah proses aktif untuk memposisikan riset Anda dalam konteks pengetahuan yang ada. Pendekatan **concept-centric** lebih bernilai daripada author-centric.
+2. **Research Positioning Model** menggambarkan jalur: Existing Studies → Comparison → Limitation → Gap → Position → Contribution. Setiap tahap harus dilalui secara eksplisit.
+3. Terdapat **empat jenis gap**: performance, method, data, dan context. Gap terkuat adalah kombinasi dua jenis atau lebih.
+4. **Strategi pencarian** harus sistematis dan terdokumentasi: database, boolean query, rentang tahun, proses screening. Klaim "belum ada" harus didukung bukti pencarian.
+5. **Baseline** harus relevan, representatif, dan idealnya state-of-the-art. Baseline lemah menghasilkan kontribusi yang lemah — dan bisa merusak kredibilitas riset.
+6. Gap harus ditransformasikan menjadi **research question** yang actionable — ini adalah jembatan menuju desain eksperimen di bab-bab selanjutnya.
+7. Kekuatan kontribusi Anda berbanding lurus dengan **kekuatan baseline** yang Anda kalahkan dan **kekuatan gap** yang Anda isi.
+
+---
+
+## 3.12 Latihan & Refleksi
+
+### Latihan 1 — Concept-Centric Literature Table
+
+Pilih satu topik riset TI. Cari 10 paper dari IEEE Xplore atau Google Scholar (2020–2025). Buatlah tabel literature mapping (Study, Method, Dataset, Result, Limitasi) — **bukan** ringkasan per paper. Identifikasi pola: metode apa yang dominan? Dataset apa yang paling sering digunakan? Limitasi apa yang berulang?
+
+### Latihan 2 — Gap Identification
+
+Dari tabel literature mapping di Latihan 1, identifikasi minimal **dua jenis gap** (dari empat jenis: performance, method, data, context). Tuliskan gap statement yang spesifik dan berikan justifikasi mengapa gap tersebut penting.
+
+### Latihan 3 — Baseline Selection Challenge
+
+Untuk gap yang Anda identifikasi, pilih **3 baseline** yang fair. Jelaskan untuk setiap baseline: (a) mengapa ia relevan, (b) mengapa ia representatif, dan (c) dari paper mana ia diambil. Evaluasi apakah baseline Anda cukup kuat — atau apakah Anda sedang melakukan "straw man comparison."
+
+### Refleksi
+
+> "Sebelum membaca bab ini, bagaimana cara saya membaca paper? Apakah saya merangkum atau menganalisis? Setelah memahami concept-centric approach, apa yang akan saya ubah dalam cara membaca literatur?"
+
+---
+
+Gap sudah teridentifikasi, posisi jelas, baseline fair — fondasi Bagian 1 (Foundation of Research Thinking) lengkap. Mindset sudah dibangun (Bab 1), masalah sudah dirumuskan (Bab 2), dan posisi dalam lanskap ilmiah sudah ditentukan (Bab 3). Langkah selanjutnya: mentransformasi gap menjadi pertanyaan yang tajam dan hipotesis yang testable. Bab 4 membahas Research Question, Contribution Statement, dan Hypothesis Formulation.
+
+> *"Literature review bukan tentang apa yang sudah diketahui, tetapi tentang apa yang belum diselesaikan dan bagaimana Anda mengisinya."*
+
+---
+
+## Daftar Pustaka
+
+- Creswell, J. W., & Creswell, J. D. (2018). *Research Design: Qualitative, Quantitative, and Mixed Methods Approaches* (5th ed.). SAGE Publications.
+- Kitchenham, B. (2004). *Procedures for Performing Systematic Reviews*. Keele University Technical Report TR/SE-0401.
+- Webster, J., & Watson, R. T. (2002). Analyzing the Past to Prepare for the Future: Writing a Literature Review. *MIS Quarterly*, 26(2), xiii–xxiii.
+- Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., & Wesslén, A. (2012). *Experimentation in Software Engineering*. Springer.
+
+---
+
+<!-- METADATA -->
+| Key | Value |
+|-----|-------|
+| Signature Model | Research Positioning Model |
+| Sub-CPMK | 1.3 |
+| CPMK | CPMK01 |
+| CPL | CPL03, CPL02 |
+| Fase | Thinking |
+| Jumlah Referensi | 4 |
+| Studi Kasus | 2 (Basic: Image classification gap, Advanced: Weak baseline fraud) |
+| Cognitive Traps | 3 |
+| Quality Gate — Relevansi | ✅ Mendorong pembaca menganalisis, bukan merangkum |
+| Quality Gate — Eksperimental | ✅ Mengarahkan ke baseline selection dan gap→RQ pipeline |
+| Quality Gate — Output | ✅ Tabel literatur + gap statement + baseline selection |
+| Status | 🟢 Draft Complete |
--- a/book/bagian-1-foundation/bab-04-rq-hypothesis.md
+++ b/book/bagian-1-foundation/bab-04-rq-hypothesis.md
@ -0,0 +1,451 @@
+# Bab 4 — Research Question, Contribution & Hypothesis
+
+> **Sub-CPMK:** Sub-CPMK 1.4 — Merumuskan Research Question, Contribution Statement, dan Hypothesis
+> **CPMK:** CPMK01 — Problem Framing
+> **CPL Utama:** CPL03 (Penalaran logis, kritis, sistematis)
+> **CPL Pendukung:** CPL06 (Desain & pengembangan)
+> **Fase:** Thinking (M1–M4)
+> **Signature Model:** RQ Formation Model (Problem → Gap → RQ → Hypothesis → Experiment Design)
+
+---
+
+## Ringkasan Bab
+
+Bab ini mengajarkan cara mentransformasi research gap menjadi research question yang tajam, mengartikulasikan kontribusi secara eksplisit, dan merumuskan hipotesis yang testable. Tiga komponen ini — RQ, contribution statement, dan hypothesis — membentuk kerangka yang menentukan seluruh desain eksperimen. Di akhir bab, pembaca mampu menyusun RQ yang spesifik, contribution statement yang jelas, serta pasangan H0/H1 yang siap diuji.
+
+---
+
+## 4.1 Pembuka
+
+Bab 3 berakhir dengan sebuah posisi: gap sudah teridentifikasi, literatur sudah dipetakan, dan baseline sudah dipilih. Secara logis, langkah berikutnya adalah mengubah gap menjadi pertanyaan. Tapi pertanyaan seperti apa?
+
+Bukan sembarang pertanyaan. Research question dalam riset eksperimental TI bukan pertanyaan filosofis, bukan pertanyaan deskriptif, dan — yang sering disalahpahami — bukan judul penelitian yang diakhiri tanda tanya. Research question adalah instrumen presisi yang menentukan apa yang akan diukur, bagaimana mengukurnya, dan apa kriteria keberhasilannya. Creswell dan Creswell (2018) mendefinisikan research question sebagai pertanyaan yang menyempitkan fokus penelitian ke dalam variabel-variabel spesifik yang dapat diselidiki secara empiris.
+
+Sebuah analogi sederhana: research question seperti koordinat GPS. Tanpa koordinat, seseorang bisa berkendara ke "arah utara" dan berakhir di mana saja. Dengan koordinat yang tepat, tujuannya jelas, rute bisa direncanakan, dan keberhasilan bisa diverifikasi — apakah sudah sampai atau belum. RQ yang baik memberikan presisi yang sama terhadap eksperimen.
+
+Selain RQ, dua komponen lain yang sama pentingnya: **contribution statement** dan **hypothesis**. Contribution statement menjelaskan apa yang akan diketahui dunia setelah riset selesai yang sebelumnya belum diketahui. Hypothesis menerjemahkan RQ menjadi prediksi yang bisa diuji secara statistik. Tanpa ketiganya, eksperimen tidak memiliki arah, justifikasi, maupun kriteria evaluasi.
+
+Pertanyaan sentral bab ini: bagaimana merumuskan research question yang bukan sekadar pertanyaan, melainkan cetak biru eksperimen?
+
+---
+
+## 4.2 RQ Formation Model
+
+Bab ini menggunakan satu signature model — **RQ Formation Model** — yang menggambarkan proses transformasi dari masalah dan gap menjadi desain eksperimen melalui perumusan RQ dan hipotesis.
+
+**Gambar 4.1** — RQ Formation Model: Dari Problem ke Experiment Design
+
+```mermaid
+graph LR
+    A["🔍 <b>Research<br/>Problem</b><br/><i>Masalah terukur</i>"]
+    B["🕳️ <b>Research<br/>Gap</b><br/><i>Celah pengetahuan</i>"]
+    C["❓ <b>Research<br/>Question</b><br/><i>Pertanyaan presisi</i>"]
+    D["🎯 <b>Hypothesis</b><br/><i>H0 & H1</i>"]
+    E["⚙️ <b>Experiment<br/>Design</b><br/><i>Variabel & metrik</i>"]
+
+    A -->|"Gap<br/>identification"| B
+    B -->|"Question<br/>formulation"| C
+    C -->|"Prediction<br/>& testability"| D
+    D -->|"Operatio-<br/>nalization"| E
+
+    style A fill:#1e40af,stroke:#1e3a8a,color:#ffffff
+    style B fill:#1d4ed8,stroke:#1e40af,color:#ffffff
+    style C fill:#2563eb,stroke:#1d4ed8,color:#ffffff
+    style D fill:#3b82f6,stroke:#2563eb,color:#ffffff
+    style E fill:#60a5fa,stroke:#3b82f6,color:#ffffff
+```
+
+Model ini bekerja sebagai pipeline linear: setiap tahap membutuhkan output tahap sebelumnya. Problem yang sudah dirumuskan di Bab 2 menjadi input. Gap yang ditemukan di Bab 3 menyempitkan fokus. Research question mengubah gap menjadi pertanyaan yang actionable. Hypothesis menerjemahkan pertanyaan itu menjadi prediksi empiris. Dan experiment design — yang akan dibahas di bab-bab berikutnya — mengoperasionalisasi semuanya menjadi variabel, metrik, dan prosedur pengukuran.
+
+Dua hal penting tentang model ini. Pertama, setiap panah menandakan transformasi, bukan sekadar progresi. Problem tidak otomatis menjadi RQ — ia harus *ditransformasi* melalui proses intelektual yang disengaja. Kedua, model ini bi-directional dalam praktiknya: RQ yang tidak bisa menghasilkan hipotesis testable adalah sinyal bahwa RQ perlu direvisi, dan hipotesis yang tidak bisa dioperasionalisasi menunjukkan bahwa RQ terlalu abstrak. Revisi mundur adalah bagian normal dari proses.
+
+---
+
+## 4.3 Definisi Kunci
+
+**Research Question (RQ)**
+: Pertanyaan spesifik yang menyempitkan fokus penelitian ke dalam variabel-variabel yang dapat diukur dan diuji secara empiris. RQ menentukan apa yang akan diamati, bagaimana mengamatinya, dan apa yang dianggap sebagai jawaban (Creswell & Creswell, 2018). RQ yang baik selalu mengandung setidaknya: subjek/objek penelitian, variabel yang diukur, dan konteks pengukuran.
+
+**Contribution Statement**
+: Pernyataan eksplisit tentang apa yang akan diketahui atau tersedia setelah riset selesai yang sebelumnya belum ada. Contribution bisa berupa: metode baru (novel approach), perbaikan metode existing (improvement), atau perbandingan sistematis yang memberikan kejelasan (comparison). Contribution harus terhubung langsung dengan gap yang diidentifikasi di Bab 3.
+
+**Hypothesis**
+: Prediksi tentang hubungan antar variabel yang dirumuskan sebelum eksperimen dilakukan dan diuji melalui data empiris. Terdiri dari H0 (null hypothesis) — prediksi bahwa tidak ada perbedaan atau pengaruh signifikan, dan H1 (alternative hypothesis) — prediksi bahwa perbedaan atau pengaruh signifikan ada. Hipotesis harus falsifiable: kondisi di mana hipotesis ditolak harus bisa didefinisikan sebelum eksperimen dimulai (Creswell, 2012).
+
+---
+
+## 4.4 Konsep Inti
+
+### 4.4.1 RQ sebagai Instrumen, Bukan Pertanyaan Biasa
+
+Banyak peneliti pemula memperlakukan research question sebagai formalitas — hal yang harus ada di proposal karena template mengharuskannya. Dalam praktiknya, RQ justru merupakan komponen paling kritis dari seluruh penelitian. RQ yang baik secara implisit sudah mengandung informasi tentang metode apa yang akan digunakan, data apa yang perlu dikumpulkan, dan analisis apa yang harus dilakukan.
+
+Perhatikan perbedaan dua "pertanyaan" berikut:
+
+**Pertanyaan A:** "Bagaimana pengaruh deep learning terhadap deteksi malware?"
+
+**Pertanyaan B:** "Apakah model CNN menghasilkan F1-Score deteksi malware lebih tinggi dibandingkan Random Forest pada dataset CIC-MalMem-2022?"
+
+Pertanyaan A terdengar seperti pertanyaan penelitian, tapi sebenarnya ia adalah topik yang disamarkan sebagai pertanyaan. "Pengaruh deep learning" — pengaruh apa? Diukur dengan apa? Dibandingkan dengan apa? Pada konteks apa? Tidak satupun yang bisa dijawab tanpa menyempitkan pertanyaan lebih jauh.
+
+Pertanyaan B, sebaliknya, sudah mengandung cetak biru eksperimen:
+
+- **Subjek**: model CNN
+- **Baseline**: Random Forest
+- **Metrik**: F1-Score
+- **Domain**: deteksi malware
+- **Dataset**: CIC-MalMem-2022
+
+Dari pertanyaan ini, peneliti sudah tahu persis apa yang harus dilakukan: melatih dua model pada dataset yang sama, menghitung F1-Score masing-masing, dan membandingkan hasilnya. RQ yang baik berfungsi sebagai blueprint — ia memberi tahu apa yang harus dibangun dan bagaimana mengukur hasilnya.
+
+### 4.4.2 Tiga Jenis Research Question
+
+Tidak semua research question sama. Dalam konteks riset eksperimental TI, terdapat tiga jenis utama yang masing-masing memiliki implikasi berbeda terhadap desain eksperimen.
+
+**Gambar 4.2** — Tiga Jenis Research Question dan Implikasi Eksperimennya
+
+```mermaid
+block-beta
+  columns 3
+
+  block:comp:1
+    columns 1
+    compTitle["🔄 <b>Comparison RQ</b>"]
+    compDesc["Membandingkan dua<br/>atau lebih metode<br/>pada task yang sama"]
+    compEx["<i>A vs B → mana<br/>yang lebih baik?</i>"]
+    compImpl["<b>Implikasi:</b><br/>≥2 metode, 1 metrik,<br/>uji statistik"]
+  end
+
+  block:impr:1
+    columns 1
+    imprTitle["📈 <b>Improvement RQ</b>"]
+    imprDesc["Menguji apakah<br/>modifikasi meningkatkan<br/>performa metode"]
+    imprEx["<i>A' (modified) vs A<br/>→ apakah lebih baik?</i>"]
+    imprImpl["<b>Implikasi:</b><br/>pre/post, delta<br/>measurement"]
+  end
+
+  block:expl:1
+    columns 1
+    explTitle["🔬 <b>Exploratory RQ</b>"]
+    explDesc["Menelusuri faktor<br/>yang memengaruhi<br/>variabel tertentu"]
+    explEx["<i>Faktor X₁...Xₙ →<br/>pengaruh terhadap Y?</i>"]
+    explImpl["<b>Implikasi:</b><br/>multi-variabel,<br/>korelasi/regresi"]
+  end
+
+  style compTitle fill:#1e40af,color:#ffffff
+  style imprTitle fill:#1d4ed8,color:#ffffff
+  style explTitle fill:#2563eb,color:#ffffff
+  style comp fill:#dbeafe,stroke:#2563eb
+  style impr fill:#dbeafe,stroke:#2563eb
+  style expl fill:#dbeafe,stroke:#2563eb
+```
+
+**Comparison RQ** membandingkan dua atau lebih pendekatan yang sudah ada pada task yang sama. Contoh: "Apakah BERT menghasilkan akurasi sentimen analisis lebih tinggi dibandingkan SVM pada dataset Twitter berbahasa Indonesia?" Jenis ini paling umum dalam riset TI dan memerlukan desain eksperimen dengan minimal dua kondisi, satu metrik utama, dan uji statistik untuk menentukan apakah perbedaannya signifikan.
+
+**Improvement RQ** menguji apakah modifikasi terhadap metode yang sudah ada menghasilkan performa yang lebih baik. Contoh: "Apakah penambahan attention mechanism pada model LSTM meningkatkan akurasi prediksi harga saham dibandingkan LSTM standar?" Jenis ini memerlukan pengukuran sebelum dan sesudah modifikasi dengan metrik yang sama, serta demonstrasi bahwa peningkatan bukan kebetulan.
+
+**Exploratory RQ** menelusuri hubungan antara beberapa variabel tanpa prediksi arah yang spesifik. Contoh: "Faktor apa saja yang memengaruhi waktu respons API pada arsitektur microservices?" Jenis ini lebih terbuka dan membutuhkan desain yang melibatkan pengukuran beberapa variabel serta analisis korelasi atau regresi. Dalam riset TI eksperimental, exploratory RQ biasanya digunakan pada tahap awal investigasi, dan hasilnya sering memunculkan comparison atau improvement RQ yang lebih spesifik.
+
+Setiap jenis memiliki implikasi desain yang berbeda. Comparison membutuhkan baseline eksplisit. Improvement membutuhkan versi sebelum dan sesudah modifikasi. Exploratory membutuhkan identifikasi variabel yang komprehensif. Memilih jenis RQ yang salah untuk masalah yang dihadapi akan menghasilkan desain eksperimen yang tidak cocok.
+
+### 4.4.3 Contribution: Apa yang Dunia Peroleh
+
+Contribution statement menjawab pertanyaan yang sering dilupakan: setelah riset selesai, apa yang berubah? Apa yang sekarang diketahui yang sebelumnya tidak diketahui?
+
+Terdapat tiga jenis contribution utama dalam riset TI:
+
+1. **Improvement** — menghasilkan metode atau pendekatan yang terbukti lebih baik dari yang sudah ada pada metrik tertentu. Contoh: "Metode X-Modified terbukti meningkatkan F1-Score sebesar 12% dibandingkan metode X original pada dataset Y."
+
+2. **Comparison** — memberikan perbandingan sistematis yang sebelumnya belum ada, sehingga komunitas ilmiah memiliki referensi untuk memilih metode yang tepat. Contoh: "Studi ini memberikan perbandingan komprehensif antara tiga metode deteksi anomali pada data IoT, yang sebelumnya belum dilakukan."
+
+3. **Novel Approach** — memperkenalkan pendekatan yang benar-benar baru untuk menyelesaikan masalah yang sudah diketahui. Contoh: "Model hybrid CNN-GAN yang diajukan merupakan pendekatan pertama yang mengombinasikan data augmentation dengan deteksi untuk domain X."
+
+Contribution harus terhubung langsung dengan gap. Jika gap di Bab 3 menyatakan "belum ada perbandingan metode A dan B pada konteks C," maka contribution harus berupa perbandingan tersebut. Kontribusi yang tidak mengisi gap yang sudah diidentifikasi menandakan adanya disconnect dalam alur logis penelitian.
+
+### 4.4.4 Hipotesis: Prediksi yang Harus Dinyatakan Sebelum Eksperimen
+
+Hipotesis sering disamakan dengan "tebakan terdidik." Meski tidak sepenuhnya salah, definisi ini meremehkan fungsi sesungguhnya. Hipotesis adalah komitmen intelektual — pernyataan yang dibuat *sebelum* eksperimen tentang apa yang diharapkan terjadi, beserta kondisi di mana harapan itu dinyatakan salah.
+
+Dalam riset kuantitatif, hipotesis selalu dipasangkan:
+
+- **H0 (Null Hypothesis)**: Tidak ada perbedaan signifikan antara kondisi yang dibandingkan. H0 adalah asumsi default — yang harus dibuktikan salah, bukan dibuktikan benar.
+- **H1 (Alternative Hypothesis)**: Ada perbedaan signifikan. H1 adalah apa yang peneliti harapkan, tetapi hanya bisa diterima jika H0 berhasil ditolak melalui data.
+
+Contoh untuk comparison RQ sebelumnya:
+
+> **H0:** Tidak terdapat perbedaan signifikan pada F1-Score antara model CNN dan Random Forest untuk deteksi malware pada dataset CIC-MalMem-2022.
+>
+> **H1:** Model CNN menghasilkan F1-Score yang signifikan lebih tinggi dibandingkan Random Forest untuk deteksi malware pada dataset CIC-MalMem-2022.
+
+Yang membuat hipotesis bernilai ilmiah bukan kebenaran prediksinya, melainkan *falsifiability*-nya. Hipotesis yang tidak bisa dibuktikan salah — "sistem ini akan bermanfaat" — bukanlah hipotesis ilmiah. Hipotesis harus menyertakan metrik yang terukur, ambang batas statistik, dan kondisi eksperimen yang cukup spesifik sehingga data bisa menolak atau gagal menolaknya.
+
+Creswell (2012) menekankan bahwa hipotesis harus dirumuskan sebelum pengumpulan data. Hipotesis yang dibuat setelah melihat hasil (post-hoc hypothesis) rentan terhadap *HARKing* (Hypothesizing After Results are Known) — praktik yang merusak integritas ilmiah karena menciptakan ilusi konfirmasi.
+
+### 4.4.5 Rantai Operasionalisasi: RQ → Variable → Metric → Data → Analysis
+
+Research question, contribution, dan hypothesis tidak berdiri sendiri. Ketiganya terhubung dalam rantai operasionalisasi yang mengubah konsep abstrak menjadi prosedur terukur:
+
+| Tahap | Contoh |
+|-------|--------|
+| **RQ** | Apakah CNN lebih akurat dari RF untuk deteksi malware? |
+| **Variable** | Independent: jenis model (CNN, RF). Dependent: akurasi deteksi |
+| **Metric** | F1-Score |
+| **Data** | CIC-MalMem-2022 (10.000 sampel, 4 kelas malware) |
+| **Analysis** | Independent sample t-test (α = 0.05) |
+
+Setiap baris tabel di atas adalah turunan langsung dari baris sebelumnya. RQ menentukan variabel. Variabel menentukan metrik (bagaimana variabel diukur). Metrik menentukan data apa yang diperlukan. Dan data menentukan analisis apa yang cocok. Rantai ini akan dibahas lebih detail di Bab 5 (Metric & Measurement), tetapi penting dipahami sejak sekarang bahwa RQ yang tidak bisa menghasilkan rantai ini secara lengkap adalah RQ yang belum mature.
+
+---
+
+## 4.5 Research vs Engineering
+
+**Tabel 4.1** — Pertanyaan dalam Research vs Engineering
+
+| Aspek | Engineering | Research |
+|-------|------------|----------|
+| **Tujuan pertanyaan** | Apa yang harus dibangun? | Apa yang harus dibuktikan? |
+| **Bentuk jawaban** | Sistem yang berfungsi | Bukti empiris yang terukur |
+| **Sukses diukur oleh** | User satisfaction, uptime, SLA | Signifikansi statistik, effect size |
+| **Baseline** | Requirement specification | Metode terbaik saat ini (SOTA) |
+| **Jika gagal** | Debug dan perbaiki | Laporkan, analisis mengapa, revisi hipotesis |
+
+Seorang engineer bertanya "Bagaimana cara membuat sistem rekomendasi yang akurat?" dan jawabannya adalah kode yang berjalan. Seorang peneliti bertanya "Apakah collaborative filtering menghasilkan rekomendasi yang lebih relevan daripada content-based filtering pada dataset MovieLens?" dan jawabannya adalah data perbandingan yang dianalisis secara statistik. Keduanya membangun sistem, tetapi untuk tujuan yang berbeda. Sistem engineer adalah produk. Sistem peneliti adalah alat uji.
+
+---
+
+## 4.6 Research Reality
+
+### Fenomena 1 — Judul Penelitian sebagai "Research Question"
+
+Salah satu pola paling umum di lingkungan akademik: peneliti pemula mengubah judul penelitian menjadi pertanyaan, lalu menyebutnya research question. "Implementasi Metode K-Means untuk Segmentasi Pelanggan" menjadi "Bagaimana implementasi metode K-Means untuk segmentasi pelanggan?" Secara sintaksis, ini memang pertanyaan. Secara ilmiah, ini bukan research question — ini deskripsi pekerjaan. Tidak ada variabel yang dibandingkan, tidak ada metrik yang ditargetkan, tidak ada hipotesis yang bisa ditolak.
+
+### Fenomena 2 — Hipotesis yang Tidak Bisa Salah
+
+Fenomena kedua yang sama seringnya: hipotesis yang dirumuskan sedemikian rupa sehingga tidak mungkin ditolak. "Sistem ini bermanfaat bagi pengguna." Bermanfaat bagaimana? Diukur dengan apa? Dibandingkan dengan kondisi tanpa sistem? Jika pengguna mengatakan "ya, bermanfaat" pada kuesioner, apakah itu cukup? Hipotesis semacam ini tidak testable — ia adalah harapan yang dibungkus bahasa formal. Riset yang berbasis pada hipotesis tak-testable menghasilkan kesimpulan yang tidak bisa dipercaya maupun direplikasi.
+
+### Fenomena 3 — Contribution yang Mengambang
+
+Fenomena ini lebih halus: riset mengklaim kontribusi berupa "metode baru," tetapi tidak pernah mendefinisikan gap secara eksplisit. Jika gap tidak didefinisikan, maka kontribusi tidak punya akar — ia mengambang tanpa justifikasi. Pertanyaan kritis untuk setiap contribution statement: kontribusi ini mengisi gap apa, tepatnya?
+
+---
+
+## 4.7 Cognitive Traps
+
+**Trap 1: "RQ = Judul dalam Bentuk Tanya"**
+
+Mengubah judul menjadi kalimat tanya bukan memformulasi research question. "Penerapan Metode X untuk Y" diubah menjadi "Bagaimana penerapan metode X untuk Y?" tidak menambah nilai ilmiah apapun. RQ yang valid harus mengandung variabel yang terukur, metrik yang jelas, dan secara implisit menunjukkan desain eksperimen yang diperlukan untuk menjawabnya. Jika sebuah pertanyaan bisa dijawab dengan "baik" atau "berhasil" tanpa data kuantitatif, itu bukan RQ — itu topik.
+
+**Trap 2: "RQ Tidak Perlu Metric"**
+
+"Apakah metode A lebih baik dari metode B?" — lebih baik dalam hal apa? Lebih cepat? Lebih akurat? Lebih hemat memori? RQ tanpa metrik adalah pertanyaan yang tidak bisa dijawab secara definitif karena tidak ada kriteria untuk menentukan jawaban. Setiap RQ harus mengandung atau paling tidak mengimplikasikan metric yang spesifik. "Lebih baik" harus didefinisikan: lebih baik menurut F1-Score, menurut latency, menurut throughput — bukan dibiarkan ambigu.
+
+**Trap 3: "RQ Bisa Dijawab Tanpa Eksperimen"**
+
+Jika sebuah pertanyaan bisa dijawab hanya dengan membaca literatur atau argumentasi logis, ia bukan research question untuk riset eksperimental. "Apa saja jenis metode machine learning untuk NLP?" bisa dijawab dengan survey. "Metode mana yang paling efektif untuk sentimen analisis teks pendek?" membutuhkan eksperimen. Dalam konteks mata kuliah Riset TI, setiap RQ harus memerlukan eksperimen untuk menjawabnya — jika tidak, pertanyaan itu lebih cocok untuk mata kuliah lain.
+
+---
+
+## 4.8 Studi Kasus
+
+### Studi Kasus Basic — RQ Terlalu Umum
+
+**Konteks:** Seorang peneliti meneliti penggunaan machine learning untuk mendeteksi email spam.
+
+**Versi Awal (Bermasalah):**
+
+- RQ: "Bagaimana machine learning dapat mendeteksi email spam?"
+- Contribution: "Menerapkan machine learning untuk deteksi email spam."
+- Hypothesis: "Machine learning dapat mendeteksi spam."
+
+**Analisis masalah:**
+
+RQ ini tidak actionable. "Machine learning" terlalu luas — algoritma mana? "Mendeteksi" — diukur dengan apa? Tidak ada baseline, tidak ada dataset spesifik, tidak ada metrik. Contribution-nya bukan kontribusi — spam detection dengan ML sudah ada ribuan studi. Hipotesisnya tidak testable — apa kondisi untuk menolak H0 dalam konteks ini?
+
+**Versi Revisi:**
+
+- RQ: "Apakah model Naive Bayes menghasilkan precision deteksi email spam yang lebih tinggi dibandingkan rule-based filtering pada dataset Enron Email?"
+- Contribution: "Perbandingan kuantitatif antara pendekatan probabilistik (Naive Bayes) dan rule-based filtering untuk spam detection pada dataset email korporat, yang belum tersedia dalam literatur saat ini."
+- H0: "Tidak terdapat perbedaan signifikan pada precision antara Naive Bayes dan rule-based filtering pada dataset Enron Email."
+- H1: "Naive Bayes menghasilkan precision yang signifikan lebih tinggi dibandingkan rule-based filtering pada dataset Enron Email."
+
+**Tabel 4.2** — Perbandingan Versi Awal dan Revisi
+
+| Komponen | Versi Awal | Versi Revisi |
+|----------|-----------|--------------|
+| **Spesifisitas** | "Machine learning" (terlalu luas) | "Naive Bayes" (spesifik) |
+| **Metric** | Tidak ada | Precision |
+| **Baseline** | Tidak ada | Rule-based filtering |
+| **Dataset** | Tidak ada | Enron Email |
+| **Testability** | Tidak testable | Bisa diuji dengan t-test |
+
+### Studi Kasus Advanced — RQ Tanpa Baseline
+
+**Konteks:** Seorang peneliti mengajukan model hybrid CNN-LSTM untuk prediksi trafik jaringan.
+
+**Versi Awal (Bermasalah):**
+
+- RQ: "Apakah model CNN-LSTM efektif untuk memprediksi trafik jaringan?"
+- Contribution: "Mengajukan model CNN-LSTM untuk prediksi trafik."
+- H0: "Model CNN-LSTM tidak efektif untuk prediksi trafik jaringan."
+- H1: "Model CNN-LSTM efektif untuk prediksi trafik jaringan."
+
+**Analisis masalah:**
+
+RQ ini memiliki model spesifik (CNN-LSTM), tetapi tidak memiliki baseline. "Efektif" relatif terhadap apa? Tanpa pembanding, klaim efektivitas tidak bermakna secara ilmiah. Contribution-nya juga bermasalah: mengajukan model bukan kontribusi jika tidak jelas apa yang membuatnya lebih baik dari pendekatan existing. Dan hipotesisnya — "efektif" atau "tidak efektif" — tidak bisa diuji secara statistik karena tidak ada metrik kuantitatif.
+
+**Versi Revisi:**
+
+- RQ: "Apakah model hybrid CNN-LSTM menghasilkan RMSE prediksi trafik jaringan yang lebih rendah dibandingkan LSTM standar dan ARIMA pada dataset Abilene Network 2019–2023?"
+- Contribution: "Evaluasi komparatif model hybrid CNN-LSTM terhadap dua baseline established (LSTM dan ARIMA) menggunakan data trafik jaringan nyata, dengan fokus pada akurasi prediksi jangka pendek (1–24 jam)."
+- H0: "Tidak terdapat perbedaan signifikan pada RMSE antara model CNN-LSTM, LSTM standar, dan ARIMA untuk prediksi trafik jaringan pada dataset Abilene Network."
+- H1: "Model CNN-LSTM menghasilkan RMSE yang signifikan lebih rendah dibandingkan LSTM standar dan ARIMA untuk prediksi trafik jaringan pada dataset Abilene Network."
+
+**Tabel 4.3** — Analisis Revisi
+
+| Perbaikan | Penjelasan |
+|-----------|-----------|
+| **Baseline ditambahkan** | LSTM standar + ARIMA — dua metode established |
+| **Metrik dispesifikasi** | RMSE, bukan "efektivitas" |
+| **Dataset konkret** | Abilene Network 2019–2023 |
+| **Contribution terhubung gap** | Evaluasi komparatif yang sebelumnya belum ada |
+| **H0/H1 testable** | Falsifiable melalui statistical test |
+
+Perbedaan antara kedua versi bukan kosmetik. Versi awal mengarah pada eksperimen yang hasilnya sulit diinterpretasi. Versi revisi menghasilkan eksperimen yang jelas: latih tiga model, hitung RMSE masing-masing, bandingkan secara statistik. Hasilnya bisa positif (CNN-LSTM lebih baik), negatif (tidak lebih baik), atau mixed — dan semua hasil tersebut bermakna ilmiah.
+
+---
+
+## 4.9 Template Praktis
+
+> **Template RQ-Contribution-Hypothesis**
+>
+> ```
+> ═══════════════════════════════════════════════════
+>         RQ-CONTRIBUTION-HYPOTHESIS TEMPLATE
+> ═══════════════════════════════════════════════════
+>
+> 1. RESEARCH QUESTION
+>    Jenis RQ   : [Comparison / Improvement / Exploratory]
+>    Formulasi  : [Tulis RQ lengkap di sini]
+>
+>    Checklist:
+>    [ ] Mengandung variabel spesifik?
+>    [ ] Menyebutkan metrik?
+>    [ ] Memiliki baseline/pembanding?
+>    [ ] Menyebutkan dataset/konteks?
+>    [ ] Memerlukan eksperimen untuk menjawab?
+>
+> 2. CONTRIBUTION STATEMENT
+>    Jenis      : [Improvement / Comparison / Novel Approach]
+>    Statement  : [Apa yang akan diketahui setelah riset
+>                  selesai yang sebelumnya belum diketahui?]
+>    Gap link   : [Gap mana dari Bab 3 yang diisi?]
+>
+> 3. HYPOTHESIS
+>    H0         : [Null hypothesis — tidak ada perbedaan
+>                  signifikan...]
+>    H1         : [Alternative hypothesis — terdapat
+>                  perbedaan signifikan...]
+>    Metric     : [Metrik yang digunakan untuk uji]
+>    Threshold  : [Significance level, e.g., α = 0.05]
+>
+> 4. OPERATIONALIZATION CHAIN
+>    RQ         → [...]
+>    Variable   → Independent: [...], Dependent: [...]
+>    Metric     → [...]
+>    Data       → [...]
+>    Analysis   → [...]
+>
+> ═══════════════════════════════════════════════════
+> Checklist:
+> [ ] RQ terhubung dengan gap di Bab 3?
+> [ ] Contribution mengisi gap yang diidentifikasi?
+> [ ] H0 bisa ditolak (falsifiable)?
+> [ ] H1 spesifik dan terukur?
+> [ ] Rantai operasionalisasi lengkap sampai analysis?
+> ```
+
+---
+
+## 4.10 Mindmap Bab 4
+
+**Gambar 4.3** — Mindmap: Research Question, Contribution & Hypothesis
+
+```mermaid
+mindmap
+  root((RQ, Contribution<br/>& Hypothesis))
+    Research Question
+      Instrumen presisi bukan pertanyaan biasa
+      3 Jenis RQ
+        Comparison
+        Improvement
+        Exploratory
+      Harus mengandung variabel metrik konteks
+    Contribution Statement
+      Improvement
+      Comparison
+      Novel Approach
+      Harus terhubung dengan gap
+    Hypothesis
+      H0 Null Hypothesis
+      H1 Alternative Hypothesis
+      Falsifiable dan testable
+      Dirumuskan SEBELUM eksperimen
+    RQ Formation Model
+      Problem lalu Gap lalu RQ lalu Hypothesis lalu Experiment
+      Transformasi bukan progresi otomatis
+      Revisi mundur adalah bagian normal
+    Operationalization Chain
+      RQ lalu Variable lalu Metric lalu Data lalu Analysis
+    Cognitive Traps
+      RQ sama dengan judul ditambah tanda tanya
+      RQ tanpa metric
+      RQ tanpa eksperimen
+```
+
+---
+
+## 4.11 Rangkuman
+
+1. **Research question** bukan sekadar pertanyaan — ia adalah instrumen yang menentukan variabel, metrik, data, dan analisis yang diperlukan. RQ yang tidak mengandung komponen-komponen ini belum cukup mature untuk memulai eksperimen.
+2. Terdapat **tiga jenis RQ** dalam riset eksperimental TI: comparison (membandingkan metode), improvement (menguji modifikasi), dan exploratory (menelusuri faktor). Masing-masing memiliki implikasi desain eksperimen yang berbeda.
+3. **Contribution statement** mengartikulasikan apa yang dunia peroleh dari riset. Contribution harus terhubung langsung dengan gap — kontribusi tanpa gap adalah klaim tanpa justifikasi.
+4. **Hypothesis** adalah prediksi yang dibuat sebelum eksperimen. H0 (null) menyatakan tidak ada perbedaan signifikan; H1 (alternative) menyatakan ada. Hipotesis harus falsifiable.
+5. **RQ Formation Model** menggambarkan pipeline: Problem → Gap → RQ → Hypothesis → Experiment Design. Model ini bi-directional — RQ yang tidak bisa menghasilkan hipotesis testable harus direvisi.
+6. **Rantai operasionalisasi** (RQ → Variable → Metric → Data → Analysis) adalah alat uji kematangan RQ. Jika rantai ini tidak bisa dilengkapi, RQ perlu disempurnakan.
+
+---
+
+## 4.12 Latihan & Refleksi
+
+### Latihan 1 — Dari Gap ke RQ
+
+Ambil gap statement yang dihasilkan dari latihan Bab 3. Transformasikan menjadi research question yang memenuhi lima kriteria: variabel spesifik, metrik jelas, baseline ada, dataset/konteks disebutkan, dan memerlukan eksperimen. Tentukan jenis RQ-nya (comparison, improvement, atau exploratory).
+
+### Latihan 2 — Contribution Statement
+
+Untuk RQ yang dirumuskan di Latihan 1, tulis contribution statement yang menjelaskan: (a) apa yang akan diketahui setelah riset selesai, (b) jenis contribution (improvement, comparison, novel approach), dan (c) gap spesifik mana yang diisi oleh kontribusi ini.
+
+### Latihan 3 — Hypothesis Pair
+
+Rumuskan pasangan H0 dan H1 untuk RQ di atas. Pastikan: (a) H0 menyatakan tidak ada perbedaan signifikan, (b) H1 menyatakan ada perbedaan signifikan, (c) metrik pengujian disebut eksplisit, dan (d) kondisi di mana H0 ditolak bisa didefinisikan dengan jelas.
+
+### Refleksi
+
+> "Apakah research question yang selama ini saya rumuskan benar-benar bisa dijawab melalui eksperimen? Atau ia hanya topik yang disamarkan sebagai pertanyaan?"
+
+---
+
+Bagian 1 (Foundation of Research Thinking) berakhir di sini. Empat bab telah membangun fondasi lengkap: cara berpikir sebagai peneliti (Bab 1), merumuskan masalah yang terukur (Bab 2), menemukan posisi dalam lanskap ilmiah (Bab 3), dan mentransformasi gap menjadi pertanyaan, kontribusi, dan hipotesis yang siap diuji (Bab 4). Bagian 2 melangkah ke tahap selanjutnya: menerjemahkan RQ dan hipotesis menjadi desain eksperimen yang konkret, dimulai dari metrik dan pengukuran di Bab 5.
+
+> *"Research Question bukan sekadar pertanyaan, tetapi blueprint dari eksperimen yang akan dilakukan."*
+
+---
+
+## Daftar Pustaka
+
+- Creswell, J. W., & Creswell, J. D. (2018). *Research Design: Qualitative, Quantitative, and Mixed Methods Approaches* (5th ed.). SAGE Publications.
+- Creswell, J. W. (2012). *Educational Research: Planning, Conducting, and Evaluating Quantitative and Qualitative Research* (4th ed.). Pearson.
+- Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., & Wesslén, A. (2012). *Experimentation in Software Engineering*. Springer.
+- Shadish, W. R., Cook, T. D., & Campbell, D. T. (2002). *Experimental and Quasi-Experimental Designs for Generalized Causal Inference*. Houghton Mifflin.
+
+<!-- STATUS: 🟢 Draft Complete -->
--- a/book/bagian-2-design/bab-05-metrics-measurement.md
+++ b/book/bagian-2-design/bab-05-metrics-measurement.md
@ -0,0 +1,424 @@
+# Bab 5 — Metric, Measurement & Data
+
+> **Sub-CPMK:** 2.1 — Mendefinisikan metrik yang valid dan representatif
+> **CPMK:** CPMK02 — Measurement & Design
+> **CPL Utama:** CPL06 (Desain & pengembangan)
+> **Fase:** Designing (M5–M7)
+> **Signature Model:** Measurement Alignment Model (Problem → Concept → Variable → Metric → Data → Result)
+
+---
+
+## Ringkasan Bab
+
+Bab ini membahas bagaimana menerjemahkan konsep abstrak menjadi angka yang bisa diukur, dibandingkan, dan diuji. Proses ini — yang dalam literatur disebut *operationalization* — adalah jembatan antara teori dan eksperimen. Tanpa metrik yang valid, research question sebagus apa pun tidak akan menghasilkan jawaban yang bermakna. Kita akan belajar memilih metrik yang tepat, memahami jenis data, menilai kualitas data, dan menghindari jebakan pengukuran yang sering tidak disadari hingga tahap analisis.
+
+---
+
+## 5.1 Pembuka
+
+Bab 4 berakhir dengan sebuah produk: research question yang tajam, contribution statement yang eksplisit, dan pasangan hipotesis H0/H1 yang siap diuji. Secara konseptual, arahnya sudah jelas. Tapi ada satu pertanyaan krusial yang belum terjawab: **apa yang sebenarnya akan diukur?**
+
+Pertanyaan ini terdengar sederhana, padahal justru di sinilah banyak eksperimen mulai goyah. Seorang peneliti menulis hipotesis "sistem yang diusulkan memiliki performa lebih baik dibanding baseline." Performa diukur dari apa? Akurasi? Precision? F1-score? Waktu respons? Dan jika dipilih akurasi — akurasi terhadap apa? Apakah distribusi datanya seimbang? Jika tidak, apakah akurasi masih representatif?
+
+Dalam riset TI dan software engineering, metrik bukan sekadar angka yang dilaporkan di akhir eksperimen. Metrik adalah *kontrak* antara peneliti dan pembaca: ia mendefinisikan apa yang dimaksud "berhasil" dan apa yang dimaksud "gagal." Wohlin et al. (2012) menjelaskan bahwa pemilihan metrik harus dilakukan sebelum eksperimen berjalan — bukan setelah melihat data dan memilih metrik yang kebetulan menghasilkan angka bagus.
+
+Metrik juga bukan entitas yang berdiri sendiri. Setiap metrik harus bisa ditelusuri balik ke variabel, variabel ke konsep, dan konsep ke masalah riset. Jika rantai ini terputus, eksperimen kehilangan *construct validity* — mengukur sesuatu, tapi bukan yang seharusnya diukur. Field (2018) menyebut fenomena ini sebagai salah satu risiko terbesar dalam pengukuran: ketidaksesuaian antara apa yang *ingin* diukur dan apa yang *sebenarnya* diukur.
+
+Bab ini membuka Bagian 2 (Measurement & Design) dengan pertanyaan sentral: **Bagaimana memastikan bahwa apa yang kita ukur benar-benar merepresentasikan apa yang ingin kita ketahui?**
+
+---
+
+## 5.2 Measurement Alignment Model
+
+Inti dari bab ini terangkum dalam satu model: setiap pengukuran yang valid harus bisa ditelusuri dari masalah riset sampai ke hasil akhir tanpa "lompatan logis" di tengah jalan.
+
+**Gambar 5.1** — Measurement Alignment Model: Dari Problem ke Result
+
+```mermaid
+graph LR
+    A["🔍 <b>Problem</b><br/><i>Masalah riset</i>"]
+    B["💭 <b>Concept</b><br/><i>Konsep abstrak</i>"]
+    C["📊 <b>Variable</b><br/><i>Variabel terukur</i>"]
+    D["📏 <b>Metric</b><br/><i>Satuan pengukuran</i>"]
+    E["📦 <b>Data</b><br/><i>Nilai observasi</i>"]
+    F["✅ <b>Result</b><br/><i>Temuan eksperimen</i>"]
+
+    A -->|"Abstraksi"| B
+    B -->|"Operasionalisasi"| C
+    C -->|"Kuantifikasi"| D
+    D -->|"Pengumpulan"| E
+    E -->|"Analisis"| F
+
+    style A fill:#D1FAE5,stroke:#059669,color:#064E3B
+    style B fill:#A7F3D0,stroke:#059669,color:#064E3B
+    style C fill:#6EE7B7,stroke:#059669,color:#064E3B
+    style D fill:#34D399,stroke:#059669,color:#FFFFFF
+    style E fill:#10B981,stroke:#047857,color:#FFFFFF
+    style F fill:#059669,stroke:#047857,color:#FFFFFF
+```
+
+Setiap transisi dalam model ini memiliki fungsi spesifik:
+
+1. **Problem → Concept (Abstraksi).** Masalah riset diekstrak menjadi konsep yang akan diselidiki. Contoh: jika masalahnya "pengguna meninggalkan aplikasi setelah 3 hari," konsepnya mungkin *user retention* atau *user engagement*. Satu masalah bisa mengandung lebih dari satu konsep.
+
+2. **Concept → Variable (Operasionalisasi).** Konsep abstrak diterjemahkan menjadi variabel yang bisa diobservasi. *User engagement* bisa dioperasionalisasikan menjadi "jumlah sesi per minggu," "durasi rata-rata sesi," atau "jumlah fitur yang digunakan per sesi." Langkah ini adalah titik paling kritis — karena di sinilah peneliti membuat keputusan tentang *apa yang mewakili apa*.
+
+3. **Variable → Metric (Kuantifikasi).** Variabel diberi satuan pengukuran yang spesifik. "Jumlah sesi per minggu" diukur sebagai bilangan bulat. "Durasi rata-rata sesi" diukur dalam menit. "Waktu respons" diukur dalam milidetik. Tanpa metrik yang jelas, variabel hanya label tanpa substansi.
+
+4. **Metric → Data (Pengumpulan).** Metrik diaplikasikan pada subjek/objek eksperimen untuk menghasilkan data aktual. Di tahap ini, kualitas data menjadi penentu: apakah datanya lengkap, konsisten, dan representatif?
+
+5. **Data → Result (Analisis).** Data diproses melalui uji statistik untuk menghasilkan temuan yang menjawab research question. Temuan ini baru bermakna jika seluruh rantai sebelumnya valid.
+
+Jika rantai ini putus di mana saja — misalnya metrik tidak merepresentasikan variabel, atau variabel tidak merepresentasikan konsep — maka hasilnya cacat secara fundamental, meskipun angkanya terlihat meyakinkan.
+
+Wohlin et al. (2012) menyebut prinsip ini sebagai *measurement validity*: sejauh mana instrumen pengukuran benar-benar mengukur apa yang dimaksudkan untuk diukur. Bukan soal angkanya besar atau kecil, tapi soal apakah angkanya *relevan*.
+
+---
+
+## 5.3 Definisi Kunci
+
+**Operasionalisasi (*Operationalization*)**
+: Proses mentransformasi konsep abstrak menjadi variabel yang dapat diobservasi dan diukur secara empiris. Operasionalisasi adalah jembatan antara dunia teori dan dunia data (Wohlin et al., 2012).
+
+**Metrik (*Metric*)**
+: Satuan pengukuran kuantitatif yang digunakan untuk mengevaluasi variabel tertentu. Metrik harus spesifik (apa yang diukur), reprodusibel (bisa diulang dengan hasil serupa), dan relevan (terkait langsung dengan research question).
+
+**Construct Validity**
+: Sejauh mana pengukuran benar-benar mengukur konsep yang dimaksudkan untuk diukur. Pelanggaran construct validity terjadi ketika metrik yang dipilih tidak merepresentasikan konsep yang diteliti (Shadish et al., 2002).
+
+**Skala Pengukuran (*Measurement Scale*)**
+: Klasifikasi jenis data berdasarkan sifat matematisnya: nominal (kategori tanpa urutan), ordinal (kategori dengan urutan), interval (jarak bermakna tanpa nol absolut), dan ratio (jarak bermakna dengan nol absolut). Jenis skala menentukan analisis statistik yang valid (Field, 2018).
+
+---
+
+## 5.4 Konsep Inti
+
+### 5.4.1 Dari Konsep ke Metrik: Operasionalisasi sebagai Keputusan Desain
+
+Operasionalisasi bukan proses mekanis — ia adalah keputusan desain yang memiliki konsekuensi besar terhadap seluruh eksperimen. Ketika seorang peneliti memutuskan bahwa "kualitas kode" akan diukur melalui "jumlah code smell yang terdeteksi oleh SonarQube," keputusan itu mengandung asumsi implisit: bahwa code smell yang dideteksi oleh tool tertentu merepresentasikan kualitas kode secara keseluruhan.
+
+Apakah asumsi itu benar? Belum tentu. Code smell yang terdeteksi SonarQube mungkin tidak mencakup masalah arsitektural. Tool yang berbeda mungkin mendeteksi code smell yang berbeda. Dan "kualitas kode" sendiri sebagai konsep bisa mencakup readability, maintainability, performance, atau security — masing-masing membutuhkan metrik yang berbeda.
+
+Inilah mengapa operasionalisasi harus didokumentasikan secara eksplisit dan dijustifikasi. Pembaca harus bisa memahami:
+- Konsep apa yang dioperasionalisasikan?
+- Mengapa variabel ini dipilih untuk merepresentasikan konsep tersebut?
+- Apa keterbatasan representasi ini?
+- Apakah ada variabel alternatif yang dipertimbangkan?
+
+Dokumentasi ini bukan formalitas — ia adalah bagian dari *research transparency*. Tanpa justifikasi operasionalisasi, reviewer tidak bisa menilai apakah temuan eksperimen benar-benar menjawab research question atau hanya menjawab pertanyaan yang berbeda dari yang dimaksud.
+
+### 5.4.2 Empat Jenis Data: Nominal, Ordinal, Interval, Ratio
+
+Tidak semua data diciptakan sama. Jenis data menentukan operasi matematika apa yang valid dilakukan dan uji statistik apa yang bisa digunakan. Field (2018) mengklasifikasikan data ke dalam empat skala:
+
+**Nominal** — Data berupa kategori tanpa urutan. Contoh: jenis browser (Chrome, Firefox, Safari), bahasa pemrograman (Python, Java, Go), genre aplikasi (e-commerce, healthcare, fintech). Operasi yang valid: frekuensi, modus, Chi-square test. Menghitung rata-rata jenis browser tidak bermakna.
+
+**Ordinal** — Data berupa kategori dengan urutan, tapi jarak antar kategori tidak seragam. Contoh: skala Likert (sangat tidak setuju → sangat setuju), tingkat severity bug (low, medium, high, critical). Operasi yang valid: median, percentile, Mann-Whitney U test. Meskipun bisa dikodekan 1-2-3-4-5, perbedaan antara "setuju" dan "sangat setuju" belum tentu sama dengan perbedaan antara "netral" dan "setuju."
+
+**Interval** — Data numerik dengan jarak yang bermakna, tapi tidak memiliki nol absolut. Contoh: temperatur dalam Celsius, skor IQ, tahun kalender. Operasi yang valid: rata-rata, standar deviasi, t-test. Nol derajat Celsius bukan berarti "tidak ada temperatur."
+
+**Ratio** — Data numerik dengan jarak bermakna dan nol absolut. Contoh: waktu respons (ms), throughput (request/detik), jumlah bug, akurasi (%). Operasi yang valid: semua operasi aritmetika, termasuk rasio. Nol milidetik berarti tidak ada waktu respons.
+
+Dalam riset TI, sebagian besar metrik performa berada di skala ratio — waktu eksekusi, akurasi, jumlah error, throughput. Tapi metrik yang melibatkan persepsi pengguna (usability, satisfaction) biasanya berada di skala ordinal. Kesalahan paling umum: memperlakukan data ordinal seolah-olah interval, lalu menghitung rata-rata skala Likert dan menggunakan t-test. Secara teknis, operasi ini tidak valid — meskipun dalam praktek banyak peneliti melakukannya dengan justifikasi tertentu (panjang skala ≥ 5, distribusi mendekati normal). Perbedaan ini penting karena menentukan keabsahan analisis statistik di tahap selanjutnya.
+
+### 5.4.3 Memilih Metrik: Representatif, Sensitif, dan Feasible
+
+Tidak ada metrik yang sempurna. Setiap metrik memiliki kelebihan dan keterbatasan. Yang penting adalah memilih metrik yang paling sesuai dengan research question — bukan metrik yang paling mudah dikumpulkan atau paling sering digunakan di literatur.
+
+Tiga kriteria pemilihan metrik:
+
+**Representatif** — Metrik harus merepresentasikan konsep yang diteliti. Jika research question tentang "efektivitas deteksi malware," maka detection rate lebih representatif daripada waktu eksekusi. Waktu eksekusi mungkin penting, tapi ia mengukur efisiensi — bukan efektivitas.
+
+**Sensitif** — Metrik harus mampu menangkap perbedaan yang bermakna. Jika dua algoritma menghasilkan akurasi 99.1% vs 99.3%, apakah perbedaan itu signifikan? Tergantung dataset dan konteks. Metrik yang "ceiling effect" — sudah mendekati batas maksimal — kehilangan kemampuan untuk membedakan performa. Dalam kasus ini, metrik lain mungkin lebih sensitif (misalnya F1-score pada kelas minoritas).
+
+**Feasible** — Metrik harus bisa dikumpulkan dalam batasan waktu, biaya, dan akses yang tersedia. Mengukur "kepuasan pengguna jangka panjang" mungkin ideal secara konseptual, tapi jika waktu riset hanya 4 bulan, survei longitudinal tidak feasible. Metrik alternatif yang bisa dikumpulkan dalam waktu terbatas harus dipilih, dengan keterbatasan ini dinyatakan secara eksplisit.
+
+Wohlin et al. (2012) merekomendasikan penggunaan **multiple metrics** untuk setiap konsep yang diukur. Satu metrik tunggal jarang cukup untuk merepresentasikan konsep yang kompleks. Sistem rekomendasi, misalnya, sebaiknya tidak hanya diukur dari akurasi — tambahkan diversity, novelty, atau coverage untuk gambaran yang lebih lengkap.
+
+### 5.4.4 Kualitas Data: Empat Dimensi yang Harus Dipenuhi
+
+Data yang sudah dikumpulkan belum tentu layak dianalisis. Sebelum masuk ke tahap statistik, data harus melewati empat pemeriksaan kualitas:
+
+**Completeness** — Apakah semua data point yang direncanakan berhasil dikumpulkan? Missing data adalah masalah serius yang bisa mengubah hasil analisis. Jika dari 100 responden hanya 60 yang mengisi lengkap, 40% data hilang — dan cara menangani missing data (deletion, imputation, atau analisis terpisah) mempengaruhi kesimpulan.
+
+**Consistency** — Apakah data bebas dari kontradiksi internal? Contoh: seorang responden menjawab "sangat puas" pada survei kepuasan tetapi memberikan skor 1/10 pada pertanyaan rating. Atau log eksperimen mencatat waktu respons negatif. Inconsistency bisa disebabkan human error, bug pada instrumen, atau noise.
+
+**Validity** — Apakah data benar-benar mengukur apa yang dimaksudkan? Ini berbeda dari completeness dan consistency: data bisa lengkap dan konsisten, tapi tidak valid. Contoh: mengukur "kemampuan coding" menggunakan jumlah baris kode yang ditulis. Data ini bisa lengkap dan konsisten, tapi jumlah baris kode bukan indikator valid untuk kemampuan coding.
+
+**Representativeness** — Apakah data merepresentasikan populasi yang dituju? Jika eksperimen tentang "pengguna aplikasi mobile" tetapi seluruh partisipan dari satu departemen di satu universitas, datanya tidak representatif terhadap populasi umum. Ini mempengaruhi *external validity* — sejauh mana temuan bisa digeneralisasi.
+
+Keempat dimensi ini bukan checklist opsional. Data yang gagal di satu dimensi saja bisa menginvalidasi seluruh eksperimen. Lebih baik mengulang pengumpulan data daripada menganalisis data yang cacat — karena analisis statistik yang canggih sekalipun tidak bisa memperbaiki data yang fundamentalnya bermasalah.
+
+---
+
+## 5.5 Research vs Engineering
+
+**Tabel 5.1** — Perspektif Metrik: Engineering vs Research
+
+| Aspek | Engineering | Research |
+|-------|------------|----------|
+| **Tujuan pengukuran** | Monitoring performa sistem di production | Menguji hipotesis dan menjawab research question |
+| **Pemilihan metrik** | Berdasarkan kebiasaan industri atau tool yang tersedia | Berdasarkan construct validity dan representasi konsep |
+| **Jumlah metrik** | Semakin banyak dashboard, semakin baik | Dipilih secara selektif, setiap metrik harus dijustifikasi |
+| **Penanganan anomali** | Dihapus atau di-filter agar laporan bersih | Diinvestigasi — anomali bisa mengandung temuan penting |
+| **Baseline** | Versi sebelumnya (rilis terakhir) | Metode/algoritma dari literatur yang sudah divalidasi |
+| **Kapan metrik dipilih** | Setelah sistem jadi (monitoring) | Sebelum eksperimen berjalan (desain) |
+
+Perbedaan paling kritis ada di kolom terakhir. Dalam engineering, metrik sering ditambahkan setelah sistem berjalan — sebagai alat monitoring. Dalam riset, metrik *harus* didefinisikan sebelum data dikumpulkan. Memilih metrik setelah melihat data adalah salah satu bentuk *p-hacking* — cherry-picking metrik yang kebetulan menghasilkan hasil signifikan.
+
+---
+
+## 5.6 Research Reality
+
+### Fenomena 1 — "Metrik Diam-diam Dipilih Setelah Eksperimen"
+
+Praktik ini lebih umum daripada yang diakui. Seorang peneliti menjalankan eksperimen, melihat hasilnya, lalu memilih metrik yang menghasilkan angka paling bagus. Akurasi tidak menunjukkan peningkatan? Coba precision. Precision juga biasa saja? Mungkin F1-score. Masih kurang? Gunakan AUC-ROC. Proses ini mengubah riset dari *hypothesis testing* menjadi *data fishing* — dan hasilnya, meskipun terlihat valid secara teknis, kehilangan kredibilitas ilmiah.
+
+Solusinya sederhana tapi memerlukan disiplin: metrik harus didefinisikan dan didaftarkan dalam dokumen desain eksperimen *sebelum* data dikumpulkan. Jika kemudian ditemukan metrik tambahan yang menarik, ia bisa dilaporkan — tapi sebagai temuan eksplorasi, bukan sebagai pengujian hipotesis utama.
+
+### Fenomena 2 — "Satu Angka Mewakili Segalanya"
+
+Banyak ringkasan riset menyederhanakan temuan menjadi satu angka: "akurasi 94%." Tapi angka tunggal hampir selalu menyembunyikan sesuatu. Akurasi 94% pada dataset seimbang (50:50) artinya sangat berbeda dari akurasi 94% pada dataset tidak seimbang (95:5) — karena pada kasus kedua, model yang selalu menebak kelas mayoritas sudah mencapai akurasi 95% tanpa "belajar" apa-apa.
+
+Multi-metric evaluation bukan kemewahan — ia kebutuhan. Accuracy tanpa precision/recall, throughput tanpa latency, usability score tanpa task completion rate — semuanya memberikan gambaran yang tidak lengkap. Peneliti yang hanya melaporkan satu metrik meninggalkan pertanyaan kritis yang tidak terjawab.
+
+### Fenomena 3 — "Data Dikumpulkan, Baru Kemudian Dicari Metriknya"
+
+Ini kebalikan dari Fenomena 1, namun efeknya sama destruktif. Peneliti mengumpulkan data — log sistem, survei, atau output eksperimen — tanpa rencana metrik yang jelas. Setelah data terkumpul, baru ia bertanya: "data ini bisa diukur pakai apa?" Akibatnya, banyak data yang ternyata tidak relevan (membuang waktu), dan data yang sebenarnya dibutuhkan justru tidak dikumpulkan (memaksa eksperimen ulang).
+
+Urutan yang benar selalu sama: research question → metrik → instrumen pengumpulan → data. Bukan sebaliknya.
+
+---
+
+## 5.7 Cognitive Traps
+
+### Trap 1: "Akurasi tinggi berarti model bagus"
+
+Akurasi adalah metrik yang paling intuitif — tapi juga paling menipu dalam banyak konteks. Pada dataset dengan distribusi kelas 90:10, model yang selalu memprediksi kelas mayoritas sudah mencapai akurasi 90%. Untuk masalah dengan kelas tidak seimbang (deteksi fraud, deteksi malware, diagnosis penyakit langka), precision, recall, dan F1-score pada kelas minoritas jauh lebih informatif. Wohlin et al. (2012) menekankan bahwa pemilihan metrik harus mempertimbangkan karakteristik dataset dan konteks domain.
+
+### Trap 2: "Semakin banyak metrik, semakin lengkap"
+
+Paradoksnya, terlalu banyak metrik justru membingungkan. Jika sebuah studi melaporkan 15 metrik dan 10 di antaranya menunjukkan peningkatan sementara 5 sisanya tidak, apa kesimpulannya? Metrik yang berlebihan tanpa hierarki prioritas membuat pembaca tidak bisa menilai apa yang sebenarnya dibuktikan. Metrik utama (*primary metric*) harus didefinisikan sejak awal — metrik inilah yang langsung terkait dengan hipotesis. Metrik sekunder boleh dilaporkan, tapi statusnya jelas: pendukung, bukan penentu.
+
+### Trap 3: "Data yang sudah ada pasti cukup"
+
+Peneliti pemula sering tergoda menggunakan dataset publik atau data yang sudah tersedia tanpa memeriksa apakah data tersebut sesuai dengan research question mereka. Dataset ImageNet untuk riset deteksi objek medis? Mungkin tidak representatif. Data log server kampus untuk riset tentang e-commerce? Jelas tidak relevan. Kesesuaian data dengan research question bukan soal "data apa yang tersedia" — melainkan "data apa yang dibutuhkan."
+
+### Trap 4: "Mean dan standar deviasi cukup untuk semua data"
+
+Mean hanya bermakna untuk data interval dan ratio dengan distribusi yang mendekati normal. Untuk data ordinal (skala Likert), median lebih tepat. Untuk data dengan outlier ekstrem, mean bisa sangat misleading — satu waktu respons 30 detik di antara 99 respons yang masing-masing 200ms akan mendistorsi rata-rata secara dramatis. Selalu periksa distribusi sebelum memilih statistik deskriptif.
+
+---
+
+## 5.8 Studi Kasus
+
+### Kasus 1 (Basic): "Akurasi Tinggi tapi Metrik Menipu"
+
+**Konteks:**
+
+Sebuah penelitian tentang deteksi email spam menggunakan classifier berbasis Naive Bayes. Dataset terdiri dari 10.000 email: 9.000 non-spam dan 1.000 spam. Setelah training dan testing, peneliti melaporkan akurasi 95% dan menyimpulkan bahwa model bekerja efektif.
+
+**❌ Pendekatan Salah (Bad Approach):**
+
+Peneliti hanya melaporkan akurasi keseluruhan. Tidak ada analisis per-kelas. Tidak ada confusion matrix. Kesimpulan: "Model berhasil mendeteksi spam dengan akurasi 95%."
+
+Mengapa salah: model yang *selalu* memprediksi "non-spam" sudah mencapai akurasi 90% (9.000/10.000). Akurasi 95% hanya menunjukkan peningkatan 5% dari baseline bodoh (*majority classifier*). Lebih penting lagi, jika dari 1.000 email spam hanya 500 yang terdeteksi (recall 50%), maka setengah spam lolos — sebuah kegagalan fundamental untuk detektor spam.
+
+**✅ Pendekatan Benar (Good Approach):**
+
+Peneliti mendefinisikan metrik sebelum eksperimen:
+- **Primary metric:** Recall kelas spam (karena tujuannya mendeteksi spam, bukan mengklasifikasi non-spam)
+- **Secondary metrics:** Precision kelas spam, F1-score kelas spam, akurasi keseluruhan
+- **Baseline:** Majority classifier (akurasi 90%, recall spam 0%)
+
+Hasil dilaporkan dengan confusion matrix lengkap. Recall spam 78% dengan precision 85% (F1 = 0.81). Akurasi keseluruhan 95%. Kesimpulan jauh lebih nuanced: "Model mendeteksi 78% spam dengan false positive rate rendah, meskipun 22% spam masih lolos."
+
+**Perbandingan:**
+
+| Aspek | Bad | Good |
+|-------|-----|------|
+| **Metrik utama** | Akurasi saja | Recall spam (metrik paling relevan) |
+| **Baseline** | Tidak ada | Majority classifier (90%) |
+| **Interpretasi** | "95% akurat = berhasil" | "78% spam terdeteksi, 22% masih lolos" |
+| **Construct validity** | Rendah — akurasi tidak merepresentasikan kemampuan deteksi pada kelas minoritas | Tinggi — recall langsung mengukur kemampuan deteksi |
+
+**Pelajaran:** Metrik harus dipilih berdasarkan apa yang paling penting dalam konteks masalah, bukan berdasarkan apa yang menghasilkan angka tertinggi.
+
+---
+
+### Kasus 2 (Advanced): "User Satisfaction vs System Metric — Dua Dunia yang Tidak Bertemu"
+
+**Konteks:**
+
+Sebuah tim mengembangkan sistem rekomendasi buku menggunakan collaborative filtering. Evaluasi teknis menunjukkan hasil solid: RMSE 0.82 (lebih baik dari baseline content-based filtering yang mencapai 0.91) dan precision@10 sebesar 0.73. Namun saat dilakukan user study terhadap 45 partisipan, Net Promoter Score (NPS) hanya 22 — tergolong rendah. Komentar kualitatif dominan: "rekomendasi sudah ditebak" dan "tidak ada sesuatu yang baru."
+
+**❌ Pendekatan Salah:**
+
+Peneliti memilih salah satu: hanya melaporkan metrik teknis (karena hasilnya bagus) atau hanya melaporkan NPS (karena hasilnya menguntungkan narasi perbaikan). Metrik yang tidak menguntungkan dihilangkan dari laporan.
+
+Mengapa salah: *selective reporting* adalah bentuk bias yang merusak integritas riset. Metrik teknis dan metrik pengalaman pengguna mengukur konsep yang berbeda — keduanya relevan dan harus dilaporkan.
+
+**✅ Pendekatan Benar:**
+
+Peneliti mendefinisikan dua kelompok metrik sejak awal desain eksperimen:
+- **Metrik teknis:** RMSE (akurasi prediksi), Precision@10 (relevansi), Coverage (diversitas katalog), Novelty (seberapa "baru" rekomendasi bagi user)
+- **Metrik pengalaman pengguna:** NPS, task completion rate, self-reported discovery score
+
+Hasil dilaporkan lengkap: metrik teknis unggul di RMSE dan precision, tapi coverage hanya 12% (dari seluruh katalog) dan novelty rendah. Ini menjelaskan *mengapa* NPS rendah: sistem akurat tapi repetitif — merekomendasikan buku yang sudah dikenal pengguna.
+
+Kesimpulan: "Collaborative filtering lebih akurat dalam prediksi rating, tetapi kurang efektif dalam memberikan penemuan baru (*serendipity*) bagi pengguna. Dibutuhkan mekanisme hybrid yang menggabungkan akurasi prediksi dengan explorasi katalog."
+
+**Perbandingan:**
+
+| Aspek | Bad | Good |
+|-------|-----|------|
+| **Pelaporan** | Selektif (hanya metrik yang menguntungkan) | Lengkap (teknis + pengalaman pengguna) |
+| **Diagnosis** | Tidak ada penjelasan mengapa user tidak puas | Coverage rendah + novelty rendah = repetisi |
+| **Kontribusi** | "Sistem kami lebih akurat" | "Akurasi tinggi tidak menjamin kepuasan — butuh dimensi novelty" |
+| **Implikasi** | Tidak ada | Arah riset baru: hybrid recommender |
+
+**Pelajaran:** Metrik teknis dan metrik pengguna mengukur dimensi yang berbeda. Riset yang hanya melaporkan satu sisi kehilangan setengah cerita. Multi-dimensional evaluation bukan pilihan — ia keharusan jika research question menyentuh aspek manusia dan sistem sekaligus.
+
+---
+
+## 5.9 Template Praktis
+
+### Template: Definisi Variabel, Metrik & Justifikasi
+
+```
+═══════════════════════════════════════════════════════════════
+  VARIABEL, METRIK & JUSTIFIKASI — [Judul Penelitian]
+═══════════════════════════════════════════════════════════════
+
+RESEARCH QUESTION:
+  [Tulis RQ lengkap di sini]
+
+VARIABEL INDEPENDEN:
+  Nama       : _______________
+  Tipe       : [Nominal / Ordinal / Interval / Ratio]
+  Level      : [Sebutkan level/kondisi, misal: Metode A vs Metode B]
+  Kontrol    : [Bagaimana variabel ini dimanipulasi?]
+
+VARIABEL DEPENDEN:
+  ┌──────────────────┬────────────┬──────────┬──────────────────┐
+  │ Konsep           │ Variabel   │ Metrik   │ Skala            │
+  ├──────────────────┼────────────┼──────────┼──────────────────┤
+  │ [Konsep abstrak] │ [Variabel  │ [Satuan  │ [Nominal/Ordinal/│
+  │                  │  terukur]  │  ukur]   │  Interval/Ratio] │
+  ├──────────────────┼────────────┼──────────┼──────────────────┤
+  │                  │            │          │                  │
+  └──────────────────┴────────────┴──────────┴──────────────────┘
+
+VARIABEL KONTROL (confounding yang dikontrol):
+  1. [Variabel] — Dikontrol dengan cara: [...]
+  2. [Variabel] — Dikontrol dengan cara: [...]
+
+JUSTIFIKASI METRIK:
+  Primary Metric  : [Nama] — Dipilih karena: [alasan terkait RQ]
+  Secondary Metric: [Nama] — Dipilih karena: [alasan pendukung]
+
+BASELINE:
+  [Metode/algoritma pembanding + sumber referensi]
+
+DATA QUALITY CHECKLIST:
+  □ Completeness — Target: ___% data point terkumpul
+  □ Consistency  — Mekanisme validasi: [...]
+  □ Validity     — Instrumen telah divalidasi melalui: [...]
+  □ Representativeness — Sampel mencakup: [...]
+
+═══════════════════════════════════════════════════════════════
+```
+
+---
+
+## 5.10 Mindmap Ringkasan
+
+**Gambar 5.2** — Mindmap Bab 5: Metric, Measurement & Data
+
+```mermaid
+mindmap
+  root(("**Bab 5**<br/>Metric, Measurement<br/>& Data"))
+    ("**Measurement<br/>Alignment Model**")
+      ("Problem → Concept")
+      ("Concept → Variable")
+      ("Variable → Metric")
+      ("Metric → Data")
+      ("Data → Result")
+    ("**Operasionalisasi**")
+      ("Konsep abstrak → terukur")
+      ("Keputusan desain")
+      ("Harus dijustifikasi")
+    ("**Jenis Data**")
+      ("Nominal")
+      ("Ordinal")
+      ("Interval")
+      ("Ratio")
+    ("**Pemilihan Metrik**")
+      ("Representatif")
+      ("Sensitif")
+      ("Feasible")
+      ("Multi-metric")
+    ("**Kualitas Data**")
+      ("Completeness")
+      ("Consistency")
+      ("Validity")
+      ("Representativeness")
+    ("**Cognitive Traps**")
+      ("Akurasi ≠ performa")
+      ("Terlalu banyak metrik")
+      ("Data ≠ relevansi")
+      ("Mean ≠ selalu tepat")
+```
+
+---
+
+## 5.11 Rangkuman
+
+**Poin-poin utama bab ini:**
+
+1. Setiap pengukuran dalam eksperimen harus bisa ditelusuri dari masalah riset melalui konsep, variabel, metrik, hingga data — tanpa lompatan logis. Rantai ini disebut *measurement alignment*.
+
+2. Operasionalisasi adalah keputusan desain yang consequential: bagaimana konsep abstrak diterjemahkan menjadi variabel terukur menentukan apa yang sebenarnya diuji oleh eksperimen.
+
+3. Jenis data (nominal, ordinal, interval, ratio) menentukan analisis statistik yang valid. Memperlakukan data ordinal sebagai interval atau menggunakan mean untuk data dengan outlier ekstrem menghasilkan kesimpulan yang menyesatkan.
+
+4. Metrik harus dipilih *sebelum* eksperimen berjalan berdasarkan tiga kriteria: representatif terhadap konsep, sensitif terhadap perbedaan, dan feasible untuk dikumpulkan.
+
+5. Kualitas data mencakup empat dimensi — completeness, consistency, validity, dan representativeness — yang harus dipenuhi sebelum analisis dilakukan.
+
+6. Multi-metric evaluation bukan kemewahan. Satu metrik tunggal hampir selalu gagal merepresentasikan konsep yang kompleks secara memadai.
+
+Bab ini meletakkan fondasi pengukuran. Tapi metrik tidak berada di ruang hampa — ia harus diimplementasikan melalui sistem. Bab 6 membahas bagaimana merancang sistem sebagai *experimental artifact*: bukan untuk dipakai, melainkan untuk membuktikan sesuatu secara ilmiah.
+
+> *"Penelitian yang baik bukan hanya mengukur, tetapi memastikan bahwa apa yang diukur benar-benar merepresentasikan realitas."*
+
+---
+
+## 5.12 Latihan & Refleksi
+
+### Latihan 1 — Operasionalisasi Konsep
+
+Pilih satu konsep abstrak dari daftar berikut: (a) kualitas kode, (b) kepuasan pengguna, (c) keamanan sistem, (d) efisiensi algoritma. Untuk konsep yang dipilih, definisikan minimal dua variabel berbeda yang bisa merepresentasikannya. Untuk setiap variabel, tentukan metrik spesifik, skala pengukuran, dan jelaskan keterbatasan representasinya.
+
+### Latihan 2 — Evaluasi Metrik pada Kasus Nyata
+
+Sebuah penelitian mengklaim bahwa "model NLP yang diusulkan lebih baik dari baseline dengan akurasi 92% vs 88%." Dataset berisi 10.000 sampel dengan 7 kelas, distribusi kelas: 60%, 15%, 10%, 5%, 4%, 3%, 3%. Evaluasi: (a) apakah akurasi merupakan metrik yang representatif untuk dataset ini? (b) metrik apa yang lebih informatif? (c) informasi tambahan apa yang dibutuhkan untuk menilai temuan ini?
+
+### Latihan 3 — Data Quality Audit
+
+Ambil dataset publik yang relevan dengan bidang riset yang diminati (misalnya dari Kaggle, UCI ML Repository, atau GitHub). Lakukan audit terhadap empat dimensi kualitas data: completeness, consistency, validity, dan representativeness. Dokumentasikan temuan dan rekomendasi penanganan untuk setiap masalah yang ditemukan.
+
+### Refleksi
+
+> "Apakah metrik yang saya pilih dalam riset benar-benar mengukur konsep yang ingin saya teliti — atau hanya mengukur apa yang paling mudah diukur?"
+
+---
+
+## Daftar Pustaka
+
+- Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., & Wesslén, A. (2012). *Experimentation in Software Engineering*. Springer.
+- Field, A. (2018). *Discovering Statistics Using IBM SPSS Statistics* (5th ed.). SAGE Publications.
+- Shadish, W. R., Cook, T. D., & Campbell, D. T. (2002). *Experimental and Quasi-Experimental Designs for Generalized Causal Inference*. Houghton Mifflin.
+- Creswell, J. W., & Creswell, J. D. (2018). *Research Design: Qualitative, Quantitative, and Mixed Methods Approaches* (5th ed.). SAGE Publications.
+
+<!-- STATUS: 🟢 Draft Complete -->
--- a/book/bagian-2-design/bab-06-system-design.md
+++ b/book/bagian-2-design/bab-06-system-design.md
@ -0,0 +1,414 @@
+# Bab 6 — System Design sebagai Experimental Artifact
+
+> **Sub-CPMK:** 2.2 — Merancang sistem sebagai alat uji hipotesis
+> **CPMK:** CPMK02 — Measurement & Design
+> **CPL Utama:** CPL06 (Desain & pengembangan)
+> **Fase:** Designing (M5–M7)
+> **Signature Model:** System as Experiment Model (RQ → Variable → System Component → Experimental Setup → Output)
+
+---
+
+## Ringkasan Bab
+
+Bab ini membahas prinsip yang sering diabaikan oleh peneliti di bidang TI: bahwa sistem yang dibangun dalam riset bukan produk — ia adalah **alat uji hipotesis**. Arsitektur sistem, pemilihan komponen, dan cara modul berinteraksi seharusnya ditentukan oleh research question dan variabel eksperimen, bukan oleh preferensi teknis atau tren industri. Kita akan belajar memetakan RQ ke komponen sistem, menerapkan empat prinsip desain eksperimental (traceability, modularity, controllability, measurability), dan mengendalikan variabel melalui arsitektur.
+
+---
+
+## 6.1 Pembuka
+
+Bab 5 menyiapkan fondasi pengukuran: konsep sudah dioperasionalisasikan menjadi variabel, metrik sudah dipilih dan dijustifikasi, jenis data sudah ditentukan. Pertanyaan selanjutnya: **di mana variabel-variabel itu hidup?**
+
+Jawabannya: di dalam sistem.
+
+Dalam riset TI dan software engineering, hipotesis diuji melalui sistem — entah itu aplikasi web, model machine learning, API, atau pipeline data. Sistem adalah medium tempat variabel independen dimanipulasi dan variabel dependen diukur. Tapi di sinilah masalah dimulai: banyak peneliti merancang sistem dengan mentalitas *engineer*, bukan mentalitas *eksperimentalis*.
+
+Seorang engineer membangun sistem agar berfungsi dengan baik, scalable, dan user-friendly. Seorang eksperimentalis membangun sistem agar **bisa mengisolasi variabel**. Kedua tujuan ini tidak selalu sejalan. Sistem yang paling elegan secara arsitektural belum tentu paling mudah dieksperimenkan. Sebaliknya, sistem yang dirancang untuk eksperimen mungkin terlihat "berlebihan" dari perspektif engineering — modul yang seharusnya bisa digabung justru dipisah, konfigurasi yang seharusnya di-hardcode justru dibuat parameterik.
+
+Hevner et al. (2004) mendefinisikan sistem dalam konteks riset sebagai *artifact* — sebuah objek yang sengaja diciptakan untuk mendemonstrasikan atau menguji claim tertentu. Artifact bukan tujuan akhir; ia adalah instrumen pembuktian. Peffers et al. (2007) mempertegas bahwa dalam Design Science Research, artifact harus dievaluasi melalui demonstrasi yang terukur — dan evaluasi itu hanya mungkin jika artifact dirancang dengan mempertimbangkan *apa yang akan diukur* sejak awal.
+
+Pertanyaan sentral bab ini: **Bagaimana merancang sistem yang bukan sekadar berfungsi, melainkan bisa membuktikan sesuatu secara ilmiah?**
+
+---
+
+## 6.2 System as Experiment Model
+
+Model ini menunjukkan bahwa setiap komponen sistem harus bisa ditelusuri balik ke variabel penelitian, dan setiap variabel harus bisa ditelusuri ke research question.
+
+**Gambar 6.1** — System as Experiment Model: Dari RQ ke Output Terukur
+
+```mermaid
+graph LR
+    A["❓ <b>Research<br/>Question</b><br/><i>Apa yang diuji?</i>"]
+    B["📊 <b>Variable</b><br/><i>IV, DV, Control</i>"]
+    C["🔧 <b>System<br/>Component</b><br/><i>Modul & arsitektur</i>"]
+    D["⚙️ <b>Experimental<br/>Setup</b><br/><i>Konfigurasi & skenario</i>"]
+    E["📏 <b>Output</b><br/><i>Data terukur</i>"]
+
+    A -->|"Dekomposisi"| B
+    B -->|"Mapping"| C
+    C -->|"Konfigurasi"| D
+    D -->|"Eksekusi"| E
+
+    style A fill:#D1FAE5,stroke:#059669,color:#064E3B
+    style B fill:#A7F3D0,stroke:#059669,color:#064E3B
+    style C fill:#6EE7B7,stroke:#059669,color:#064E3B
+    style D fill:#34D399,stroke:#059669,color:#FFFFFF
+    style E fill:#059669,stroke:#047857,color:#FFFFFF
+```
+
+Setiap transisi menjalankan fungsi spesifik:
+
+1. **RQ → Variable (Dekomposisi).** Research question dipecah menjadi variabel-variabel: independen (yang dimanipulasi), dependen (yang diukur), dan kontrol (yang dijaga konstan). Contoh: RQ "Apakah caching strategy X mengurangi waktu respons dibanding strategy Y?" menghasilkan IV = caching strategy (X vs Y), DV = waktu respons (ms), dan variabel kontrol = beban server, ukuran data, konfigurasi hardware.
+
+2. **Variable → System Component (Mapping).** Setiap variabel dipetakan ke komponen sistem tertentu. IV (caching strategy) → modul caching. DV (waktu respons) → logging module yang mengukur latensi. Variabel kontrol → konfigurasi environment yang di-lock. Jika sebuah variabel tidak bisa dipetakan ke komponen manapun, berarti arsitektur sistem perlu dirancang ulang.
+
+3. **System Component → Experimental Setup (Konfigurasi).** Komponen-komponen dirangkai menjadi skenario eksperimen. Setup A menggunakan caching strategy X; Setup B menggunakan caching strategy Y. Semua variabel kontrol identik di kedua setup. Konfigurasi ini harus bisa direproduksi — artinya, semua parameter didokumentasikan secara eksplisit.
+
+4. **Experimental Setup → Output (Eksekusi).** Eksperimen dijalankan dan menghasilkan data terukur. Output ini harus langsung terkait dengan DV yang sudah didefinisikan. Jika output yang dihasilkan ternyata tidak bisa menjawab RQ, masalahnya ada di tahap mapping atau dekomposisi — bukan di analisis.
+
+Kekuatan model ini terletak pada **traceability dua arah**: dari RQ ke bawah (apakah setiap variabel diimplementasikan?) dan dari output ke atas (apakah setiap pengukuran menjawab RQ?). Jika salah satu arah terputus, eksperimen memiliki *loose end* yang harus diperbaiki sebelum data dikumpulkan.
+
+---
+
+## 6.3 Definisi Kunci
+
+**Artifact**
+: Dalam konteks Design Science Research, artifact adalah objek yang sengaja diciptakan untuk memecahkan masalah atau menguji proposisi tertentu. Artifact bisa berupa sistem, model, metode, atau instantiation. Dalam riset eksperimental TI, artifact biasanya berupa sistem perangkat lunak yang menjadi medium pengujian hipotesis (Hevner et al., 2004).
+
+**Traceability**
+: Kemampuan untuk menelusuri hubungan antara research question, variabel, komponen sistem, dan output eksperimen secara eksplisit. Setiap keputusan desain harus bisa dijawab: "mengapa komponen ini ada, dan variabel mana yang dilayaninya?"
+
+**Variable Isolation**
+: Prinsip eksperimental yang mengharuskan perubahan hanya dilakukan pada satu variabel pada satu waktu, sementara semua variabel lain dijaga konstan. Dalam konteks sistem, ini berarti arsitektur harus memungkinkan substitusi satu komponen tanpa mempengaruhi komponen lain (Bass et al., 2012).
+
+**Experimental Setup**
+: Konfigurasi lengkap dari sistem, data, parameter, dan lingkungan yang digunakan untuk satu skenario eksperimen. Setiap setup merepresentasikan satu kondisi eksperimental.
+
+---
+
+## 6.4 Konsep Inti
+
+### 6.4.1 Sistem Bukan Tujuan — Sistem adalah Alat Uji
+
+Perbedaan antara proyek engineering dan proyek riset terletak pada pertanyaan dasar. Engineer bertanya: "Apakah sistem ini berfungsi?" Peneliti bertanya: "Apa yang bisa dibuktikan oleh sistem ini?"
+
+Dalam proyek engineering, keberhasilan diukur dari apakah sistem memenuhi requirement dan berjalan di production. Dalam riset, keberhasilan diukur dari apakah sistem mampu **mengisolasi variabel** dan **menghasilkan data yang menjawab research question**. Sistem yang berfungsi dengan baik tapi tidak bisa dieksperimenkan adalah kegagalan riset.
+
+Peffers et al. (2007) mendeskripsikan artifact dalam Design Science Research sebagai sesuatu yang harus melewati siklus *build-evaluate*: dibangun berdasarkan design theory, lalu dievaluasi melalui demonstrasi yang terukur. Evaluasi bukan "apakah sistem berhasil di-deploy" — melainkan "apakah evaluasi terhadap artifact menghasilkan bukti yang mendukung atau menolak hipotesis."
+
+Konsekuensi praktisnya signifikan. Seorang peneliti yang membangun sistem rekomendasi untuk riset perlu memikirkan: bagaimana cara mengaktifkan dan menonaktifkan fitur tertentu tanpa mengubah kode? Bagaimana cara menjalankan eksperimen dengan dataset berbeda tanpa rebuild? Bagaimana cara logging yang cukup detail untuk menjawab RQ, tapi tidak terlalu invasif sehingga mengubah perilaku sistem?
+
+### 6.4.2 Mapping RQ ke System Component
+
+Setiap research question mengimplikasikan komponen sistem tertentu. Proses mapping ini harus dilakukan secara eksplisit — bukan dibiarkan "terbentuk sendiri" selama development.
+
+Ambil contoh RQ: "Apakah penggunaan attention mechanism pada model sentiment analysis meningkatkan F1-score dibanding model tanpa attention pada dataset review produk berbahasa Indonesia?"
+
+Mapping yang diperlukan:
+
+| Variabel | Jenis | Komponen Sistem |
+|----------|-------|-----------------|
+| Attention mechanism (ada/tidak) | Independen | Model layer — harus bisa di-toggle on/off |
+| F1-score | Dependen | Evaluation module — menghitung per-kelas dan macro |
+| Dataset review produk | Kontrol | Data pipeline — dataset identik untuk kedua kondisi |
+| Preprocessing | Kontrol | NLP pipeline — tokenizer, stopword, stemming identik |
+| Hyperparameter | Kontrol | Config file — learning rate, batch size, epoch identik |
+| Hardware | Kontrol | Environment spec — GPU, RAM, OS identik |
+
+Tanpa mapping ini, sering terjadi situasi di mana variabel kontrol tidak benar-benar terkontrol. Peneliti mengganti model (IV) tetapi juga mengganti preprocessing (seharusnya kontrol) — sehingga perbedaan hasil tidak bisa diatribusikan ke model saja. Arsitektur yang memisahkan modul model dari modul preprocessing mencegah masalah ini secara struktural.
+
+### 6.4.3 Empat Prinsip Desain Eksperimental
+
+Bass et al. (2012) dan Wohlin et al. (2012) secara implisit menunjukkan bahwa sistem yang baik untuk eksperimen memiliki empat kualitas:
+
+**Traceability** — Setiap komponen dalam sistem harus bisa dijawab: "ini melayani variabel apa?" Komponen yang tidak terkait dengan variabel manapun adalah noise arsitektural — ia menambah kompleksitas tanpa menambah kemampuan eksperimental. Traceability juga berarti dokumentasi: arsitektur komponen, mapping ke variabel, dan justifikasi keberadaan setiap modul.
+
+**Modularity** — Komponen yang merepresentasikan variabel independen harus bisa diganti tanpa mempengaruhi komponen lain. Jika mengganti algoritma klasifikasi memaksa perubahan pada modul preprocessing, modul evaluasi, dan modul logging secara bersamaan, berarti arsitekturnya *tightly coupled* — dan eksperimen tidak bisa mengisolasi efek algoritma saja.
+
+**Controllability** — Variabel kontrol harus bisa dikunci nilainya. Ini berarti konfigurasi (hyperparameter, versi library, random seed, dataset split) harus di-eksternalisasi ke config file — bukan di-hardcode di dalam kode. Controllability juga mencakup reproducibility: siapa pun yang menjalankan eksperimen dengan konfigurasi yang sama harus mendapat hasil yang sama (atau sangat serupa).
+
+**Measurability** — Sistem harus menghasilkan data yang dibutuhkan secara otomatis. Logging, metric collection, dan output formatting harus dirancang sejak awal — bukan ditambahkan setelah eksperimen selesai sebagai afterthought. Jika research question membutuhkan waktu respons per-request, sistem harus memiliki mekanisme pencatatan waktu di level yang tepat. Jika membutuhkan confusion matrix, evaluation module harus menghasilkan prediksi per-sampel, bukan hanya akurasi agregat.
+
+### 6.4.4 Kontrol dan Isolasi Variabel Melalui Arsitektur
+
+Isolasi variabel bukan hanya prinsip statistik — ia prinsip arsitektural. Sistem yang monolitik, di mana semua komponen saling tergantung, secara inheren sulit untuk dieksperimenkan. Mengubah satu hal berarti mengubah banyak hal — dan hasilnya tidak bisa diatribusikan ke perubahan tunggal.
+
+Solusi arsitektural untuk isolasi variabel:
+
+**Modular architecture** — Pisahkan komponen berdasarkan variabel yang dilayani. Model tersendiri, preprocessing tersendiri, evaluation tersendiri, data loading tersendiri. Setiap modul berkomunikasi melalui interface yang terdefinisi — sehingga substitusi satu modul tidak memaksa perubahan di modul lain.
+
+**Configuration-driven execution** — Semua parameter eksperimen disimpan di config file (YAML, JSON, atau sejenisnya), bukan di-hardcode. Menjalankan eksperimen dengan kondisi berbeda cukup mengubah config, bukan mengubah kode. Ini juga memudahkan reproduksi: config file *adalah* dokumentasi eksperimen.
+
+**Feature toggle** — Untuk variabel independen yang bersifat binary (ada/tidak), implementasikan sebagai flag yang bisa diaktifkan atau dinonaktifkan. Ini memungkinkan ablation study — menguji kontribusi setiap komponen secara individual tanpa membangun ulang sistem.
+
+---
+
+## 6.5 Research vs Engineering
+
+**Tabel 6.1** — Perspektif Sistem: Engineering vs Research
+
+| Aspek | Engineering | Research |
+|-------|------------|----------|
+| **Tujuan sistem** | Memenuhi kebutuhan pengguna | Menguji hipotesis dan menghasilkan bukti |
+| **Keberhasilan** | Sistem berjalan di production | Eksperimen menghasilkan data yang menjawab RQ |
+| **Arsitektur** | Optimasi untuk performa dan skalabilitas | Optimasi untuk isolasi variabel dan reproducibility |
+| **Komponen** | Dipilih berdasarkan best practice industri | Dipilih berdasarkan mapping ke variabel eksperimen |
+| **Konfigurasi** | Sering di-hardcode untuk simplisitas | Di-eksternalisasi ke config file untuk kontrol |
+| **Fitur tambahan** | Menambah nilai bagi pengguna | Menambah noise pada eksperimen jika tidak terkait RQ |
+
+Perbedaan ini bukan berarti riset menghasilkan sistem yang buruk. Sistem riset bisa saja di-deploy kemudian. Tapi prioritas pertamanya jelas: **kemampuan eksperimental**. Sistem yang bagus secara engineering tapi tidak bisa mengisolasi variabel adalah kegagalan riset.
+
+---
+
+## 6.6 Research Reality
+
+### Fenomena 1 — "Model ML Monolith: Bagus tapi Tidak Bisa Diuji"
+
+Situasi ini sangat umum: seorang peneliti membangun model machine learning end-to-end — dari data loading, preprocessing, feature engineering, model training, hingga evaluation — dalam satu notebook atau satu file script panjang. Hasilnya mungkin bagus (akurasi tinggi), tapi ketika reviewer bertanya "apa kontribusi spesifik dari teknik preprocessing yang diusulkan?" — jawaban jujurnya, tidak bisa diketahui.
+
+Karena semua tahap saling tergantung dalam satu alur, tidak ada cara untuk mengisolasi efek preprocessing saja. Mengganti preprocessing berarti menjalankan ulang seluruh pipeline — dan jika parameter lain juga berubah (sengaja atau tidak), hasilnya bukan perbandingan yang adil.
+
+Solusi arsitektural: pisahkan pipeline menjadi modul independen. Simpan output setiap tahap sebagai file intermediate. Pastikan setiap modul bisa dijalankan sendiri dengan input yang konsisten. Ini membutuhkan effort lebih di awal, tapi menghemat waktu signifikan saat eksperimen perlu diulang atau divariasikan.
+
+### Fenomena 2 — "Multiple Feature Change, No Clear Impact"
+
+Peneliti membangun sistem versi 2 yang "lebih baik" dari versi 1. Tapi versi 2 mengubah tiga hal sekaligus: algoritma baru, preprocessing baru, dan hyperparameter baru. Hasil versi 2 lebih tinggi — tapi peningkatan itu datang dari mana? Algoritma? Preprocessing? Hyperparameter? Atau kombinasi ketiganya?
+
+Tanpa isolasi variabel, pertanyaan ini tidak bisa dijawab. Dan jika tidak bisa dijawab, kontribusi riset menjadi ambigu. Reviewer akan bertanya: "Jika hanya algoritmanya yang diganti dan preprocessing tetap sama, apakah hasilnya tetap meningkat?" Jika jawabannya tidak diketahui, klaim "metode yang diusulkan lebih baik" tidak memiliki dasar yang kuat.
+
+Prinsip dasarnya sederhana: **ubah satu, kontrol sisanya**. Jika ingin menguji tiga faktor, jalankan tiga eksperimen terpisah (atau desain faktorial, yang dibahas di Bab 7) — bukan satu eksperimen yang mengubah semuanya sekaligus.
+
+---
+
+## 6.7 Cognitive Traps
+
+### Trap 1: "Sistem saya berfungsi, berarti hipotesis terbukti"
+
+Sistem yang berfungsi *tidak sama* dengan hipotesis yang terbukti. Hipotesis memerlukan bukti komparatif: lebih baik dari apa? Diukur dengan apa? Pada kondisi apa? Sistem yang berfungsi hanya membuktikan bahwa implementasi berhasil secara teknis — bukan bahwa pendekatan yang dipilih superior terhadap alternatif yang ada.
+
+### Trap 2: "Arsitektur paling elegan pasti paling baik untuk riset"
+
+Arsitektur yang elegan (clean, DRY, well-abstracted) merupakan praktik baik dalam engineering, tapi bisa kontraproduktif dalam riset. Abstraksi yang terlalu dalam menyembunyikan parameter eksperimen. Dependency injection yang berlebihan membuat tracing variabel menjadi sulit. Dalam riset, transparansi lebih penting daripada elegansi — setiap keputusan arsitektural harus bisa ditelusuri ke variabel.
+
+### Trap 3: "Menambah fitur pasti menambah nilai riset"
+
+Dalam engineering, fitur tambahan bisa menambah nilai produk. Dalam riset, fitur tambahan yang tidak terkait dengan variabel eksperimen justru menambah **confounding factor**. Setiap komponen yang tidak bisa dijustifikasi keberadaannya terhadap RQ seharusnya dihilangkan dari sistem eksperimen — atau setidaknya dikontrol nilainya.
+
+### Trap 4: "Config bisa diatur nanti"
+
+Menunda eksternalisasi konfigurasi ke tahap akhir development hampir selalu berakhir dengan dua hal: parameter yang ter-hardcode di berbagai tempat dan eksperimen yang tidak bisa direproduksi. Konfigurasi bukan afterthought — ia adalah infrastruktur eksperimen. Tanpa config yang terpusat dan terdokumentasi, menjalankan ulang eksperimen dengan kondisi identik menjadi mustahil.
+
+---
+
+## 6.8 Studi Kasus
+
+### Kasus 1 (Basic): "Model ML Tidak Bisa Diuji — Monolith Tanpa Isolasi"
+
+**Konteks:**
+
+Seorang peneliti membangun model klasifikasi sentimen menggunakan LSTM. Seluruh pipeline — data loading, cleaning, tokenization, embedding, training, dan evaluation — ditulis dalam satu Jupyter notebook berurutan (500+ baris kode). Model menghasilkan akurasi 87%, lebih tinggi dari baseline SVM (82%). Peneliti menyimpulkan bahwa LSTM lebih baik dari SVM untuk klasifikasi sentimen.
+
+**❌ Pendekatan Salah:**
+
+Tidak ada pemisahan modul. Preprocessing untuk LSTM dan SVM berbeda (LSTM menggunakan word embedding, SVM menggunakan TF-IDF). Hyperparameter tuning hanya dilakukan untuk LSTM. Dataset split tidak konsisten (random seed berbeda). Kesimpulan: "LSTM 5% lebih akurat dari SVM."
+
+Mengapa salah: perbedaan 5% bisa disebabkan oleh preprocessing yang berbeda, tuning yang tidak seimbang, atau split data yang tidak identik — bukan oleh model LSTM itu sendiri. Perbandingan ini tidak adil (*unfair comparison*).
+
+**✅ Pendekatan Benar:**
+
+Arsitektur dipisah menjadi modul:
+- **Data module:** loading dan split (random seed terkunci di config)
+- **Preprocessing module:** dua variant (embedding untuk LSTM, TF-IDF untuk SVM) — keduanya menerima input identik
+- **Model module:** LSTM dan SVM sebagai komponen yang interchangeable
+- **Evaluation module:** menghitung akurasi, F1, precision, recall — menerima output dari model manapun
+
+Config file mengatur semua parameter: `{model: "lstm", preprocessing: "embedding", seed: 42, epochs: 50, ...}`. Menjalankan eksperimen untuk SVM cukup mengubah config, bukan menulis ulang notebook. Hyperparameter tuning dilakukan untuk kedua model secara setara.
+
+**Perbandingan:**
+
+| Aspek | Bad | Good |
+|-------|-----|------|
+| **Arsitektur** | Monolith notebook | Modular pipeline |
+| **Variabel kontrol** | Tidak konsisten | Terkunci di config file |
+| **Fairness** | Preprocessing dan tuning tidak setara | Identical split, equal tuning effort |
+| **Reproducibility** | Tidak bisa diulang dengan hasil sama | Config file = dokumentasi eksperimen |
+
+**Pelajaran:** Perbandingan yang adil membutuhkan arsitektur yang memungkinkan isolasi variabel. Tanpa modularitas, perbedaan hasil tidak bisa diatribusikan ke satu faktor.
+
+---
+
+### Kasus 2 (Advanced): "Multiple Feature Change — Mana yang Berkontribusi?"
+
+**Konteks:**
+
+Sebuah tim mengembangkan sistem deteksi intrusi jaringan. Versi awal (v1) menggunakan Random Forest dengan fitur statistik dasar (mean, std, max packet size) dan evaluasi pada dataset NSL-KDD. Versi baru (v2) dibangun dengan tiga perubahan sekaligus: (a) model diganti ke XGBoost, (b) fitur ditambah 15 fitur baru berbasis temporal, dan (c) preprocessing ditambah normalization Z-score. Hasil: akurasi v2 = 93%, v1 = 86%. Peneliti menyimpulkan: "XGBoost lebih baik dari Random Forest untuk deteksi intrusi."
+
+**❌ Pendekatan Salah:**
+
+Hanya melaporkan v1 vs v2. Tidak ada ablation study. Klaim bahwa "XGBoost lebih baik" tidak bisa dibuktikan karena tiga variabel berubah bersamaan. Peningkatan 7% mungkin seluruhnya berasal dari 15 fitur baru — bukan dari model XGBoost.
+
+**✅ Pendekatan Benar:**
+
+Arsitektur dirancang dengan tiga modul independen: feature extraction, preprocessing, dan model. Eksperimen dijalankan secara bertahap:
+
+| Eksperimen | Model | Fitur | Preprocessing | Akurasi |
+|------------|-------|-------|---------------|---------|
+| Baseline (v1) | Random Forest | Dasar | Tanpa normalisasi | 86% |
+| Exp-A | **XGBoost** | Dasar | Tanpa normalisasi | 87% |
+| Exp-B | Random Forest | **Dasar + Temporal** | Tanpa normalisasi | 91% |
+| Exp-C | Random Forest | Dasar | **Z-score** | 87% |
+| Exp-D | XGBoost | Dasar + Temporal | Z-score | 93% |
+
+Temuan: peningkatan terbesar berasal dari fitur temporal (+5%), bukan dari model XGBoost (+1%) atau normalisasi (+1%). Kontribusi riset berubah dari "XGBoost lebih baik" menjadi "fitur temporal berbasis window menjadi faktor dominan dalam peningkatan deteksi intrusi" — klaim yang lebih spesifik, lebih honest, dan lebih bernilai ilmiah.
+
+**Perbandingan:**
+
+| Aspek | Bad | Good |
+|-------|-----|------|
+| **Variabel yang berubah** | 3 sekaligus | 1 per eksperimen (ablation) |
+| **Klaim** | "XGBoost lebih baik" (overstatement) | "Fitur temporal berkontribusi paling besar" (presisi) |
+| **Arsitektur** | Dua versi monolith | Tiga modul yang bisa dikombinasikan |
+| **Evidential strength** | Lemah (confounded) | Kuat (isolated factors) |
+
+**Pelajaran:** Ablation study — menguji kontribusi setiap faktor secara independen — hanya mungkin jika arsitektur mendukung substitusi komponen. Klaim riset yang kuat membutuhkan bukti yang terpisah untuk setiap faktor yang berubah.
+
+---
+
+## 6.9 Template Praktis
+
+### Template: Mapping RQ ke Arsitektur Sistem
+
+```
+═══════════════════════════════════════════════════════════════
+  MAPPING RQ → SYSTEM ARCHITECTURE — [Judul Penelitian]
+═══════════════════════════════════════════════════════════════
+
+RESEARCH QUESTION:
+  [Tulis RQ lengkap di sini]
+
+DEKOMPOSISI VARIABEL:
+  ┌──────────────────┬────────────┬──────────────────────────┐
+  │ Variabel         │ Jenis      │ Komponen Sistem          │
+  ├──────────────────┼────────────┼──────────────────────────┤
+  │ [Variabel 1]     │ Independen │ [Modul/layer yang       │
+  │                  │            │  mengimplementasikan]     │
+  ├──────────────────┼────────────┼──────────────────────────┤
+  │ [Variabel 2]     │ Dependen   │ [Modul yang mengukur]    │
+  ├──────────────────┼────────────┼──────────────────────────┤
+  │ [Variabel 3]     │ Kontrol    │ [Komponen yang dikunci]  │
+  └──────────────────┴────────────┴──────────────────────────┘
+
+4 PRINSIP DESAIN:
+  □ Traceability   — Setiap komponen terhubung ke variabel: [Y/N]
+  □ Modularity     — IV bisa disubstitusi tanpa ubah komponen lain: [Y/N]
+  □ Controllability — Variabel kontrol di-eksternalisasi ke config: [Y/N]
+  □ Measurability  — DV tercatat otomatis oleh sistem: [Y/N]
+
+CONFIG FILE CHECKLIST:
+  □ Random seed
+  □ Dataset path & split ratio
+  □ Hyperparameter model
+  □ Preprocessing parameter
+  □ Environment spec (library version, hardware)
+
+SKENARIO EKSPERIMEN:
+  ┌─────────────┬─────────────┬───────────────┬─────────────┐
+  │ Setup       │ IV (kondisi)│ Kontrol       │ DV (diukur) │
+  ├─────────────┼─────────────┼───────────────┼─────────────┤
+  │ Baseline    │ [Kondisi A] │ [Semua sama]  │ [Metrik]    │
+  ├─────────────┼─────────────┼───────────────┼─────────────┤
+  │ Treatment   │ [Kondisi B] │ [Semua sama]  │ [Metrik]    │
+  └─────────────┴─────────────┴───────────────┴─────────────┘
+
+═══════════════════════════════════════════════════════════════
+```
+
+---
+
+## 6.10 Mindmap Ringkasan
+
+**Gambar 6.2** — Mindmap Bab 6: System Design sebagai Experimental Artifact
+
+```mermaid
+mindmap
+  root(("**Bab 6**<br/>System Design<br/>sebagai Artifact"))
+    ("**System as<br/>Experiment Model**")
+      ("RQ → Variable")
+      ("Variable → Component")
+      ("Component → Setup")
+      ("Setup → Output")
+    ("**Sistem = Alat Uji**")
+      ("Bukan produk")
+      ("Bukan tujuan akhir")
+      ("Instrumen pembuktian")
+    ("**4 Prinsip**")
+      ("Traceability")
+      ("Modularity")
+      ("Controllability")
+      ("Measurability")
+    ("**Mapping RQ →<br/>Komponen**")
+      ("IV → modul yang dimanipulasi")
+      ("DV → modul yang mengukur")
+      ("Kontrol → config yang dikunci")
+    ("**Isolasi Variabel**")
+      ("Modular architecture")
+      ("Config-driven execution")
+      ("Feature toggle")
+    ("**Cognitive Traps**")
+      ("Berfungsi ≠ terbukti")
+      ("Elegan ≠ eksperimentable")
+      ("Fitur tambahan = noise")
+```
+
+---
+
+## 6.11 Rangkuman
+
+**Poin-poin utama bab ini:**
+
+1. Sistem dalam riset bukan produk — ia adalah *experimental artifact* yang dirancang untuk menguji hipotesis. Keberhasilannya bukan dari apakah ia berfungsi, melainkan dari apakah ia bisa mengisolasi variabel dan menghasilkan data yang menjawab research question.
+
+2. Setiap komponen sistem harus bisa ditelusuri ke variabel eksperimen tertentu. Komponen yang tidak terkait dengan variabel manapun adalah noise arsitektural.
+
+3. Empat prinsip desain eksperimental — traceability, modularity, controllability, measurability — menentukan apakah sebuah sistem layak dijadikan alat uji.
+
+4. Isolasi variabel bukan hanya prinsip statistik; ia prinsip arsitektural. Sistem monolitik yang mengubah banyak hal sekaligus tidak bisa menghasilkan klaim yang spesifik.
+
+5. Ablation study — menguji kontribusi setiap faktor secara independen — hanya mungkin jika arsitektur mendukung substitusi komponen secara modular.
+
+6. Konfigurasi yang di-eksternalisasi adalah fondasi reproducibility. Tanpa config file yang terdokumentasi, eksperimen yang "berhasil" tidak bisa diverifikasi.
+
+Dengan pemahaman tentang metrik (Bab 5) dan arsitektur sistem (Bab 6), tahap terakhir dari desain eksperimen adalah merancang eksperimen itu sendiri: bagaimana menyusun skenario pengujian, memastikan validitas, dan membangun bukti kausalitas yang dapat dipercaya. Ini menjadi fokus Bab 7.
+
+> *"Dalam penelitian, sistem bukan dibangun untuk digunakan, tetapi untuk membuktikan sesuatu secara ilmiah."*
+
+---
+
+## 6.12 Latihan & Refleksi
+
+### Latihan 1 — Mapping RQ ke Arsitektur
+
+Ambil research question dari latihan Bab 4. Identifikasi semua variabel (independen, dependen, kontrol). Petakan setiap variabel ke komponen sistem yang akan mengimplementasikan atau mengukurnya. Gambarkan diagram arsitektur sederhana yang menunjukkan mapping ini.
+
+### Latihan 2 — Evaluasi 4 Prinsip
+
+Pilih satu proyek riset (milik sendiri atau dari literatur). Evaluasi arsitektur sistemnya terhadap empat prinsip: traceability, modularity, controllability, measurability. Untuk setiap prinsip, beri skor (1-5) dan jelaskan alasannya. Identifikasi prinsip mana yang paling lemah dan usulkan perbaikan.
+
+### Latihan 3 — Desain Ablation Study
+
+Untuk sistem dari Latihan 1, rancang ablation study yang menguji kontribusi setiap komponen secara independen. Buat tabel skenario eksperimen (seperti Kasus 2 di atas) yang menunjukkan: kondisi baseline, variasi per faktor, dan kombinasi final.
+
+### Refleksi
+
+> "Apakah sistem yang saya bangun dirancang untuk berfungsi, atau dirancang untuk membuktikan sesuatu? Apakah setiap komponen bisa dijustifikasi terhadap research question?"
+
+---
+
+## Daftar Pustaka
+
+- Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design Science in Information Systems Research. *MIS Quarterly*, 28(1), 75–105.
+- Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007). A Design Science Research Methodology for Information Systems Research. *Journal of Management Information Systems*, 24(3), 45–77.
+- Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., & Wesslén, A. (2012). *Experimentation in Software Engineering*. Springer.
+- Bass, L., Clements, P., & Kazman, R. (2012). *Software Architecture in Practice* (3rd ed.). Addison-Wesley.
+
+<!-- STATUS: 🟢 Draft Complete -->
--- a/book/bagian-2-design/bab-07-experiment-design.md
+++ b/book/bagian-2-design/bab-07-experiment-design.md
@ -0,0 +1,468 @@
+# Bab 7 — Experimental Design & Validity
+
+> **Sub-CPMK:** 2.3 — Merancang eksperimen terkontrol dengan validitas tinggi
+> **CPMK:** CPMK02 — Measurement & Design
+> **CPL Utama:** CPL06 (Desain & pengembangan)
+> **Fase:** Designing (M5–M7)
+> **Signature Model:** Experimental Validity Model (RQ → Hypothesis → Variable Design → Controlled Experiment → Data → Analysis → Conclusion)
+
+---
+
+## Ringkasan Bab
+
+Bab ini membahas inti dari riset eksperimental: bagaimana merancang eksperimen yang mampu membuktikan hubungan sebab-akibat, bukan sekadar korelasi. Kita akan belajar membedakan *causality* dari *correlation*, merancang eksperimen terkontrol, memahami empat jenis validitas (internal, external, construct, conclusion), dan mengenal tiga tipe eksperimen yang paling relevan di bidang TI — comparison study, ablation study, dan parameter study. Bab ini menutup Bagian 2 (Measurement & Design) dan menyiapkan transisi ke Bagian 3 (Execution).
+
+---
+
+## 7.1 Pembuka
+
+Bab 5 mendefinisikan apa yang akan diukur. Bab 6 merancang sistem sebagai instrumen pengukuran. Pertanyaan terakhir sebelum eksperimen benar-benar dijalankan: **bagaimana memastikan bahwa apa yang diukur menghasilkan bukti yang valid?**
+
+Pertanyaan ini bukan retoris. Banyak eksperimen yang secara teknis berhasil — sistem jalan, data terkumpul, angka ada — tetapi buktinya lemah karena desain eksperimennya cacat. Contoh klasik: seorang peneliti membandingkan algoritma A dan algoritma B, melaporkan bahwa A lebih baik (akurasi 91% vs 87%), tapi ternyata A diuji pada versi dataset yang sudah di-cleaning sementara B diuji pada versi raw. Perbedaan 4% itu mungkin sepenuhnya disebabkan oleh perbedaan data — bukan algoritma.
+
+Ini bukan masalah statistik. Ini masalah **desain**.
+
+Shadish, Cook, dan Campbell (2002) mendefinisikan eksperimen sebagai investigasi di mana peneliti secara sengaja memanipulasi satu atau lebih variabel independen dan mengamati efeknya pada variabel dependen, sambil mengontrol variabel-variabel lain yang bisa mempengaruhi hasil. Kata kunci di sini ada tiga: **manipulasi** (ada intervensi yang disengaja), **pengamatan** (efeknya diukur), dan **kontrol** (faktor-faktor lain dijaga konstan).
+
+Tanpa kontrol, yang terjadi bukan eksperimen — melainkan observasi. Tanpa manipulasi, yang terjadi bukan eksperimen — melainkan survei. Dan tanpa pengamatan yang terukur, yang terjadi bukan eksperimen — melainkan demonstrasi.
+
+Wohlin et al. (2012) menekankan bahwa desain eksperimen di software engineering memiliki tantangan unik. Berbeda dengan eksperimen di laboratorium kimia yang bisa mengontrol suhu, tekanan, dan konsentrasi secara presisi, eksperimen TI berurusan dengan variabel yang lebih sulit dikontrol: perilaku pengguna, kualitas kode yang bervariasi, versi library yang berubah, dan hardware yang tidak identik. Justru karena kontrol lebih sulit, desain yang cermat menjadi lebih penting.
+
+Pertanyaan sentral bab ini: **Bagaimana merancang eksperimen yang menghasilkan bukti kausalitas yang dapat dipercaya, bukan sekadar angka yang terlihat meyakinkan?**
+
+---
+
+## 7.2 Experimental Validity Model
+
+Model ini menggambarkan alur lengkap dari research question hingga kesimpulan, dengan **validitas** sebagai filter di setiap tahap.
+
+**Gambar 7.1** — Experimental Validity Model: Dari RQ ke Conclusion yang Valid
+
+```mermaid
+graph LR
+    A["❓ <b>RQ</b><br/><i>Apa yang diuji?</i>"]
+    B["🎯 <b>Hypothesis</b><br/><i>H0 & H1</i>"]
+    C["📊 <b>Variable<br/>Design</b><br/><i>IV, DV, Control</i>"]
+    D["⚙️ <b>Controlled<br/>Experiment</b><br/><i>Setup & skenario</i>"]
+    E["📦 <b>Data</b><br/><i>Hasil observasi</i>"]
+    F["📈 <b>Analysis</b><br/><i>Uji statistik</i>"]
+    G["✅ <b>Conclusion</b><br/><i>Validity Level</i>"]
+
+    A -->|"Prediksi"| B
+    B -->|"Operasionalisasi"| C
+    C -->|"Eksekusi"| D
+    D -->|"Pengumpulan"| E
+    E -->|"Pengujian"| F
+    F -->|"Interpretasi"| G
+
+    style A fill:#D1FAE5,stroke:#059669,color:#064E3B
+    style B fill:#A7F3D0,stroke:#059669,color:#064E3B
+    style C fill:#6EE7B7,stroke:#059669,color:#064E3B
+    style D fill:#34D399,stroke:#059669,color:#FFFFFF
+    style E fill:#10B981,stroke:#047857,color:#FFFFFF
+    style F fill:#059669,stroke:#047857,color:#FFFFFF
+    style G fill:#047857,stroke:#065F46,color:#FFFFFF
+```
+
+Setiap transisi membawa risiko ancaman validitas (*validity threat*):
+
+1. **RQ → Hypothesis:** Apakah hipotesis benar-benar menterjemahkan RQ? Hipotesis yang terlalu sempit atau terlalu luas menghasilkan eksperimen yang tidak menjawab pertanyaan sebenarnya.
+
+2. **Hypothesis → Variable Design:** Apakah variabel yang dipilih merepresentasikan konsep dalam hipotesis? Ini adalah isu *construct validity* yang dibahas di Bab 5.
+
+3. **Variable Design → Controlled Experiment:** Apakah eksperimen benar-benar mengontrol semua variabel yang seharusnya? Jika ada variabel yang tidak terkontrol — *confounding variable* — maka hubungan yang ditemukan mungkin palsu. Ini ancaman *internal validity*.
+
+4. **Controlled Experiment → Data:** Apakah pengumpulan data bebas dari bias? Instrumen yang cacat, sampling yang tidak representatif, atau kondisi pengumpulan yang tidak konsisten mengancam kualitas data.
+
+5. **Data → Analysis:** Apakah uji statistik yang dipilih sesuai dengan jenis data dan distribsinya? Ini ancaman *conclusion validity* — kemampuan analisis untuk mendeteksi efek yang sebenarnya ada (atau tidak melihat efek yang sebenarnya tidak ada).
+
+6. **Analysis → Conclusion:** Apakah temuan bisa digeneralisasi di luar konteks eksperimen? Ini ancaman *external validity* — sejauh mana hasil eksperimen berlaku untuk populasi, setting, atau waktu yang berbeda.
+
+Model ini menunjukkan bahwa validitas bukan properti tunggal — ia terdistribusi di seluruh rantai eksperimen. Satu kelemahan di satu titik bisa menginvalidasi seluruh kesimpulan.
+
+---
+
+## 7.3 Definisi Kunci
+
+**Kausalitas (*Causality*)**
+: Hubungan sebab-akibat di mana perubahan pada variabel X secara langsung menyebabkan perubahan pada variabel Y. Kausalitas memerlukan tiga syarat: korelasi (X dan Y bergerak bersama), urutan temporal (X terjadi sebelum Y), dan eliminasi alternatif (tidak ada faktor lain yang menjelaskan hubungan tersebut). Eksperimen terkontrol adalah satu-satunya metode yang bisa membuktikan kausalitas (Shadish et al., 2002).
+
+**Internal Validity**
+: Sejauh mana hubungan yang ditemukan antara variabel independen dan dependen benar-benar disebabkan oleh manipulasi eksperimental — bukan oleh faktor lain (*confounding variable*). Internal validity tinggi berarti peneliti bisa yakin bahwa "perubahan Y memang disebabkan oleh X" (Shadish et al., 2002).
+
+**External Validity**
+: Sejauh mana temuan eksperimen bisa digeneralisasi ke populasi, setting, waktu, atau konteks yang berbeda dari kondisi eksperimen. Eksperimen laboratorium cenderung tinggi internal validity tetapi rendah external validity; field study sebaliknya (Wohlin et al., 2012).
+
+**Conclusion Validity**
+: Sejauh mana kesimpulan tentang hubungan antar variabel secara statistik valid. Ini mencakup kekuatan uji statistik (*statistical power*), ukuran sampel, dan kesesuaian metode analisis dengan jenis data (Field, 2018).
+
+**Construct Validity**
+: Sejauh mana variabel yang diukur dan dimanipulasi benar-benar merepresentasikan konsep yang dimaksudkan. Pelanggaran construct validity terjadi ketika metrik tidak sesuai dengan konsep — seperti mengukur "kualitas kode" hanya dari jumlah baris (Shadish et al., 2002).
+
+---
+
+## 7.4 Konsep Inti
+
+### 7.4.1 Korelasi Bukan Kausalitas — dan Mengapa Ini Penting
+
+Pernyataan "korelasi bukan kausalitas" mungkin terdengar klise, tapi implikasinya sangat praktis dalam riset TI. Pertimbangkan situasi berikut: seorang peneliti menemukan bahwa proyek open-source dengan lebih banyak kontributor memiliki lebih sedikit bug kritis. Kesimpulan naif: "lebih banyak kontributor menyebabkan lebih sedikit bug." Tapi mungkin yang terjadi adalah proyek yang lebih matang (dan sudah stabil) menarik lebih banyak kontributor — dan kematangan itulah yang mengurangi bug, bukan jumlah orang.
+
+Tanpa desain eksperimental yang mengontrol variabel "kematangan proyek," hubungan yang ditemukan hanya korelasi — bukan bukti bahwa menambah kontributor akan mengurangi bug. Ini bukan masalah statistik yang bisa diselesaikan dengan teknik analisis lebih canggih. Ini masalah desain.
+
+Eksperimen terkontrol menyelesaikan masalah ini dengan prinsip sederhana: **ubah satu variabel, kontrol sisanya, lalu amati efeknya**. Jika variabel independen (caching strategy) berubah, variabel kontrol (beban server, hardware, versi software) dijaga konstan, dan variabel dependen (waktu respons) berubah — maka ada dasar untuk klaim kausal: perubahan caching strategy menyebabkan perubahan waktu respons.
+
+Tiga syarat kausalitas dari Shadish et al. (2002) harus dipenuhi secara simultan:
+- **Kovariansi:** X dan Y memang bergerak bersama (ditunjukkan oleh data eksperimen).
+- **Temporal precedence:** X berubah sebelum Y berubah (dijamin oleh urutan manipulasi).
+- **Eliminasi alternatif:** Tidak ada faktor lain yang menjelaskan perubahan Y (dijamin oleh kontrol variabel).
+
+### 7.4.2 Empat Jenis Validitas: Peta Ancaman Eksperimen
+
+Shadish et al. (2002) mengidentifikasi empat jenis validitas yang berfungsi sebagai "peta ancaman" terhadap eksperimen. Setiap jenis menjaga aspek berbeda dari klaim ilmiah:
+
+**Internal Validity** — Ancaman utama: *confounding variable*. Jika ada variabel yang berubah bersamaan dengan variabel independen tanpa dikontrol, hubungan kausal yang diklaim mungkin palsu. Contoh di TI: membandingkan framework A dan B, tapi A diuji di server baru sementara B di server lama. Perbedaan performa mungkin disebabkan hardware.
+
+Cara meminimalkan ancaman: random assignment (jika ada subjek manusia), counterbalancing (urutan pengujian dirotasi), dan standardisasi prosedur (semua kondisi dijalankan pada environment identik).
+
+**External Validity** — Ancaman utama: *generalizability*. Temuan dari eksperimen di satu konteks belum tentu berlaku di konteks lain. Model yang diuji pada dataset bahasa Inggris belum tentu bekerja sama baiknya pada bahasa Indonesia. Sistem yang diuji dengan 100 pengguna simulasi belum tentu berperilaku sama dengan 10.000 pengguna nyata.
+
+Cara meminimalkan ancaman: variasi subjek (gunakan dataset dari beberapa domain), variasi setting (uji di beberapa environment), dan replikasi (ulangi eksperimen di kondisi berbeda). Perlu diingat: internal dan external validity sering berkonflik. Semakin ketat kontrol (internal tinggi), semakin tidak natural situasinya (external rendah).
+
+**Construct Validity** — Ancaman utama: *operationalization gap*. Variabel yang diukur tidak merepresentasikan konsep yang dimaksud. Mengukur "usability" hanya dari waktu penyelesaian tugas mengabaikan aspek learnability, satisfaction, dan error rate. Ini sudah dibahas mendalam di Bab 5, tapi menjadi relevan kembali di sini: bahkan desain eksperimen yang sempurna menjadi tidak bermakna jika metriknya salah.
+
+**Conclusion Validity** — Ancaman utama: *statistical power*. Ukuran sampel yang terlalu kecil tidak mampu mendeteksi efek yang sebenarnya ada (*Type II error*). Sebaliknya, ukuran sampel yang sangat besar bisa mendeteksi perbedaan yang secara statistik signifikan tapi secara praktis tidak bermakna. Conclusion validity juga mencakup pemilihan uji statistik yang tepat — menggunakan t-test pada data yang tidak terdistribusi normal, misalnya, menghasilkan kesimpulan yang meragukan.
+
+### 7.4.3 Tiga Tipe Eksperimen di Riset TI
+
+Wohlin et al. (2012) dan Creswell (2012) mendeskripsikan beberapa desain eksperimen. Dalam konteks riset TI dan software engineering, tiga tipe paling umum:
+
+**Comparison Study** — Membandingkan dua atau lebih pendekatan/metode/algoritma pada kondisi yang sama. Struktur: metode A vs metode B vs baseline, diukur pada dataset dan metrik yang identik. Ini tipe paling fundamental — hampir semua riset eksperimental TI mengandung elemen perbandingan.
+
+Syarat utama: **fairness**. Perbandingan hanya valid jika semua kondisi selain variabel independen benar-benar identik. Dataset sama, preprocessing sama, hyperparameter di-tune dengan effort setara, hardware sama. Jika satu kondisi mendapat "perlakuan istimewa" (data lebih bersih, tuning lebih lama, hardware lebih cepat), perbandingan menjadi bias.
+
+**Ablation Study** — Menguji kontribusi setiap komponen sistem secara individual. Dimulai dari sistem lengkap, lalu satu per satu komponen dihapus atau dinonaktifkan untuk mengamati efeknya. Contoh: sistem rekomendasi memiliki tiga modul — collaborative filtering, content-based, dan popularity-based. Ablation study menguji: sistem penuh, sistem tanpa CF, sistem tanpa CB, sistem tanpa popularity.
+
+Ablation study menjawab pertanyaan yang tidak bisa dijawab oleh comparison study: *bagian mana yang paling berkontribusi?* Ini sangat relevan jika sistem yang diusulkan memiliki beberapa komponen novel.
+
+**Parameter Study** — Menguji efek variasi parameter tertentu pada performa sistem. Contoh: bagaimana learning rate (0.001, 0.01, 0.1) mempengaruhi convergence time dan akurasi akhir? Bagaimana jumlah hidden layer (1, 2, 3, 5) mempengaruhi overfitting?
+
+Parameter study berguna untuk memahami *sensitivitas* sistem terhadap konfigurasi. Jika performa berfluktuasi drastis dengan perubahan parameter kecil, sistem tidak robust — dan ini informasi penting untuk dilaporkan.
+
+### 7.4.4 Controlled Experiment: Ubah Satu, Kontrol Sisanya
+
+Prinsip paling fundamental dalam eksperimen terkontrol: **hanya satu variabel yang berubah pada satu waktu**. Semua variabel lain dijaga konstan. Jika hasilnya berubah, perubahan bisa diatribusikan ke variabel yang dimanipulasi.
+
+Dalam praktek riset TI, "kontrol" berarti:
+- **Dataset identik** untuk semua kondisi (split, preprocessing, seed)
+- **Environment identik** (versi library, hardware, OS)
+- **Parameter identik** untuk semua variabel yang bukan IV
+- **Prosedur identik** (urutan langkah, durasi training, stopping criteria)
+- **Evaluasi identik** (metrik sama, threshold sama, metode statistik sama)
+
+Wohlin et al. (2012) mengingatkan bahwa dalam software engineering, kontrol sempurna sering tidak mungkin — ada *accidental complexity* dari environment, timing, dan non-determinisme. Yang penting adalah: variabel yang tidak bisa dikontrol sepenuhnya harus **diakui dan didokumentasikan** sebagai *threat to validity*. Mengakui keterbatasan bukan kelemahan — mengabaikannya yang merupakan kelemahan.
+
+---
+
+## 7.5 Research vs Engineering
+
+**Tabel 7.1** — Perspektif Eksperimen: Engineering vs Research
+
+| Aspek | Engineering | Research |
+|-------|------------|----------|
+| **Tujuan pengujian** | Memastikan sistem berfungsi sesuai requirement | Membuktikan hubungan kausal antara variabel |
+| **Testing** | Black-box (input → output sesuai spesifikasi) | Hypothesis-driven (apakah H0 bisa ditolak?) |
+| **Kontrol** | Environment staging/production | Semua variabel selain IV dikunci konstan |
+| **Baseline** | Versi sebelumnya | Metode dari literatur yang sudah divalidasi |
+| **Failure** | Bug report, fix, release | H0 tidak ditolak — tetap kontribusi ilmiah |
+| **Keberhasilan** | 100% test pass | Bukti valid — entah mendukung atau menolak hipotesis |
+
+Poin terakhir layak ditekankan: dalam engineering, "gagal" berarti ada bug. Dalam riset, hipotesis yang ditolak *bukan* kegagalan — ia temuan yang sah. Bahkan temuan negatif ("metode A tidak lebih baik dari metode B") berkontribusi pada pengetahuan ilmiah, selama eksperimennya dirancang dengan valid.
+
+---
+
+## 7.6 Research Reality
+
+### Fenomena 1 — "Eksperimen Tanpa Kontrol: Semua Variabel Berubah"
+
+Ini mungkin masalah paling prevalent dalam riset TI pemula. Peneliti membangun "sistem baru" yang berbeda dari "sistem lama" di banyak aspek — algoritma baru, fitur baru, preprocessing baru, dataset berbeda, bahkan hardware berbeda. Hasilnya lebih baik. Tapi lebih baik karena apa?
+
+Tanpa kontrol, pertanyaan ini tidak bisa dijawab. Dan jika tidak bisa dijawab, klaim "metode yang diusulkan lebih baik" kehilangan fondasi. Reviewer yang cermat akan menanyakan: "Bagaimana Anda tahu peningkatan ini berasal dari metode yang diusulkan, bukan dari preprocessing yang berbeda atau dataset yang lebih bersih?"
+
+Solusinya bukan menghindari perubahan — melainkan mengisolasi setiap perubahan. Jika ada tiga hal yang berbeda, lakukan tiga eksperimen terpisah yang masing-masing mengubah satu hal saja. Ini membutuhkan waktu lebih lama, tapi menghasilkan bukti yang jauh lebih kuat.
+
+### Fenomena 2 — "Baseline yang Tidak Fair"
+
+Masalah kedua yang sering muncul: baseline yang sengaja atau tidak sengaja "diperlemah." Peneliti membandingkan algoritma yang ia usulkan (di-tuning secara optimal, preprocessing terbaik, hardware terbaru) dengan baseline dari paper 5 tahun lalu (default parameter, preprocessing minimal, hardware tidak disebut). Hasilnya: metode yang diusulkan menang. Tapi apakah perbandingan ini adil?
+
+Creswell (2012) mengingatkan bahwa perbandingan hanya bermakna jika kondisinya *comparable*. Baseline harus mendapat perlakuan yang sama: tuning effort setara, preprocessing setara, dataset identik, hardware identik. Jika baseline tidak di-tune tapi metode yang diusulkan di-tune, perbedaan hasilnya bukan bukti superioritas metode — melainkan bukti superioritas tuning.
+
+### Fenomena 3 — "Threat to Validity yang Hanya Ditulis di Akhir"
+
+Banyak paper yang memiliki section "threats to validity" di akhir — tapi isinya template generik yang tidak spesifik terhadap eksperimen yang dilakukan. "External validity mungkin terbatas karena kami hanya menggunakan satu dataset." Ya, tapi apa implikasinya terhadap kesimpulan?
+
+Ancaman validitas seharusnya diidentifikasi *sebelum* eksperimen berjalan — dan langkah mitigasi dirancang sebagai bagian dari desain eksperimen. Menulis threats to validity setelah eksperimen bukan refleksi — ia damage control.
+
+---
+
+## 7.7 Cognitive Traps
+
+### Trap 1: "Hasilnya signifikan, berarti penting"
+
+Signifikansi statistik (*p-value* < 0.05) hanya berarti hasil tersebut tidak mungkin terjadi secara kebetulan jika H0 benar. Ia tidak mengatakan bahwa perbedaannya *bermakna* secara praktis. Dengan sampel yang cukup besar, perbedaan akurasi 0.1% pun bisa signifikan secara statistik — meskipun secara praktis tidak relevan. Selalu laporkan *effect size* bersamaan dengan p-value untuk memberikan konteks besaran efek (Field, 2018).
+
+### Trap 2: "Semakin banyak eksperimen, semakin kuat buktinya"
+
+Menjalankan banyak eksperimen tanpa desain yang koheren tidak memperkuat bukti — justru meningkatkan risiko *multiple comparison problem*. Jika 20 uji statistik independen dijalankan dengan α = 0.05, kemungkinan setidaknya satu menunjukkan hasil "signifikan" secara kebetulan mendekati 64%. Setiap eksperimen harus direncanakan sebagai bagian dari desain keseluruhan dengan koreksi yang sesuai (misal: Bonferroni correction).
+
+### Trap 3: "Eksperimen kami gagal karena H0 tidak ditolak"
+
+Hipotesis yang tidak ditolak bukan kegagalan — ia temuan. Temuan bahwa "metode A tidak lebih baik dari metode B pada kondisi tertentu" sama validnya dengan temuan bahwa "metode A lebih baik." Yang penting adalah eksperimennya dirancang dengan benar dan memiliki statistical power yang memadai. Jika power rendah (sampel terlalu kecil), maka gagal menolak H0 mungkin karena kurangnya power — bukan karena benar-benar tidak ada efek.
+
+### Trap 4: "Baseline dari paper asli sudah cukup"
+
+Mengambil angka hasil dari paper lain sebagai baseline tanpa mereplikasinya sendiri sangat berisiko. Kondisi eksperimen di paper asli mungkin berbeda: versi dataset, preprocessing, split, hardware, bahkan versi library. Baseline harus dijalankan ulang pada kondisi identik dengan eksperimen yang dilakukan — bukan disalin dari tabel paper lain.
+
+---
+
+## 7.8 Studi Kasus
+
+### Kasus 1 (Basic): "Eksperimen Tanpa Kontrol — Semua Variabel Berubah"
+
+**Konteks:**
+
+Seorang peneliti membandingkan sistem chatbot versi lama (berbasis rule-based) dengan versi baru (berbasis GPT fine-tuned). Klaim: "Chatbot berbasis GPT memiliki kepuasan pengguna 35% lebih tinggi dari chatbot berbasis rule." Eksperimen melibatkan 40 pengguna.
+
+**❌ Pendekatan Salah:**
+
+Versi lama diuji 6 bulan yang lalu dengan 20 pengguna (karyawan internal). Versi baru diuji minggu lalu dengan 20 pengguna berbeda (campuran karyawan dan mahasiswa). Survei kepuasan menggunakan skala dan pertanyaan yang berbeda. UI chatbot versi baru juga sudah di-redesign.
+
+Mengapa salah: setidaknya empat variabel berubah bersamaan — model (rule vs GPT), pengguna (internal vs campuran), waktu (6 bulan lalu vs sekarang), instrument survei (pertanyaan berbeda), dan UI (desain berbeda). Perbedaan 35% tidak bisa diatribusikan ke model chatbot.
+
+**✅ Pendekatan Benar:**
+
+Desain eksperimen terkontrol:
+- **Partisipan:** 40 pengguna yang sama, diacak jadi dua kelompok (20 rule-based, 20 GPT), atau within-subject design di mana setiap pengguna mencoba kedua versi (dengan counterbalancing).
+- **UI identik:** Kedua versi menggunakan interface yang sama — hanya backend (model) yang berbeda.
+- **Waktu:** Kedua kondisi diuji pada periode yang sama.
+- **Survei identik:** Pertanyaan, skala, dan urutan yang sama untuk kedua kondisi.
+- **Variabel kontrol:** Skenario percakapan yang sama (5 pertanyaan standar dari domain yang konsisten).
+
+Hasil: kepuasan pengguna GPT 72/100 vs rule-based 58/100. Perbedaan 14 poin bisa diatribusikan ke model karena semua variabel lain dikontrol.
+
+**Perbandingan:**
+
+| Aspek | Bad | Good |
+|-------|-----|------|
+| **Variabel yang berubah** | ≥ 4 (model, user, waktu, UI, survei) | 1 (model saja) |
+| **Partisipan** | Kelompok berbeda, waktu berbeda | Sama atau comparable, randomized |
+| **Instrumen** | Survei berbeda | Survei identik |
+| **Atribusi** | Tidak bisa diatribusikan | Jelas: efek model |
+
+**Pelajaran:** Eksperimen tanpa kontrol bisa menghasilkan angka — tapi angka tanpa kontrol adalah cerita tanpa dasar. Setiap klaim kausal membutuhkan isolasi variabel.
+
+---
+
+### Kasus 2 (Advanced): "Baseline Tidak Fair — Perbandingan yang Bias"
+
+**Konteks:**
+
+Sebuah paper mengklaim bahwa "model deteksi intrusi berbasis Transformer outperform Random Forest dan SVM pada dataset CICIDS-2017." Tabel hasil menunjukkan: Transformer 96.3%, Random Forest 89.1%, SVM 84.5%. Sekilas, buktinya meyakinkan.
+
+**❌ Pendekatan Salah:**
+
+Pada pemeriksaan lebih lanjut:
+- Transformer menggunakan feature engineering yang di-custom (30 fitur tambahan berbasis temporal flow)
+- Random Forest dan SVM menggunakan fitur default dari dataset (hanya 15 fitur dasar)
+- Transformer di-tune menggunakan Bayesian optimization (100 trial)
+- Random Forest menggunakan default hyperparameter scikit-learn
+- SVM menggunakan parameter dari paper 2015
+
+Perbandingan ini tidak adil. Transformer mendapat fitur lebih banyak, tuning lebih intensif, dan konfigurasi lebih modern. Angka 96.3% mungkin sepenuhnya disebabkan oleh fitur tambahan dan tuning — bukan oleh arsitektur Transformer.
+
+**✅ Pendekatan Benar:**
+
+Perbandingan yang fair:
+
+| Kondisi | Model | Fitur | Tuning | Akurasi |
+|---------|-------|-------|--------|---------|
+| V1a | Transformer | 15 fitur dasar | Grid search (50 trial) | 91.2% |
+| V1b | Random Forest | 15 fitur dasar | Grid search (50 trial) | 90.8% |
+| V1c | SVM | 15 fitur dasar | Grid search (50 trial) | 88.4% |
+| V2a | Transformer | 45 fitur (dasar + temporal) | Grid search (50 trial) | 96.3% |
+| V2b | Random Forest | 45 fitur (dasar + temporal) | Grid search (50 trial) | 94.7% |
+| V2c | SVM | 45 fitur (dasar + temporal) | Grid search (50 trial) | 91.8% |
+
+Temuan yang sebenarnya: pada fitur yang sama, perbedaan model hanya 0.4-2.8%. Peningkatan terbesar berasal dari fitur temporal (+5.1% untuk Transformer, +3.9% untuk RF). Kontribusi utama paper bergeser dari "Transformer lebih baik" menjadi "fitur temporal meningkatkan deteksi secara signifikan terlepas dari model yang digunakan."
+
+**Perbandingan:**
+
+| Aspek | Bad | Good |
+|-------|-----|------|
+| **Fitur** | Berbeda per model | Identik per perbandingan |
+| **Tuning effort** | Tidak setara | Grid search standar untuk semua |
+| **Klaim** | "Transformer outperform" (overstatement) | "Fitur temporal berkontribusi dominan" (presisi) |
+| **Scientific value** | Rendah (confounded) | Tinggi (disentangled) |
+
+**Pelajaran:** Perbandingan yang bias tidak hanya menghasilkan kesimpulan yang salah — ia juga menyia-nyiakan kesempatan untuk menemukan kontribusi yang sebenarnya lebih penting dan lebih interesting dari klaim awal.
+
+---
+
+## 7.9 Template Praktis
+
+### Template: Desain Eksperimen Lengkap
+
+```
+═══════════════════════════════════════════════════════════════
+  DESAIN EKSPERIMEN — [Judul Penelitian]
+═══════════════════════════════════════════════════════════════
+
+RESEARCH QUESTION:
+  [Tulis RQ lengkap]
+
+HIPOTESIS:
+  H0: [Tidak ada perbedaan signifikan antara... pada metrik...]
+  H1: [Ada perbedaan signifikan antara... pada metrik...]
+
+TIPE EKSPERIMEN:
+  [Comparison / Ablation / Parameter Study]
+
+VARIABEL:
+  Independen : [Apa yang dimanipulasi? Berapa level?]
+  Dependen   : [Apa yang diukur? Metrik apa? Skala apa?]
+  Kontrol    : [Apa yang dijaga konstan?]
+
+SKENARIO:
+  ┌─────────────┬───────────────┬──────────────┬─────────────┐
+  │ Kondisi     │ IV            │ Kontrol      │ DV          │
+  ├─────────────┼───────────────┼──────────────┼─────────────┤
+  │ Baseline    │ [Metode A]    │ [Semua sama] │ [Metrik]    │
+  ├─────────────┼───────────────┼──────────────┼─────────────┤
+  │ Treatment 1 │ [Metode B]    │ [Semua sama] │ [Metrik]    │
+  ├─────────────┼───────────────┼──────────────┼─────────────┤
+  │ Treatment 2 │ [Metode C]    │ [Semua sama] │ [Metrik]    │
+  └─────────────┴───────────────┴──────────────┴─────────────┘
+
+BASELINE:
+  Metode: [Nama] — Sumber: [Referensi]
+  Dijalankan ulang pada kondisi identik: [Ya / Tidak — alasan]
+
+FAIRNESS CHECKLIST:
+  □ Dataset identik untuk semua kondisi
+  □ Preprocessing identik
+  □ Tuning effort setara
+  □ Hardware & environment identik
+  □ Random seed terkunci
+  □ Evaluasi metrik identik
+
+ANALISIS STATISTIK:
+  Uji: [t-test / Mann-Whitney / ANOVA / Wilcoxon / dll.]
+  Justifikasi: [Berdasarkan jenis data dan distribusi]
+  Significance level: α = [0.05 / 0.01]
+  Effect size measure: [Cohen's d / η² / dll.]
+
+THREATS TO VALIDITY:
+  Internal  : [Ancaman spesifik + mitigasi]
+  External  : [Ancaman spesifik + mitigasi]
+  Construct : [Ancaman spesifik + mitigasi]
+  Conclusion: [Ancaman spesifik + mitigasi]
+
+═══════════════════════════════════════════════════════════════
+```
+
+---
+
+## 7.10 Mindmap Ringkasan
+
+**Gambar 7.2** — Mindmap Bab 7: Experimental Design & Validity
+
+```mermaid
+mindmap
+  root(("**Bab 7**<br/>Experimental Design<br/>& Validity"))
+    ("**Experimental<br/>Validity Model**")
+      ("RQ → Hypothesis")
+      ("Variable Design")
+      ("Controlled Experiment")
+      ("Data → Analysis")
+      ("Conclusion + Validity")
+    ("**Kausalitas**")
+      ("Korelasi ≠ Kausalitas")
+      ("Kovariansi")
+      ("Temporal precedence")
+      ("Eliminasi alternatif")
+    ("**4 Validitas**")
+      ("Internal")
+      ("External")
+      ("Construct")
+      ("Conclusion")
+    ("**Tipe Eksperimen**")
+      ("Comparison Study")
+      ("Ablation Study")
+      ("Parameter Study")
+    ("**Controlled<br/>Experiment**")
+      ("Ubah satu, kontrol sisanya")
+      ("Fair comparison")
+      ("Baseline yang valid")
+    ("**Cognitive Traps**")
+      ("Signifikan ≠ penting")
+      ("Banyak ≠ kuat")
+      ("H0 tidak ditolak ≠ gagal")
+      ("Baseline paper ≠ cukup")
+```
+
+---
+
+## 7.11 Rangkuman
+
+**Poin-poin utama bab ini:**
+
+1. Eksperimen terkontrol adalah satu-satunya metode yang bisa membuktikan kausalitas. Tiga syaratnya: kovariansi, temporal precedence, dan eliminasi alternatif — ketiganya harus dipenuhi simultan.
+
+2. Empat jenis validitas — internal, external, construct, conclusion — menjaga aspek berbeda dari klaim ilmiah. Kelemahan di satu jenis bisa menginvalidasi seluruh kesimpulan.
+
+3. Tiga tipe eksperimen paling relevan di riset TI: comparison study (membandingkan pendekatan), ablation study (mengisolasi kontribusi komponen), dan parameter study (menguji sensitivitas konfigurasi).
+
+4. Prinsip "ubah satu, kontrol sisanya" bukan idealisme — ia keharusan. Tanpa isolasi variabel, tidak ada klaim kausal yang bisa dipertahankan.
+
+5. Fairness dalam perbandingan mencakup: dataset identik, preprocessing setara, tuning effort setara, environment identik, dan evaluasi metrik yang sama. Baseline yang "diperlemah" menghasilkan perbandingan yang tidak bermakna.
+
+6. Ancaman validitas harus diidentifikasi sebelum eksperimen berjalan — dan langkah mitigasi dirancang sebagai bagian dari desain, bukan ditulis sebagai formalitas di akhir paper.
+
+Bagian 2 (Measurement & Design) berakhir di sini. Tiga bab telah membangun kerangka desain lengkap: apa yang diukur (Bab 5), di mana diukur (Bab 6), dan bagaimana mendapat bukti yang valid (Bab 7). Bagian 3 melangkah ke tahap berikutnya — mengeksekusi desain yang sudah dirancang. Bab 8 terlebih dahulu merakit seluruh fondasi dan desain menjadi satu proposal yang koheren, sebelum Bab 9 mengimplementasikan sistem dan menyiapkan environment eksperimen.
+
+> *"Eksperimen bukan sekadar menjalankan sistem, tetapi membangun bukti yang dapat dipercaya."*
+
+---
+
+## 7.12 Latihan & Refleksi
+
+### Latihan 1 — Identifikasi Ancaman Validitas
+
+Pilih satu paper riset eksperimental dari bidang TI/SE. Identifikasi ancaman validitas untuk keempat jenis (internal, external, construct, conclusion). Untuk setiap ancaman, usulkan langkah mitigasi yang spesifik — bukan generik.
+
+### Latihan 2 — Desain Perbandingan yang Fair
+
+Ambil research question dari latihan Bab 4. Rancang comparison study dengan minimal dua kondisi (metode yang diusulkan vs baseline). Isi template desain eksperimen dari Section 7.9 secara lengkap. Pastikan fairness checklist terpenuhi seluruhnya.
+
+### Latihan 3 — Kausalitas vs Korelasi
+
+Untuk setiap pernyataan berikut, tentukan: apakah ini klaim kausal atau klaim korelasi? Jika korelasi, variabel confounding apa yang mungkin menjelaskan hubungan tersebut? Bagaimana mendesain eksperimen untuk mengubah korelasi ini menjadi bukti kausal?
+- (a) "Proyek dengan code review lebih ketat memiliki lebih sedikit bug."
+- (b) "Aplikasi yang menggunakan caching memiliki waktu respons lebih cepat."
+- (c) "Developer yang menghadiri training Agile menyelesaikan sprint lebih tepat waktu."
+
+### Refleksi
+
+> "Jika seseorang meragukan hasil eksperimen saya, apakah desain eksperimen saya mampu menjawab keraguan tersebut — atau justru membenarkannya?"
+
+---
+
+## Daftar Pustaka
+
+- Shadish, W. R., Cook, T. D., & Campbell, D. T. (2002). *Experimental and Quasi-Experimental Designs for Generalized Causal Inference*. Houghton Mifflin.
+- Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., & Wesslén, A. (2012). *Experimentation in Software Engineering*. Springer.
+- Creswell, J. W. (2012). *Educational Research: Planning, Conducting, and Evaluating Quantitative and Qualitative Research* (4th ed.). Pearson.
+- Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design Science in Information Systems Research. *MIS Quarterly*, 28(1), 75–105.
+- Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007). A Design Science Research Methodology for Information Systems Research. *Journal of Management Information Systems*, 24(3), 45–77.
+- Field, A. (2018). *Discovering Statistics Using IBM SPSS Statistics* (5th ed.). SAGE Publications.
+
+<!-- STATUS: 🟢 Draft Complete -->
--- a/book/bagian-3-execution/bab-08-proposal-checkpoint.md
+++ b/book/bagian-3-execution/bab-08-proposal-checkpoint.md
@ -0,0 +1,242 @@
+# Bab 8 — Proposal & Checkpoint
+
+> **Catatan:** Bab ini bersifat integratif — merangkum Bab 1–7 ke dalam proposal riset.
+> **Fase:** Transisi dari Designing ke Executing
+> **Konten Utama:** Template proposal, rubrik penilaian, peta integrasi antar-bab
+
+---
+
+## Ringkasan Bab
+
+Bab ini bukan bab konseptual baru. Ia adalah **checkpoint**: titik di mana seluruh fondasi (Bab 1–4) dan desain (Bab 5–7) dirakit menjadi satu dokumen yang koheren — proposal riset. Proposal adalah bukti bahwa peneliti memahami masalah, memiliki posisi di literatur, merumuskan pertanyaan yang tajam, memilih metrik yang valid, merancang sistem sebagai alat uji, dan mendesain eksperimen yang terkontrol. Bab ini menyediakan template, rubrik evaluasi, dan panduan untuk memastikan setiap komponen proposal terhubung secara logis.
+
+---
+
+## 8.1 Pembuka
+
+Tujuh bab telah dilalui. Bab 1 membangun mindset peneliti. Bab 2 merumuskan masalah yang terukur. Bab 3 menemukan posisi di lanskap ilmiah. Bab 4 mentransformasi gap menjadi research question, contribution statement, dan hipotesis. Bab 5 mendefinisikan metrik dan pengukuran. Bab 6 merancang sistem sebagai instrumen eksperimen. Bab 7 mendesain eksperimen terkontrol dengan validitas tinggi.
+
+Sekarang pertanyaannya: **apakah semua itu terhubung?**
+
+Sebuah proposal riset bukan kumpulan bab-bab independen yang dijejer berurutan. Ia adalah **argumen tunggal** yang mengalir dari masalah ke solusi yang direncanakan. Setiap komponen harus merujuk komponen lain: research question harus menjawab gap yang ditemukan di literatur, metrik harus mengukur variabel yang ada di hipotesis, desain sistem harus mengimplementasikan variabel tersebut, dan desain eksperimen harus mampu menghasilkan data yang menjawab research question.
+
+Jika ada satu sambungan yang putus — misalnya, metrik yang dipilih tidak mengukur variabel dalam hipotesis — seluruh proposal kehilangan koherensi. Reviewer akan langsung menyadari ketidakkonsistenan ini, bahkan jika setiap bagian secara individual terlihat baik.
+
+Bab ini menyediakan dua hal: **template proposal** yang menunjukkan struktur standar, dan **integration map** yang membantu memverifikasi bahwa setiap komponen terhubung secara logis.
+
+---
+
+## 8.2 Peta Integrasi: Bagaimana Setiap Bab Terhubung
+
+Sebelum menulis proposal, pahami dulu alur logis yang harus terjaga:
+
+```mermaid
+graph LR
+    A["🔍 <b>Problem</b><br/><i>Bab 2</i>"]
+    B["📚 <b>Gap</b><br/><i>Bab 3</i>"]
+    C["❓ <b>RQ & H</b><br/><i>Bab 4</i>"]
+    D["📏 <b>Metrik</b><br/><i>Bab 5</i>"]
+    E["🔧 <b>Sistem</b><br/><i>Bab 6</i>"]
+    F["⚙️ <b>Eksperimen</b><br/><i>Bab 7</i>"]
+
+    A -->|"Gap muncul<br/>dari problem"| B
+    B -->|"RQ menjawab<br/>gap"| C
+    C -->|"Metrik mengukur<br/>variabel di H"| D
+    D -->|"Sistem mengimple-<br/>mentasikan variabel"| E
+    E -->|"Eksperimen menguji<br/>via sistem"| F
+
+    style A fill:#FFF7ED,stroke:#EA580C,color:#7C2D12
+    style B fill:#FFEDD5,stroke:#EA580C,color:#7C2D12
+    style C fill:#FED7AA,stroke:#EA580C,color:#7C2D12
+    style D fill:#FDBA74,stroke:#EA580C,color:#FFFFFF
+    style E fill:#FB923C,stroke:#C2410C,color:#FFFFFF
+    style F fill:#EA580C,stroke:#C2410C,color:#FFFFFF
+```
+
+**Gambar 8.1** — Peta Integrasi Proposal: Setiap Bab Harus Terhubung
+
+Setiap panah di diagram ini merepresentasikan hubungan yang harus **eksplisit** di dalam proposal:
+
+| Koneksi | Pertanyaan Verifikasi | Bab Sumber |
+|---------|----------------------|------------|
+| Problem → Gap | Apakah gap muncul dari analisis literatur terhadap problem? | 2 → 3 |
+| Gap → RQ | Apakah RQ secara langsung menjawab gap yang teridentifikasi? | 3 → 4 |
+| RQ → Metrik | Apakah setiap variabel di RQ memiliki metrik yang terdefinisi? | 4 → 5 |
+| Metrik → Sistem | Apakah setiap metrik bisa diukur oleh komponen sistem? | 5 → 6 |
+| Sistem → Eksperimen | Apakah desain eksperimen menggunakan sistem sebagai instrumen? | 6 → 7 |
+
+Jika ada satu baris di tabel ini yang jawabannya "tidak" atau "tidak yakin," proposal belum siap. Kembali ke bab yang bermasalah dan perbaiki koneksinya.
+
+---
+
+## 8.3 Struktur Proposal Riset
+
+Proposal riset eksperimental di bidang TI umumnya mengikuti struktur berikut. Setiap bagian dipetakan ke bab yang relevan:
+
+### Bagian 1 — Pendahuluan (dari Bab 1 + 2)
+
+Pendahuluan membangun konteks dan menyajikan masalah. Urutan yang efektif:
+1. **Konteks domain** — Bidang apa yang diteliti dan mengapa relevan?
+2. **Fenomena/masalah** — Apa yang diamati? Apa gejalanya?
+3. **Problem statement** — Apa akar masalah yang terdiagnosis?
+4. **Urgensi** — Mengapa masalah ini harus diteliti sekarang?
+5. **Scope** — Batasan penelitian (apa yang diteliti dan tidak diteliti)
+
+Kesalahan paling umum di Pendahuluan: terlalu banyak konteks umum, terlalu sedikit presisi terhadap masalah spesifik. Pendahuluan yang baik menyempit secara progresif — dari domain luas ke masalah presisi.
+
+### Bagian 2 — Tinjauan Pustaka (dari Bab 3)
+
+Tinjauan pustaka bukan daftar ringkasan paper. Ia adalah **argumen** yang menunjukkan posisi penelitian di lanskap ilmiah:
+1. **Literature mapping** — Apa yang sudah diketahui tentang topik ini?
+2. **Comparison** — Bagaimana studi-studi sebelumnya berbeda dan serupa?
+3. **Gap identification** — Apa yang belum diteliti atau belum terjawab?
+4. **Positioning** — Di mana posisi penelitian ini relatif terhadap studi yang ada?
+
+### Bagian 3 — Research Question, Contribution & Hypothesis (dari Bab 4)
+
+Bagian ini menerjemahkan gap menjadi pertanyaan dan prediksi yang testable:
+1. **Research Question** — Pertanyaan spesifik yang akan dijawab eksperimen
+2. **Contribution Statement** — Apa yang akan diketahui dunia setelah riset selesai?
+3. **Hypothesis (H0/H1)** — Prediksi yang bisa diuji secara statistik
+
+### Bagian 4 — Metodologi (dari Bab 5 + 6 + 7)
+
+Metodologi adalah jantung proposal eksperimental:
+1. **Definisi variabel dan metrik** (Bab 5) — Apa yang diukur, dengan apa, skala apa?
+2. **Desain sistem** (Bab 6) — Arsitektur sistem sebagai alat uji, mapping ke variabel
+3. **Desain eksperimen** (Bab 7) — Skenario, baseline, fairness, kontrol variabel
+4. **Analisis statistik** — Uji apa yang akan digunakan dan mengapa?
+5. **Threats to validity** — Ancaman yang sudah diidentifikasi dan mitigasinya
+
+### Bagian 5 — Timeline & Output
+
+Timeline harus realistis dan mencakup:
+1. **Fase implementasi** — Berapa lama membangun sistem?
+2. **Fase eksperimen** — Berapa lama pengumpulan data?
+3. **Fase analisis** — Berapa lama analisis dan penulisan?
+4. **Output yang dijanjikan** — Artefak apa yang dihasilkan di setiap tahap?
+
+---
+
+## 8.4 Rubrik Evaluasi Proposal
+
+Gunakan rubrik berikut untuk self-assessment sebelum mengajukan proposal:
+
+| Kriteria | Bobot | Indikator Kuat (4) | Indikator Lemah (1) |
+|----------|-------|--------------------|--------------------|
+| **Kejelasan masalah** | 20% | Problem statement presisi, terukur, terikat konteks | Masalah terlalu umum atau ambigu |
+| **Kualitas gap** | 15% | Gap teridentifikasi dari analisis literatur sistematis | Gap tidak jelas atau hanya asumsi |
+| **Ketajaman RQ** | 15% | RQ spesifik, memiliki variabel dan metrik eksplisit | RQ terlalu luas atau tidak testable |
+| **Validitas metrik** | 15% | Metrik dijustifikasi, representatif, multi-metric | Metrik generik tanpa justifikasi |
+| **Desain eksperimen** | 20% | Terkontrol, fair, threats diidentifikasi | Tanpa kontrol, baseline tidak fair |
+| **Koherensi keseluruhan** | 15% | Semua komponen terhubung secara logis | Koneksi antar-bagian terputus |
+
+Skor ≥ 3.0 per kriteria menunjukkan proposal yang siap. Skor < 2.0 di kriteria manapun menunjukkan kelemahan fundamental yang harus diperbaiki sebelum lanjut ke eksekusi.
+
+---
+
+## 8.5 Cognitive Traps dalam Proposal
+
+### Trap 1: "Pendahuluan yang Menjual, Bukan Menjelaskan"
+
+Proposal bukan brosur produk. Kalimat seperti "penelitian ini sangat penting dan akan memberikan kontribusi besar" tanpa bukti spesifik hanya mengisi ruang. Pendahuluan yang kuat menyajikan *data*, *fakta*, dan *gap* — bukan klaim kosong tentang pentingnya penelitian.
+
+### Trap 2: "Metodologi Copy-Paste"
+
+Menulis metodologi dengan menyalin deskripsi metode dari textbook tanpa menyesuaikan dengan research question spesifik. "Penelitian ini menggunakan metode eksperimental" — lalu apa? Setiap elemen metodologi harus dijustifikasi terhadap RQ: mengapa metode *ini*, mengapa metrik *ini*, mengapa baseline *ini*.
+
+### Trap 3: "Timeline Optimis"
+
+Timeline yang mengalokasikan 2 minggu untuk implementasi dan 1 minggu untuk analisis hampir selalu unrealistic. Implementasi selalu lebih lama dari perkiraan — ada bug, ada dependency issue, ada fitur yang perlu redesign. Tambahkan buffer 30-50% dari estimasi awal.
+
+### Trap 4: "Proposal Tanpa Kemungkinan Gagal"
+
+Proposal yang menyiratkan bahwa hasilnya pasti berhasil — "metode yang diusulkan akan meningkatkan akurasi" — menunjukkan bahwa peneliti tidak memahami sifat eksperimen. Proposal yang jujur mengakui: ini yang diprediksi, ini cara mengujinya, ini kemungkinan hasilnya (termasuk kemungkinan H0 tidak ditolak).
+
+---
+
+## 8.6 Integration Checklist
+
+Sebelum menganggap proposal selesai, jawab setiap pertanyaan berikut dengan **ya** dan tunjukkan buktinya di proposal:
+
+```
+═══════════════════════════════════════════════════════════════
+  INTEGRATION CHECKLIST — Proposal Riset Eksperimental
+═══════════════════════════════════════════════════════════════
+
+KOHERENSI VERTIKAL (apakah mengalir dari atas ke bawah?):
+  □ Problem → gap yang teridentifikasi dari literatur
+  □ Gap → RQ yang secara langsung menjawab gap
+  □ RQ → hipotesis yang testable
+  □ Hipotesis → variabel yang terdefinisi
+  □ Variabel → metrik yang spesifik dan dijustifikasi
+  □ Metrik → komponen sistem yang mengukurnya
+  □ Sistem → desain eksperimen yang menggunakannya
+  □ Eksperimen → analisis statistik yang sesuai
+
+KOHERENSI HORIZONTAL (apakah konsisten di setiap level?):
+  □ Istilah variabel konsisten di seluruh dokumen
+  □ Nama metrik sama di metodologi dan di rencana analisis
+  □ Baseline yang disebut di tinjauan pustaka = baseline di eksperimen
+  □ Scope di pendahuluan = scope di metodologi
+
+KELENGKAPAN:
+  □ Setiap keputusan desain memiliki justifikasi
+  □ Threats to validity teridentifikasi dengan mitigasi spesifik
+  □ Timeline realistis dengan buffer
+  □ Output di setiap tahap terdefinisi
+
+═══════════════════════════════════════════════════════════════
+```
+
+---
+
+## 8.7 Rangkuman
+
+**Poin-poin utama bab ini:**
+
+1. Proposal riset bukan kumpulan bagian independen — ia satu argumen tunggal yang mengalir dari masalah ke rencana eksperimen. Setiap komponen harus merujuk dan terhubung dengan komponen lain.
+
+2. Peta integrasi menunjukkan enam koneksi kritis: Problem→Gap→RQ→Metrik→Sistem→Eksperimen. Satu koneksi yang putus berarti proposal belum koheren.
+
+3. Rubrik evaluasi membantu menilai kualitas proposal secara objektif sebelum diajukan. Kelemahan di satu kriteria harus diperbaiki — bukan ditutupi dengan narasi yang panjang.
+
+4. Integration checklist memverifikasi koherensi vertikal (alur logis atas-bawah) dan horizontal (konsistensi istilah dan scope di setiap level).
+
+Dengan proposal yang koheren, langkah berikutnya adalah **mengeksekusi** rencana tersebut. Bab 9 membahas bagaimana mengimplementasikan sistem dan menyiapkan environment eksperimen dengan prinsip reproducibility.
+
+> *"Proposal yang baik bukan yang paling panjang, melainkan yang paling koheren — setiap kalimat terhubung ke kalimat sebelumnya, setiap keputusan dijustifikasi oleh keputusan sebelumnya."*
+
+---
+
+## 8.8 Latihan & Refleksi
+
+### Latihan 1 — Integration Map
+
+Ambil output dari semua latihan Bab 2–7 (problem statement, gap, RQ, hipotesis, metrik, arsitektur sistem, desain eksperimen). Susun ke dalam satu dokumen proposal mengikuti struktur di Section 8.3. Setelah selesai, periksa setiap koneksi di peta integrasi (Gambar 8.1) — apakah semuanya terhubung?
+
+### Latihan 2 — Self-Assessment
+
+Evaluasi proposal dari Latihan 1 menggunakan rubrik di Section 8.4. Beri skor per kriteria dan identifikasi dua kriteria dengan skor terendah. Untuk masing-masing, buat rencana perbaikan spesifik.
+
+### Latihan 3 — Peer Review
+
+Tukar proposal dengan rekan. Gunakan integration checklist (Section 8.6) untuk mengevaluasi proposal rekan. Tandai setiap checklist item yang belum terpenuhi dan berikan rekomendasi perbaikan.
+
+### Refleksi
+
+> "Jika proposal saya dievaluasi bukan dari panjangnya, melainkan dari koherensi koneksi antar-bagian — apakah ia akan lulus?"
+
+---
+
+## Daftar Pustaka
+
+- Creswell, J. W., & Creswell, J. D. (2018). *Research Design: Qualitative, Quantitative, and Mixed Methods Approaches* (5th ed.). SAGE Publications.
+- Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., & Wesslén, A. (2012). *Experimentation in Software Engineering*. Springer.
+- Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007). A Design Science Research Methodology for Information Systems Research. *Journal of Management Information Systems*, 24(3), 45–77.
+
+---
+
+<!-- STATUS: 🟢 Draft Complete -->
+
+<!-- STATUS: ⬜ Not Started -->
--- a/book/bagian-3-execution/bab-09-implementation-environment.md
+++ b/book/bagian-3-execution/bab-09-implementation-environment.md
@ -0,0 +1,384 @@
+# Bab 9 — Implementation & Environment
+
+> **Sub-CPMK:** 3.1 — Mengimplementasikan sistem dan environment eksperimen yang reproducible
+> **CPMK:** CPMK03 — Research Execution
+> **CPL Utama:** CPL06 (Desain & pengembangan)
+> **Fase:** Executing (M9–M12)
+> **Signature Model:** Reproducible Implementation Model (Experiment Design → Implementation → Environment Setup → Execution Consistency → Reproducibility → Trustworthy Result)
+
+---
+
+## Ringkasan Bab
+
+Bab ini membahas langkah transisi dari desain ke eksekusi: mengimplementasikan sistem eksperimen dan menyiapkan environment yang reproducible. Implementasi dalam riset berbeda secara fundamental dari coding biasa — tujuannya bukan menghasilkan software yang berfungsi, melainkan menciptakan instrumen pengukuran yang konsisten dan bisa direproduksi. Kita akan belajar mengelola environment (hardware, software, dependency), membedakan repeatability dari reproducibility, dan mendokumentasikan setup dengan standar yang memungkinkan siapa pun mereplikasi eksperimen.
+
+---
+
+## 9.1 Pembuka
+
+Bab 8 menghasilkan proposal yang koheren — sebuah rencana. Tapi rencana bukan eksperimen. Transisi dari desain ke eksekusi ternyata bukan sekadar "mulai coding." Ada jarak yang sering diremehkan antara "saya tahu apa yang akan saya bangun" dan "saya memiliki sistem yang siap dieksperimenkan."
+
+Jarak itu diisi oleh tiga hal: **implementasi yang konsisten**, **environment yang terkontrol**, dan **dokumentasi yang memungkinkan reproduksi**. Tanpa ketiganya, eksperimen mungkin berhasil di mesin peneliti — tapi tidak bisa diverifikasi, diulang, atau dipercaya oleh siapapun.
+
+Wohlin et al. (2012) menjelaskan bahwa dalam software engineering experiments, variasi tak terencana pada environment (versi library, konfigurasi OS, spesifikasi hardware) bisa mengubah hasil secara signifikan. Dua peneliti yang menjalankan "eksperimen yang sama" pada environment berbeda mungkin mendapat hasil berbeda — bukan karena metode berbeda, melainkan karena *infrastruktur* berbeda. Ini bukan ancaman teoretis; studi replikasi di machine learning secara konsisten menunjukkan bahwa reproduksi hasil lebih sulit dari yang diasumsikan.
+
+Pertanyaan sentral bab ini: **Bagaimana memastikan bahwa eksperimen yang "berhasil" di mesin kita bisa direproduksi oleh siapa pun, kapan pun, di mana pun?**
+
+---
+
+## 9.2 Reproducible Implementation Model
+
+Model ini menunjukkan bahwa trustworthy result bukan hanya produk dari desain eksperimen yang baik — ia juga produk dari implementasi dan environment yang terkontrol.
+
+**Gambar 9.1** — Reproducible Implementation Model
+
+```mermaid
+graph LR
+    A["📋 <b>Experiment<br/>Design</b><br/><i>Rencana dari Bab 7</i>"]
+    B["💻 <b>Implementation</b><br/><i>Kode & sistem</i>"]
+    C["🖥️ <b>Environment<br/>Setup</b><br/><i>HW, SW, dependency</i>"]
+    D["🔄 <b>Execution<br/>Consistency</b><br/><i>Setiap run identik</i>"]
+    E["♻️ <b>Reproducibility</b><br/><i>Siapa pun bisa<br/>mengulang</i>"]
+    F["✅ <b>Trustworthy<br/>Result</b><br/><i>Hasil yang<br/>dipercaya</i>"]
+
+    A -->|"Coding"| B
+    B -->|"Konfigurasi"| C
+    C -->|"Kontrol"| D
+    D -->|"Dokumentasi"| E
+    E -->|"Verifikasi"| F
+
+    style A fill:#FFF7ED,stroke:#EA580C,color:#7C2D12
+    style B fill:#FFEDD5,stroke:#EA580C,color:#7C2D12
+    style C fill:#FED7AA,stroke:#EA580C,color:#7C2D12
+    style D fill:#FDBA74,stroke:#EA580C,color:#FFFFFF
+    style E fill:#FB923C,stroke:#C2410C,color:#FFFFFF
+    style F fill:#EA580C,stroke:#C2410C,color:#FFFFFF
+```
+
+Setiap transisi memiliki syarat:
+
+1. **Design → Implementation (Coding).** Desain eksperimen diterjemahkan menjadi kode. Setiap modul sistem harus sesuai dengan mapping variabel-ke-komponen dari Bab 6. Implementasi yang tidak sesuai desain menghasilkan eksperimen yang menguji sesuatu yang berbeda dari yang direncanakan.
+
+2. **Implementation → Environment Setup (Konfigurasi).** Kode memerlukan environment: versi Python/Java, library dependencies, GPU driver, dataset path, OS. Jika environment tidak didefinisikan secara eksplisit, eksperimen hanya bisa berjalan di mesin yang kebetulan memiliki konfigurasi serupa.
+
+3. **Environment → Execution Consistency (Kontrol).** Setiap kali eksperimen dijalankan, hasilnya harus konsisten (atau variasinya terukur). Ini memerlukan: random seed terkunci, urutan eksekusi deterministik, dan kondisi environment yang stabil.
+
+4. **Consistency → Reproducibility (Dokumentasi).** Konsistensi internal belum cukup. Agar orang lain bisa mereproduksi, dokumentasi harus lengkap: versi kode, environment spec, parameter, data, dan langkah-langkah eksekusi.
+
+5. **Reproducibility → Trustworthy Result (Verifikasi).** Hasil baru dipercaya ketika ada jaminan bahwa siapa pun yang mengikuti dokumentasi akan mendapat hasil yang sama atau sangat serupa.
+
+---
+
+## 9.3 Definisi Kunci
+
+**Repeatability**
+: Kemampuan untuk mendapatkan hasil yang sama ketika eksperimen diulang oleh **peneliti yang sama**, di **environment yang sama**, dengan **kode yang sama**. Repeatability adalah syarat minimum — jika eksperimen tidak bisa diulang sendiri, ia pasti tidak bisa direproduksi oleh orang lain.
+
+**Reproducibility**
+: Kemampuan untuk mendapatkan hasil yang sama (atau serupa) ketika eksperimen diulang oleh **peneliti berbeda**, di **environment berbeda**, mengikuti **dokumentasi yang disediakan**. Reproducibility adalah standar emas riset ilmiah (Wohlin et al., 2012).
+
+**Environment Specification**
+: Deskripsi lengkap tentang seluruh komponen infrastruktur yang diperlukan untuk menjalankan eksperimen: hardware (CPU, RAM, GPU), operating system, versi bahasa pemrograman, library dependencies (dengan versi), konfigurasi parameter, dan random seed.
+
+**Dependency**
+: Komponen eksternal (library, framework, API) yang dibutuhkan oleh kode eksperimen. Dependency yang tidak di-lock versinya adalah sumber variasi tak terkontrol — library versi baru mungkin memiliki perilaku yang berbeda dari versi yang digunakan saat eksperimen asli.
+
+---
+
+## 9.4 Konsep Inti
+
+### 9.4.1 Implementasi Riset ≠ Coding Biasa
+
+Perbedaan fundamental antara coding proyek software dan coding untuk riset terletak pada **tujuan akhir**. Proyek software bertujuan menghasilkan sistem yang berfungsi untuk pengguna. Kode riset bertujuan menghasilkan **instrumen pengukuran** yang konsisten.
+
+Konsekuensi praktis dari perbedaan ini:
+
+**Modularity bukan opsional.** Bab 6 sudah menjelaskan bahwa komponen sistem harus dipetakan ke variabel. Saat implementasi, pemetaan ini harus dipertahankan: modul preprocessing terpisah dari modul model, modul evaluasi terpisah dari modul training. Jika godaan muncul untuk "menyederhanakan" dengan menggabungkan modul — jangan. Modularitas adalah syarat untuk isolasi variabel.
+
+**Hardcoded parameter adalah musuh.** Setiap parameter eksperimen — learning rate, batch size, jumlah epoch, threshold, random seed — harus disimpan di config file, bukan di dalam kode. Perubahan konfigurasi tidak boleh memerlukan perubahan kode. Ini bukan tentang "clean code"; ini tentang kemampuan menjalankan eksperimen dengan kondisi berbeda tanpa risiko memperkenalkan bug.
+
+**Logging bukan afterthought.** Sistem harus mencatat: input yang diterima, parameter yang digunakan, output yang dihasilkan, waktu eksekusi, dan environment info. Tanpa log, debugging hasil yang aneh menjadi tebak-tebakan.
+
+### 9.4.2 Environment Control: Hardware, Software, Dependency
+
+Environment adalah segalanya yang mengelilingi kode — dan ia bisa mengubah hasil secara diam-diam. Beberapa sumber variasi environment yang sering diabaikan:
+
+**Versi library.** TensorFlow 2.10 dan 2.15 bisa menghasilkan hasil training yang berbeda meskipun kode dan data identik. Perubahan implementasi internal (optimizer behavior, floating point handling) yang tidak terlihat di API level bisa menyebabkan perbedaan output. Solusi: gunakan dependency lock file (`requirements.txt` dengan versi pinned, `Pipfile.lock`, `package-lock.json`).
+
+**Random seed.** Banyak proses dalam machine learning bersifat stokastik: inisialisasi weight, shuffling data, dropout. Tanpa random seed yang di-fix, dua run identik bisa menghasilkan hasil berbeda. Tapi perhatian: fix seed di satu library tidak cukup — Python, NumPy, dan framework ML masing-masing memiliki random generator sendiri. Semua harus di-set.
+
+**Hardware.** GPU yang berbeda (model berbeda, memori berbeda) bisa menghasilkan hasil floating point yang sedikit berbeda karena paralelisme dan urutan operasi. Ini biasanya tidak mengubah kesimpulan, tapi bisa menyebabkan perbedaan numerik di belakang koma. Dokumentasikan spesifikasi hardware yang digunakan.
+
+**Lingkungan OS.** Path separator, encoding default, environment variable — semua ini bisa berbeda antar OS. Kode yang berjalan di Linux mungkin gagal di Windows karena perbedaan path handling. Jika feasible, gunakan container (Docker) untuk mengisolasi environment.
+
+### 9.4.3 Repeatability vs Reproducibility: Dua Level Kepercayaan
+
+Repeatability dan reproducibility sering dicampuradukkan, padahal keduanya mengukur hal yang berbeda:
+
+**Repeatability** menjawab: "Jika saya tekan 'run' lagi sekarang, apakah hasilnya sama?" Ini paling dasar, tapi banyak eksperimen gagal di sini karena random seed tidak terkunci, data di-shuffle ulang, atau environment berubah (update library otomatis).
+
+**Reproducibility** menjawab: "Jika orang lain mengikuti instruksi saya, apakah ia bisa mendapat hasil yang sama?" Ini jauh lebih sulit karena melibatkan: apakah dokumentasi cukup lengkap? Apakah semua dependency terdaftar? Apakah data tersedia? Apakah langkah-langkah cukup rinci?
+
+Dalam praktek, prioritaskan repeatability dulu. Jika eksperimen tidak bisa diulang oleh peneliti sendiri, ia pasti tidak bisa direproduksi oleh orang lain. Setelah repeatability tercapai, tambahkan dokumentasi dan packaging untuk mencapai reproducibility.
+
+### 9.4.4 Dokumentasi: README Eksperimen sebagai Kontrak
+
+Dokumentasi eksperimen bukan formalitas — ia kontrak antara peneliti dengan komunitas ilmiah. Minimum yang harus didokumentasikan:
+
+1. **Environment specification** — Versi bahasa, library, OS, hardware
+2. **Installation steps** — Langkah-langkah dari mesin kosong sampai siap run
+3. **Data** — Di mana data tersedia, bagaimana preprocessing, format apa
+4. **Execution** — Command atau script untuk menjalankan eksperimen
+5. **Expected output** — Apa yang seharusnya muncul jika berhasil
+6. **Configuration** — Semua parameter dan cara mengubahnya
+
+Format standar: README.md di root repository eksperimen. Jika memungkinkan, sertakan script otomatis (`setup.sh`, `run_experiment.py`) yang menjalankan seluruh pipeline dengan satu command.
+
+---
+
+## 9.5 Research vs Engineering
+
+**Tabel 9.1** — Perspektif Implementasi: Engineering vs Research
+
+| Aspek | Engineering | Research |
+|-------|------------|----------|
+| **Tujuan** | Sistem yang berfungsi untuk user | Instrumen pengukuran yang konsisten |
+| **Dependency management** | Update ke versi terbaru (fitur baru, security patch) | Lock di versi spesifik (konsistensi hasil) |
+| **Testing** | Unit test, integration test, E2E test | Repeatability test (run ulang → hasil sama?) |
+| **Dokumentasi** | User guide, API docs | Environment spec, execution steps, expected output |
+| **Config** | Default yang masuk akal | Setiap parameter eksplisit dan adjustable |
+| **Kode cleanup** | Refactor, DRY, abstraksi | Hati-hati — refactor bisa mengubah perilaku |
+
+Perbedaan di baris terakhir sering diabaikan. Dalam engineering, refactoring kode untuk membuatnya lebih bersih adalah praktik baik. Dalam riset, refactoring di tengah eksperimen berbahaya — perubahan kode sekecil apa pun bisa mengubah perilaku dan menginvalidasi hasil sebelumnya. Refactor hanya sebelum eksperimen dimulai, tidak selama data dikumpulkan.
+
+---
+
+## 9.6 Research Reality
+
+### Fenomena 1 — "Berjalan di Laptop Saya"
+
+Situasi klasik: eksperimen berhasil di laptop peneliti, tapi ketika reviewer atau pembimbing mencoba mereplikasi, hasilnya berbeda — atau bahkan error. Penyebab paling umum: dependency yang tidak terdaftar (library terinstall tapi tidak ada di requirements), environment variable yang di-set manual tapi tidak didokumentasikan, atau data path yang hardcoded ke lokasi lokal.
+
+Solusi yang sederhana tapi efektif: sebelum mengklaim eksperimen berhasil, coba jalankan dari environment bersih (fresh virtual environment atau container). Jika gagal, dokumentasi belum lengkap.
+
+### Fenomena 2 — "Hasil Berubah Setelah Update Library"
+
+Seorang peneliti menjalankan eksperimen di bulan Maret dan mendapat akurasi 91%. Di bulan Juni, saat menulis laporan, ia menjalankan ulang — dan akurasi turun menjadi 88%. Setelah investigasi, ternyata library scikit-learn ter-update secara otomatis, dan implementasi internal random forest sedikit berubah. Tiga bulan kerja analisis menjadi usang karena dependency tidak di-lock.
+
+Lesson: `pip install scikit-learn` tanpa versi spesifik adalah bom waktu. Selalu gunakan `scikit-learn==1.3.2` (atau versi spesifik lainnya) di requirements.
+
+### Fenomena 3 — "Random Seed? Tidak Penting..."
+
+Banyak peneliti pemula menganggap random seed hanya mempengaruhi "sedikit." Dalam beberapa kasus memang benar — perbedaannya mungkin 0.1-0.5%. Tapi dalam kasus lain (dataset kecil, model sensitif, split yang tidak representatif), perbedaan bisa mencapai 3-5%. Jika eksperimen membandingkan dua metode dengan perbedaan 2%, dan random seed menghasilkan variasi 3%, maka kesimpulan eksperimen sepenuhnya ditentukan oleh kebetulan — bukan oleh metode.
+
+---
+
+## 9.7 Cognitive Traps
+
+### Trap 1: "Setup environment nanti saja, yang penting coding dulu"
+
+Menunda environment setup ke akhir hampir selalu berakhir dengan dokumentasi yang tidak lengkap. Jika environment dibuat dari awal (virtual environment, requirements file, config template), setiap dependency yang ditambahkan otomatis terdokumentasi. Jika dibuat di akhir, harus rekonstruksi dari ingatan — dan selalu ada yang terlewat.
+
+### Trap 2: "Kode saya sederhana, tidak perlu version control"
+
+Setiap eksperimen — sekecil apa pun — harus di-version control (Git). Bukan hanya karena backup, tapi karena *traceability*: harus bisa diketahui versi kode mana yang menghasilkan data mana. Tanpa version control, situasi "data ini dihasilkan oleh versi kode yang mana?" tidak bisa dijawab.
+
+### Trap 3: "Docker/container terlalu ribet untuk riset kecil"
+
+Benar bahwa container memiliki learning curve. Tapi untuk eksperimen yang melibatkan multiple dependencies, model training, atau interaksi dengan system-level library, container menyelesaikan mayoritas masalah reproducibility sekaligus. Investasi waktu untuk setup Docker di awal sering terbayar berkali-kali lipat saat harus mereproduksi eksperimen berbulan-bulan kemudian.
+
+### Trap 4: "Hasilnya sama persis tiga kali, pasti sudah repeatable"
+
+Tiga run yang sama belum menjamin repeatability — mungkin random seed tidak benar-benar aktif dan hasilnya deterministik secara kebetulan (contoh: cache yang menyimpan hasil sebelumnya). Uji repeatability yang benar: ubah random seed secara sadar, jalankan beberapa kali, dan verifikasi bahwa variasi hasilnya terukur dan masuk akal.
+
+---
+
+## 9.8 Studi Kasus
+
+### Kasus 1 (Basic): "Eksperimen Tidak Bisa Diulang — Dependency Hilang"
+
+**Konteks:**
+
+Seorang peneliti mengembangkan model klasifikasi teks menggunakan Python. Setelah 3 bulan pengembangan, hasilnya memuaskan (F1 82%). Saat diminta mereplikasi untuk verifikasi, ia membuat virtual environment baru dan menjalankan `pip install -r requirements.txt` — tapi script error karena library `ftfy` (digunakan untuk text cleaning) tidak ada di requirements. Setelah install manual, versi `ftfy` terbaru ternyata mengubah perilaku fungsi `fix_text()`, dan hasil preprocessing berbeda. F1 turun ke 78%.
+
+**❌ Pendekatan Salah:**
+
+Requirements file dibuat di akhir proyek dengan `pip freeze > requirements.txt` — tapi di environment kerja sehari-hari, banyak library tidak relevan juga ikut terinstall di global, sehingga requirements bloated (200+ library) dan beberapa yang kritis justru terlewat karena diinstall terpisah.
+
+**✅ Pendekatan Benar:**
+
+Dari awal, gunakan virtual environment (venv atau conda) yang dedicated untuk proyek ini. Setiap kali install library baru: (1) install di venv, (2) tambahkan ke requirements dengan versi spesifik, (3) test bahwa pipeline masih berjalan. Sebelum finalisasi, uji reproducibility: buat venv baru, install requirements, jalankan pipeline dari awal.
+
+**Perbandingan:**
+
+| Aspek | Bad | Good |
+|-------|-----|------|
+| **Requirements** | Dump di akhir, bloated, ada yang terlewat | Maintained sepanjang development, versi pinned |
+| **Virtual environment** | Global install, campur dengan proyek lain | Dedicated venv dari awal |
+| **Reproducibility test** | Tidak pernah diuji | Diuji di environment bersih sebelum finalisasi |
+
+**Pelajaran:** Reproducibility bukan tugas akhir — ia proses yang dimulai dari hari pertama implementasi.
+
+---
+
+### Kasus 2 (Advanced): "Hasil Berbeda di GPU Berbeda — Siapa yang Benar?"
+
+**Konteks:**
+
+Sebuah tim mentraining model deep learning di dua mesin: Mesin A (NVIDIA RTX 3090, CUDA 11.7, cuDNN 8.4) dan Mesin B (NVIDIA A100, CUDA 12.0, cuDNN 8.9). Kode, data, random seed, dan hyperparameter identik. Training di Mesin A menghasilkan akurasi 87.3%. Training di Mesin B menghasilkan 88.1%. Perbedaan 0.8% kecil tapi konsisten di multiple run.
+
+**❌ Pendekatan Salah:**
+
+Melaporkan 88.1% (Mesin B) karena lebih tinggi, tanpa menyebutkan bahwa hasilnya berbeda di mesin lain. Atau membuang salah satu hasil dan hanya melaporkan satu mesin.
+
+**✅ Pendekatan Benar:**
+
+Mengakui bahwa perbedaan ini adalah artefak dari hardware (floating point arithmetic, parallelism order, cuDNN algorithm selection). Melaporkan kedua hasil. Menjalankan eksperimen di kedua mesin untuk semua kondisi (treatment dan baseline) — sehingga perbandingan *relatif* tetap valid meskipun angka absolut berbeda. Mendokumentasikan spesifikasi kedua mesin dan menyebutkan variasi hardware sebagai threat to validity.
+
+**Perbandingan:**
+
+| Aspek | Bad | Good |
+|-------|-----|------|
+| **Pelaporan** | Satu angka dari satu mesin | Kedua angka, variasi didokumentasikan |
+| **Perbandingan** | Mungkin bias karena treatment dan baseline di mesin berbeda | Fair — semua kondisi dijalankan di setiap mesin |
+| **Transparency** | Hardware tidak disebut | Spesifikasi lengkap, variasi diakui |
+
+**Pelajaran:** Variasi hardware tidak bisa selalu dihilangkan — tapi bisa didokumentasikan dan dikelola. Yang penting bukan angka absolut identik, melainkan **perbandingan relatif yang konsisten** di setiap environment.
+
+---
+
+## 9.9 Template Praktis
+
+### Template: Dokumentasi Setup Eksperimen
+
+```
+═══════════════════════════════════════════════════════════════
+  EXPERIMENT SETUP DOCUMENTATION — [Judul Penelitian]
+═══════════════════════════════════════════════════════════════
+
+HARDWARE:
+  CPU    : [Model, jumlah core]
+  RAM    : [Kapasitas]
+  GPU    : [Model, VRAM] (jika digunakan)
+  Storage: [Tipe, kapasitas]
+
+SOFTWARE:
+  OS              : [Nama, versi]
+  Language        : [Python 3.x / Java x / dll.]
+  Framework       : [TensorFlow 2.x / PyTorch x.y / dll.]
+  Key libraries   : [library==versi, library==versi, ...]
+  CUDA / cuDNN    : [Versi] (jika GPU)
+
+DEPENDENCY MANAGEMENT:
+  Lock file       : [requirements.txt / Pipfile.lock / package-lock.json]
+  Container       : [Docker image tag, jika ada]
+
+CONFIGURATION:
+  Config file     : [path ke config.yaml / config.json]
+  Random seed     : [nilai]
+  Key parameters  : [list parameter kunci dan nilainya]
+
+DATA:
+  Dataset         : [Nama, versi, sumber]
+  Split           : [Train/Val/Test ratio, stratifikasi]
+  Preprocessing   : [Langkah-langkah]
+
+EXECUTION:
+  Setup command   : [pip install -r requirements.txt / docker build / dll.]
+  Run command     : [python run_experiment.py --config config.yaml]
+  Expected output : [Deskripsi output yang seharusnya muncul]
+  Expected runtime: [Estimasi per-run]
+
+VERSION CONTROL:
+  Repository      : [URL atau lokasi]
+  Commit/tag      : [Hash atau tag yang digunakan untuk eksperimen]
+
+═══════════════════════════════════════════════════════════════
+```
+
+---
+
+## 9.10 Mindmap Ringkasan
+
+**Gambar 9.2** — Mindmap Bab 9: Implementation & Environment
+
+```mermaid
+mindmap
+  root(("**Bab 9**<br/>Implementation<br/>& Environment"))
+    ("**Reproducible<br/>Implementation Model**")
+      ("Design → Implementation")
+      ("Environment Setup")
+      ("Execution Consistency")
+      ("Reproducibility")
+      ("Trustworthy Result")
+    ("**Implementasi Riset**")
+      ("≠ coding biasa")
+      ("Modular wajib")
+      ("Config-driven")
+      ("Logging dari awal")
+    ("**Environment Control**")
+      ("Library version lock")
+      ("Random seed")
+      ("Hardware spec")
+      ("Container/venv")
+    ("**Repeatability vs<br/>Reproducibility**")
+      ("Repeat: sama person, sama env")
+      ("Reproduce: beda person, beda env")
+      ("Repeat dulu, baru reproduce")
+    ("**Dokumentasi**")
+      ("README eksperimen")
+      ("Environment spec")
+      ("Execution steps")
+      ("Expected output")
+```
+
+---
+
+## 9.11 Rangkuman
+
+**Poin-poin utama bab ini:**
+
+1. Implementasi dalam riset bukan coding biasa — tujuannya menciptakan instrumen pengukuran yang konsisten, bukan software yang berfungsi. Modularitas, config-driven execution, dan logging dari awal adalah keharusan.
+
+2. Environment control mencakup: versi library (di-lock), random seed (di-set untuk semua library), hardware specification (didokumentasikan), dan OS/dependency (idealnya di-containerkan).
+
+3. Repeatability (bisa diulang sendiri) dan reproducibility (bisa diulang orang lain) adalah dua level kepercayaan yang berbeda. Capai repeatability dulu, lalu tambahkan dokumentasi untuk reproducibility.
+
+4. Dokumentasi setup eksperimen bukan formalitas akhir — ia proses yang dimulai dari hari pertama. README eksperimen harus memungkinkan siapa pun mereplikasi dari nol.
+
+5. Variasi environment (hardware, library version) bisa mengubah hasil. Yang penting bukan menghilangkan variasi sepenuhnya, melainkan mendokumentasikan dan memastikan perbandingan relatif tetap konsisten.
+
+Dengan sistem terimplementasi dan environment terkontrol, langkah berikutnya adalah menjalankan eksperimen itu sendiri. Bab 10 membahas execution plan, multiple run, data collection, dan bagaimana memastikan proses pengumpulan data menghasilkan dataset yang layak dianalisis.
+
+> *"Riset bukan hanya tentang apa yang ditemukan, tetapi apakah temuan itu bisa diverifikasi oleh siapa pun yang mengikuti langkah yang sama."*
+
+---
+
+## 9.12 Latihan & Refleksi
+
+### Latihan 1 — Setup Reproducibility
+
+Dari sistem yang dirancang di latihan Bab 6, buat dokumentasi setup eksperimen menggunakan template di Section 9.9. Pastikan setiap field terisi. Lalu minta satu rekan untuk mencoba mereplikasi setup berdasarkan dokumentasi saja (tanpa bantuan verbal) — catat di mana mereka tersandung.
+
+### Latihan 2 — Repeatability Test
+
+Jalankan eksperimen (atau latihan eksperimen) dua kali berturut-turut dengan konfigurasi identik. Bandingkan hasilnya. Jika berbeda: identifikasi penyebabnya (random seed? dependency? caching?). Jika sama: ubah random seed dan jalankan lagi — apakah variasi hasilnya masuk akal?
+
+### Latihan 3 — Dependency Audit
+
+Pilih satu proyek riset open-source dari GitHub. Evaluasi reproducibility-nya: apakah requirements lengkap? Apakah versi di-lock? Apakah ada instruksi setup yang jelas? Apakah random seed disediakan? Beri skor 1-5 untuk setiap aspek dan jelaskan alasannya.
+
+### Refleksi
+
+> "Jika laptop saya hilang besok, apakah dokumentasi yang saya miliki cukup untuk membangun ulang seluruh eksperimen dari nol?"
+
+---
+
+## Daftar Pustaka
+
+- Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., & Wesslén, A. (2012). *Experimentation in Software Engineering*. Springer.
+- Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design Science in Information Systems Research. *MIS Quarterly*, 28(1), 75–105.
+
+<!-- STATUS: 🟢 Draft Complete -->
+
+<!-- STATUS: ⬜ Not Started -->
--- a/book/bagian-3-execution/bab-10-experiment-execution.md
+++ b/book/bagian-3-execution/bab-10-experiment-execution.md
@ -0,0 +1,399 @@
+# Bab 10 — Experiment Execution & Data Collection
+
+> **Sub-CPMK:** 3.2 — Menjalankan eksperimen terkontrol dan mengumpulkan data
+> **CPMK:** CPMK03 — Research Execution
+> **CPL Utama:** CPL06 (Desain & pengembangan)
+> **Fase:** Executing (M9–M12)
+> **Signature Model:** Experiment Execution Pipeline (Design → Execution Plan → Controlled Execution → Data Collection → Data Logging → Dataset for Analysis)
+
+---
+
+## Ringkasan Bab
+
+Bab ini membahas bagaimana menjalankan eksperimen yang sudah dirancang: menyusun execution plan, memastikan konsistensi setiap run, mengumpulkan data secara sistematis, dan menyimpan log yang lengkap. Menjalankan eksperimen bukan sekadar menekan tombol "run" — ia proses terkontrol yang memerlukan perencanaan jumlah run, urutan eksekusi, mekanisme logging, dan verifikasi bahwa setiap skenario dijalankan sesuai rencana.
+
+---
+
+## 10.1 Pembuka
+
+Bab 9 menyiapkan infrastruktur: sistem terimplementasi, environment terkontrol, dependency terkunci. Sekarang saatnya menjalankan eksperimen. Dan di sinilah banyak peneliti membuat kesalahan yang tidak mereka sadari sampai tahap analisis.
+
+Kesalahan paling umum? **Single run**. Seorang peneliti menjalankan eksperimen sekali, mendapat angka, lalu melaporkannya. Tapi satu run tidak cukup untuk membuat klaim ilmiah. Hasil dari satu run bisa dipengaruhi oleh variasi stokastik (random initialization, data shuffling, non-determinisme GPU), kondisi sesaat (beban CPU saat itu, caching OS), atau kebetulan (split data yang kebetulan mudah).
+
+Wohlin et al. (2012) menjelaskan bahwa eksperimen yang valid harus dijalankan **multiple times** untuk memastikan bahwa hasilnya stabil — bukan artefak dari satu kondisi lucky. Berapa kali? Tergantung variabilitas, tapi prinsip umumnya: cukup banyak untuk menghitung statistik deskriptif yang bermakna (rata-rata, standar deviasi, confidence interval).
+
+Selain multiple run, aspek kritis lainnya adalah **data collection yang sistematis**. Data yang dikumpulkan harus lengkap (semua run tercatat), konsisten (format sama), dan traceable (setiap data point bisa ditelusuri ke run spesifik dengan konfigurasi spesifik). Jika data hilang, tidak konsisten, atau tidak bisa ditelusuri — analisis selanjutnya dibangun di atas fondasi yang rapuh.
+
+Pertanyaan sentral bab ini: **Bagaimana memastikan bahwa eksekusi eksperimen menghasilkan dataset yang valid, lengkap, dan siap dianalisis?**
+
+---
+
+## 10.2 Experiment Execution Pipeline
+
+Model ini menggambarkan alur dari desain eksperimen hingga dataset yang siap analisis.
+
+**Gambar 10.1** — Experiment Execution Pipeline
+
+```mermaid
+graph LR
+    A["📋 <b>Design</b><br/><i>Desain dari Bab 7</i>"]
+    B["📝 <b>Execution<br/>Plan</b><br/><i>Skenario & jadwal</i>"]
+    C["⚙️ <b>Controlled<br/>Execution</b><br/><i>Multiple run</i>"]
+    D["📦 <b>Data<br/>Collection</b><br/><i>Pencatatan output</i>"]
+    E["📊 <b>Data<br/>Logging</b><br/><i>ID, timestamp, param</i>"]
+    F["✅ <b>Dataset for<br/>Analysis</b><br/><i>Terstruktur & lengkap</i>"]
+
+    A -->|"Perencanaan"| B
+    B -->|"Eksekusi"| C
+    C -->|"Pencatatan"| D
+    D -->|"Strukturisasi"| E
+    E -->|"Validasi"| F
+
+    style A fill:#FFF7ED,stroke:#EA580C,color:#7C2D12
+    style B fill:#FFEDD5,stroke:#EA580C,color:#7C2D12
+    style C fill:#FED7AA,stroke:#EA580C,color:#7C2D12
+    style D fill:#FDBA74,stroke:#EA580C,color:#FFFFFF
+    style E fill:#FB923C,stroke:#C2410C,color:#FFFFFF
+    style F fill:#EA580C,stroke:#C2410C,color:#FFFFFF
+```
+
+Setiap transisi:
+
+1. **Design → Execution Plan.** Desain eksperimen (Bab 7) diterjemahkan menjadi rencana eksekusi konkret: berapa skenario, berapa run per skenario, random seed apa yang digunakan, urutan eksekusi bagaimana.
+
+2. **Execution Plan → Controlled Execution.** Setiap skenario dijalankan sesuai rencana. "Controlled" berarti: satu variabel berubah per skenario, semua variabel kontrol dijaga, environment konsisten.
+
+3. **Controlled Execution → Data Collection.** Output dari setiap run dikumpulkan: metrik yang diukur, prediksi per-sampel, waktu eksekusi, resource usage.
+
+4. **Data Collection → Data Logging.** Data mentah distrukturkan dengan metadata: run ID, timestamp, konfigurasi yang digunakan, environment info.
+
+5. **Data Logging → Dataset for Analysis.** Log divalidasi: apakah semua run tercatat? Apakah ada data yang hilang? Apakah format konsisten? Dataset yang lulus validasi siap masuk ke tahap analisis.
+
+---
+
+## 10.3 Definisi Kunci
+
+**Execution Plan**
+: Dokumen yang mendeskripsikan secara rinci bagaimana eksperimen akan dijalankan: urutan skenario, jumlah run per skenario, parameter per run, random seed per run, dan checklist pra-eksekusi. Execution plan adalah "resep" yang memastikan eksperimen berjalan secara sistematis.
+
+**Multiple Run**
+: Praktek menjalankan setiap skenario eksperimen lebih dari satu kali (dengan random seed berbeda) untuk menangkap variabilitas stokastik dan memungkinkan perhitungan statistik deskriptif (mean, std, CI). Single run tidak cukup untuk klaim ilmiah.
+
+**Data Log**
+: Catatan terstruktur dari setiap run eksperimen yang mencakup: identitas run (ID, timestamp), konfigurasi (parameter, seed), dan hasil (metrik, output). Data log harus cukup lengkap untuk merekonstruksi run secara teoritis.
+
+**Run Traceability**
+: Kemampuan untuk menghubungkan setiap data point dengan run spesifik, konfigurasi spesifik, dan code version spesifik. Tanpa traceability, data anomali tidak bisa diinvestigasi.
+
+---
+
+## 10.4 Konsep Inti
+
+### 10.4.1 Execution Plan: Dari Desain ke Jadwal Konkret
+
+Execution plan menerjemahkan desain eksperimen menjadi langkah-langkah yang bisa dieksekusi. Elemennya:
+
+**Daftar skenario.** Setiap kondisi eksperimental (baseline, treatment 1, treatment 2, dst.) didaftarkan secara eksplisit. Dari desain di Bab 7, ini sudah terdefinisi — execution plan hanya memformatnya menjadi daftar yang executable.
+
+**Jumlah run per skenario.** Berapa kali setiap skenario dijalankan? Minimum yang umum dalam riset machine learning: 5-10 run dengan random seed berbeda. Untuk eksperimen yang melibatkan subjek manusia: tergantung power analysis. Kuncinya: jumlah run harus cukup untuk menghitung standar deviasi dan confidence interval yang bermakna.
+
+**Random seed per run.** Setiap run menggunakan seed yang berbeda, tapi seed-nya didaftarkan di execution plan — bukan dipilih secara acak pada saat run. Ini memungkinkan reproduksi setiap run individu jika diperlukan.
+
+**Urutan eksekusi.** Dalam beberapa kasus, urutan bisa mempengaruhi hasil (terutama jika melibatkan caching, GPU thermal throttling, atau dataset yang berubah antar-run). Randomisasi urutan atau counterbalancing bisa mengurangi bias urutan.
+
+**Checklist pra-eksekusi.** Sebelum run pertama: (1) environment sudah di-set sesuai dokumentasi, (2) config file sesuai skenario, (3) data tersedia dan utuh, (4) logging aktif, (5) disk space cukup.
+
+### 10.4.2 Multiple Run: Mengapa Satu Run Tidak Pernah Cukup
+
+Satu run menghasilkan satu angka. Satu angka tidak memiliki distribusi, tidak memiliki variabilitas, dan tidak bisa diuji secara statistik. Pertanyaan "apakah metode A lebih baik dari metode B?" tidak bisa dijawab dari satu angka per metode.
+
+Dengan multiple run (misal 10 run per skenario), didapat:
+- **Rata-rata (mean)** — estimasi sentral dari performa
+- **Standar deviasi (std)** — seberapa besar variasi antar-run
+- **Confidence interval** — rentang di mana performa sebenarnya kemungkinan berada
+- **Uji statistik** — apakah perbedaan mean antara dua skenario signifikan atau kebetulan
+
+Contoh: Metode A menghasilkan akurasi [88.1, 87.5, 88.3, 87.9, 88.0] (mean=87.96, std=0.30). Metode B menghasilkan [87.2, 88.4, 86.8, 88.1, 87.0] (mean=87.50, std=0.70). Mean A lebih tinggi, tapi variabilitas B lebih besar. Apakah perbedaan 0.46% signifikan? Hanya uji statistik yang bisa menjawab — dan uji statistik memerlukan multiple data points.
+
+Single run? A=88.1, B=87.2. Kesimpulan naif: "A lebih baik 0.9%." Tapi jika run berikutnya A=87.5 dan B=88.4, kesimpulan terbalik. Tanpa variabilitas, angka tunggal bisa menipu.
+
+### 10.4.3 Data Logging: Apa yang Harus Dicatat
+
+Setiap run eksperimen harus menghasilkan log yang mencakup:
+
+**Identitas run:**
+- Run ID (unik, konsisten)
+- Timestamp (mulai dan selesai)
+- Skenario (baseline/treatment)
+
+**Konfigurasi:**
+- Semua parameter (termasuk yang default)
+- Random seed
+- Dataset version/path
+- Code version (commit hash)
+
+**Hasil:**
+- Metrik utama (primary metric)
+- Metrik sekunder (secondary metrics)
+- Output detail jika diperlukan (confusion matrix, prediksi per-sampel, loss curve)
+
+**Metadata eksekusi:**
+- Waktu eksekusi (training, inference)
+- Resource usage (GPU memory, CPU load)
+- Warning atau error yang muncul
+
+Format logging: strukturisasi dalam format yang mudah diproses — CSV, JSON, atau database. Hindari logging ke stdout yang kemudian di-copy-paste manual. Otomasi logging mengurangi human error dan meningkatkan konsistensi.
+
+### 10.4.4 Konsistensi Eksekusi: Menjaga Kontrol di Setiap Run
+
+Konsistensi berarti: variabel kontrol benar-benar terkontrol di setiap run. Beberapa ancaman konsistensi yang sering diabaikan:
+
+**Background processes.** Jika eksperimen mengukur waktu eksekusi, beban CPU dari aplikasi lain bisa mengubah hasil. Tutup aplikasi yang tidak diperlukan, atau bahkan lebih baik — jalankan eksperimen di mesin dedicated.
+
+**Caching.** Run pertama mungkin lebih lambat karena cold cache. Run berikutnya lebih cepat karena data sudah di-cache di memory/disk. Solusi: warming run sebelum data collection dimulai, atau flush cache antar-run.
+
+**Disk I/O variability.** Operasi yang melibatkan baca/tulis disk bisa bervariasi tergantung fragmentasi, aktivitas lain, atau jenis storage (HDD vs SSD). Jika I/O time kritis, monitor dan dokumentasikan.
+
+**Thermal throttling.** GPU yang dijalankan berkepanjangan bisa mengalami thermal throttling — menurunkan clock speed untuk menjaga temperatur. Ini memperlambat run berikutnya tanpa perubahan kode atau konfigurasi. Monitoring temperatur GPU bisa membantu mendeteksi masalah ini.
+
+---
+
+## 10.5 Research vs Engineering
+
+**Tabel 10.1** — Perspektif Eksekusi: Engineering vs Research
+
+| Aspek | Engineering | Research |
+|-------|------------|----------|
+| **Run** | Sekali jalan (deploy ke production) | Multiple run (minimal 5-10 dengan seed berbeda) |
+| **Logging** | Error log, access log | Semua parameter, semua metrik, semua metadata |
+| **Variasi** | Minimalisir (stabilitas) | Tangkap (ukur variabilitas) |
+| **Urutan** | Tidak penting | Bisa bias — randomisasi/counterbalancing |
+| **Anomali** | Bug → fix → redeploy | Investigasi → dokumentasi → analisis |
+
+Perbedaan kritis pada penanganan anomali: dalam engineering, anomali adalah bug yang harus diperbaiki. Dalam riset, anomali bisa menjadi **temuan** — data yang tidak sesuai ekspektasi mungkin mengungkap sesuatu yang menarik tentang hipotesis atau desain eksperimen.
+
+---
+
+## 10.6 Research Reality
+
+### Fenomena 1 — "Run Sekali, Langsung Laporan"
+
+Ini mungkin masalah paling umum di riset TI: peneliti menjalankan eksperimen satu kali, mendapat angka, langsung memasukkannya ke tabel hasil. Tidak ada standar deviasi, tidak ada confidence interval, tidak ada uji statistik. Reviewer mendapat tabel dengan angka-angka tanpa konteks variabilitas — dan tidak bisa menilai apakah perbedaan yang terlihat bermakna atau kebetulan.
+
+### Fenomena 2 — "Log Hilang, Data Tidak Bisa Ditelusuri"
+
+Situasi: analisis menunjukkan satu run yang anomali (jauh lebih rendah dari rata-rata). Apakah ini outlier yang legitimate? Atau ada kesalahan konfigurasi di run tersebut? Tanpa log yang lengkap — parameter, seed, timestamp, environment — pertanyaan ini tidak bisa dijawab. Dan tanpa jawaban, keputusan untuk menyertakan atau mengecualikan data point tersebut menjadi arbitrary.
+
+### Fenomena 3 — "Eksperimen Marathon: 72 Jam Non-stop"
+
+Beberapa peneliti menjalankan seluruh eksperimen (semua skenario, semua run) dalam satu session panjang tanpa checkpoint. Jika crash di jam ke-60, data dari 60 jam sebelumnya mungkin hilang atau tidak bisa digunakan karena tidak di-save. Eksperimen harus di-checkpoint secara berkala — simpan hasil per-run segera setelah selesai, bukan setelah semua run selesai.
+
+---
+
+## 10.7 Cognitive Traps
+
+### Trap 1: "Satu angka sudah cukup meyakinkan"
+
+Satu angka tanpa distribusi tidak pernah cukup. Akurasi 91% dari satu run bisa menjadi 88% di run berikutnya — atau 94%. Tanpa multiple run, tidak diketahui apakah 91% itu titik tengah, ujung atas, atau ujung bawah dari distribusi performa sebenarnya. Selalu laporkan mean ± std (atau confidence interval).
+
+### Trap 2: "Random seed tidak penting untuk algoritma deterministik"
+
+Bahkan algoritma yang terlihat deterministik bisa memiliki komponen stokastik yang tersembunyi: urutan iterasi, threading, floating point accumulation order. Dan meskipun algoritmanya benar-benar deterministik, data split biasanya stokastik. Variasi split → variasi hasil. Uji dengan multiple seed tetap diperlukan.
+
+### Trap 3: "Run yang gagal bisa dihapus saja"
+
+Run yang gagal (error, crash, anomali) tidak boleh dihapus tanpa dokumentasi. Jika dihapus, dataset menjadi bias (hanya menyimpan run yang "berhasil"). Jika gagal karena bug, dokumentasikan dan re-run setelah fix. Jika gagal karena alasan legitimate (out of memory, timeout), dokumentasikan sebagai informasi tentang batas kemampuan metode.
+
+### Trap 4: "Semua run harus dilakukan hari ini"
+
+Menjalankan 30 run dalam satu hari di satu mesin bisa terkena thermal throttling, resource contention, atau kelelahan (jika melibatkan human judgment). Lebih baik membagi run ke beberapa sesi — selama environment dan konfigurasi tetap identik di setiap sesi.
+
+---
+
+## 10.8 Studi Kasus
+
+### Kasus 1 (Basic): "Single Run — Angka Tanpa Makna Statistik"
+
+**Konteks:**
+
+Sebuah paper melaporkan perbandingan tiga model NLP (BERT, LSTM, SVM) pada task klasifikasi review. Tabel hasil menunjukkan: BERT F1=89.2%, LSTM F1=85.7%, SVM F1=82.1%. Kesimpulan: "BERT secara signifikan lebih baik dari LSTM dan SVM."
+
+**❌ Pendekatan Salah:**
+
+Setiap model hanya dijalankan 1 kali. Tidak ada standar deviasi. Tidak ada uji statistik. Kata "signifikan" digunakan secara informal (bukan statistical significance). Reviewer tidak bisa menilai apakah perbedaan 3.5% (BERT vs LSTM) bermakna atau artefak dari satu data split tertentu.
+
+**✅ Pendekatan Benar:**
+
+Setiap model dijalankan 10 kali dengan random seed berbeda (seed 1-10, didaftarkan di execution plan). Hasil:
+
+| Model | Mean F1 | Std | 95% CI |
+|-------|---------|-----|--------|
+| BERT | 88.4% | 1.2% | [87.5, 89.3] |
+| LSTM | 86.1% | 1.8% | [84.8, 87.4] |
+| SVM | 82.3% | 0.9% | [81.7, 82.9] |
+
+Uji statistik (paired t-test atau Wilcoxon): BERT vs LSTM p=0.03 (signifikan). BERT vs SVM p<0.001 (signifikan). LSTM vs SVM p=0.001 (signifikan). Effect size dilaporkan.
+
+Kesimpulan lebih nuanced: "BERT mengungguli LSTM (p=0.03, Cohen's d=1.5) dan SVM (p<0.001, d=6.9), meskipun perbedaan BERT-LSTM relatif kecil (2.3%) dengan overlap confidence interval."
+
+**Pelajaran:** Multiple run mengubah "A lebih besar dari B" menjadi "A secara statistik lebih baik dari B dengan effect size tertentu" — klaim yang jauh lebih kuat dan jujur.
+
+---
+
+### Kasus 2 (Advanced): "Data Yang Hilang — Run Tidak Terdokumentasi"
+
+**Konteks:**
+
+Seorang peneliti menjalankan 20 run untuk eksperimen benchmark. Di tengah proses, 3 run crash karena GPU out of memory. Peneliti menjalankan ulang 3 run tersebut, tapi menggunakan batch size lebih kecil agar tidak crash. Hasil akhir: 20 run lengkap. Tapi 3 di antaranya menggunakan batch size berbeda dari 17 lainnya.
+
+**❌ Pendekatan Salah:**
+
+Tidak didokumentasikan bahwa 3 run menggunakan batch size berbeda. Semua 20 data point dicampur dan dihitung rata-rata. Batch size yang berbeda mungkin menghasilkan model yang sedikit berbeda — mencampurkan hasil dari dua konfigurasi berbeda menginvalidasi statistik.
+
+**✅ Pendekatan Benar:**
+
+Dokumentasikan masalah secara transparan. Opsi: (a) buang 3 run anomali dan hanya laporkan 17 run yang konsisten, (b) jalankan ulang semua 20 run dengan batch size yang lebih kecil (konsisten), atau (c) laporkan kedua set secara terpisah dan analisis efek batch size. Opsi manapun yang dipilih, justifikasi keputusan dan dokumentasikan anomali.
+
+**Perbandingan:**
+
+| Aspek | Bad | Good |
+|-------|-----|------|
+| **Dokumentasi** | Anomali tidak dicatat | Semua anomali terdokumentasi |
+| **Konsistensi** | 3 run dengan config berbeda dicampur | Config identik, atau dipisah |
+| **Transparansi** | Pembaca tidak tahu ada masalah | Masalah diakui dan ditangani |
+
+**Pelajaran:** Transparency bukan kelemahan — ia menunjukkan rigor. Menyembunyikan anomali untuk membuat data "terlihat bersih" merusak integritas riset.
+
+---
+
+## 10.9 Template Praktis
+
+### Template: Execution Plan & Data Log
+
+```
+═══════════════════════════════════════════════════════════════
+  EXECUTION PLAN — [Judul Penelitian]
+═══════════════════════════════════════════════════════════════
+
+SKENARIO EKSPERIMEN:
+  ┌─────────────┬────────────┬────────────┬──────────────────┐
+  │ ID Skenario │ Kondisi IV │ Jumlah Run │ Seeds            │
+  ├─────────────┼────────────┼────────────┼──────────────────┤
+  │ S1-baseline │ [Metode A] │ 10         │ [42,43,...,51]   │
+  ├─────────────┼────────────┼────────────┼──────────────────┤
+  │ S2-treatment│ [Metode B] │ 10         │ [42,43,...,51]   │
+  └─────────────┴────────────┴────────────┴──────────────────┘
+
+PRE-EXECUTION CHECKLIST:
+  □ Environment sesuai dokumentasi Bab 9
+  □ Config file sesuai skenario
+  □ Dataset tersedia dan checksum terverifikasi
+  □ Logging aktif dan output path terdefinisi
+  □ Disk space cukup untuk semua run
+  □ Background processes diminimalkan
+
+DATA LOG FORMAT (per run):
+  ┌──────────┬────────────┬───────┬──────────┬──────────────┐
+  │ Run ID   │ Scenario   │ Seed  │ Metrik   │ Timestamp    │
+  ├──────────┼────────────┼───────┼──────────┼──────────────┤
+  │ R001     │ S1-baseline│ 42    │ [nilai]  │ [datetime]   │
+  ├──────────┼────────────┼───────┼──────────┼──────────────┤
+  │ R002     │ S1-baseline│ 43    │ [nilai]  │ [datetime]   │
+  └──────────┴────────────┴───────┴──────────┴──────────────┘
+
+POST-EXECUTION CHECKLIST:
+  □ Semua run tercatat (tidak ada yang hilang)
+  □ Format data konsisten di semua run
+  □ Anomali didokumentasikan
+  □ Backup data sudah dibuat
+
+═══════════════════════════════════════════════════════════════
+```
+
+---
+
+## 10.10 Mindmap Ringkasan
+
+**Gambar 10.2** — Mindmap Bab 10: Experiment Execution & Data Collection
+
+```mermaid
+mindmap
+  root(("**Bab 10**<br/>Experiment Execution<br/>& Data Collection"))
+    ("**Execution Pipeline**")
+      ("Design → Plan")
+      ("Plan → Execution")
+      ("Execution → Collection")
+      ("Collection → Logging")
+      ("Logging → Dataset")
+    ("**Multiple Run**")
+      ("≥ 5-10 run per skenario")
+      ("Seed berbeda per run")
+      ("Mean, std, CI")
+      ("Uji statistik")
+    ("**Data Logging**")
+      ("Run ID & timestamp")
+      ("Full configuration")
+      ("Semua metrik")
+      ("Execution metadata")
+    ("**Konsistensi**")
+      ("Background processes")
+      ("Caching effects")
+      ("Thermal throttling")
+      ("Checkpoint per run")
+    ("**Cognitive Traps**")
+      ("Single run ≠ bukti")
+      ("Run gagal ≠ dihapus")
+      ("Marathon ≠ efisien")
+```
+
+---
+
+## 10.11 Rangkuman
+
+**Poin-poin utama bab ini:**
+
+1. Execution plan menerjemahkan desain eksperimen menjadi langkah-langkah konkret: daftar skenario, jumlah run, random seed per run, dan urutan eksekusi.
+
+2. Single run tidak pernah cukup untuk klaim ilmiah. Multiple run (5-10 minimum) memungkinkan perhitungan statistik deskriptif dan pengujian signifikansi.
+
+3. Data logging harus mencakup identitas (run ID, timestamp), konfigurasi (semua parameter, seed, code version), dan hasil (semua metrik, output detail). Log harus otomatis dan terstruktur.
+
+4. Konsistensi eksekusi memerlukan kontrol terhadap faktor-faktor yang bisa mempengaruhi hasil: background processes, caching, thermal throttling, dan disk I/O.
+
+5. Anomali dan run yang gagal harus didokumentasikan — bukan dihapus. Transparansi menunjukkan rigor, bukan kelemahan.
+
+Dengan dataset yang lengkap dan terdokumentasi, langkah berikutnya adalah memastikan data tersebut valid dan layak dianalisis. Bab 11 membahas proses validasi data dan mekanisme untuk membangun kepercayaan terhadap dataset eksperimen.
+
+> *"Eksperimen bukan tombol 'run' yang ditekan sekali. Ia proses terkontrol yang memerlukan perencanaan, repetisi, dan dokumentasi di setiap langkah."*
+
+---
+
+## 10.12 Latihan & Refleksi
+
+### Latihan 1 — Execution Plan
+
+Buat execution plan lengkap untuk eksperimen dari latihan Bab 7. Tentukan: jumlah skenario, jumlah run per skenario, random seed per run, urutan eksekusi, dan pre-execution checklist. Pastikan plan cukup rinci untuk diikuti oleh orang lain tanpa penjelasan verbal.
+
+### Latihan 2 — Multiple Run Analysis
+
+Jalankan satu pipeline sederhana (misal: classifier di dataset publik) 10 kali dengan random seed 1-10. Hitung mean, std, dan 95% confidence interval. Bandingkan: apakah kesimpulan dari run tunggal (seed=1) sama dengan kesimpulan dari 10 run?
+
+### Latihan 3 — Data Log Design
+
+Rancang skema data log untuk eksperimen dari Latihan 1. Tentukan: kolom apa saja, format data, tempat penyimpanan, dan mekanisme otomasi. Implementasikan logging otomatis menggunakan bahasa yang relevan.
+
+### Refleksi
+
+> "Jika saya hanya punya waktu untuk satu hal ekstra di eksperimen saya — multiple run atau dokumentasi yang lebih baik — mana yang akan saya pilih, dan mengapa?"
+
+---
+
+## Daftar Pustaka
+
+- Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., & Wesslén, A. (2012). *Experimentation in Software Engineering*. Springer.
+- Field, A. (2018). *Discovering Statistics Using IBM SPSS Statistics* (5th ed.). SAGE Publications.
+- Shadish, W. R., Cook, T. D., & Campbell, D. T. (2002). *Experimental and Quasi-Experimental Designs for Generalized Causal Inference*. Houghton Mifflin.
+
+<!-- STATUS: 🟢 Draft Complete -->
+
+<!-- STATUS: ⬜ Not Started -->
--- a/book/bagian-3-execution/bab-11-data-validation.md
+++ b/book/bagian-3-execution/bab-11-data-validation.md
@ -0,0 +1,391 @@
+# Bab 11 — Data Validation & Integrity
+
+> **Sub-CPMK:** 3.3 — Memvalidasi data eksperimen dan memastikan integritas dataset
+> **CPMK:** CPMK03 — Research Execution
+> **CPL Utama:** CPL06 (Desain & pengembangan)
+> **Fase:** Executing (M9–M12)
+> **Signature Model:** Data Trust Model (Raw Data → Data Cleaning → Consistency Check → Validation Process → Trusted Data)
+
+---
+
+## Ringkasan Bab
+
+Bab ini membahas proses memastikan bahwa data yang dikumpulkan dari eksperimen layak dianalisis. Data mentah tidak serta-merta bisa langsung dimasukkan ke analisis — ia perlu divalidasi: apakah formatnya konsisten? Apakah ada data yang hilang? Apakah nilainya masuk akal? Apakah data sesuai dengan desain eksperimen? Validasi data adalah garis pertahanan terakhir sebelum analisis — jika data yang masuk ke analisis cacat, semua kesimpulan yang dihasilkan turut cacat.
+
+---
+
+## 11.1 Pembuka
+
+Bab 10 menghasilkan dataset mentah: kumpulan log dari setiap run eksperimen, lengkap dengan metrik, parameter, dan metadata. Sekarang pertanyaannya: **apakah data ini bisa dipercaya?**
+
+"Bisa dipercaya" bukan soal apakah hasilnya sesuai harapan — ini bukan tentang validasi hipotesis. Validasi data adalah tentang memastikan bahwa data tersebut **akurat, konsisten, lengkap, dan valid** sebelum digunakan untuk perhitungan statistik apa pun.
+
+Mengapa tahap ini diperlukan? Beberapa skenario nyata:
+
+- Satu run menghasilkan akurasi 0.001 — kemungkinan besar error, bukan performa model yang sebenarnya. Tanpa validasi, angka ini masuk ke rata-rata dan mendistorsi hasilnya.
+- Log dari 2 run ternyata memiliki format kolom yang berbeda karena perubahan script di tengah eksperimen. Penggabungan langsung menghasilkan data yang salah alignment.
+- Dari 30 planned run, hanya 28 yang ada di log. Dua run hilang tanpa penjelasan.
+
+Han et al. (2012) mengidentifikasi empat pilar kualitas data: **accuracy, consistency, completeness, dan validity**. Keempat pilar ini menjadi kerangka kerja untuk validasi data eksperimen. Bab ini menerjemahkan kerangka tersebut menjadi proses konkret yang bisa diterapkan pada dataset hasil eksperimen.
+
+Pertanyaan sentral bab ini: **Bagaimana memastikan bahwa dataset eksperimen layak dipercaya dan siap dianalisis?**
+
+---
+
+## 11.2 Data Trust Model
+
+Model ini menggambarkan alur dari data mentah menuju data yang layak dipercaya untuk analisis.
+
+**Gambar 11.1** — Data Trust Model
+
+```mermaid
+graph LR
+    A["📥 <b>Raw Data</b><br/><i>Log eksperimen</i>"]
+    B["🧹 <b>Data<br/>Cleaning</b><br/><i>Format & missing</i>"]
+    C["🔗 <b>Consistency<br/>Check</b><br/><i>Antar-run & antar-file</i>"]
+    D["✔️ <b>Validation<br/>Process</b><br/><i>4 pilar kualitas</i>"]
+    E["✅ <b>Trusted<br/>Data</b><br/><i>Siap analisis</i>"]
+
+    A -->|"Pembersihan"| B
+    B -->|"Pengecekan"| C
+    C -->|"Validasi"| D
+    D -->|"Sertifikasi"| E
+
+    style A fill:#FFF7ED,stroke:#EA580C,color:#7C2D12
+    style B fill:#FFEDD5,stroke:#EA580C,color:#7C2D12
+    style C fill:#FED7AA,stroke:#EA580C,color:#7C2D12
+    style D fill:#FB923C,stroke:#C2410C,color:#FFFFFF
+    style E fill:#EA580C,stroke:#C2410C,color:#FFFFFF
+```
+
+Setiap transisi:
+
+1. **Raw Data → Data Cleaning.** Data mentah dari log eksperimen dibaca dan dibersihkan: parsing format, penanganan missing values, normalisasi tipe data. Tujuannya bukan mengubah data — melainkan memastikan data bisa dibaca dan diproses secara konsisten.
+
+2. **Data Cleaning → Consistency Check.** Data yang sudah bersih diperiksa konsistensinya: apakah semua run memiliki kolom yang sama? Apakah jumlah data point sesuai dengan jumlah planned run? Apakah ada duplikasi?
+
+3. **Consistency Check → Validation Process.** Data yang konsisten divalidasi terhadap empat pilar: apakah nilainya akurat (range), apakah format konsisten, apakah data lengkap, apakah data valid secara logis.
+
+4. **Validation Process → Trusted Data.** Data yang lulus validasi "disertifikasi" sebagai trusted — siap digunakan untuk analisis statistik. Anomali yang terdeteksi didokumentasikan, bukan dihapus.
+
+---
+
+## 11.3 Definisi Kunci
+
+**Accuracy (Akurasi Data)**
+: Sejauh mana nilai data mencerminkan nilai sebenarnya. Metrik per-run harus berada dalam rentang yang masuk akal. Akurasi klasifikasi di luar [0, 1] jelas error. Waktu eksekusi negatif jelas error. Validasi akurasi mendeteksi data yang jelas salah.
+
+**Consistency (Konsistensi Data)**
+: Keseragaman format, skala, dan representasi data di seluruh dataset. Semua run harus menggunakan format yang sama (jumlah kolom, tipe data, satuan). Inkonsistensi biasanya menandakan perubahan script atau konfigurasi di tengah eksperimen.
+
+**Completeness (Kelengkapan Data)**
+: Apakah semua data yang direncanakan benar-benar ada. Jika execution plan menyatakan 30 run, apakah ada 30 entry di log? Missing data harus diidentifikasi dan alasannya didokumentasikan.
+
+**Validity (Validitas Logis)**
+: Apakah data konsisten secara logis dengan desain eksperimen. Misalnya: apakah run untuk skenario "baseline" menggunakan parameter baseline (bukan treatment)? Apakah seed yang tercatat sesuai dengan yang direncanakan di execution plan?
+
+---
+
+## 11.4 Konsep Inti
+
+### 11.4.1 Empat Pilar Data Quality
+
+Han et al. (2012) mengidentifikasi accuracy, consistency, completeness, dan validity sebagai dimensi utama kualitas data. Dalam konteks eksperimen riset TI:
+
+**Accuracy** — setiap data point berada dalam range yang masuk akal. Cara memeriksa: definisikan expected range untuk setiap metrik sebelum eksperimen. Akurasi klasifikasi: [0, 1]. Waktu respons: > 0 ms. F1-score: [0, 1]. Loss: ≥ 0 (untuk kebanyakan loss function). Nilai di luar range → flag untuk investigasi.
+
+**Consistency** — format identik di semua run. Cara memeriksa: load semua file log, bandingkan schema (nama kolom, jumlah kolom, tipe data). Jika ada perbedaan, identifikasi kapan perubahan terjadi dan mengapa. Perbedaan format biasanya berarti ada perubahan script di tengah eksperimen — yang merupakan pelanggaran konsistensi eksekusi.
+
+**Completeness** — tidak ada data yang hilang. Cara memeriksa: bandingkan jumlah run di log dengan jumlah di execution plan. Untuk setiap run, periksa apakah semua kolom terisi (bukan null/NaN). Missing data perlu ditandai: apakah structurally missing (run tidak jalan) atau randomly missing (run jalan tapi kolom tertentu tidak tercatat)?
+
+**Validity** — data sesuai dengan desain eksperimen. Cara memeriksa: cross-reference setiap run dengan execution plan. Apakah parameter yang tercatat sesuai skenario? Apakah seed sesuai rencana? Apakah dataset yang digunakan benar? Validitas logis menangkap error yang tidak terdeteksi oleh tiga pilar lainnya.
+
+### 11.4.2 Proses Validasi: Format → Range → Consistency → Logic
+
+Validasi data bukanlah satu langkah — ia urutan pemeriksaan yang progresif:
+
+**Langkah 1: Format validation.** Apakah file bisa dibaca? Apakah parsing berhasil? Apakah jumlah kolom benar? Ini langkah paling dasar — jika gagal di sini, tidak perlu lanjut.
+
+**Langkah 2: Range validation.** Apakah setiap nilai numerik berada dalam range yang masuk akal? Definisikan range per metrik dan flag semua nilai di luar range. Nilai di luar range bisa berarti: (a) error logging, (b) error eksekusi, (c) outlier legitimate. Investigasi diperlukan untuk membedakan ketiganya.
+
+**Langkah 3: Consistency validation.** Apakah semua run memiliki format yang sama? Apakah satuan konsisten? Apakah jumlah data point per run seragam? Inkonsistensi memerlukan alignment sebelum analisis.
+
+**Langkah 4: Logic validation.** Apakah data sesuai desain eksperimen? Apakah parameter per skenario benar? Apakah tidak ada run yang "terbalik" (parameter treatment digunakan di skenario baseline)? Logic validation memerlukan cross-reference dengan execution plan.
+
+### 11.4.3 Anomaly Detection: Menemukan yang Tidak Beres
+
+Anomali adalah data point yang menyimpang secara signifikan dari pola mayoritas. Dalam konteks eksperimen:
+
+**Statistical outliers** — nilai yang berada di luar 1.5×IQR (interquartile range) atau lebih dari 3 standar deviasi dari mean. Metode deteksi: box plot, z-score, atau IQR method.
+
+**Contextual anomalies** — nilai yang normal secara absolut tapi tidak normal dalam konteksnya. Contoh: waktu eksekusi 10 detik normal untuk training, tapi jika 9 run lainnya memerlukan 8 detik dan 1 run memerlukan 10 detik, perbedaan tersebut layak diinvestigasi.
+
+**Pattern anomalies** — pola yang tidak normal di seluruh dataset. Contoh: performa yang terus menurun di run berurutan (mungkin thermal throttling). Atau: performa skenario A dan B yang identik (mungkin parameter tidak berubah antara skenario).
+
+Prinsip penanganan anomali: **detect → investigate → document → decide**. Jangan langsung hapus. Investigasi penyebabnya. Dokumentasikan temuan. Baru kemudian putuskan: sertakan, eksklusi dengan justifikasi, atau re-run.
+
+### 11.4.4 Data vs Experiment Alignment
+
+Validasi terakhir — dan sering terlewat — adalah memastikan bahwa dataset yang dihasilkan benar-benar selaras dengan desain eksperimen:
+
+**Coverage check.** Apakah semua skenario yang direncanakan memiliki data? Apakah semua level variabel independen terwakili? Jika desain menyatakan 3 skenario × 10 run = 30 data point, apakah ada 30 data point?
+
+**Parameter verification.** Untuk setiap run, apakah parameter yang tercatat sesuai dengan yang seharusnya untuk skenario tersebut? Ini menangkap error konfigurasi yang tidak terdeteksi saat eksekusi.
+
+**Temporal consistency.** Apakah urutan timestamp masuk akal? Apakah ada gap waktu yang tidak bisa dijelaskan? Apakah durasi setiap run konsisten (tidak ada run yang terlalu cepat atau terlalu lambat)?
+
+**Output completeness.** Apakah setiap run menghasilkan semua output yang dibutuhkan? Jika desain mengukur 3 metrik, apakah ketiga metrik ada di setiap run? Missing metrik di beberapa run → investigasi.
+
+---
+
+## 11.5 Research vs Engineering
+
+**Tabel 11.1** — Perspektif Validasi Data: Engineering vs Research
+
+| Aspek | Engineering | Research |
+|-------|------------|----------|
+| **Tujuan validasi** | Data sesuai spesifikasi bisnis | Data layak untuk analisis statistik |
+| **Missing data** | Impute atau set default | Investigasi penyebab, dokumentasi, justifikasi |
+| **Outlier** | Mungkin bug → fix | Mungkin temuan → investigasi |
+| **Threshold** | Definisi bisnis (SLA) | Definisi statistik (IQR, z-score) |
+| **Dokumentasi** | Minimal (log error) | Komprehensif (catatan anomali + keputusan) |
+| **Penanganan** | Otomatis (retry, fallback) | Manual review + keputusan terdokumentasi |
+
+Perbedaan kunci: dalam engineering, anomali biasanya berarti "sesuatu rusak — perbaiki." Dalam riset, anomali bisa berarti "sesuatu menarik terjadi — investigasi." Membuang semua outlier tanpa investigasi sama berbahayanya dengan menyimpan semua outlier tanpa pemeriksaan.
+
+---
+
+## 11.6 Research Reality
+
+### Fenomena 1 — "Data Langsung Dianalisis, Tanpa Validasi"
+
+Skenario paling umum: peneliti menjalankan eksperimen, mengumpulkan log, langsung menghitung rata-rata dan membuat grafik. Tidak ada pengecekan format, range, atau kelengkapan. Baru ditemukan saat reviewer bertanya: "Kenapa ada 28 data point untuk skenario A tapi 30 untuk skenario B?" Jawabannya: 2 run untuk skenario A gagal dan tidak tercatat. Tapi tanpa validasi, ketidaklengkapan ini tidak terdeteksi.
+
+### Fenomena 2 — "Outlier Dihapus Demi Tabel yang Bersih"
+
+Seorang peneliti menjalankan 10 run. Sembilan menghasilkan akurasi antara 87-89%. Satu menghasilkan 72%. Peneliti menghapus run 72% karena "jelas outlier" dan melaporkan mean dari 9 run. Masalahnya: (1) tidak ada investigasi mengapa 72% terjadi — mungkin parameter salah, mungkin data shuffle yang buruk, mungkin bug, mungkin performa sebenarnya, (2) menghapus tanpa justifikasi adalah cherry-picking, (3) pembaca tidak tahu ada run yang dibuang.
+
+### Fenomena 3 — "Format Log Berubah di Tengah Eksperimen"
+
+Selama eksperimen yang berjalan beberapa hari, peneliti memperbaiki bug di script logging. Perbaikan mengubah urutan kolom dan menambah kolom baru. Setengah data menggunakan format lama, setengah menggunakan format baru. Penggabungan tanpa validasi menghasilkan misalignment — metrik yang salah masuk ke kolom yang salah. Tanpa format validation di awal, error ini baru terdeteksi (jika terdeteksi) saat analisis.
+
+---
+
+## 11.7 Cognitive Traps
+
+### Trap 1: "Data yang dikumpulkan secara otomatis pasti benar"
+
+Otomasi logging mengurangi human error, tapi tidak menjamin correctness. Script logging bisa punya bug. Format bisa berubah. Disk bisa penuh dan menyebabkan truncated output. Otomasi membantu konsistensi, bukan jaminan akurasi. Data otomatis tetap perlu divalidasi.
+
+### Trap 2: "Outlier berarti error — hapus saja"
+
+Outlier bisa berarti error (parameter salah, sistem crash), tapi juga bisa berarti fenomena yang legitimate (model gagal pada split data tertentu, kondisi boundary tertentu). Menghapus outlier tanpa investigasi berisiko menghilangkan informasi penting atau bias hasil.
+
+### Trap 3: "Validasi hanya untuk data besar — dataset kecil bisa diperiksa manual"
+
+Dataset kecil (misal 30 data point) memang bisa diperiksa secara visual. Tapi pemeriksaan visual rentan terhadap oversight — terutama untuk inkonsistensi format atau logic error. Validasi terstruktur (bahkan dengan script sederhana) lebih reliable daripada mata manusia, terlepas dari ukuran dataset.
+
+### Trap 4: "Jika rata-ratanya masuk akal, datanya pasti benar"
+
+Rata-rata bisa terlihat normal bahkan jika ada masalah serius di data. Contoh: 5 run menghasilkan [94, 95, 93, 44, 94]. Rata-rata = 84% — mungkin terlihat masuk akal untuk task tertentu. Tapi satu run (44%) jelas anomali, dan kehadirannya mendistorsi rata-rata. Statistik deskriptif (range, std) dan pemeriksaan distribusi menangkap masalah yang mean sendiri tidak bisa deteksi.
+
+---
+
+## 11.8 Studi Kasus
+
+### Kasus 1 (Basic): "Missing Run — Dataset Tidak Lengkap"
+
+**Konteks:**
+
+Sebuah eksperimen membandingkan 2 algoritma sorting pada 5 dataset berbeda. Execution plan: 2 algoritma × 5 dataset × 10 run = 100 data point. Setelah eksperimen selesai, peneliti langsung menghitung rata-rata per kondisi.
+
+**❌ Pendekatan Salah:**
+
+Tidak ada completeness check. Ternyata salah satu dataset × algoritma gagal di 3 run karena timeout (dataset terlalu besar untuk algoritma yang lambat). Hanya 7 run yang tercatat. Rata-rata dihitung dari 7 run tanpa keterangan. Perbandingan antar-algoritma menjadi tidak seimbang: satu kondisi punya 10 data point, lainnya 7.
+
+**✅ Pendekatan Benar:**
+
+Sebelum analisis, jalankan completeness check:
+
+```
+Expected: 2 × 5 × 10 = 100 data points
+Actual:   97 data points
+Missing:  3 (Algo=BubbleSort, Dataset=Large, Run 8-10)
+```
+
+Investigasi: timeout karena kompleksitas O(n²) pada dataset besar. Dokumentasikan sebagai temuan (bukan error): "BubbleSort tidak dapat menyelesaikan eksekusi pada dataset > 100K elemen dalam batas waktu 1 jam."
+
+Opsi: (a) laporkan sebagai DNF (Did Not Finish) — informasi yang berguna, (b) tambah timeout yang lebih panjang dan re-run, (c) analisis terpisah: dataset kecil-menengah (semua algoritma) dan dataset besar (hanya algoritma yang selesai).
+
+**Pelajaran:** Completeness check menangkap missing data sebelum ia mencemari analisis. Missing data yang teridentifikasi bisa menjadi temuan yang informatif.
+
+---
+
+### Kasus 2 (Advanced): "Anomali Sistematis — Bukan Random, Tapi Pola"
+
+**Konteks:**
+
+Eksperimen deep learning: 20 run dari model yang sama pada dataset yang sama. Tujuannya mengukur variabilitas performa karena random initialization. Setelah validasi, ditemukan pola: run 1-10 menghasilkan akurasi ~91%, run 11-20 menghasilkan ~88%. Bukan random: ada penurunan sistematis.
+
+**Investigasi:**
+
+Step 1 — Temporal analysis. Run 1-10 dijalankan Senin pagi. Run 11-20 dijalankan Senin sore. Apakah waktu berpengaruh?
+
+Step 2 — Environment check. Monitoring menunjukkan GPU temperature: run 1-10 pada 65°C, run 11-20 pada 83°C. Thermal throttling menurunkan clock speed mulai run 11, yang mempengaruhi batch timing dan (dalam kasus tertentu) convergence karena numerical precision changes.
+
+Step 3 — Reproduksi. Run 11-20 dijalankan ulang keesokan paginya (GPU dingin). Hasil: ~90.5%, konsisten dengan run 1-10.
+
+**Penanganan:**
+
+| Opsi | Tindakan | Justifikasi |
+|------|----------|-------------|
+| A | Laporkan semua 20 run | Rata-rata terdistorsi oleh confound (thermal) |
+| B | Laporkan 10 run pertama | Hanya data dari kondisi yang konsisten |
+| C | Re-run semua 20 dengan cooling interval | Eliminasi confound |
+| **D (Dipilih)** | **Re-run 20 dengan cooling interval + laporkan temuan thermal** | **Eliminasi confound + informasi untuk komunitas** |
+
+**Pelajaran:** Anomali sistematis (bukan random) menandakan confounding variable. Deteksi memerlukan validasi yang lebih dari sekadar range check — perlu temporal analysis dan cross-reference dengan metadata environment.
+
+---
+
+## 11.9 Template Praktis
+
+### Template: Data Validation Checklist
+
+```
+═══════════════════════════════════════════════════════════════
+  DATA VALIDATION REPORT — [Judul Penelitian]
+═══════════════════════════════════════════════════════════════
+
+1. FORMAT VALIDATION
+   □ Semua file log bisa dibaca/parsed
+   □ Jumlah kolom konsisten di semua file
+   □ Tipe data per kolom sesuai ekspektasi
+   □ Encoding konsisten (UTF-8)
+   Catatan: _______________________________________________
+
+2. RANGE VALIDATION
+   Metrik utama: [nama] — Range valid: [min, max]
+   □ Semua nilai dalam range valid
+   □ Outlier teridentifikasi: ___ dari ___ data point
+   □ Investigasi outlier:
+     - Run ID: ___ | Nilai: ___ | Penyebab: ___
+   Catatan: _______________________________________________
+
+3. COMPLETENESS VALIDATION
+   Expected data points: ___
+   Actual data points  : ___
+   Missing             : ___
+   □ Missing data teridentifikasi dan didokumentasikan
+   □ Alasan missing: ______________________________________
+   Catatan: _______________________________________________
+
+4. LOGIC VALIDATION
+   □ Parameter per skenario sesuai execution plan
+   □ Seed per run sesuai execution plan
+   □ Timestamp masuk akal (urutan, durasi)
+   □ Tidak ada duplikasi run
+   Catatan: _______________________________________________
+
+5. ANOMALY DOCUMENTATION
+   ┌──────────┬──────────────┬──────────────┬──────────────┐
+   │ Run ID   │ Anomali      │ Investigasi  │ Keputusan    │
+   ├──────────┼──────────────┼──────────────┼──────────────┤
+   │          │              │              │              │
+   └──────────┴──────────────┴──────────────┴──────────────┘
+
+KEPUTUSAN AKHIR:
+   □ Dataset validated — siap analisis
+   □ Dataset perlu re-run (alasan: _______________)
+   □ Dataset validated dengan catatan anomali
+
+═══════════════════════════════════════════════════════════════
+```
+
+---
+
+## 11.10 Mindmap Ringkasan
+
+**Gambar 11.2** — Mindmap Bab 11: Data Validation & Integrity
+
+```mermaid
+mindmap
+  root(("**Bab 11**<br/>Data Validation<br/>& Integrity"))
+    ("**Data Trust Model**")
+      ("Raw Data")
+      ("Data Cleaning")
+      ("Consistency Check")
+      ("Validation Process")
+      ("Trusted Data")
+    ("**4 Pilar Kualitas**")
+      ("Accuracy — range")
+      ("Consistency — format")
+      ("Completeness — jumlah")
+      ("Validity — logika")
+    ("**Proses Validasi**")
+      ("Format → Range")
+      ("Consistency → Logic")
+      ("Anomaly detection")
+      ("Data-experiment alignment")
+    ("**Anomaly Handling**")
+      ("Detect")
+      ("Investigate")
+      ("Document")
+      ("Decide")
+    ("**Cognitive Traps**")
+      ("Otomatis ≠ benar")
+      ("Outlier ≠ hapus")
+      ("Mean normal ≠ data benar")
+```
+
+---
+
+## 11.11 Rangkuman
+
+**Poin-poin utama bab ini:**
+
+1. Data mentah dari eksperimen harus divalidasi sebelum dianalisis. Data Trust Model menggambarkan alur: Raw Data → Cleaning → Consistency Check → Validation → Trusted Data.
+
+2. Empat pilar kualitas data (Han et al., 2012): accuracy (nilai dalam range), consistency (format seragam), completeness (tidak ada data hilang), dan validity (sesuai desain eksperimen).
+
+3. Proses validasi bersifat progresif: format → range → consistency → logic. Setiap langkah menangkap jenis error yang berbeda.
+
+4. Anomali harus di-detect, investigate, document, lalu decide — bukan langsung dihapus. Anomali bisa menjadi error, tapi juga bisa menjadi temuan riset yang berharga.
+
+5. Data-experiment alignment memverifikasi bahwa dataset yang dihasilkan benar-benar sesuai dengan desain eksperimen: coverage lengkap, parameter benar, temporal consistency masuk akal.
+
+Dengan dataset yang tervalidasi dan terdokumentasi, Bagian III — Execution selesai. Dataset siap menjadi input untuk tahap analisis. Bagian IV dimulai dengan Bab 12 yang membahas bagaimana menyajikan dan menganalisis hasil eksperimen secara sistematis.
+
+> *"Data yang divalidasi bukan data yang sempurna — melainkan data yang anomalinya diketahui, didokumentasikan, dan ditangani secara transparan."*
+
+---
+
+## 11.12 Latihan & Refleksi
+
+### Latihan 1 — Completeness Check
+
+Dari execution plan yang dibuat di Latihan 1 Bab 10, simulasikan bahwa 2 run hilang (timeout). Buatlah laporan completeness check yang menjelaskan: berapa data point yang diharapkan, berapa yang ada, mana yang hilang, dan apa penanganannya.
+
+### Latihan 2 — Anomaly Investigation
+
+Diberikan dataset simulasi: 10 run menghasilkan akurasi [88.2, 87.9, 88.5, 88.1, 45.3, 87.7, 88.4, 88.0, 87.8, 88.3]. Identifikasi anomali, investigasi kemungkinan penyebab, dan tuliskan dokumentasi anomali menggunakan format dari template.
+
+### Latihan 3 — Full Validation Report
+
+Jalankan eksperimen sederhana (misal: classifier pada dataset publik, 10 run). Buat Data Validation Report lengkap menggunakan template dari Section 11.9. Dokumentasikan setiap temuan, meskipun datanya "bersih."
+
+### Refleksi
+
+> "Jika orang lain menerima dataset saya tanpa konteks apa pun, apakah dataset tersebut cukup terdokumentasi untuk membedakan data yang valid dari data yang bermasalah?"
+
+---
+
+## Daftar Pustaka
+
+- Han, J., Kamber, M., & Pei, J. (2012). *Data Mining: Concepts and Techniques* (3rd ed.). Morgan Kaufmann.
+- Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., & Wesslén, A. (2012). *Experimentation in Software Engineering*. Springer.
+- Shadish, W. R., Cook, T. D., & Campbell, D. T. (2002). *Experimental and Quasi-Experimental Designs for Generalized Causal Inference*. Houghton Mifflin.
+
+<!-- STATUS: 🟢 Draft Complete -->
+
+<!-- STATUS: ⬜ Not Started -->
--- a/book/bagian-4-analysis/bab-12-result-presentation.md
+++ b/book/bagian-4-analysis/bab-12-result-presentation.md
@ -0,0 +1,389 @@
+# Bab 12 — Result Presentation & Visualization
+
+> **Sub-CPMK:** 4.1 — Menyajikan hasil eksperimen secara terstruktur dan visual
+> **CPMK:** CPMK04 — Analysis & Interpretation
+> **CPL Utama:** CPL03 (Penalaran logis)
+> **Fase:** Scientific Thinking (M13–M16)
+> **Signature Model:** Data → Insight Model (Validated Data → Structured Presentation → Visualization → Pattern Recognition → Insight)
+
+---
+
+## Ringkasan Bab
+
+Bab ini membahas bagaimana menyajikan data hasil eksperimen dalam bentuk yang bisa dipahami, dianalisis, dan dikomunikasikan. Penyajian bukan sekadar membuat tabel dan grafik — ia proses menerjemahkan angka mentah menjadi representasi visual yang membantu mengenali pola, mendukung argumen, dan memfasilitasi interpretasi. Bab ini juga membahas bias visualisasi: cara grafik bisa menyesatkan jika tidak dirancang dengan jujur.
+
+---
+
+## 12.1 Pembuka
+
+Bagian III menghasilkan dataset yang tervalidasi — angka-angka yang sudah melewati format check, range validation, consistency check, dan logic validation. Angka-angka tersebut siap dianalisis. Tapi sebelum analisis statistik, ada langkah penting yang sering dilewati: **menyajikan data secara terstruktur**.
+
+Mengapa penyajian mendahului analisis? Karena penyajian yang baik membantu peneliti sendiri "melihat" data sebelum menghitung. Tabel yang terstruktur memperlihatkan pola kasar. Grafik yang tepat mengungkap distribusi, outlier, dan tren. Observasi visual ini membentuk intuisi awal yang kemudian diuji secara formal melalui statistik.
+
+Sebaliknya, langsung melompat ke uji statistik tanpa melihat data secara visual berisiko menghasilkan kesimpulan yang secara teknis benar tapi secara kontekstual salah. Contoh klasik: Anscombe's Quartet (1973) — empat dataset dengan statistik identik (mean, variance, korelasi) tapi distribusi visual yang sangat berbeda. Tanpa visualisasi, keempatnya terlihat "sama." Dengan visualisasi, perbedaannya jelas.
+
+Pertanyaan sentral bab ini: **Bagaimana menyajikan hasil eksperimen dalam format yang membantu mengenali pola, mendukung interpretasi, dan mengkomunikasikan temuan secara jujur?**
+
+---
+
+## 12.2 Data → Insight Model
+
+Model ini menggambarkan alur dari data tervalidasi menuju insight yang bisa dikomunikasikan.
+
+**Gambar 12.1** — Data → Insight Model
+
+```mermaid
+graph LR
+    A["📥 <b>Validated<br/>Data</b><br/><i>Dari Bab 11</i>"]
+    B["📋 <b>Structured<br/>Presentation</b><br/><i>Tabel & ringkasan</i>"]
+    C["📊 <b>Visualization</b><br/><i>Grafik & chart</i>"]
+    D["🔍 <b>Pattern<br/>Recognition</b><br/><i>Tren & anomali</i>"]
+    E["💡 <b>Insight</b><br/><i>Observasi awal</i>"]
+
+    A -->|"Strukturisasi"| B
+    B -->|"Visualisasi"| C
+    C -->|"Analisis visual"| D
+    D -->|"Formulasi"| E
+
+    style A fill:#F5F3FF,stroke:#7C3AED,color:#4C1D95
+    style B fill:#EDE9FE,stroke:#7C3AED,color:#4C1D95
+    style C fill:#DDD6FE,stroke:#7C3AED,color:#4C1D95
+    style D fill:#A78BFA,stroke:#6D28D9,color:#FFFFFF
+    style E fill:#7C3AED,stroke:#6D28D9,color:#FFFFFF
+```
+
+Setiap transisi:
+
+1. **Validated Data → Structured Presentation.** Data tervalidasi diorganisasi dalam tabel: per-skenario, per-metrik, dengan statistik deskriptif (mean, std, CI). Tabel adalah fondasi — semua angka harus ada di tabel sebelum divisualisasikan.
+
+2. **Structured Presentation → Visualization.** Data dari tabel diterjemahkan ke grafik yang sesuai tujuannya: bar chart untuk perbandingan, line chart untuk tren, box plot untuk distribusi, scatter plot untuk korelasi.
+
+3. **Visualization → Pattern Recognition.** Grafik dibaca untuk mengenali pola: skenario mana yang lebih baik? Apakah ada outlier? Apakah distribusi simetris atau skewed? Apakah ada tren temporal?
+
+4. **Pattern Recognition → Insight.** Pola yang teramati dirumuskan sebagai observasi awal — belum menjadi kesimpulan (itu tugas analisis statistik), tapi sudah membentuk hipotesis tentang apa yang mungkin terjadi.
+
+---
+
+## 12.3 Definisi Kunci
+
+**Structured Presentation**
+: Penyajian data dalam format terorganisasi (tabel, ringkasan statistik) yang memungkinkan pembaca melihat semua angka penting dalam satu pandangan. Tabel harus self-contained: bisa dipahami tanpa membaca teks pendamping.
+
+**Visualization**
+: Representasi grafis dari data yang memanfaatkan kemampuan visual manusia untuk mengenali pola, tren, dan anomali yang sulit dilihat dari angka mentah. Visualisasi yang baik memperjelas — bukan memperindah.
+
+**Visualization Bias**
+: Distorsi persepsi yang disebabkan oleh keputusan desain grafik: skala sumbu yang tidak dimulai dari nol, aspect ratio yang melebih-lebihkan perbedaan, pemilihan warna yang menyesatkan, atau data yang dipotong selektif. Bias bisa disengaja atau tidak disadari.
+
+**Observasi Awal**
+: Deskripsi pola yang terlihat dari data sebelum dikonfirmasi secara statistik. "Terlihat bahwa skenario A menghasilkan nilai lebih tinggi dari B" adalah observasi. "Skenario A secara signifikan lebih baik dari B (p < 0.05)" adalah kesimpulan statistik.
+
+---
+
+## 12.4 Konsep Inti
+
+### 12.4.1 Tabel: Presisi dan Transparansi
+
+Tabel adalah fondasi penyajian hasil. Setiap eksperimen harus memiliki tabel utama yang menampilkan:
+- Semua skenario (baris)
+- Semua metrik (kolom)
+- Statistik deskriptif per sel: mean ± std, atau median (IQR), tergantung distribusi
+- Jumlah run (N) per skenario
+
+Prinsip desain tabel:
+
+**Self-contained.** Pembaca harus bisa memahami tabel hanya dari judul, header, dan catatan kaki — tanpa membaca teks paragraf. Sertakan satuan, singkatan yang dijelaskan, dan N.
+
+**Konsisten.** Format angka konsisten: jumlah desimal sama di seluruh tabel. Jangan campur 87.2% dan 0.872 dalam satu tabel.
+
+**Minimalis.** Hanya tampilkan informasi yang relevan. Tabel dengan 20 kolom sulit dibaca. Jika perlu banyak metrik, pertimbangkan tabel terpisah atau lampiran.
+
+**Sortable.** Jika memungkinkan, urutkan baris berdasarkan performa (dari terbaik ke terburuk pada metrik utama) untuk memudahkan pembaca mengidentifikasi pola ranking.
+
+### 12.4.2 Grafik: Tujuan Menentukan Jenis
+
+Pemilihan jenis grafik bukan soal estetika — ia tentang mencocokkan tujuan komunikasi dengan representasi visual yang tepat:
+
+| Tujuan | Jenis Grafik | Kapan Digunakan |
+|--------|-------------|-----------------|
+| Perbandingan antar-skenario | Bar chart (grouped/stacked) | Membandingkan mean metrik antar-kondisi |
+| Distribusi per-skenario | Box plot / violin plot | Menampilkan median, IQR, outlier per kondisi |
+| Tren temporal | Line chart | Metrik yang berubah sepanjang waktu/epoch |
+| Korelasi dua variabel | Scatter plot | Hubungan antara dua metrik kontinu |
+| Proporsi | Pie chart (hati-hati) | Hanya jika bagian-bagiannya berjumlah 100% |
+
+Prinsip: **satu grafik, satu pesan**. Grafik yang mencoba menyampaikan terlalu banyak informasi sekaligus biasanya tidak menyampaikan apa-apa dengan jelas.
+
+### 12.4.3 Multi-Metric Presentation
+
+Eksperimen riset TI sering mengukur lebih dari satu metrik. Misalnya: akurasi, F1-score, waktu training, dan memory usage. Bagaimana menyajikan multi-metric?
+
+**Tabel terpisah per kategori metrik.** Metrik kualitas (accuracy, F1) dalam satu tabel. Metrik efisiensi (waktu, memory) dalam tabel lain. Ini menghindari tabel "monster" yang sulit dibaca.
+
+**Grafik multi-panel.** Beberapa grafik kecil yang disusun berdampingan (small multiples), masing-masing menampilkan satu metrik. Pembaca bisa membandingkan pola lintas metrik secara visual.
+
+**Radar/spider chart.** Berguna untuk profiling: skenario mana yang "menang" di metrik apa. Tapi hati-hati — radar chart bisa menyesatkan jika skala metrik berbeda secara substansial.
+
+**Trade-off plot.** Scatter plot dengan satu metrik di sumbu X dan metrik lain di sumbu Y. Berguna untuk menunjukkan trade-off (misal: accuracy vs training time). Skenario di "sudut kiri atas" (high accuracy, low time) lebih disukai.
+
+### 12.4.4 Visualization Bias: Grafik yang Menyesatkan
+
+Grafik bisa menipu — baik disengaja maupun tidak. Beberapa jenis bias yang harus dihindari:
+
+**Truncated axis.** Sumbu Y yang tidak dimulai dari nol memperbesar perbedaan visual. Perbedaan 1% terlihat seperti perbedaan 50% jika skala dipotong. Solusi: mulai dari nol, atau jika range terlalu besar, gunakan broken axis dengan indikator jelas.
+
+**Inconsistent scale.** Dua grafik yang dibandingkan menggunakan skala Y berbeda. Pembaca yang tidak memperhatikan sumbu menyimpulkan pola yang salah. Solusi: gunakan skala yang sama untuk grafik yang dibandingkan.
+
+**Cherry-picked data.** Hanya menampilkan subset data yang mendukung naratif. Menampilkan 3 metrik di mana metode A menang, menyembunyikan 2 metrik di mana metode A kalah. Solusi: tampilkan semua metrik, atau jelaskan secara eksplisit mengapa metrik tertentu dipilih.
+
+**3D effects.** Grafik 3D hampir selalu memperburuk readability tanpa menambah informasi. Perspektif 3D mendistorsi perbandingan visual. Solusi: gunakan 2D.
+
+---
+
+## 12.5 Research vs Engineering
+
+**Tabel 12.1** — Perspektif Penyajian: Engineering vs Research
+
+| Aspek | Engineering | Research |
+|-------|------------|----------|
+| **Tujuan grafik** | Dashboard monitoring | Mendukung argumen ilmiah |
+| **Audiens** | Tim teknis, stakeholder | Reviewer, komunitas riset |
+| **Informasi wajib** | KPI, threshold, status | Mean, std, CI, N, p-value |
+| **Estetika** | Penting (dashboard UX) | Sekunder (kejelasan utama) |
+| **Interaktivitas** | Sering (drill-down, filter) | Jarang (grafik statis di paper) |
+| **Bias handling** | Less critical | Wajib dihindari (peer-review) |
+
+Perbedaan kunci: grafik engineering dirancang untuk monitoring real-time. Grafik riset dirancang untuk menyajikan argumen — ia harus jujur, presisi, dan self-explanatory karena akan dievaluasi oleh reviewer yang skeptis.
+
+---
+
+## 12.6 Research Reality
+
+### Fenomena 1 — "Tabel 20 Kolom, Font Size 6pt"
+
+Peneliti yang mengukur banyak metrik sering memasukkan semuanya ke satu tabel raksasa. Hasilnya: font kecil, kolom sempit, angka berdempetan. Pembaca tidak bisa menangkap pola apa pun. Solusi: pecah menjadi beberapa tabel tematik. Lebih baik 3 tabel kecil yang jelas daripada 1 tabel besar yang tidak bisa dibaca.
+
+### Fenomena 2 — "Grafik Tanpa Error Bar"
+
+Bar chart yang menampilkan mean tanpa error bar (standar deviasi atau confidence interval) menyembunyikan informasi kritis: seberapa pasti angka tersebut? Jika dua bar berbeda 2% tapi error bar saling overlap, perbedaan tersebut kemungkinan tidak signifikan. Tanpa error bar, perbedaan visual menipu.
+
+### Fenomena 3 — "Grafik Indah, Data Tidak Jelas"
+
+Terkadang grafik dibuat dengan fokus estetika — warna gradient, efek bayangan, font dekoratif — tapi informasinya tidak jelas. Label sumbu terlalu kecil. Legenda tumpang tindih dengan data. Warna untuk dua kategori terlalu mirip. Dalam riset, kejelasan mengalahkan keindahan.
+
+---
+
+## 12.7 Cognitive Traps
+
+### Trap 1: "Grafik lebih meyakinkan dari tabel"
+
+Grafik bagus untuk pola — tabel bagus untuk presisi. Keduanya saling melengkapi, bukan menggantikan. Paper yang hanya memiliki grafik tanpa tabel menyulitkan pembaca yang ingin melihat angka eksak. Paper yang hanya memiliki tabel tanpa grafik membuat pembaca sulit menangkap pola. Gunakan keduanya.
+
+### Trap 2: "Sumbu Y dimulai dari nol? Grafiknya terlihat flat"
+
+Grafik yang "flat" mungkin memang menunjukkan realitas: perbedaan antar-skenario memang kecil. Memotong sumbu Y untuk memperbesar perbedaan secara visual bisa menyesatkan pembaca. Jika perbedaan kecil tapi signifikan, sampaikan lewat angka dan uji statistik — bukan lewat manipulasi skala.
+
+### Trap 3: "Satu grafik untuk semua metrik — efisien"
+
+Grafik yang mencoba menampilkan terlalu banyak informasi (5 metrik, 8 skenario, error bar, annotations) menjadi tidak terbaca. Prinsip: satu grafik, satu pesan utama. Jika ada 5 metrik, pertimbangkan 5 grafik kecil (small multiples) yang masing-masing fokus pada satu pesan.
+
+### Trap 4: "Pie chart untuk semuanya"
+
+Pie chart hanya efektif untuk menunjukkan proporsi dari keseluruhan (100%). Untuk perbandingan antar-kategori, bar chart hampir selalu lebih efektif — mata manusia lebih baik membandingkan panjang (bar) daripada sudut (pie slice).
+
+---
+
+## 12.8 Studi Kasus
+
+### Kasus 1 (Basic): "Tabel vs Grafik — Penyajian yang Saling Melengkapi"
+
+**Konteks:**
+
+Eksperimen membandingkan 3 model (BERT, LSTM, SVM) pada 3 metrik (Accuracy, F1, Training Time). 10 run per model.
+
+**❌ Pendekatan Salah:**
+
+Hanya menampilkan satu tabel besar:
+
+| Model | Acc | Acc Std | F1 | F1 Std | Time | Time Std | Acc CI | F1 CI | Time CI |
+|---|---|---|---|---|---|---|---|---|---|
+| BERT | 88.4 | 1.2 | 87.1 | 1.4 | 45.2m | 3.1 | [87.5,89.3] | [86.1,88.1] | [43.0,47.4] |
+| ... | ... | ... | ... | ... | ... | ... | ... | ... | ... |
+
+Pembaca tenggelam dalam angka. Pola tidak terlihat.
+
+**✅ Pendekatan Benar:**
+
+Tabel ringkas untuk presisi:
+
+| Model | Accuracy (%) | F1-Score (%) | Training Time (min) |
+|-------|-------------|-------------|---------------------|
+| BERT | 88.4 ± 1.2 | 87.1 ± 1.4 | 45.2 ± 3.1 |
+| LSTM | 86.1 ± 1.8 | 84.5 ± 2.0 | 12.8 ± 1.2 |
+| SVM | 82.3 ± 0.9 | 80.7 ± 1.1 | 0.3 ± 0.1 |
+
+*N=10 per model. Mean ± std. Diurutkan berdasarkan Accuracy.*
+
+Dilengkapi: (a) bar chart + error bar untuk perbandingan metrik kualitas, (b) box plot untuk distribusi per model, (c) scatter plot accuracy vs training time untuk trade-off. Tiga grafik, tiga pesan berbeda — saling melengkapi, bukan redundan.
+
+**Pelajaran:** Tabel menyajikan angka yang bisa direferensikan. Grafik menyajikan pola yang bisa dilihat. Keduanya diperlukan.
+
+---
+
+### Kasus 2 (Advanced): "Visualization Bias — Grafik yang Menipu"
+
+**Konteks:**
+
+Paper membandingkan accuracy dua metode pada benchmark. Metode A: 91.2%. Metode B: 90.8%. Paper menyajikan bar chart berikut:
+
+Bar chart dengan sumbu Y dimulai dari 90.0%. Secara visual, bar A terlihat dua kali lebih tinggi dari bar B. Perbedaan 0.4% terlihat seperti perbedaan substansial.
+
+**Analisis bias:**
+
+| Aspek | Presentasi Bias | Presentasi Jujur |
+|-------|----------------|-----------------|
+| **Sumbu Y** | Mulai dari 90% | Mulai dari 0% (atau 80% dengan break indicator) |
+| **Persepsi visual** | A >> B | A ≈ B |
+| **Error bar** | Tidak ada | Ada (overlap → tidak signifikan?) |
+| **Informasi tambahan** | Tidak ada | N, std, CI, p-value |
+
+Ketika sumbu Y dimulai dari nol, kedua bar terlihat hampir identik — yang memang merefleksikan realitas bahwa 0.4% adalah perbedaan yang sangat kecil. Apakah perbedaan ini bermakna? Hanya uji statistik yang bisa menjawab, dan jawaban itu harus dicantumkan bersama grafik.
+
+**Pelajaran:** Grafik yang jujur mungkin terlihat kurang "impressive," tapi ia merefleksikan realitas. Tugas visualisasi adalah membantu pembaca memahami data — bukan meyakinkan pembaca terhadap kesimpulan tertentu.
+
+---
+
+## 12.9 Template Praktis
+
+### Template: Result Presentation Plan
+
+```
+═══════════════════════════════════════════════════════════════
+  RESULT PRESENTATION PLAN — [Judul Penelitian]
+═══════════════════════════════════════════════════════════════
+
+TABEL UTAMA:
+  Tabel 1: [Deskripsi] — Metrik kualitas per skenario
+    □ Kolom: Skenario | Metrik-1 (mean±std) | Metrik-2 | N
+    □ Baris diurutkan berdasarkan: [primary metric]
+    □ Format desimal: [n] digit
+    □ Satuan tertera di header
+
+  Tabel 2: [Deskripsi] — Metrik efisiensi per skenario
+    □ Kolom: Skenario | Time | Memory | ...
+    □ Satuan: [menit/detik/MB]
+
+GRAFIK:
+  Grafik 1: [Jenis] — [Pesan utama]
+    □ Tipe: Bar chart + error bar
+    □ Variabel: X = skenario, Y = [metrik]
+    □ Sumbu Y mulai dari: [0 / custom dengan justifikasi]
+    □ Error bar: std / 95% CI
+
+  Grafik 2: [Jenis] — [Pesan utama]
+    □ Tipe: Box plot
+    □ Variabel: X = skenario, Y = [metrik]
+    □ Menampilkan: median, IQR, outlier
+
+CHECKLIST BIAS:
+  □ Sumbu Y konsisten di semua grafik perbandingan
+  □ Error bar ditampilkan
+  □ Semua metrik disajikan (tidak cherry-pick)
+  □ Tidak ada efek 3D
+  □ Warna accessible (colorblind-friendly)
+
+OBSERVASI AWAL:
+  1. ___________________________________________________
+  2. ___________________________________________________
+  3. ___________________________________________________
+
+═══════════════════════════════════════════════════════════════
+```
+
+---
+
+## 12.10 Mindmap Ringkasan
+
+**Gambar 12.2** — Mindmap Bab 12: Result Presentation & Visualization
+
+```mermaid
+mindmap
+  root(("**Bab 12**<br/>Result Presentation<br/>& Visualization"))
+    ("**Data → Insight Model**")
+      ("Validated Data")
+      ("Structured Presentation")
+      ("Visualization")
+      ("Pattern Recognition")
+      ("Insight")
+    ("**Tabel**")
+      ("Self-contained")
+      ("Mean ± std")
+      ("Konsisten format")
+      ("Minimalis")
+    ("**Grafik**")
+      ("Bar chart — perbandingan")
+      ("Box plot — distribusi")
+      ("Line chart — tren")
+      ("Scatter — korelasi")
+    ("**Visualization Bias**")
+      ("Truncated axis")
+      ("Cherry-picked data")
+      ("Missing error bar")
+      ("3D distortion")
+    ("**Cognitive Traps**")
+      ("Grafik ≠ pengganti tabel")
+      ("Flat ≠ salah")
+      ("1 grafik ≠ semua pesan")
+```
+
+---
+
+## 12.11 Rangkuman
+
+**Poin-poin utama bab ini:**
+
+1. Penyajian hasil adalah langkah antara validasi data dan analisis statistik. Tabel memberikan presisi, grafik memberikan pola — keduanya saling melengkapi.
+
+2. Pemilihan jenis grafik ditentukan oleh tujuan komunikasi: perbandingan (bar chart), distribusi (box plot), tren (line chart), korelasi (scatter plot).
+
+3. Multi-metric disajikan melalui tabel terpisah per kategori, small multiples, atau trade-off plot — bukan satu grafik yang terlalu padat.
+
+4. Visualization bias (truncated axis, cherry-picked data, missing error bar, 3D effects) harus dihindari. Grafik yang jujur mungkin kurang dramatic, tapi merefleksikan realitas.
+
+5. Observasi awal dari visualisasi bukan kesimpulan — ia hipotesis yang perlu dikonfirmasi melalui analisis statistik di bab-bab berikutnya.
+
+Dengan data yang tersaji secara terstruktur, langkah berikutnya adalah mempersiapkan data untuk analisis. Bab 13 membahas data preprocessing — bagaimana membersihkan, mentransformasi, dan menormalisasi data sebelum dianalisis secara statistik.
+
+> *"Grafik yang baik tidak memanipulasi pembaca — ia membantu pembaca melihat apa yang sebenarnya terjadi di dalam data."*
+
+---
+
+## 12.12 Latihan & Refleksi
+
+### Latihan 1 — Tabel Hasil
+
+Dari data eksperimen sebelumnya (atau data simulasi), buat tabel hasil yang memenuhi semua prinsip: self-contained, konsisten format, terurut, dan menyertakan mean ± std serta N.
+
+### Latihan 2 — Visualisasi Multi-Metrik
+
+Sajikan data dari Latihan 1 menggunakan minimal 2 jenis grafik berbeda. Untuk setiap grafik, nyatakan: apa pesan utamanya, mengapa jenis grafik tersebut dipilih, dan observasi awal apa yang terlihat.
+
+### Latihan 3 — Bias Detection
+
+Cari satu grafik dari paper atau laporan riset yang menurut Anda memiliki potensi visualization bias. Identifikasi jenis biasnya dan jelaskan bagaimana grafik tersebut bisa diperbaiki.
+
+### Refleksi
+
+> "Apakah grafik yang saya buat membantu pembaca memahami data, atau membantu saya meyakinkan pembaca terhadap kesimpulan tertentu?"
+
+---
+
+## Daftar Pustaka
+
+- Tufte, E. R. (2001). *The Visual Display of Quantitative Information* (2nd ed.). Graphics Press.
+- Few, S. (2012). *Show Me the Numbers: Designing Tables and Graphs to Enlighten* (2nd ed.). Analytics Press.
+- Anscombe, F. J. (1973). Graphs in Statistical Analysis. *The American Statistician*, 27(1), 17–21.
+
+<!-- STATUS: 🟢 Draft Complete -->
+
+<!-- STATUS: ⬜ Not Started -->
--- a/book/bagian-4-analysis/bab-13-data-preprocessing.md
+++ b/book/bagian-4-analysis/bab-13-data-preprocessing.md
@ -0,0 +1,386 @@
+# Bab 13 — Data Preprocessing
+
+> **Sub-CPMK:** 4.2 — Melakukan preprocessing data eksperimen secara reproducible
+> **CPMK:** CPMK04 — Analysis & Interpretation
+> **CPL Utama:** CPL03 (Penalaran logis)
+> **Fase:** Scientific Thinking (M13–M16)
+> **Signature Model:** Data Refinement Pipeline (Raw Data → Cleaning → Transformation → Normalization → Processed Data → Analysis Ready)
+
+---
+
+## Ringkasan Bab
+
+Bab ini membahas bagaimana mempersiapkan data eksperimen untuk analisis: membersihkan (cleaning), mentransformasi (transformation), dan menormalisasi (normalization). Preprocessing bukan proses teknis yang "otomatis" — setiap keputusan preprocessing mengubah data dan berpotensi mengubah kesimpulan. Bab ini menekankan empat prinsip: consistency, transparency, reproducibility, dan minimal distortion.
+
+---
+
+## 13.1 Pembuka
+
+Bab 12 menyajikan data secara visual dan menghasilkan observasi awal. Sebelum data masuk ke analisis statistik formal, ada langkah yang sering terjadi tapi jarang didokumentasikan dengan baik: **preprocessing**.
+
+Preprocessing mencakup semua transformasi yang dilakukan terhadap data sebelum analisis utama. Ini bisa sederhana (menghapus baris duplikat) atau kompleks (normalisasi fitur, encoding variabel kategorikal, agregasi cross-validation folds). Masalahnya: setiap keputusan preprocessing mengubah data — dan perubahan ini bisa mengubah hasil analisis.
+
+Contoh: dataset memiliki 3 missing values dari 100 data point. Opsi: (a) hapus 3 baris (listwise deletion) — jumlah data berkurang. (b) Imputasi dengan mean — distribusi data berubah. (c) Imputasi dengan model — dependensi baru diperkenalkan. Ketiga opsi menghasilkan dataset yang sedikit berbeda, yang mungkin menghasilkan kesimpulan statistik yang berbeda. Mana yang "benar"? Tidak ada jawaban universal — tapi apapun yang dipilih harus dijustifikasi dan didokumentasikan.
+
+Pertanyaan sentral bab ini: **Bagaimana melakukan preprocessing yang memperbaiki kualitas data tanpa mendistorsi informasi yang dikandungnya?**
+
+---
+
+## 13.2 Data Refinement Pipeline
+
+Model ini menggambarkan alur pemrosesan data dari bentuk mentah menuju data yang siap dianalisis.
+
+**Gambar 13.1** — Data Refinement Pipeline
+
+```mermaid
+graph LR
+    A["📥 <b>Raw Data</b><br/><i>Dari eksperimen</i>"]
+    B["🧹 <b>Cleaning</b><br/><i>Missing, duplikat, error</i>"]
+    C["🔄 <b>Transformation</b><br/><i>Encoding, agregasi</i>"]
+    D["📐 <b>Normalization</b><br/><i>Scaling, standardisasi</i>"]
+    E["📦 <b>Processed<br/>Data</b><br/><i>Siap analisis</i>"]
+    F["✅ <b>Analysis<br/>Ready</b><br/><i>Terdokumentasi</i>"]
+
+    A -->|"Pembersihan"| B
+    B -->|"Transformasi"| C
+    C -->|"Normalisasi"| D
+    D -->|"Verifikasi"| E
+    E -->|"Dokumentasi"| F
+
+    style A fill:#F5F3FF,stroke:#7C3AED,color:#4C1D95
+    style B fill:#EDE9FE,stroke:#7C3AED,color:#4C1D95
+    style C fill:#DDD6FE,stroke:#7C3AED,color:#4C1D95
+    style D fill:#C4B5FD,stroke:#6D28D9,color:#4C1D95
+    style E fill:#A78BFA,stroke:#6D28D9,color:#FFFFFF
+    style F fill:#7C3AED,stroke:#6D28D9,color:#FFFFFF
+```
+
+Setiap transisi:
+
+1. **Raw Data → Cleaning.** Data mentah dibersihkan: missing values ditangani, duplikat dihapus, error format diperbaiki. Cleaning menghilangkan "noise" teknis tanpa mengubah substansi data.
+
+2. **Cleaning → Transformation.** Data bersih ditransformasi jika diperlukan: variabel kategorikal di-encode, fitur di-aggregate, format disatukan. Transformasi mengubah representasi data, bukan isinya.
+
+3. **Transformation → Normalization.** Jika analisis memerlukan skala yang seragam (misalnya untuk clustering atau neural network), data dinormalisasi. Normalisasi mengubah skala, bukan distribusi relatif.
+
+4. **Normalization → Processed Data.** Data yang sudah diproses diverifikasi: apakah preprocessing memperkenalkan artefak? Apakah distribusi masih masuk akal? Apakah jumlah data point konsisten?
+
+5. **Processed Data → Analysis Ready.** Setiap langkah preprocessing didokumentasikan secara lengkap — metode, justifikasi, dan dampaknya — agar reproducible dan auditable.
+
+---
+
+## 13.3 Definisi Kunci
+
+**Data Cleaning**
+: Proses mengidentifikasi dan menangani masalah kualitas data — missing values, duplikasi, format error, dan outlier teknis. Tujuannya meningkatkan kualitas tanpa mengubah informasi substantif yang dikandung data.
+
+**Data Transformation**
+: Proses mengubah representasi data — encoding kategorikal ke numerik, agregasi dari level granular ke level ringkasan, atau pembuatan fitur turunan (feature engineering). Transformasi mengubah bentuk, bukan substansi.
+
+**Normalization**
+: Proses menyeragamkan skala variabel agar comparable — misalnya min-max scaling ke [0,1] atau z-score standardization ke mean=0, std=1. Diperlukan ketika analisis sensitif terhadap perbedaan skala.
+
+**Minimal Distortion**
+: Prinsip bahwa setiap langkah preprocessing harus mengubah data sesedikit mungkin untuk mencapai tujuannya. Jika cleaning bisa dilakukan tanpa menghapus data, jangan hapus. Jika normalisasi tidak diperlukan, jangan lakukan.
+
+---
+
+## 13.4 Konsep Inti
+
+### 13.4.1 Cleaning: Missing Values, Duplikat, dan Error
+
+**Missing values.** Data point yang tidak ada (NaN, null, kosong). Penyebab: logging gagal, run timeout, kolom tidak tercatat. Penanganan:
+
+| Metode | Cara Kerja | Kapan Tepat | Risiko |
+|--------|-----------|-------------|--------|
+| Listwise deletion | Hapus seluruh baris | Missing sedikit (< 5%), random | Kehilangan data |
+| Mean/median imputation | Ganti dengan mean/median | Missing sedikit, distribusi normal | Mengurangi variabilitas |
+| Model-based imputation | Prediksi dari variabel lain | Missing banyak, pola sistematis | Memperkenalkan dependensi |
+| Flag and separate | Tandai, analisis terpisah | Missing karena alasan substantif | Kompleksitas analisis |
+
+Prinsip: pilihan metode harus dijustifikasi berdasarkan pola missing (random vs systematic) dan dampak terhadap analisis.
+
+**Duplikasi.** Baris identik yang muncul lebih dari sekali. Penyebab: script logging menulis dua kali, merge error, re-run tanpa clearing. Deteksi: periksa run ID + timestamp — duplikasi memiliki ID/timestamp identik. Penanganan: hapus duplikat, dokumentasikan jumlah dan penyebab.
+
+**Format error.** Tipe data yang salah (string di kolom numerik), value yang tidak valid (akurasi > 100%), atau encoding yang rusak. Penanganan: fix jika jelas (parsing error), flag jika ambiguous, hapus jika irreparable.
+
+### 13.4.2 Transformation: Encoding dan Agregasi
+
+**Encoding variabel kategorikal.** Jika analisis memerlukan input numerik (regresi, clustering), variabel kategorikal perlu di-encode. One-hot encoding untuk nominal (tanpa urutan). Ordinal encoding untuk ordinal (ada urutan). Label encoding untuk binary.
+
+**Agregasi.** Menggabungkan data dari level granular ke level yang dianalisis. Contoh: jika eksperimen menghasilkan accuracy per-fold (5-fold CV), dan analisis membandingkan antar-skenario, maka aggregate ke mean per skenario. Dokumentasikan level agregasi.
+
+**Feature engineering.** Membuat variabel turunan dari variabel yang ada. Contoh: dari training time dan epochs, hitung time-per-epoch. Dari precision dan recall, hitung F1-score. Feature engineering yang relevan membantu analisis — yang berlebihan memperkeruh.
+
+### 13.4.3 Normalization dan Scaling
+
+**Kapan diperlukan:** machine learning yang sensitif terhadap skala (SVM, k-NN, neural network), analisis yang membandingkan variabel dengan satuan berbeda (clustering), PCA.
+
+**Kapan tidak diperlukan:** analisis statistik yang scale-invariant (korelasi rank, uji non-parametrik), tree-based models (random forest, decision tree), perbandingan metrik yang sudah dalam skala yang sama.
+
+| Metode | Formula | Range Output | Sensitif terhadap Outlier |
+|--------|---------|-------------|--------------------------|
+| Min-max scaling | (x - min) / (max - min) | [0, 1] | Ya |
+| Z-score standardization | (x - mean) / std | Tidak terbatas | Lebih robust |
+| Robust scaling | (x - median) / IQR | Tidak terbatas | Paling robust |
+
+Prinsip: normalisasi harus dihitung dari training data saja (jika ada split train/test) untuk menghindari data leakage.
+
+### 13.4.4 Empat Prinsip Preprocessing
+
+Setiap keputusan preprocessing harus memenuhi empat prinsip:
+
+**Consistency.** Preprocessing yang sama harus diterapkan ke semua data — tidak boleh ada skenario yang mendapat treatment berbeda tanpa justifikasi.
+
+**Transparency.** Setiap langkah didokumentasikan: apa yang dilakukan, mengapa, bagaimana, dan apa dampaknya terhadap data.
+
+**Reproducibility.** Preprocessing harus bisa direproduksi oleh orang lain — idealnya dalam bentuk script, bukan langkah manual.
+
+**Minimal distortion.** Jangan lakukan preprocessing yang tidak diperlukan. Setiap transformasi berpotensi memperkenalkan artefak. Lakukan hanya apa yang diperlukan untuk analisis.
+
+---
+
+## 13.5 Research vs Engineering
+
+**Tabel 13.1** — Perspektif Preprocessing: Engineering vs Research
+
+| Aspek | Engineering | Research |
+|-------|------------|----------|
+| **Tujuan** | Data siap untuk model production | Data siap untuk analisis statistik |
+| **Missing values** | Impute (harus handle semua case) | Dokumentasi + justifikasi metode |
+| **Feature engineering** | Ekstensif (maximize performa) | Minimal (jangan bias hasil) |
+| **Normalization** | Selalu (pipeline production) | Hanya jika diperlukan analisis |
+| **Dokumentasi** | Pipeline config file | Penjelasan lengkap di metode |
+| **Validation** | A/B test pada production | Perbandingan distribusi sebelum/sesudah |
+
+Perbedaan kritis: dalam engineering, preprocessing bertujuan **memaksimalkan performa model**. Dalam riset, preprocessing bertujuan **mempersiapkan data tanpa mendistorsi informasi**. Over-preprocessing dalam riset bisa mengaburkan temuan yang sebenarnya.
+
+---
+
+## 13.6 Research Reality
+
+### Fenomena 1 — "Preprocessing Tidak Didokumentasikan"
+
+Seorang peneliti melakukan 5 langkah preprocessing (hapus duplikat, impute mean, encode label, normalize, hapus outlier) tapi hanya menulis "data were preprocessed" di paper. Reviewer — atau peneliti lain yang ingin mereproduksi — tidak tahu apa yang dilakukan. Preprocessing yang tidak didokumentasikan adalah preprocessing yang tidak reproducible.
+
+### Fenomena 2 — "Over-Preprocessing Mengubah Kesimpulan"
+
+Dataset asli: metode A lebih baik dari B (p=0.04). Setelah outlier removal + normalisasi + imputation: metode A dan B tidak berbeda signifikan (p=0.12). Apakah berarti preprocessing "merusak" hasil? Belum tentu — mungkin hasil awal didorong oleh outlier. Tapi tanpa dokumentasi dan sensitivitas analysis (menjalankan analisis dengan dan tanpa preprocessing), tidak bisa dibedakan apakah preprocessing mengungkap kebenaran atau menyembunyikannya.
+
+### Fenomena 3 — "Normalisasi pada Seluruh Dataset (Data Leakage)"
+
+Peneliti menghitung min-max scaling menggunakan seluruh dataset (train + test), kemudian split. Hasilnya: normalisasi parameter "mengandung" informasi dari test set — analogi dengan melihat ujian sebelum dijawab. Ini data leakage. Normalisasi harus dihitung dari training set saja, lalu diterapkan ke test set menggunakan parameter yang sama.
+
+---
+
+## 13.7 Cognitive Traps
+
+### Trap 1: "Preprocessing adalah tahap teknis — tidak perlu dilaporkan detail"
+
+Preprocessing bisa mengubah distribusi data, jumlah data point, dan bahkan kesimpulan statistik. Setiap keputusan preprocessing adalah keputusan riset — bukan keputusan teknis. Dokumentasikan secara lengkap di bagian metode.
+
+### Trap 2: "Lebih banyak preprocessing = data lebih bersih = hasil lebih baik"
+
+Over-preprocessing bisa memperkenalkan artefak atau menghilangkan variasi natural yang informatif. Menghapus semua outlier, menormalisasi semua variabel, dan melakukan feature engineering berlebihan bisa mengubah data menjadi "terlalu bersih" — tidak lagi merefleksikan realitas eksperimen.
+
+### Trap 3: "Normalisasi selalu diperlukan"
+
+Banyak analisis statistik tidak memerlukan normalisasi. Korelasi Spearman, uji Wilcoxon, uji Mann-Whitney — semuanya rank-based dan scale-invariant. Random forest dan decision tree tidak sensitif terhadap skala. Normalisasi yang tidak diperlukan menambah kompleksitas tanpa manfaat.
+
+### Trap 4: "Imputation yang sama untuk semua situasi"
+
+Mean imputation cocok jika missing sedikit dan random. Tapi jika missing bersifat sistematis (misalnya: semua run yang timeout memiliki missing training time), maka mean imputation menyembunyikan informasi bahwa data tersebut hilang karena alasan substantif — bukan random.
+
+---
+
+## 13.8 Studi Kasus
+
+### Kasus 1 (Basic): "Missing Values — Tiga Pendekatan, Tiga Hasil"
+
+**Konteks:**
+
+Dataset eksperimen: 50 run, 3 metrik (accuracy, F1, time). Dua run memiliki missing training time karena crash (GPU out of memory). Dataset ingin dibandingkan: rata-rata metrik antar-skenario.
+
+**Pendekatan 1 — Listwise Deletion:**
+
+Hapus 2 run. N turun dari 50 ke 48. Rata-rata accuracy dan F1 berubah sedikit. Training time rata-rata menjadi lebih rendah (yang crash mungkin lebih lambat). Analisis valid dengan N=48.
+
+**Pendekatan 2 — Mean Imputation:**
+
+Ganti missing time dengan rata-rata dari 48 run lainnya. N tetap 50. Tapi imputasi menyembunyikan fakta bahwa 2 run crash karena terlalu memakan waktu — time mereka bukan "rata-rata," tapi "lebih dari batas."
+
+**Pendekatan 3 — Flag and Report:**
+
+Tandai 2 run sebagai DNF (Did Not Finish). Laporkan: "50 run dilakukan, 48 selesai, 2 crash karena GPU OOM pada training menit ke-XX. Statistik dihitung dari 48 run yang selesai. Run yang crash menunjukkan bahwa konfigurasi tertentu memerlukan GPU memory > 16GB."
+
+**Pendekatan 3 paling informatif** — missing data menjadi temuan, bukan hanya masalah teknis.
+
+---
+
+### Kasus 2 (Advanced): "Data Leakage via Preprocessing"
+
+**Konteks:**
+
+Eksperimen klasifikasi: 1000 sampel, split 80/20 (800 train, 200 test). Feature normalization menggunakan min-max scaling. Model: SVM.
+
+**❌ Pendekatan Salah (Leakage):**
+
+```
+1. Load seluruh 1000 sampel
+2. Normalisasi min-max pada 1000 sampel  ← LEAKAGE
+3. Split 800/200
+4. Train SVM on 800, test on 200
+5. Report accuracy: 94.5%
+```
+
+Min-max parameter (min, max) dihitung menggunakan data yang akan menjadi test set. Model "secara implisit" mengetahui karakteristik test data melalui normalisasi.
+
+**✅ Pendekatan Benar:**
+
+```
+1. Load seluruh 1000 sampel
+2. Split 800/200
+3. Hitung min-max dari 800 sampel training SAJA
+4. Terapkan normalisasi ke 800 (training) dan 200 (test)
+   menggunakan parameter dari langkah 3
+5. Train SVM on 800, test on 200
+6. Report accuracy: 92.1%
+```
+
+Perbedaan 2.4% (94.5% vs 92.1%) sepenuhnya berasal dari leakage. Dalam riset, 2.4% bisa mengubah kesimpulan tentang model mana yang lebih baik.
+
+**Pelajaran:** Data leakage bisa subtle dan tersembunyi dalam preprocessing. Prinsip: semua parameter preprocessing harus dihitung dari training data saja.
+
+---
+
+## 13.9 Template Praktis
+
+### Template: Preprocessing Documentation Log
+
+```
+═══════════════════════════════════════════════════════════════
+  PREPROCESSING LOG — [Judul Penelitian]
+═══════════════════════════════════════════════════════════════
+
+DATA AWAL:
+  Jumlah data point : ___
+  Jumlah variabel   : ___
+  Sumber             : [Output dari Bab 10/11]
+
+LANGKAH PREPROCESSING:
+  ┌─────┬──────────────┬──────────────┬──────────────────────┐
+  │ No. │ Langkah      │ Metode       │ Justifikasi          │
+  ├─────┼──────────────┼──────────────┼──────────────────────┤
+  │ 1   │ Duplikasi    │ [hapus/flag] │ [alasan]             │
+  ├─────┼──────────────┼──────────────┼──────────────────────┤
+  │ 2   │ Missing val  │ [metode]     │ [alasan + pola]      │
+  ├─────┼──────────────┼──────────────┼──────────────────────┤
+  │ 3   │ Encoding     │ [metode]     │ [alasan]             │
+  ├─────┼──────────────┼──────────────┼──────────────────────┤
+  │ 4   │ Normalisasi  │ [metode]     │ [alasan]             │
+  └─────┴──────────────┴──────────────┴──────────────────────┘
+
+DAMPAK PREPROCESSING:
+  Data point sebelum: ___ → sesudah: ___
+  Variabel sebelum  : ___ → sesudah: ___
+  Distribusi berubah: [ya/tidak — detail]
+
+LEAKAGE CHECK:
+  □ Normalisasi parameter dari training set saja
+  □ Tidak ada fitur derivatif dari test set
+  □ Split dilakukan SEBELUM preprocessing
+
+SCRIPT:
+  File: [path ke preprocessing script]
+  Reproducible: [ya/tidak]
+
+═══════════════════════════════════════════════════════════════
+```
+
+---
+
+## 13.10 Mindmap Ringkasan
+
+**Gambar 13.2** — Mindmap Bab 13: Data Preprocessing
+
+```mermaid
+mindmap
+  root(("**Bab 13**<br/>Data<br/>Preprocessing"))
+    ("**Refinement Pipeline**")
+      ("Raw Data → Cleaning")
+      ("Cleaning → Transformation")
+      ("Transformation → Normalization")
+      ("Normalization → Processed")
+      ("Processed → Analysis Ready")
+    ("**Cleaning**")
+      ("Missing values")
+      ("Duplikasi")
+      ("Format error")
+      ("Metode + justifikasi")
+    ("**Transformation**")
+      ("Encoding kategorikal")
+      ("Agregasi level")
+      ("Feature engineering")
+    ("**Normalization**")
+      ("Min-max scaling")
+      ("Z-score")
+      ("Robust scaling")
+      ("Hanya jika diperlukan")
+    ("**4 Prinsip**")
+      ("Consistency")
+      ("Transparency")
+      ("Reproducibility")
+      ("Minimal distortion")
+```
+
+---
+
+## 13.11 Rangkuman
+
+**Poin-poin utama bab ini:**
+
+1. Preprocessing mengubah data — setiap keputusan berpotensi mengubah kesimpulan analisis. Dokumentasi lengkap bukan opsional.
+
+2. Tiga tahap utama: cleaning (missing, duplikat, error), transformation (encoding, agregasi), dan normalization (scaling). Masing-masing hanya dilakukan jika diperlukan.
+
+3. Empat prinsip: consistency (sama untuk semua data), transparency (didokumentasikan), reproducibility (via script), dan minimal distortion (jangan over-preprocess).
+
+4. Data leakage melalui preprocessing (normalisasi menggunakan parameter dari test set) bisa menghasilkan performa artifisial yang overestimated. Parameter preprocessing harus dihitung dari training set saja.
+
+5. Missing data yang bersifat sistematis (bukan random) harus ditangani berbeda dari missing random — dan bisa menjadi temuan riset tersendiri.
+
+Dengan data yang sudah dibersihkan, ditransformasi, dan dinormalisasi secara terdokumentasi, langkah berikutnya adalah analisis dan interpretasi. Bab 14 membahas bagaimana menganalisis data secara statistik, menginterpretasi hasilnya, dan menganalisis kegagalan.
+
+> *"Preprocessing yang baik tidak membuat data 'terlihat bagus' — ia membuat data siap dianalisis tanpa kehilangan cerita yang dikandungnya."*
+
+---
+
+## 13.12 Latihan & Refleksi
+
+### Latihan 1 — Missing Value Strategy
+
+Diberikan dataset simulasi dengan 5% missing values pada kolom training time. Terapkan tiga strategi (listwise deletion, mean imputation, flag & report). Bandingkan: apakah rata-rata training time berubah? Apakah kesimpulan perbandingan antar-skenario berubah?
+
+### Latihan 2 — Preprocessing Pipeline
+
+Buat script preprocessing lengkap (bahasa bebas) untuk dataset eksperimen dari latihan sebelumnya. Script harus mencakup: cleaning, encoding (jika perlu), normalisasi (jika perlu). Dokumentasikan setiap langkah di dalam script sebagai komentar.
+
+### Latihan 3 — Leakage Detection
+
+Review preprocessing pipeline dari Latihan 2. Identifikasi apakah ada potensi data leakage. Jika ada, perbaiki. Jika tidak ada, jelaskan mengapa tidak.
+
+### Refleksi
+
+> "Jika saya menghapus satu baris data dari dataset saya, bisakah saya menjelaskan mengapa — dan apakah orang lain akan setuju dengan alasan tersebut?"
+
+---
+
+## Daftar Pustaka
+
+- Han, J., Kamber, M., & Pei, J. (2012). *Data Mining: Concepts and Techniques* (3rd ed.). Morgan Kaufmann.
+- Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., & Wesslén, A. (2012). *Experimentation in Software Engineering*. Springer.
+- Kuhn, M., & Johnson, K. (2013). *Applied Predictive Modeling*. Springer.
+
+<!-- STATUS: 🟢 Draft Complete -->
+
+<!-- STATUS: ⬜ Not Started -->
--- a/book/bagian-4-analysis/bab-14-data-analysis.md
+++ b/book/bagian-4-analysis/bab-14-data-analysis.md
@ -0,0 +1,385 @@
+# Bab 14 — Data Analysis, Interpretation & Failure Analysis
+
+> **Sub-CPMK:** 4.3 — Menganalisis data, menginterpretasi hasil, dan menganalisis kegagalan
+> **CPMK:** CPMK04 — Analysis & Interpretation
+> **CPL Utama:** CPL03 (Penalaran logis)
+> **Fase:** Scientific Thinking (M13–M16)
+> **Signature Model:** Data → Knowledge Model (Data → Analysis → Interpretation → Explanation → Knowledge)
+
+---
+
+## Ringkasan Bab
+
+Bab ini membahas inti dari riset eksperimental: menganalisis data secara statistik, menginterpretasi hasilnya dalam konteks research question, dan menganalisis kegagalan sebagai sumber insight. Analisis menjawab "apa yang terjadi." Interpretasi menjawab "mengapa terjadi" dan "apa artinya." Failure analysis menjawab "mengapa tidak bekerja" — yang sering kali lebih informatif dari keberhasilan.
+
+---
+
+## 14.1 Pembuka
+
+Bab 12 menyajikan data secara visual. Bab 13 mempersiapkan data melalui preprocessing. Sekarang data siap dianalisis — dan di sinilah riset membuahkan hasil.
+
+Analisis data dalam riset berbeda dari sekadar "menjalankan uji statistik." Ia proses tiga tahap: (1) menganalisis secara kuantitatif — apakah hipotesis didukung data? (2) menginterpretasi hasilnya — apa artinya dalam konteks masalah riset? (3) menganalisis kegagalan — mengapa beberapa aspek tidak bekerja sesuai harapan?
+
+Banyak peneliti berhenti di tahap 1: melaporkan p-value dan berhenti. Tapi p-value tanpa interpretasi adalah angka tanpa makna. Dan keberhasilan tanpa analisis kegagalan adalah kesempatan belajar yang terlewat.
+
+Shadish et al. (2002) menekankan bahwa kesimpulan harus dihubungkan kembali ke research question — bukan sekadar laporan angka. Wohlin et al. (2012) mengingatkan bahwa limitation harus diakui secara eksplisit, bukan disembunyikan. Bab ini menggabungkan ketiganya: analysis, interpretation, dan failure analysis menjadi satu alur utuh.
+
+Pertanyaan sentral bab ini: **Apa yang data katakan tentang hipotesis, dan apa yang bisa dipelajari dari apa yang tidak berjalan sesuai rencana?**
+
+---
+
+## 14.2 Data → Knowledge Model
+
+Model ini menggambarkan alur dari data menuju pengetahuan yang bisa dikontribusikan.
+
+**Gambar 14.1** — Data → Knowledge Model
+
+```mermaid
+graph LR
+    A["📊 <b>Data</b><br/><i>Preprocessed</i>"]
+    B["🔬 <b>Analysis</b><br/><i>Statistik & uji</i>"]
+    C["🧠 <b>Interpretation</b><br/><i>Makna & konteks</i>"]
+    D["💬 <b>Explanation</b><br/><i>Mengapa & limitation</i>"]
+    E["💡 <b>Knowledge</b><br/><i>Kontribusi</i>"]
+
+    A -->|"Uji hipotesis"| B
+    B -->|"Kontekstualisasi"| C
+    C -->|"Refleksi"| D
+    D -->|"Generalisasi"| E
+
+    style A fill:#F5F3FF,stroke:#7C3AED,color:#4C1D95
+    style B fill:#EDE9FE,stroke:#7C3AED,color:#4C1D95
+    style C fill:#DDD6FE,stroke:#7C3AED,color:#4C1D95
+    style D fill:#A78BFA,stroke:#6D28D9,color:#FFFFFF
+    style E fill:#7C3AED,stroke:#6D28D9,color:#FFFFFF
+```
+
+Setiap transisi:
+
+1. **Data → Analysis.** Data yang sudah dipreprocess dianalisis: statistik deskriptif, uji hipotesis, effect size, confidence interval. Analisis menjawab: apakah ada perbedaan? Apakah perbedaan tersebut signifikan?
+
+2. **Analysis → Interpretation.** Hasil analisis dikontekstualisasikan ke research question. "p < 0.05" diterjemahkan menjadi "hipotesis H1 didukung: metode A secara signifikan lebih cepat dari B." Angka menjadi narasi.
+
+3. **Interpretation → Explanation.** Mengapa hasilnya seperti itu? Apa yang menjelaskan keberhasilan? Apa yang menjelaskan kegagalan? Apa limitasinya? Explanation menambahkan reasoning di balik angka.
+
+4. **Explanation → Knowledge.** Penjelasan yang solid menjadi kontribusi pengetahuan — temuan yang bisa digeneralisasi (dengan batasan yang jelas) ke konteks serupa.
+
+---
+
+## 14.3 Definisi Kunci
+
+**Statistical Analysis**
+: Proses menerapkan metode statistik pada data untuk menguji hipotesis — deskriptif (mean, std, median) untuk meringkas, inferensial (t-test, ANOVA, Wilcoxon) untuk menguji perbedaan, dan effect size (Cohen's d, eta-squared) untuk mengukur besarnya perbedaan.
+
+**Interpretation**
+: Proses menghubungkan hasil analisis dengan research question, hipotesis, dan konteks masalah. Interpretation menjawab "apa artinya ini?" — bukan sekadar "berapa angkanya?"
+
+**Failure Analysis**
+: Proses menganalisis secara mendalam mengapa aspek-aspek tertentu dari eksperimen tidak menghasilkan hasil sesuai harapan. Failure analysis bukan pengakuan kelemahan — ia sumber insight yang sering kali lebih berharga dari keberhasilan.
+
+**Limitation**
+: Batasan-batasan yang mempengaruhi generalizability dan validitas kesimpulan. Setiap riset memiliki limitation — mengakuinya secara eksplisit menunjukkan pemahaman mendalam, bukan kelemahan.
+
+---
+
+## 14.4 Konsep Inti
+
+### 14.4.1 Analysis: "Apa yang Terjadi?"
+
+Analisis menjawab pertanyaan faktual tentang data:
+
+**Statistik deskriptif.** Mean, median, standar deviasi, range, percentile. Ini memberikan gambaran umum: skenario mana yang secara numerik lebih baik? Seberapa besar variasi?
+
+**Uji hipotesis.** Menguji apakah perbedaan yang teramati (antara skenario) secara statistik signifikan — bukan kebetulan. Pemilihan uji:
+
+| Kondisi | Uji yang Tepat |
+|---------|---------------|
+| 2 kelompok, data normal, berpasangan | Paired t-test |
+| 2 kelompok, data tidak normal | Wilcoxon signed-rank |
+| > 2 kelompok, data normal | One-way ANOVA + post-hoc |
+| > 2 kelompok, data tidak normal | Kruskal-Wallis + post-hoc |
+| Hubungan 2 variabel kontinu | Pearson (normal) / Spearman (rank) |
+
+Pentingnya: p-value saja tidak cukup. p < 0.05 mengatakan "perbedaan ini kemungkinan bukan kebetulan." Ia tidak mengatakan "perbedaan ini besar" atau "perbedaan ini bermakna secara praktis."
+
+**Effect size.** Mengukur besarnya perbedaan — bukan hanya apakah ada perbedaan. Cohen's d untuk perbandingan dua mean: d < 0.2 (small), 0.2-0.8 (medium), > 0.8 (large). Eta-squared (η²) untuk ANOVA. Effect size memberikan konteks yang p-value tidak bisa.
+
+**Confidence interval.** Rentang di mana nilai sebenarnya kemungkinan berada. CI 95% = [86.5, 89.3] berarti "dengan 95% keyakinan, true mean berada di rentang ini." CI lebih informatif dari p-value — ia memberikan range, bukan binary yes/no.
+
+### 14.4.2 Interpretation: "Apa Artinya?"
+
+Interpretasi menghubungkan angka statistik ke research question:
+
+**Link wajib: Result → RQ → Hypothesis → Conclusion.** Setiap temuan harus diatribusikan kembali ke pertanyaan spesifik yang diajukan. "Berdasarkan uji t berpasangan (p=0.003, d=1.2), metode A secara signifikan lebih cepat dari B, mendukung H1 dan menjawab RQ1."
+
+**Beyond p-value.** Signifikansi statistik bukan signifikansi praktis. Perbedaan 0.3% accuracy mungkin signifikan secara statistik (p=0.02 dengan N=1000) tapi tidak bermakna secara praktis (perbedaannya terlalu kecil untuk berdampak). Interpretasi harus mempertimbangkan keduanya.
+
+**Perbandingan dengan literatur.** Bagaimana hasil ini dibandingkan dengan studi sebelumnya? Apakah konsisten? Jika berbeda, mengapa? Apakah perbedaan kondisi eksperimen (data, environment, implementasi) bisa menjelaskan?
+
+**Implikasi.** Apa konsekuensi dari temuan ini? Untuk peneliti lain (arah riset berikutnya), untuk praktisi (rekomendasi teknis), untuk domain (pemahaman baru).
+
+### 14.4.3 Failure Analysis: "Mengapa Tidak Bekerja?"
+
+Failure analysis sering dilewati — padahal ini bagian yang paling informatif:
+
+**Hipotesis yang ditolak bukan kegagalan riset.** Hipotesis yang ditolak mengatakan sesuatu yang bermakna: "metode yang diusulkan TIDAK lebih baik dari baseline dalam kondisi ini." Ini informasi berharga — ia mencegah peneliti lain mengulangi pendekatan yang sama.
+
+**Mengapa gagal?** Analisis mendalam:
+- **Apakah metode yang salah,** atau implementasi yang kurang tepat?
+- **Apakah masalahnya di data** — dataset terlalu kecil, noise terlalu tinggi, distribusi tidak sesuai asumsi?
+- **Apakah desain eksperimen yang kurang** — metrik tidak sensitif, skenario tidak cukup kontras?
+- **Apakah kondisi boundary** — metode bekerja di dataset tertentu tapi tidak di dataset lain?
+
+**Dari kegagalan ke insight.** "Metode A tidak lebih baik dari B dalam skenario X — analisis lebih lanjut menunjukkan bahwa penyebabnya adalah distribusi data yang highly imbalanced, di mana metode A tidak memiliki mekanisme balancing." Ini insight yang lebih berharga dari sekadar "A = 87%, B = 88%."
+
+### 14.4.4 Limitation: Mengakui Batas
+
+Setiap riset memiliki limitation. Mengakuinya bukan kelemahan — ia bukti pemahaman mendalam. Jenis limitation umum:
+
+**Internal validity.** Apakah ada confounding variable yang tidak terkontrol? Apakah ada bias dalam pengumpulan data?
+
+**External validity.** Apakah hasil bisa digeneralisasi ke dataset lain? Ke domain lain? Ke skala yang berbeda?
+
+**Construct validity.** Apakah metrik yang digunakan benar-benar mengukur apa yang ingin diukur?
+
+**Statistical limitation.** Sample size yang terbatas, asumsi distribusi yang mungkin tidak terpenuhi, multiple comparison yang bisa inflate false positive.
+
+Format pelaporan: jelaskan limitasinya, jelaskan dampak potensialnya terhadap kesimpulan, dan sarankan cara mengatasinya di riset berikutnya.
+
+---
+
+## 14.5 Research vs Engineering
+
+**Tabel 14.1** — Perspektif Analisis: Engineering vs Research
+
+| Aspek | Engineering | Research |
+|-------|------------|----------|
+| **Analisis** | A/B test → deploy yang lebih baik | Uji hipotesis → klaim yang terjustifikasi |
+| **Kegagalan** | Bug → fix → ship | Insight → explain → contribute |
+| **Limitation** | Edge case yang akan ditangani nanti | Boundary kondisi yang diakui dan didokumentasikan |
+| **Metric** | KPI bisnis (revenue, latency) | Metrik riset (accuracy, F1, effect size) |
+| **Kesimpulan** | "Ship metode A" | "Metode A lebih baik dalam kondisi X, dengan limitation Y" |
+
+Perbedaan paling fundamental: engineering bertujuan **memilih** yang terbaik. Research bertujuan **memahami** mengapa yang terbaik lebih baik — dan kapan ia tidak lebih baik.
+
+---
+
+## 14.6 Research Reality
+
+### Fenomena 1 — "p < 0.05. Selesai."
+
+Banyak paper berhenti di p-value. Tabel berisi kolom "p" dengan tanda bintang (**), tanpa effect size, tanpa confidence interval, tanpa interpretasi kontekstual. Reviewer tidak tahu apakah perbedaan yang "signifikan" itu besar atau kecil, bermakna secara praktis atau hanya artefak dari sample size besar.
+
+### Fenomena 2 — "Hipotesis Ditolak = Riset Gagal"
+
+Peneliti yang hipotesisnya ditolak sering menganggap risetnya gagal — dan kadang memanipulasi analisis sampai menemukan "signifikansi." Ini p-hacking: menjalankan berbagai uji statistik sampai salah satunya p < 0.05. Hipotesis yang ditolak secara jujur jauh lebih berharga dari hipotesis yang "diterima" melalui manipulasi.
+
+### Fenomena 3 — "Limitation Satu Kalimat"
+
+Bagian limitation di banyak paper: "Penelitian ini memiliki beberapa keterbatasan yang bisa diatasi dalam penelitian selanjutnya." Kalimat ini tidak mengatakan apa-apa. Limitation yang bermakna: "Eksperimen hanya menggunakan 3 dataset dari domain e-commerce. Generalisasi ke domain lain (healthcare, finance) memerlukan validasi tambahan, karena karakteristik data (class distribution, feature density) mungkin berbeda secara substansial."
+
+---
+
+## 14.7 Cognitive Traps
+
+### Trap 1: "Signifikan secara statistik = penting secara praktis"
+
+Dengan sample size yang cukup besar, perbedaan sekecil apa pun bisa signifikan secara statistik. Perbedaan 0.1% accuracy dengan N=10.000 bisa menghasilkan p < 0.01. Tapi 0.1% hampir tidak ada artinya di dunia nyata. Selalu laporkan effect size bersama p-value.
+
+### Trap 2: "Hipotesis tidak terdukung = harus cari angle baru"
+
+Mengulangi analisis dengan variasi (uji statistik berbeda, subset data berbeda, metrik berbeda) sampai menemukan p < 0.05 adalah p-hacking. Pre-registrasi analisis (menentukan uji yang akan digunakan sebelum melihat data) adalah solusi, tapi setidaknya — laporkan semua analisis yang dilakukan, bukan hanya yang "berhasil."
+
+### Trap 3: "Kegagalan tidak perlu dilaporkan secara detail"
+
+Kegagalan sering disembunyikan atau diringkas dalam satu kalimat. Padahal, analisis mendalam tentang mengapa sesuatu tidak bekerja bisa menjadi kontribusi utama paper — terutama jika menunjukkan batas kondisi (boundary condition) dari metode tertentu.
+
+### Trap 4: "Limitation cukup disebutkan, tidak perlu dianalisis"
+
+Menyebutkan "data terbatas" tanpa membahas dampaknya sama dengan tidak menyebutkan. Limitation harus dianalisis: apa dampaknya terhadap validitas kesimpulan? Seberapa serius? Bagaimana bisa dimitigasi?
+
+---
+
+## 14.8 Studi Kasus
+
+### Kasus 1 (Basic): "Dari p-value ke Interpretasi Utuh"
+
+**Konteks:**
+
+Eksperimen membandingkan metode caching A vs B pada web server. Metrik: response time (ms). 30 run per metode.
+
+**❌ Pendekatan Salah (p-value only):**
+
+"Paired t-test menunjukkan p = 0.021 (*). Metode A secara signifikan lebih baik dari B."
+
+Masalah: signifikan seberapa? Lebih cepat berapa? Dalam kondisi apa? Apa limitasinya?
+
+**✅ Pendekatan Benar (Full interpretation):**
+
+"Metode A menghasilkan rata-rata response time 142 ± 12 ms, dibandingkan metode B dengan 158 ± 18 ms (paired t-test: p = 0.021, Cohen's d = 1.05, 95% CI untuk perbedaan: [3.2, 28.8] ms). Perbedaan 16 ms (10.1%) secara statistik signifikan dan memiliki effect size besar (d > 0.8). Dalam konteks web application di mana threshold user-perceived delay adalah 200 ms, perbedaan ini bermakna secara praktis — metode A tetap di bawah threshold sementara B mendekatinya.
+
+Namun, hasil ini memiliki limitation: eksperimen menggunakan single-server setup dengan beban sintetis. Pada deployment multi-server dengan traffic nyata, faktor jaringan dan load balancing bisa mengubah relative advantage. Selain itu, metode A memiliki memory footprint 40% lebih besar — trade-off yang perlu dipertimbangkan di environment dengan memory constraint."
+
+**Pelajaran:** Interpretasi utuh menghubungkan angka → signifikansi → konteks praktis → limitation. Angka tanpa konteks adalah noise.
+
+---
+
+### Kasus 2 (Advanced): "Failure Analysis Menjadi Kontribusi Utama"
+
+**Konteks:**
+
+Seorang peneliti mengusulkan metode deteksi anomali baru untuk log server. Hipotesis: metode baru lebih akurat dari baseline (Isolation Forest). Eksperimen: 5 dataset, 10 run per dataset.
+
+**Hasil:**
+
+| Dataset | Metode Baru (F1) | Baseline (F1) | p-value | Cohen's d |
+|---------|------------------|---------------|---------|-----------|
+| DS-1 (small, clean) | 94.2 ± 1.1 | 89.3 ± 1.5 | < 0.001 | 3.7 |
+| DS-2 (medium, clean) | 91.7 ± 1.3 | 88.1 ± 1.8 | < 0.001 | 2.3 |
+| DS-3 (large, clean) | 90.5 ± 1.6 | 87.9 ± 2.0 | 0.003 | 1.4 |
+| DS-4 (medium, noisy) | 78.3 ± 3.2 | 82.1 ± 2.8 | 0.008 | -1.3 |
+| DS-5 (large, noisy) | 71.6 ± 4.1 | 80.5 ± 3.0 | < 0.001 | -2.5 |
+
+**Failure analysis:**
+
+Metode baru lebih baik pada dataset bersih (DS-1 sampai DS-3) tapi lebih buruk pada dataset noisy (DS-4, DS-5). Mengapa?
+
+Investigasi: metode baru menggunakan distribusi Gaussian untuk modeling normal behavior. Dataset noisy memiliki heavy-tailed distribution yang melanggar asumsi Gaussian. Baseline (Isolation Forest) non-parametrik — tidak membuat asumsi distribusi — sehingga lebih robust terhadap noise.
+
+**Kontribusi dari kegagalan:** "Metode yang diusulkan mengungguli baseline pada data bersih, tapi bergantung pada asumsi distribusi Gaussian yang dilanggar oleh data noisy. Temuan ini menyarankan bahwa hybrid approach (metode baru untuk data bersih, non-parametrik untuk data noisy) mungkin optimal."
+
+**Pelajaran:** Kegagalan parsial + failure analysis = kontribusi yang lebih kaya daripada keberhasilan penuh tanpa analisis mendalam.
+
+---
+
+## 14.9 Template Praktis
+
+### Template: Analysis & Interpretation Report
+
+```
+═══════════════════════════════════════════════════════════════
+  ANALYSIS & INTERPRETATION — [Judul Penelitian]
+═══════════════════════════════════════════════════════════════
+
+1. DESCRIPTIVE STATISTICS
+   ┌──────────┬──────────┬─────────┬──────────┬──────────────┐
+   │ Skenario │ Mean     │ Std     │ Median   │ 95% CI       │
+   ├──────────┼──────────┼─────────┼──────────┼──────────────┤
+   │          │          │         │          │              │
+   └──────────┴──────────┴─────────┴──────────┴──────────────┘
+
+2. HYPOTHESIS TESTING
+   RQ: _______________________________________________
+   H0: _______________________________________________
+   H1: _______________________________________________
+   Uji: [nama uji] | Justifikasi: [mengapa uji ini]
+   Hasil: p = ___ | Effect size = ___ | CI = ___
+   Keputusan: [tolak/gagal menolak H0]
+
+3. INTERPRETATION
+   Apa artinya dalam konteks RQ: ____________________
+   Perbandingan dengan literatur: ____________________
+   Signifikansi praktis: ____________________________
+
+4. FAILURE ANALYSIS
+   Aspek yang tidak sesuai harapan: _________________
+   Investigasi penyebab: ____________________________
+   Insight dari kegagalan: __________________________
+
+5. LIMITATION
+   ┌─────┬──────────────────┬──────────────┬──────────────┐
+   │ No. │ Limitation       │ Dampak       │ Mitigasi     │
+   ├─────┼──────────────────┼──────────────┼──────────────┤
+   │     │                  │              │              │
+   └─────┴──────────────────┴──────────────┴──────────────┘
+
+═══════════════════════════════════════════════════════════════
+```
+
+---
+
+## 14.10 Mindmap Ringkasan
+
+**Gambar 14.2** — Mindmap Bab 14: Data Analysis, Interpretation & Failure Analysis
+
+```mermaid
+mindmap
+  root(("**Bab 14**<br/>Analysis, Interpretation<br/>& Failure Analysis"))
+    ("**Analysis**")
+      ("Statistik deskriptif")
+      ("Uji hipotesis")
+      ("Effect size")
+      ("Confidence interval")
+    ("**Interpretation**")
+      ("Result → RQ → Conclusion")
+      ("Beyond p-value")
+      ("Perbandingan literatur")
+      ("Implikasi praktis")
+    ("**Failure Analysis**")
+      ("Ditolak ≠ gagal")
+      ("Investigasi penyebab")
+      ("Boundary condition")
+      ("Kegagalan → insight")
+    ("**Limitation**")
+      ("Internal validity")
+      ("External validity")
+      ("Construct validity")
+      ("Statistical limitation")
+    ("**Cognitive Traps**")
+      ("p < 0.05 ≠ penting")
+      ("p-hacking")
+      ("Limitation asal-asalan")
+```
+
+---
+
+## 14.11 Rangkuman
+
+**Poin-poin utama bab ini:**
+
+1. Analisis menjawab "apa yang terjadi" (statistik deskriptif + uji hipotesis + effect size + CI). P-value saja tidak cukup — selalu sertakan effect size dan confidence interval.
+
+2. Interpretasi menjawab "apa artinya" — menghubungkan hasil ke research question, membandingkan dengan literatur, dan menilai signifikansi praktis (bukan hanya statistik).
+
+3. Failure analysis menjawab "mengapa tidak bekerja" — hipotesis yang ditolak bukan kegagalan, melainkan temuan. Analisis penyebab kegagalan sering menghasilkan insight lebih berharga dari keberhasilan.
+
+4. Limitation bukan formalitas — ia analisis jujur tentang batas validitas dan generalizability. Limitation yang spesifik dan dianalisis menunjukkan keahlian, bukan kelemahan.
+
+5. Alur utuh: Data → Analysis → Interpretation → Explanation → Knowledge. Setiap tahap menambahkan layer pemahaman yang tidak bisa di-skip.
+
+Dengan analisis dan interpretasi yang utuh, langkah berikutnya adalah mengkomunikasikan temuan secara tertulis. Bab 15 membahas scientific writing — bagaimana menyusun laporan ilmiah yang menyampaikan argumen riset secara terstruktur dan meyakinkan.
+
+> *"Data yang dianalisis tanpa diinterpretasi adalah angka. Kegagalan yang tidak dianalisis adalah kesempatan yang terbuang."*
+
+---
+
+## 14.12 Latihan & Refleksi
+
+### Latihan 1 — Full Statistical Analysis
+
+Dari data eksperimen (atau data simulasi), lakukan analisis utuh: statistik deskriptif, uji hipotesis (pilih uji yang tepat dan justifikasi), effect size, dan confidence interval. Laporkan hasilnya menggunakan format template.
+
+### Latihan 2 — Interpretasi vs Deskripsi
+
+Tulis dua versi "hasil" dari analisis Latihan 1: (a) versi deskriptif (hanya angka), (b) versi interpretasi (angka + konteks + implikasi). Bandingkan: versi mana yang lebih bermakna bagi pembaca?
+
+### Latihan 3 — Failure Analysis
+
+Identifikasi satu aspek dari eksperimen Anda yang tidak sesuai harapan. Tulis failure analysis: apa yang terjadi, mengapa terjadi (minimal 2 kemungkinan penyebab), dan insight apa yang bisa dipetik.
+
+### Refleksi
+
+> "Jika seseorang bertanya 'apa kontribusi riset Anda?' — bisakah saya menjawab tanpa menyebut angka tunggal, tapi dengan menjelaskan apa yang dipelajari?"
+
+---
+
+## Daftar Pustaka
+
+- Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., & Wesslén, A. (2012). *Experimentation in Software Engineering*. Springer.
+- Shadish, W. R., Cook, T. D., & Campbell, D. T. (2002). *Experimental and Quasi-Experimental Designs for Generalized Causal Inference*. Houghton Mifflin.
+- Field, A. (2018). *Discovering Statistics Using IBM SPSS Statistics* (5th ed.). SAGE Publications.
+- Cohen, J. (1988). *Statistical Power Analysis for the Behavioral Sciences* (2nd ed.). Lawrence Erlbaum.
+
+<!-- STATUS: 🟢 Draft Complete -->
+
+<!-- STATUS: ⬜ Not Started -->
--- a/book/bagian-4-analysis/bab-15-scientific-writing.md
+++ b/book/bagian-4-analysis/bab-15-scientific-writing.md
@ -0,0 +1,385 @@
+# Bab 15 — Scientific Writing
+
+> **Sub-CPMK:** 5.1 — Menulis karya ilmiah yang terstruktur dan argumentatif
+> **CPMK:** CPMK05 — Scientific Communication
+> **CPL Utama:** CPL02 (Karya ilmiah/komunikasi)
+> **Fase:** Scientific Thinking (M13–M16)
+> **Signature Model:** Scientific Argument Flow (Problem → Gap → RQ → Method → Result → Analysis → Conclusion → Contribution)
+
+---
+
+## Ringkasan Bab
+
+Bab ini membahas penulisan ilmiah sebagai proses menyusun argumen riset — bukan sekadar mendokumentasikan apa yang dilakukan. Penulisan ilmiah menerjemahkan seluruh proses riset (Bab 1–14) menjadi satu dokumen koheren yang menyampaikan: apa masalahnya, mengapa penting, apa yang sudah diketahui, apa yang belum, bagaimana diuji, apa hasilnya, dan apa artinya. Bab ini membahas struktur IMRAD, logical flow, konsistensi antar-bagian, dan kualitas penulisan.
+
+---
+
+## 15.1 Pembuka
+
+Semua yang dilakukan sejak Bab 1 — merumuskan masalah, meninjau literatur, menemukan gap, membentuk research question, merancang eksperimen, mengeksekusi, menganalisis — tidak berarti apa-apa jika tidak bisa dikomunikasikan secara tertulis. Riset yang tidak ditulis adalah riset yang tidak ada.
+
+Tapi penulisan ilmiah bukan dokumentasi kronologis ("pertama saya melakukan X, lalu Y, lalu Z"). Ia penyusunan argumen: setiap bagian paper memiliki peran dalam menjelaskan **mengapa** research question penting, **bagaimana** dijawab, dan **apa** yang ditemukan.
+
+Kelemahan paling umum yang ditemukan reviewer bukan di analisis statistik — melainkan di penulisan. Paper dengan analisis yang solid tapi penulisan yang buruk (tidak terstruktur, inkonsisten, tidak jelas) sering ditolak. Sebaliknya, paper yang ditulis dengan jelas — di mana setiap paragraf mengalir secara logis ke paragraf berikutnya — memudahkan reviewer mengevaluasi dan menghargai kontribusi riset.
+
+Pertanyaan sentral bab ini: **Bagaimana menyusun laporan ilmiah yang terstruktur, konsisten, dan menyampaikan argumen riset secara meyakinkan?**
+
+---
+
+## 15.2 Scientific Argument Flow
+
+Model ini menggambarkan alur argumen utama dalam tulisan ilmiah.
+
+**Gambar 15.1** — Scientific Argument Flow
+
+```mermaid
+graph LR
+    A["❗ <b>Problem</b><br/><i>Masalah & motivasi</i>"]
+    B["🔍 <b>Gap</b><br/><i>Apa yang belum</i>"]
+    C["❓ <b>RQ</b><br/><i>Pertanyaan riset</i>"]
+    D["🔧 <b>Method</b><br/><i>Cara menjawab</i>"]
+    E["📊 <b>Result</b><br/><i>Temuan</i>"]
+    F["🧠 <b>Analysis</b><br/><i>Interpretasi</i>"]
+    G["📝 <b>Conclusion</b><br/><i>Jawaban & batasan</i>"]
+    H["💡 <b>Contribution</b><br/><i>Apa yang baru</i>"]
+
+    A -->|"Justifikasi"| B
+    B -->|"Fokus"| C
+    C -->|"Desain"| D
+    D -->|"Eksekusi"| E
+    E -->|"Interpretasi"| F
+    F -->|"Sintesis"| G
+    G -->|"Kontribusi"| H
+
+    style A fill:#F5F3FF,stroke:#7C3AED,color:#4C1D95
+    style B fill:#EDE9FE,stroke:#7C3AED,color:#4C1D95
+    style C fill:#DDD6FE,stroke:#7C3AED,color:#4C1D95
+    style D fill:#C4B5FD,stroke:#6D28D9,color:#4C1D95
+    style E fill:#A78BFA,stroke:#6D28D9,color:#FFFFFF
+    style F fill:#A78BFA,stroke:#6D28D9,color:#FFFFFF
+    style G fill:#7C3AED,stroke:#6D28D9,color:#FFFFFF
+    style H fill:#6D28D9,stroke:#4C1D95,color:#FFFFFF
+```
+
+Flow ini adalah "benang merah" yang menghubungkan seluruh paper. Setiap bagian menjawab satu pertanyaan dalam rantai: Why → What's missing → What's asked → How → What happened → What it means → So what → What's new.
+
+---
+
+## 15.3 Definisi Kunci
+
+**IMRAD**
+: Struktur standar paper ilmiah — Introduction, Method, Results, And Discussion. IMRAD bukan format arbitrary — ia merefleksikan logical flow riset: mengapa dilakukan (I), bagaimana dilakukan (M), apa yang ditemukan (R), apa artinya (D).
+
+**Logical Flow**
+: Keterkaitan logis antar-paragraf dan antar-bagian. Setiap paragraf menjawab satu pertanyaan, dan akhirnya memicu pertanyaan berikutnya yang dijawab oleh paragraf selanjutnya. Paper tanpa logical flow terasa "melompat-lompat."
+
+**Konsistensi Internal**
+: Keselarasan antar-bagian paper: masalah yang dinyatakan di Introduction harus dijawab di Discussion. Metrik yang disebutkan di Method harus muncul di Results. Hipotesis yang diformulasikan harus diuji dan dibahas. Inkonsistensi menunjukkan paper yang "tambal sulam."
+
+**Precision**
+: Menggunakan istilah yang tepat, menghindari ambiguitas, dan menghilangkan kata yang tidak menambah informasi. "Performa model meningkat secara signifikan" tidak presisi. "Akurasi model meningkat dari 85.3% ke 89.7% (p=0.003, d=1.2)" presisi.
+
+---
+
+## 15.4 Konsep Inti
+
+### 15.4.1 Struktur IMRAD dan Role Setiap Bagian
+
+**Introduction** — menyampaikan motivasi, konteks, gap, dan research question. Introduction harus menjawab: mengapa riset ini perlu dilakukan? Apa yang sudah diketahui? Apa yang belum? Apa pertanyaannya? Diakhiri dengan pernyataan kontribusi yang jelas.
+
+**Method** — mendeskripsikan bagaimana riset dilakukan: desain eksperimen, data, environment, implementasi, metrik. Method harus cukup detail untuk reproduksi — orang lain harus bisa mengulang eksperimen menggunakan deskripsi ini saja.
+
+**Results** — melaporkan temuan secara objektif: statistik deskriptif, uji hipotesis, tabel, grafik. Results menyajikan fakta, bukan interpretasi. "Metode A menghasilkan akurasi 88.4 ± 1.2%" adalah result. "Metode A lebih baik karena..." adalah discussion.
+
+**Discussion** — menginterpretasi hasil dalam konteks research question, membandingkan dengan literatur, menganalisis kegagalan, dan menyatakan limitation. Discussion menambahkan **meaning** pada angka yang disajikan di Results.
+
+**Conclusion** — meringkas temuan utama, menjawab research question secara eksplisit, menyatakan kontribusi, dan menyarankan arah riset berikutnya.
+
+### 15.4.2 Logical Flow: Benang Merah Paper
+
+Paper yang baik memiliki "benang merah" — setiap paragraf mengalir secara natural ke paragraf berikutnya. Cara mencapainya:
+
+**Within paragraph.** Setiap paragraf memiliki satu ide utama (topic sentence), didukung oleh bukti/penjelasan, dan diakhiri dengan transisi ke ide berikutnya.
+
+**Between paragraphs.** Kalimat pertama paragraf baru mengacu pada ide dari paragraf sebelumnya, kemudian memperkenalkan ide baru. Ini menciptakan "rantai logis" yang mem-pull pembaca dari satu paragraf ke berikutnya.
+
+**Between sections.** Akhir satu section menyiapkan pembaca untuk section berikutnya. "Setelah mendefinisikan metrik, langkah berikutnya adalah mendesain eksperimen" — transisi natural dari Method bagian metrik ke Method bagian eksperimen.
+
+**Across the paper.** Problem yang dinyatakan di Introduction harus di-address di Discussion dan di-conclude di Conclusion. RQ yang dirumuskan harus dijawab secara eksplisit. Setiap elemen "berjanji" di awal harus "ditepati" di akhir.
+
+### 15.4.3 Konsistensi Antar-Bagian
+
+Inkonsistensi adalah masalah penulisan yang paling merusak credibility. Checklist konsistensi:
+
+| Elemen | Harus Konsisten Di |
+|--------|-------------------|
+| Problem statement | Intro ↔ Discussion ↔ Conclusion |
+| Research question | Intro ↔ Method ↔ Discussion ↔ Conclusion |
+| Hipotesis | Intro ↔ Method ↔ Result ↔ Discussion |
+| Metrik | Method ↔ Result |
+| Klaim | Result ↔ Discussion (didukung data) |
+| Terminologi | Seluruh paper (jangan berganti istilah) |
+
+Inkonsistensi umum: Introduction menyebut 3 research question, tapi Discussion hanya membahas 2. Method mendefinisikan 5 metrik, tapi Results hanya melaporkan 3. Terminologi berubah: "accuracy" di satu tempat menjadi "correctness" di tempat lain.
+
+### 15.4.4 Writing Quality: Clarity, Precision, Conciseness
+
+Tiga dimensi kualitas penulisan:
+
+**Clarity** — apakah kalimat bisa dipahami pada pembacaan pertama? Kalimat yang harus dibaca ulang 2-3 kali untuk dipahami adalah kalimat yang gagal. Cara meningkatkan clarity: kalimat pendek, subject-verb dekat, hindari nested subordinate clause.
+
+**Precision** — apakah setiap istilah digunakan secara tepat? "Model performs well" tidak presisi — well menurut siapa? "Model achieves 91.2% F1-score on benchmark X" presisi.
+
+**Conciseness** — apakah setiap kata menambah informasi? "In this paper, we propose a novel and innovative approach to solve the challenging problem of..." bisa menjadi "We propose an approach to [problem]." Conciseness menghormati waktu pembaca.
+
+---
+
+## 15.5 Research vs Engineering
+
+**Tabel 15.1** — Perspektif Penulisan: Engineering vs Research
+
+| Aspek | Engineering | Research |
+|-------|------------|----------|
+| **Format** | README, design doc, API doc | IMRAD paper, laporan ilmiah |
+| **Tujuan** | Dokumentasi → orang lain bisa pakai | Argumen → community bisa evaluasi |
+| **Audiens** | Developer, user, stakeholder | Reviewer, peneliti, akademisi |
+| **Tone** | Praktis, step-by-step | Formal, argumentatif, evidence-based |
+| **Klaim** | "This tool does X" | "We show that X, supported by evidence Y" |
+| **Evaluasi** | "Does it work?" | "Is it valid? Is it novel? Is it significant?" |
+
+Perbedaan fundamental: dokumentasi engineering menjelaskan *how to use*. Paper ilmiah menjelaskan *why to believe*.
+
+---
+
+## 15.6 Research Reality
+
+### Fenomena 1 — "Paper Ditulis dari Awal ke Akhir secara Kronologis"
+
+Banyak penulis pemula menulis paper dari halaman 1 ke halaman terakhir secara berurutan. Masalahnya: Introduction ditulis sebelum analisis selesai, sehingga "janji" di awal mungkin tidak sesuai "temuan" di akhir. Pendekatan yang lebih efektif: tulis Method dan Results terlebih dahulu (karena sudah pasti), kemudian Discussion (interpretasi), baru Introduction (framing yang sesuai dengan temuan aktual), terakhir Abstract dan Conclusion.
+
+### Fenomena 2 — "Bahasa Berbunga tapi Isi Kosong"
+
+"This groundbreaking research makes seminal contributions to the advancement of knowledge in the field of computer science through a rigorous and comprehensive investigation." — Kalimat sepanjang 23 kata yang tidak mengatakan apa-apa tentang apa yang sebenarnya dilakukan. Reviewer langsung skeptis ketika melihat bahasa berlebihan tanpa substansi.
+
+### Fenomena 3 — "Copy-Paste antar Paper Sendiri"
+
+Peneliti yang menulis beberapa paper sering copy-paste bagian Method dari paper sebelumnya tanpa memastikan konsistensi dengan paper baru. Hasilnya: method section yang menyebut dataset berbeda, metrik berbeda, atau bahkan judul paper berbeda. Inkonsistensi ini langsung terlihat oleh reviewer.
+
+---
+
+## 15.7 Cognitive Traps
+
+### Trap 1: "Semakin panjang, semakin lengkap"
+
+Paper yang panjang bukan paper yang lengkap — ia bisa paper yang tidak diedit. Setiap kalimat harus membawa informasi baru. Pengulangan ide yang sama di paragraf berbeda, kalimat pembuka yang tidak menambah informasi ("It is well known that..."), dan contoh yang redundan — semua ini bisa dipotong tanpa kehilangan substansi.
+
+### Trap 2: "Introduction harus ditulis pertama"
+
+Introduction yang ditulis sebelum analisis selesai sering perlu ditulis ulang. Tulis section yang paling stabil terlebih dahulu (Method, Results), kemudian section yang tergantung temuan (Discussion, Introduction). Urutan penulisan tidak harus sama dengan urutan pembacaan.
+
+### Trap 3: "Istilah teknis membuat paper terlihat lebih ilmiah"
+
+Menggunakan jargon yang tidak perlu membuat paper sulit diakses tanpa menambah presisi. "We utilized a convolutional neural network architecture" ≈ "We used a CNN." Jika istilah sederhana mengatakan hal yang sama, gunakan istilah sederhana. Kompleksitas bahasa tidak sama dengan kompleksitas riset.
+
+### Trap 4: "Discussion = ringkasan Results"
+
+Discussion yang hanya mengulang angka dari Results tanpa menambah interpretasi, perbandingan, atau refleksi bukan Discussion — ia duplikasi. Discussion menjawab "apa artinya" dan "mengapa terjadi" — bukan "berapa angkanya" (itu sudah di Results).
+
+---
+
+## 15.8 Studi Kasus
+
+### Kasus 1 (Basic): "Dari Temuan ke Paper — Struktur IMRAD"
+
+**Konteks:**
+
+Peneliti sudah punya: (1) RQ tentang komparasi metode caching, (2) desain eksperimen (2 skenario × 10 run), (3) hasil analisis (metode A lebih cepat, p=0.02, d=1.05), (4) failure analysis (metode A butuh lebih banyak memory). Perlu disusun menjadi paper.
+
+**Struktur yang Disarankan:**
+
+| Bagian | Isi | Kata Target |
+|--------|-----|-------------|
+| Introduction | Domain (web performance) → Gap (caching comparison kurang) → RQ → Kontribusi | 500-700 |
+| Related Work | Studi caching sebelumnya → Posisi riset ini → Gap | 700-1000 |
+| Method | Desain eksperimen, dataset, environment, metrik, analisis | 800-1200 |
+| Results | Statistik deskriptif, uji hipotesis, tabel, grafik | 500-800 |
+| Discussion | Interpretasi, perbandingan, failure analysis, limitation | 600-900 |
+| Conclusion | Jawaban RQ, kontribusi utama, future work | 200-400 |
+
+**Benang merah:** Introduction berjanji menjawab RQ → Method menjelaskan bagaimana → Results menunjukkan apa yang ditemukan → Discussion menjawab RQ secara eksplisit → Conclusion meringkas jawaban.
+
+**Pelajaran:** Struktur bukan batasan — ia kerangka yang memastikan setiap elemen penting tersampaikan.
+
+---
+
+### Kasus 2 (Advanced): "Inkonsistensi yang Terlewat — dan Dampaknya"
+
+**Konteks:**
+
+Draft paper di-submit ke conference. Reviewer menolak dengan komentar: "Serious inconsistencies between sections."
+
+**Inkonsistensi yang ditemukan:**
+
+| Lokasi | Masalah |
+|--------|---------|
+| Introduction | Menyebut 3 RQ (RQ1, RQ2, RQ3) |
+| Method | Menjelaskan metrik untuk RQ1 dan RQ2 saja — RQ3 tidak ada metrik |
+| Results | Menampilkan 4 tabel — satu menggunakan metrik yang tidak disebutkan di Method |
+| Discussion | Membahas RQ1 dan RQ3 — RQ2 tidak dibahas |
+| Conclusion | Menyebut "novel contribution" yang tidak disebutkan di Introduction |
+
+**Akar masalah:** Paper ditulis oleh 2 orang. Orang A menulis Introduction dan Discussion. Orang B menulis Method dan Results. Mereka tidak melakukan cross-check konsistensi.
+
+**Solusi — Consistency Matrix:**
+
+```
+         Intro  Method  Result  Discuss  Conclude
+RQ1        ✓      ✓       ✓       ✓        ✓
+RQ2        ✓      ✓       ✓       ✗ ←      ✓
+RQ3        ✓      ✗ ←     ✗       ✓        ✓
+Metrik-X   ✗      ✗       ✓ ←     ✗        ✗
+```
+
+Setiap tanda (✗ ←) adalah inkonsistensi yang harus diperbaiki sebelum submit.
+
+**Pelajaran:** Konsistensi antar-bagian bukan detail minor — ia fundamental. Gunakan consistency matrix sebelum submit.
+
+---
+
+## 15.9 Template Praktis
+
+### Template: Paper Structure Checklist
+
+```
+═══════════════════════════════════════════════════════════════
+  PAPER STRUCTURE CHECKLIST — [Judul Paper]
+═══════════════════════════════════════════════════════════════
+
+INTRODUCTION:
+  □ Problem statement jelas
+  □ Gap teridentifikasi dengan referensi
+  □ Research question dinyatakan eksplisit
+  □ Kontribusi disebutkan
+  □ Diakhiri dengan overview struktur paper
+
+METHOD:
+  □ Desain eksperimen lengkap
+  □ Dataset/data dideskripsikan
+  □ Environment terdokumentasi
+  □ Metrik didefinisikan (sesuai RQ)
+  □ Prosedur analisis disebutkan
+  □ Cukup detail untuk reproduksi
+
+RESULTS:
+  □ Statistik deskriptif per skenario
+  □ Uji hipotesis + p-value + effect size
+  □ Tabel dan grafik memenuhi standar
+  □ Semua metrik dari Method dilaporkan
+
+DISCUSSION:
+  □ Interpretasi per RQ
+  □ Perbandingan dengan literatur
+  □ Failure analysis (jika ada)
+  □ Limitation (spesifik, dianalisis)
+
+CONCLUSION:
+  □ Jawaban RQ eksplisit
+  □ Kontribusi utama dirangkum
+  □ Future work spesifik
+
+CONSISTENCY CHECK:
+  □ Setiap RQ: Intro ↔ Method ↔ Result ↔ Discussion ↔ Conclusion
+  □ Setiap metrik: Method ↔ Result
+  □ Setiap klaim: didukung data di Result
+  □ Terminologi konsisten di seluruh paper
+  □ Referensi dalam teks cocok dengan daftar pustaka
+
+═══════════════════════════════════════════════════════════════
+```
+
+---
+
+## 15.10 Mindmap Ringkasan
+
+**Gambar 15.2** — Mindmap Bab 15: Scientific Writing
+
+```mermaid
+mindmap
+  root(("**Bab 15**<br/>Scientific<br/>Writing"))
+    ("**Argument Flow**")
+      ("Problem → Gap → RQ")
+      ("Method → Result")
+      ("Analysis → Conclusion")
+      ("Conclusion → Contribution")
+    ("**IMRAD**")
+      ("Introduction: Why")
+      ("Method: How")
+      ("Results: What")
+      ("Discussion: So what")
+      ("Conclusion: Therefore")
+    ("**Logical Flow**")
+      ("Within paragraph")
+      ("Between paragraphs")
+      ("Between sections")
+      ("Across paper")
+    ("**Writing Quality**")
+      ("Clarity — mudah dipahami")
+      ("Precision — tepat & spesifik")
+      ("Conciseness — tanpa redundansi")
+    ("**Cognitive Traps**")
+      ("Panjang ≠ lengkap")
+      ("Intro bukan ditulis pertama")
+      ("Discussion ≠ ulang Results")
+```
+
+---
+
+## 15.11 Rangkuman
+
+**Poin-poin utama bab ini:**
+
+1. Penulisan ilmiah adalah penyusunan argumen, bukan kronologi. Setiap bagian paper memiliki peran dalam rantai: Why → What's missing → How → What → So what → Therefore.
+
+2. IMRAD (Introduction, Method, Results, Discussion) adalah struktur standar yang merefleksikan logical flow riset. Method dan Results ditulis terlebih dahulu karena paling stabil.
+
+3. Konsistensi internal — antara RQ, metrik, hasil, dan interpretasi — adalah aspek yang paling sering menjadi alasan penolakan. Gunakan consistency matrix sebelum submit.
+
+4. Writing quality terdiri dari clarity (bisa dipahami pada pembacaan pertama), precision (istilah tepat, angka spesifik), dan conciseness (setiap kata menambah informasi).
+
+5. Logical flow menghubungkan seluruh paper menjadi satu narasi koheren — dari paragraf ke paragraf, dari section ke section, dari masalah ke kontribusi.
+
+Dengan paper yang tertulis, langkah terakhir adalah mempertahankannya secara lisan. Bab 16 membahas presentation dan defense — bagaimana menyampaikan argumen riset di depan audiens dan menjawab pertanyaan secara meyakinkan.
+
+> *"Paper yang baik bukan yang menggunakan kata-kata besar — melainkan yang menyampaikan ide besar dengan kata-kata yang tepat."*
+
+---
+
+## 15.12 Latihan & Refleksi
+
+### Latihan 1 — IMRAD Outline
+
+Buat outline paper IMRAD dari riset Anda. Untuk setiap bagian (I, M, R, D), tuliskan 3-5 poin utama yang akan disampaikan. Pastikan ada benang merah: setiap RQ muncul di setiap bagian.
+
+### Latihan 2 — Consistency Matrix
+
+Buat consistency matrix untuk draft Anda: dapatkan setiap RQ di setiap bagian (Intro, Method, Result, Discussion, Conclusion)?Identifikasi inkonsistensi dan perbaiki.
+
+### Latihan 3 — Revisi untuk Clarity
+
+Ambil satu paragraf terpanjang dari draft Anda. Revisi dengan tujuan: (a) setiap kalimat memiliki satu ide, (b) tidak ada kata yang bisa dihapus, (c) semua istilah teknis presisi.
+
+### Refleksi
+
+> "Jika reviewer hanya membaca Introduction dan Conclusion saya — apakah mereka bisa memahami apa masalahnya, apa yang ditemukan, dan apa kontribusinya?"
+
+---
+
+## Daftar Pustaka
+
+- Glasman-Deal, H. (2020). *Science Research Writing: For Non-Native Speakers of English* (2nd ed.). World Scientific.
+- Zobel, J. (2014). *Writing for Computer Science* (3rd ed.). Springer.
+- Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., & Wesslén, A. (2012). *Experimentation in Software Engineering*. Springer.
+
+<!-- STATUS: 🟢 Draft Complete -->
+
+<!-- STATUS: ⬜ Not Started -->
--- a/book/bagian-4-analysis/bab-16-presentation-defense.md
+++ b/book/bagian-4-analysis/bab-16-presentation-defense.md
@ -0,0 +1,416 @@
+# Bab 16 — Presentation & Defense
+
+> **Sub-CPMK:** 6.1 — Mempresentasikan dan mempertahankan argumen riset secara lisan
+> **CPMK:** CPMK06 — Research Defense
+> **CPL Utama:** CPL02 (Karya ilmiah/komunikasi)
+> **Fase:** Scientific Thinking (M13–M16)
+> **Signature Model:** Scientific Defense Model (Research Work → Presentation → Questioning → Defense → Evaluation → Acceptance)
+
+---
+
+## Ringkasan Bab
+
+Bab ini membahas tahap akhir proses riset: mempresentasikan temuan di depan audiens dan mempertahankan argumen melalui tanya-jawab. Presentasi bukan ringkasan paper — ia simulasi peer-review langsung di mana peneliti harus menyampaikan argumen secara jelas dan menjawab pertanyaan secara meyakinkan. Defense bukan pertarungan — ia dialog ilmiah yang menguji validitas, kejelasan, dan kedalaman pemahaman peneliti terhadap risetnya sendiri.
+
+---
+
+## 16.1 Pembuka
+
+Paper sudah ditulis (Bab 15). Seluruh proses riset dari Bab 1 sampai 14 sudah terdokumentasi secara tertulis. Langkah terakhir: menyampaikannya secara lisan — di seminar, conference, atau sidang.
+
+Banyak yang menganggap presentasi adalah "versi ringkas paper." Tapi presentasi dan paper berbeda secara fundamental dalam medium, waktu, dan interaksi. Paper dibaca — pembaca bisa kembali ke halaman sebelumnya. Presentasi didengar — audiens hanya punya satu kesempatan untuk memahami setiap slide. Paper tidak terinterupsi — presentasi bisa ditanya kapan saja. Perbedaan ini memerlukan strategi komunikasi yang berbeda.
+
+Dan kemudian ada defense — bagian di mana peneliti yang mempresentasikan menjadi peneliti yang menjawab. Pertanyaan bisa tentang motivasi ("mengapa masalah ini penting?"), metode ("mengapa memilih uji ini?"), hasil ("bagaimana menjelaskan anomali di tabel 3?"), atau generalisasi ("apakah ini berlaku di domain lain?"). Kemampuan menjawab pertanyaan secara langsung, berbasis data, dan jujur (termasuk mengakui keterbatasan) membedakan peneliti yang memahami risetnya dari yang hanya menjalankannya.
+
+Pertanyaan sentral bab ini: **Bagaimana menyampaikan dan mempertahankan argumen riset secara lisan dengan jelas, meyakinkan, dan jujur?**
+
+---
+
+## 16.2 Scientific Defense Model
+
+Model ini menggambarkan alur dari kerja riset menuju penerimaan melalui presentasi dan defense.
+
+**Gambar 16.1** — Scientific Defense Model
+
+```mermaid
+graph LR
+    A["📄 <b>Research<br/>Work</b><br/><i>Paper/laporan</i>"]
+    B["🎤 <b>Presentation</b><br/><i>Penyampaian</i>"]
+    C["❓ <b>Questioning</b><br/><i>Tanya audiens</i>"]
+    D["🛡️ <b>Defense</b><br/><i>Argumentasi</i>"]
+    E["📋 <b>Evaluation</b><br/><i>Penilaian</i>"]
+    F["✅ <b>Acceptance</b><br/><i>Pengakuan</i>"]
+
+    A -->|"Penyajian"| B
+    B -->|"Interaksi"| C
+    C -->|"Respons"| D
+    D -->|"Justifikasi"| E
+    E -->|"Keputusan"| F
+
+    style A fill:#F5F3FF,stroke:#7C3AED,color:#4C1D95
+    style B fill:#EDE9FE,stroke:#7C3AED,color:#4C1D95
+    style C fill:#DDD6FE,stroke:#7C3AED,color:#4C1D95
+    style D fill:#C4B5FD,stroke:#6D28D9,color:#4C1D95
+    style E fill:#A78BFA,stroke:#6D28D9,color:#FFFFFF
+    style F fill:#7C3AED,stroke:#6D28D9,color:#FFFFFF
+```
+
+Setiap transisi:
+
+1. **Research Work → Presentation.** Riset yang sudah terdokumentasi (paper/laporan) diterjemahkan ke format presentasi: slide, narasi, dan demonstrasi. Bukan ringkasan — melainkan reformulasi untuk medium lisan.
+
+2. **Presentation → Questioning.** Audiens mengajukan pertanyaan berdasarkan apa yang dipresentasikan. Pertanyaan bisa mengklarifikasi ("apa maksudnya...?"), menantang ("mengapa tidak menggunakan...?"), atau memperdalam ("bagaimana jika...?").
+
+3. **Questioning → Defense.** Peneliti merespons pertanyaan menggunakan argumentasi ilmiah: klaim + evidence + reasoning. Defense yang baik mengakui batas pengetahuan — menjawab "belum tahu, tapi akan diinvestigasi" lebih baik dari menjawab asal.
+
+4. **Defense → Evaluation.** Evaluator (penguji, reviewer, audiens) menilai kualitas riset berdasarkan presentasi dan defense: kejelasan pemikiran, kedalaman pemahaman, kualitas respons.
+
+5. **Evaluation → Acceptance.** Riset yang berhasil mempertahankan argumentasinya diterima — sebagai paper, tesis, atau kontribusi ilmiah.
+
+---
+
+## 16.3 Definisi Kunci
+
+**Scientific Presentation**
+: Penyampaian lisan riset menggunakan media visual (slide) yang dirancang untuk audiens yang mendengarkan, bukan membaca. Presentasi harus bisa dipahami oleh audiens dalam satu kali dengar tanpa kesempatan "scroll back."
+
+**Defense (Argumentasi)**
+: Proses mempertahankan keputusan riset — dari pemilihan masalah hingga interpretasi hasil — melalui tanya-jawab dengan audiens atau penguji. Defense bukan debat untuk "menang" — ia dialog untuk mendemonstrasikan pemahaman.
+
+**Claim-Evidence-Reasoning (CER)**
+: Framework argumentasi ilmiah. Claim: pernyataan yang ingin dipertahankan. Evidence: data atau fakta yang mendukung claim. Reasoning: penjelasan logis mengapa evidence mendukung claim.
+
+**Anticipatory Defense**
+: Proses mengidentifikasi pertanyaan potensial sebelum presentasi dan menyiapkan jawaban. Setiap keputusan riset (masalah, metode, metrik, interpretasi) bisa ditanyakan — dan harus bisa dijawab.
+
+---
+
+## 16.4 Konsep Inti
+
+### 16.4.1 Presentasi: Bukan Ringkasan Paper
+
+Slide presentasi bukan halaman paper yang di-paste ke slide. Perbedaan fundamental:
+
+| Paper | Presentasi |
+|-------|-----------|
+| Dibaca (self-paced) | Didengar (presenter-paced) |
+| Detail lengkap | Ide utama + highlight |
+| Tabel numerik detail | Grafik visual + key numbers |
+| Pembaca bisa re-read | Audiens hanya dengar sekali |
+| Referensi lengkap | Referensi minimal |
+
+**Prinsip desain slide:**
+
+**Satu slide, satu pesan.** Setiap slide menyampaikan satu ide utama. Jika slide memerlukan penjelasan lebih dari 2 menit, pecah menjadi 2 slide.
+
+**Visual over text.** Gunakan grafik, diagram, dan key numbers — bukan paragraf. Audiens tidak bisa membaca paragraph panjang sambil mendengarkan narasi. Teks di slide berfungsi sebagai anchor — bukan pengganti narasi.
+
+**Build progression.** Slide harus mengalir: masalah → gap → pertanyaan → metode → temuan → kesimpulan. Setiap slide menjawab pertanyaan yang muncul dari slide sebelumnya.
+
+**Timing.** Aturan umum: 1-2 menit per slide. Presentasi 15 menit = 8-12 slide konten + slide judul + slide penutup. Lebih sedikit slide yang powerful lebih baik dari banyak slide yang rushed.
+
+### 16.4.2 Argumentation: Claim + Evidence + Reasoning
+
+Setiap jawaban dalam defense harus mengikuti struktur CER:
+
+**Claim.** Pernyataan yang dipertahankan. "Metode A lebih efektif dari baseline."
+
+**Evidence.** Data yang mendukung. "Akurasi A = 88.4 ± 1.2%, baseline = 82.3 ± 0.9%, p < 0.001, d = 5.7."
+
+**Reasoning.** Mengapa evidence mendukung claim. "Perbedaan 6.1% secara statistik signifikan dengan effect size sangat besar, menunjukkan bahwa peningkatan bukan artefak variabilitas. Perbedaan ini juga bermakna secara praktis karena melampaui threshold 5% yang umum dianggap meaningful di domain ini."
+
+Jawaban tanpa evidence: opini. Jawaban tanpa reasoning: laporan angka. Argumen yang lengkap memerlukan ketiganya.
+
+### 16.4.3 Anticipating Questions
+
+Pertanyaan dalam defense bisa diprediksi — karena mengikuti pola:
+
+**Pertanyaan tentang masalah:**
+- Mengapa masalah ini penting? Untuk siapa?
+- Apakah sudah ada solusi yang cukup baik?
+
+**Pertanyaan tentang gap:**
+- Apakah gap ini benar-benar belum di-address?
+- Studi X sudah melakukan hal serupa — apa bedanya?
+
+**Pertanyaan tentang metode:**
+- Mengapa memilih metode/metrik/dataset ini?
+- Bagaimana jika menggunakan metode lain?
+- Apakah desain eksperimen valid?
+
+**Pertanyaan tentang hasil:**
+- Bagaimana menjelaskan anomali di hasil?
+- Apakah perbedaan ini bermakna secara praktis?
+- Apa yang terjadi jika kondisinya berbeda?
+
+**Pertanyaan tentang generalisasi:**
+- Apakah hasil ini berlaku di dataset/domain lain?
+- Apa batasan generalisasi?
+
+Untuk setiap pertanyaan yang bisa diprediksi — siapkan jawaban berbasis CER. Pertanyaan yang tidak diprediksi? Jawab dengan jujur: "Pertanyaan yang bagus. Berdasarkan data yang ada, [jawaban terbaik]. Tapi untuk konfirmasi, perlu investigasi lebih lanjut."
+
+### 16.4.4 Handling Questions: Langsung, Data-Based, Jujur
+
+Tiga prinsip menjawab pertanyaan:
+
+**Langsung.** Jawab pertanyaan terlebih dahulu, baru elaborasi. Jangan memulai jawaban dengan backstory 2 menit yang tidak menjawab pertanyaan. "Ya, kami menggunakan dataset X karena [alasan]" — bukan "Jadi, dalam proses riset, kami mempertimbangkan berbagai dataset, dan dalam konteks yang lebih luas, dataset memiliki berbagai karakteristik..."
+
+**Data-based.** Jika ada data yang relevan, gunakan. Arahkan ke slide, tabel, atau grafik spesifik. "Jika kita lihat Tabel 3, skenario tersebut menunjukkan..." Jawaban yang mengacu pada data lebih meyakinkan dari jawaban yang hanya beropini.
+
+**Jujur.** Jika tidak tahu, katakan. "Saya belum menguji skenario tersebut, tapi berdasarkan temuan di DS-1 sampai DS-3, saya memperkirakan [hipotesis]. Ini bisa menjadi investigasi lanjutan." Mengakui batas pengetahuan menunjukkan integritas — dan evaluator menghargai kejujuran lebih dari jawaban yang dibuat-buat.
+
+---
+
+## 16.5 Research vs Engineering
+
+**Tabel 16.1** — Perspektif Presentasi: Engineering vs Research
+
+| Aspek | Engineering | Research |
+|-------|------------|----------|
+| **Format** | Demo, pitch, sprint review | Seminar, conference talk, sidang |
+| **Tujuan** | Convince → adopt/buy/use | Demonstrate → evaluate/accept |
+| **Audiens** | Stakeholder, client | Penguji, reviewer, komunitas |
+| **Pertanyaan** | "Berapa biayanya?" "Kapan ready?" | "Mengapa valid?" "Apa limitasinya?" |
+| **Jawaban ideal** | Pasti, optimistis | Evidence-based, nuanced, jujur |
+
+Perbedaan kritis: engineering pitch menjual solusi. Research defense mendemonstrasikan pemahaman. Audiens engineering ingin tahu apakah ini **berguna**. Audiens riset ingin tahu apakah ini **valid**.
+
+---
+
+## 16.6 Research Reality
+
+### Fenomena 1 — "Slide Penuh Teks, Presenter Membaca"
+
+Slide dengan 10 poin bullet point dan presenter yang membacanya kata per kata. Audiens bisa membaca lebih cepat dari presenter berbicara — jadi mereka membaca sendiri dan berhenti mendengarkan. Slide seharusnya mendukung narasi, bukan menggantikannya. Key points, grafik, dan angka kunci — bukan paragraf.
+
+### Fenomena 2 — "Tidak Bisa Menjawab 'Mengapa'"
+
+Pertanyaan: "Mengapa memilih F1-score dan bukan precision?" Jawaban: "Karena... umm... biasanya penelitian lain juga pakai F1-score." Ini bukan justifikasi — ini konformitas. Jawaban yang benar: "Karena dataset memiliki class imbalance 1:10, dan F1-score menangkap balance antara precision dan recall lebih baik dari accuracy yang bisa misleading pada imbalanced data."
+
+### Fenomena 3 — "Defense sebagai Pertarungan"
+
+Beberapa presenter menganggap pertanyaan sebagai serangan dan merespons secara defensif. "Anda tidak memahami metode saya" atau "Sudah saya jelaskan di slide sebelumnya." Pertanyaan evaluator bukan serangan — ia kesempatan untuk mendemonstrasikan kedalaman pemahaman. Respons terbaik: berterima kasih, jawab dengan data, akui jika ada yang bisa ditingkatkan.
+
+---
+
+## 16.7 Cognitive Traps
+
+### Trap 1: "Presentasi = semua yang ada di paper"
+
+Paper 20 halaman tidak bisa dipresentasikan dalam 15 menit. Presentasi memerlukan seleksi brutal: hanya ide utama, temuan kunci, dan visualisasi terpenting. Detail yang tidak disajikan bisa dijawab saat tanya-jawab — dan justru itu momen defense yang baik.
+
+### Trap 2: "Slide yang indah = presentasi yang baik"
+
+Animasi, gradient, dan font dekoratif tidak membuat argumen lebih kuat. Slide yang paling efektif sering yang paling sederhana: judul yang jelas, satu grafik, satu key number, satu pesan. Estetika membantu, tapi substansi yang menentukan.
+
+### Trap 3: "Pertanyaan yang tidak bisa dijawab = kegagalan"
+
+Tidak semua pertanyaan harus bisa dijawab saat itu juga. Pertanyaan yang menantang batas riset ("bagaimana jika dataset berbeda?" "apakah berlaku di skala industrial?") sering tidak bisa dijawab karena memang di luar scope. Jawab: "Pertanyaan ini di luar scope riset saat ini, tapi merupakan arah yang menarik untuk investigasi selanjutnya." Ini jawaban yang jujur dan profesional.
+
+### Trap 4: "Latihan tidak perlu — saya sudah tahu riset saya"
+
+Mengetahui riset bukan berarti bisa mempresentasikannya dengan baik. Presentasi memerlukan latihan: timing, transisi antar-slide, pacing narasi, dan antisipasi pertanyaan. Latihan 2-3 kali di depan rekan sering mengungkap kelemahan yang tidak terlihat saat berlatih sendiri.
+
+---
+
+## 16.8 Studi Kasus
+
+### Kasus 1 (Basic): "Dari Paper ke Slide — Seleksi Konten"
+
+**Konteks:**
+
+Paper 15 halaman tentang perbandingan metode caching. Ada 5 tabel, 3 grafik, 8 halaman method detail. Presentasi: 15 menit + 5 menit Q&A.
+
+**❌ Pendekatan Salah:**
+
+24 slide yang berusaha memuat semua konten paper. Setiap slide padat. Presenter berbicara cepat dan masih melebihi waktu. Audiens kebingungan di slide ke-10.
+
+**✅ Pendekatan Benar:**
+
+| No. | Slide | Waktu | Pesan |
+|-----|-------|-------|-------|
+| 1 | Judul + konteks | 1 min | Apa riset ini tentang |
+| 2 | Masalah + motivasi | 2 min | Mengapa penting |
+| 3 | Gap + RQ | 1.5 min | Apa yang belum terjawab |
+| 4 | Method overview | 2 min | Bagaimana dijawab (diagram) |
+| 5 | Key result — tabel ringkas | 2 min | Temuan utama |
+| 6 | Key result — grafik | 2 min | Pola visual |
+| 7 | Interpretasi + failure | 2 min | Apa artinya |
+| 8 | Limitation + future | 1.5 min | Batasan & arah |
+| 9 | Conclusion + kontribusi | 1 min | Pesan penutup |
+
+Total: 9 slide, ~15 menit. Detail method, tabel tambahan, dan analisis sekunder tersedia sebagai "backup slide" jika ditanya.
+
+**Pelajaran:** 9 slide yang jelas lebih efektif dari 24 slide yang rushed. Slide yang tidak ditampilkan bisa menjadi amunisi di Q&A.
+
+---
+
+### Kasus 2 (Advanced): "Defense — Pertanyaan Sulit dan Cara Menjawab"
+
+**Konteks:**
+
+Sidang tesis. Penguji mengajukan 4 pertanyaan. Berikut pertanyaan dan dua versi jawaban:
+
+**Q1: "Mengapa hanya menggunakan 3 dataset? Apakah hasilnya bisa digeneralisasi?"**
+
+❌ "Tiga dataset sudah cukup untuk menunjukkan bahwa metode kami bekerja."
+
+✅ "Kami menggunakan 3 dataset yang mewakili variasi karakteristik: dataset kecil-bersih (DS-1), medium-bersih (DS-2), dan medium-noisy (DS-3). Generalisasi ke dataset besar atau domain berbeda memerlukan validasi tambahan — ini kami cantumkan sebagai limitation dan future work di halaman 14."
+
+**Q2: "Hasil di DS-3 menurun. Apakah ini masalah metode Anda?"**
+
+❌ "Itu outlier. Dataset DS-3 memang sulit."
+
+✅ "Ya, penurunan di DS-3 signifikan. Kami analisis di Section 5.3: penyebabnya adalah distribusi heavy-tail yang melanggar asumsi Gaussian dari metode kami. Baseline non-parametrik tidak terdampak. Ini menunjukkan boundary condition: metode kami optimal untuk data berdistribusi normal, tapi memerlukan adaptasi untuk distribusi heavy-tail."
+
+**Q3: "Bagaimana jika menggunakan deep learning approach?"**
+
+❌ "Kami tidak mempertimbangkan deep learning."
+
+✅ "Deep learning approach seperti autoencoder bisa menjadi alternatif yang menarik. Kami tidak menggunakannya karena scope riset ini fokus pada metode statistik yang interpretable. Perbandingan dengan deep learning approach adalah arah future work yang valid."
+
+**Q4: "Anda menyebut 'significant improvement.' Effect size-nya berapa?"**
+
+❌ "P-value-nya 0.003, jadi signifikan."
+
+✅ "Cohen's d = 1.2, yang termasuk large effect. Jadi bukan hanya signifikan secara statistik, tapi besarnya perbedaan juga substansial."
+
+**Pola jawaban yang baik:** Acknowledge → answer with evidence → contextualize → acknowledge limitations if applicable.
+
+---
+
+## 16.9 Template Praktis
+
+### Template: Defense Preparation Sheet
+
+```
+═══════════════════════════════════════════════════════════════
+  DEFENSE PREPARATION — [Judul Penelitian]
+═══════════════════════════════════════════════════════════════
+
+SLIDE PLAN (max 10-12 slide konten):
+  Slide 1: _____________ (1 min)
+  Slide 2: _____________ (2 min)
+  ...
+  Total: ___ slide, ___ menit
+
+ANTICIPATED QUESTIONS & ANSWERS:
+  ┌─────┬──────────────────┬──────────────────────────────────┐
+  │ No. │ Pertanyaan       │ Jawaban (CER format)             │
+  ├─────┼──────────────────┼──────────────────────────────────┤
+  │ 1   │ Mengapa masalah  │ Claim: ___                       │
+  │     │ ini penting?     │ Evidence: ___                    │
+  │     │                  │ Reasoning: ___                   │
+  ├─────┼──────────────────┼──────────────────────────────────┤
+  │ 2   │ Mengapa metode   │ C: ___ E: ___ R: ___            │
+  │     │ ini dipilih?     │                                  │
+  ├─────┼──────────────────┼──────────────────────────────────┤
+  │ 3   │ Bagaimana jika   │ C: ___ E: ___ R: ___            │
+  │     │ [alternatif]?    │                                  │
+  ├─────┼──────────────────┼──────────────────────────────────┤
+  │ 4   │ Apa limitasi     │ C: ___ E: ___ R: ___            │
+  │     │ utama?           │                                  │
+  ├─────┼──────────────────┼──────────────────────────────────┤
+  │ 5   │ Apakah bisa      │ C: ___ E: ___ R: ___            │
+  │     │ digeneralisasi?  │                                  │
+  └─────┴──────────────────┴──────────────────────────────────┘
+
+BACKUP SLIDES:
+  □ Detail method (jika ditanya)
+  □ Tabel lengkap (jika ditanya angka spesifik)
+  □ Analisis tambahan (jika ditanya "bagaimana jika")
+
+PRACTICE LOG:
+  Latihan 1: [tanggal] — [catatan timing & feedback]
+  Latihan 2: [tanggal] — [catatan timing & feedback]
+  Latihan 3: [tanggal] — [catatan timing & feedback]
+
+═══════════════════════════════════════════════════════════════
+```
+
+---
+
+## 16.10 Mindmap Ringkasan
+
+**Gambar 16.2** — Mindmap Bab 16: Presentation & Defense
+
+```mermaid
+mindmap
+  root(("**Bab 16**<br/>Presentation<br/>& Defense"))
+    ("**Defense Model**")
+      ("Research Work")
+      ("Presentation")
+      ("Questioning")
+      ("Defense")
+      ("Evaluation")
+    ("**Slide Design**")
+      ("1 slide = 1 pesan")
+      ("Visual over text")
+      ("Build progression")
+      ("Max 10-12 konten")
+    ("**Argumentation**")
+      ("Claim")
+      ("Evidence")
+      ("Reasoning")
+    ("**Handling Questions**")
+      ("Langsung jawab")
+      ("Data-based")
+      ("Jujur & akui batas")
+      ("Anticipatory defense")
+    ("**Cognitive Traps**")
+      ("Presentasi ≠ seluruh paper")
+      ("Indah ≠ efektif")
+      ("Tidak tahu ≠ gagal")
+```
+
+---
+
+## 16.11 Rangkuman
+
+**Poin-poin utama bab ini:**
+
+1. Presentasi ilmiah bukan ringkasan paper — ia reformulasi riset untuk medium lisan. Prinsip: satu slide satu pesan, visual over text, dan build progression dari masalah ke kontribusi.
+
+2. Defense menggunakan framework Claim-Evidence-Reasoning (CER). Setiap jawaban harus memiliki klaim yang jelas, bukti yang konkret, dan penalaran yang menghubungkan keduanya.
+
+3. Pertanyaan bisa diantisipasi: tentang masalah (mengapa penting), metode (mengapa dipilih), hasil (apa artinya), dan generalisasi (di mana batas berlakunya). Siapkan jawaban CER untuk setiap kategori.
+
+4. Tiga prinsip menjawab: langsung (jawab dulu, elaborasi kemudian), data-based (arahkan ke evidence konkret), dan jujur (akui batas pengetahuan jika memang tidak tahu).
+
+5. Latihan presentasi bukan opsional — ia cara menemukan kelemahan yang tidak terlihat saat berlatih sendiri.
+
+Dengan bab ini, seluruh siklus riset eksperimental selesai — dari merumuskan masalah (Bab 1) hingga mempertahankan temuan (Bab 16). Setiap bab membangun di atas bab sebelumnya, membentuk satu alur utuh yang menghubungkan curiosity dengan kontribusi ilmiah.
+
+> *"Riset yang baik layak dipresentasikan dengan baik. Dan presentasi yang baik dimulai dari pemahaman mendalam tentang apa yang ingin disampaikan — dan mengapa."*
+
+---
+
+## 16.12 Latihan & Refleksi
+
+### Latihan 1 — Slide Deck
+
+Buat slide deck presentasi (max 10 slide konten) dari riset Anda. Untuk setiap slide, tuliskan: pesan utama, elemen visual, dan narasi target (dalam catatan).
+
+### Latihan 2 — Anticipatory Defense
+
+Identifikasi 5 pertanyaan paling mungkin tentang riset Anda. Untuk setiap pertanyaan, siapkan jawaban dalam format CER (Claim + Evidence + Reasoning).
+
+### Latihan 3 — Presentasi & Feedback
+
+Presentasikan slide deck dari Latihan 1 di depan rekan (atau rekam diri sendiri). Minta feedback pada: timing, kejelasan narasi, dan slide yang membingungkan. Perbaiki berdasarkan feedback.
+
+### Refleksi
+
+> "Jika saya hanya punya satu menit untuk menjelaskan riset saya kepada seseorang yang bukan dari bidang saya — apa yang akan saya katakan?"
+
+---
+
+## Daftar Pustaka
+
+- Alley, M. (2013). *The Craft of Scientific Presentations* (2nd ed.). Springer.
+- Glasman-Deal, H. (2020). *Science Research Writing: For Non-Native Speakers of English* (2nd ed.). World Scientific.
+- Toulmin, S. E. (2003). *The Uses of Argument* (Updated ed.). Cambridge University Press.
+
+<!-- STATUS: 🟢 Draft Complete -->
+
+<!-- STATUS: ⬜ Not Started -->
--- a/book/front-matter/daftar-gambar.md
+++ b/book/front-matter/daftar-gambar.md
@ -0,0 +1,66 @@
+# Daftar Gambar
+
+---
+
+## Bagian I — Foundation & Problem Framing
+
+| No. | Gambar | Judul | Hal. |
+|-----|--------|-------|------|
+| 1 | Gambar 1.1 | Research Trust Model: Rantai Kepercayaan dari Realitas ke Pengetahuan | — |
+| 2 | Gambar 1.2 | Paradigm Positioning: Posisi Riset TI dalam Lanskap Paradigma | — |
+| 3 | Gambar 1.3 | Mindmap: Research Mindset in IT | — |
+| 4 | Gambar 2.1 | Problem Formation Model: Dari Realitas ke Variabel Terukur | — |
+| 5 | Gambar 2.2 | Problem Quality Model: 5 Kriteria Masalah Riset yang Layak | — |
+| 6 | Gambar 2.3 | Mindmap Bab 2: Problem Formulation & System Context | — |
+| 7 | Gambar 3.1 | Research Positioning Model: Dari Studi Terdahulu ke Kontribusi | — |
+| 8 | Gambar 3.2 | Empat Jenis Research Gap | — |
+| 9 | Gambar 3.3 | Mindmap: Literature Review, Research Gap & Baseline | — |
+| 10 | Gambar 4.1 | RQ Formation Model: Dari Problem ke Experiment Design | — |
+| 11 | Gambar 4.2 | Tiga Jenis Research Question dan Implikasi Eksperimennya | — |
+| 12 | Gambar 4.3 | Mindmap: Research Question, Contribution & Hypothesis | — |
+
+## Bagian II — Design & Measurement
+
+| No. | Gambar | Judul | Hal. |
+|-----|--------|-------|------|
+| 13 | Gambar 5.1 | Measurement Alignment Model: Dari Problem ke Result | — |
+| 14 | Gambar 5.2 | Mindmap Bab 5: Metric, Measurement & Data | — |
+| 15 | Gambar 6.1 | System as Experiment Model: Dari RQ ke Output Terukur | — |
+| 16 | Gambar 6.2 | Mindmap Bab 6: System Design sebagai Experimental Artifact | — |
+| 17 | Gambar 7.1 | Experimental Validity Model: Dari RQ ke Conclusion yang Valid | — |
+| 18 | Gambar 7.2 | Mindmap Bab 7: Experimental Design & Validity | — |
+
+## Bagian III — Execution & Validation
+
+| No. | Gambar | Judul | Hal. |
+|-----|--------|-------|------|
+| 19 | Gambar 8.1 | Peta Integrasi Proposal: Setiap Bab Harus Terhubung | — |
+| 20 | Gambar 9.1 | Reproducible Implementation Model | — |
+| 21 | Gambar 9.2 | Mindmap Bab 9: Implementation & Environment | — |
+| 22 | Gambar 10.1 | Experiment Execution Pipeline | — |
+| 23 | Gambar 10.2 | Mindmap Bab 10: Experiment Execution & Data Collection | — |
+| 24 | Gambar 11.1 | Data Trust Model | — |
+| 25 | Gambar 11.2 | Mindmap Bab 11: Data Validation & Integrity | — |
+
+## Bagian IV — Analysis & Communication
+
+| No. | Gambar | Judul | Hal. |
+|-----|--------|-------|------|
+| 26 | Gambar 12.1 | Data → Insight Model | — |
+| 27 | Gambar 12.2 | Mindmap Bab 12: Result Presentation & Visualization | — |
+| 28 | Gambar 13.1 | Data Refinement Pipeline | — |
+| 29 | Gambar 13.2 | Mindmap Bab 13: Data Preprocessing | — |
+| 30 | Gambar 14.1 | Data → Knowledge Model | — |
+| 31 | Gambar 14.2 | Mindmap Bab 14: Data Analysis, Interpretation & Failure Analysis | — |
+| 32 | Gambar 15.1 | Scientific Argument Flow | — |
+| 33 | Gambar 15.2 | Mindmap Bab 15: Scientific Writing | — |
+| 34 | Gambar 16.1 | Scientific Defense Model | — |
+| 35 | Gambar 16.2 | Mindmap Bab 16: Presentation & Defense | — |
+
+---
+
+**Total: 35 Gambar** — 16 Signature Model + 15 Mindmap + 4 Diagram Tambahan
+
+> *Nomor halaman akan diisi pada tahap layout final.*
+
+<!-- STATUS: 🟢 Complete -->
--- a/book/front-matter/daftar-isi.md
+++ b/book/front-matter/daftar-isi.md
@ -0,0 +1,90 @@
+# Daftar Isi
+
+---
+
+## Front Matter
+
+- Halaman Judul
+- Kata Pengantar
+- Daftar Isi
+- Daftar Gambar
+- Daftar Tabel
+
+---
+
+## Bagian I — Foundation of Research Thinking
+
+**Bab 1 — Research Mindset in IT**
+1.1 Pembuka · 1.2 Research Trust Model · 1.3 Definisi Kunci · 1.4 Konsep Inti · 1.5 Research vs Engineering · 1.6 Research Reality · 1.7 Cognitive Traps · 1.8 Studi Kasus · 1.9 Template Praktis · 1.10 Mindmap · 1.11 Rangkuman · 1.12 Latihan & Refleksi
+
+**Bab 2 — Problem Formulation**
+2.1 Pembuka · 2.2 Problem Formation Model · 2.3 Definisi Kunci · 2.4 Konsep Inti · 2.5 Research vs Engineering · 2.6 Research Reality · 2.7 Cognitive Traps · 2.8 Studi Kasus · 2.9 Template Praktis · 2.10 Mindmap · 2.11 Rangkuman · 2.12 Latihan & Refleksi
+
+**Bab 3 — Literature Review, Research Gap & Baseline**
+3.1 Pembuka · 3.2 Research Positioning Model · 3.3 Definisi Kunci · 3.4 Konsep Inti · 3.5 Research vs Engineering · 3.6 Research Reality · 3.7 Cognitive Traps · 3.8 Studi Kasus · 3.9 Template Praktis · 3.10 Mindmap · 3.11 Rangkuman · 3.12 Latihan & Refleksi
+
+**Bab 4 — Research Question, Contribution & Hypothesis**
+4.1 Pembuka · 4.2 RQ Formation Model · 4.3 Definisi Kunci · 4.4 Konsep Inti · 4.5 Research vs Engineering · 4.6 Research Reality · 4.7 Cognitive Traps · 4.8 Studi Kasus · 4.9 Template Praktis · 4.10 Mindmap · 4.11 Rangkuman · 4.12 Latihan & Refleksi
+
+---
+
+## Bagian II — Research Design & Planning
+
+**Bab 5 — Metric, Measurement & Data**
+5.1 Pembuka · 5.2 Measurement Alignment Model · 5.3 Definisi Kunci · 5.4 Konsep Inti · 5.5 Research vs Engineering · 5.6 Research Reality · 5.7 Cognitive Traps · 5.8 Studi Kasus · 5.9 Template Praktis · 5.10 Mindmap · 5.11 Rangkuman · 5.12 Latihan & Refleksi
+
+**Bab 6 — System Design sebagai Experimental Artifact**
+6.1 Pembuka · 6.2 System as Experiment Model · 6.3 Definisi Kunci · 6.4 Konsep Inti · 6.5 Research vs Engineering · 6.6 Research Reality · 6.7 Cognitive Traps · 6.8 Studi Kasus · 6.9 Template Praktis · 6.10 Mindmap · 6.11 Rangkuman · 6.12 Latihan & Refleksi
+
+**Bab 7 — Experimental Design & Validity**
+7.1 Pembuka · 7.2 Experimental Validity Model · 7.3 Definisi Kunci · 7.4 Konsep Inti · 7.5 Research vs Engineering · 7.6 Research Reality · 7.7 Cognitive Traps · 7.8 Studi Kasus · 7.9 Template Praktis · 7.10 Mindmap · 7.11 Rangkuman · 7.12 Latihan & Refleksi
+
+---
+
+## Bagian III — Research Execution
+
+**Bab 8 — Proposal & Checkpoint**
+8.1 Pembuka · 8.2 Peta Integrasi · 8.3 Struktur Proposal · 8.4 Rubrik Evaluasi · 8.5 Cognitive Traps · 8.6 Integration Checklist · 8.7 Rangkuman · 8.8 Latihan & Refleksi
+
+**Bab 9 — Implementation & Environment**
+9.1 Pembuka · 9.2 Reproducible Implementation Model · 9.3 Definisi Kunci · 9.4 Konsep Inti · 9.5 Research vs Engineering · 9.6 Research Reality · 9.7 Cognitive Traps · 9.8 Studi Kasus · 9.9 Template Praktis · 9.10 Mindmap · 9.11 Rangkuman · 9.12 Latihan & Refleksi
+
+**Bab 10 — Experiment Execution & Data Collection**
+10.1 Pembuka · 10.2 Experiment Execution Pipeline · 10.3 Definisi Kunci · 10.4 Konsep Inti · 10.5 Research vs Engineering · 10.6 Research Reality · 10.7 Cognitive Traps · 10.8 Studi Kasus · 10.9 Template Praktis · 10.10 Mindmap · 10.11 Rangkuman · 10.12 Latihan & Refleksi
+
+**Bab 11 — Data Validation & Integrity**
+11.1 Pembuka · 11.2 Data Trust Model · 11.3 Definisi Kunci · 11.4 Konsep Inti · 11.5 Research vs Engineering · 11.6 Research Reality · 11.7 Cognitive Traps · 11.8 Studi Kasus · 11.9 Template Praktis · 11.10 Mindmap · 11.11 Rangkuman · 11.12 Latihan & Refleksi
+
+---
+
+## Bagian IV — Analysis & Scientific Communication
+
+**Bab 12 — Result Presentation & Visualization**
+12.1 Pembuka · 12.2 Data → Insight Model · 12.3 Definisi Kunci · 12.4 Konsep Inti · 12.5 Research vs Engineering · 12.6 Research Reality · 12.7 Cognitive Traps · 12.8 Studi Kasus · 12.9 Template Praktis · 12.10 Mindmap · 12.11 Rangkuman · 12.12 Latihan & Refleksi
+
+**Bab 13 — Data Preprocessing**
+13.1 Pembuka · 13.2 Data Refinement Pipeline · 13.3 Definisi Kunci · 13.4 Konsep Inti · 13.5 Research vs Engineering · 13.6 Research Reality · 13.7 Cognitive Traps · 13.8 Studi Kasus · 13.9 Template Praktis · 13.10 Mindmap · 13.11 Rangkuman · 13.12 Latihan & Refleksi
+
+**Bab 14 — Data Analysis, Interpretation & Failure Analysis**
+14.1 Pembuka · 14.2 Data → Knowledge Model · 14.3 Definisi Kunci · 14.4 Konsep Inti · 14.5 Research vs Engineering · 14.6 Research Reality · 14.7 Cognitive Traps · 14.8 Studi Kasus · 14.9 Template Praktis · 14.10 Mindmap · 14.11 Rangkuman · 14.12 Latihan & Refleksi
+
+**Bab 15 — Scientific Writing**
+15.1 Pembuka · 15.2 Scientific Argument Flow · 15.3 Definisi Kunci · 15.4 Konsep Inti · 15.5 Research vs Engineering · 15.6 Research Reality · 15.7 Cognitive Traps · 15.8 Studi Kasus · 15.9 Template Praktis · 15.10 Mindmap · 15.11 Rangkuman · 15.12 Latihan & Refleksi
+
+**Bab 16 — Presentation & Defense**
+16.1 Pembuka · 16.2 Scientific Defense Model · 16.3 Definisi Kunci · 16.4 Konsep Inti · 16.5 Research vs Engineering · 16.6 Research Reality · 16.7 Cognitive Traps · 16.8 Studi Kasus · 16.9 Template Praktis · 16.10 Mindmap · 16.11 Rangkuman · 16.12 Latihan & Refleksi
+
+---
+
+## Back Matter
+
+- Daftar Pustaka
+- Glosarium
+- Lampiran A — Kumpulan Template Praktis
+- Lampiran B — Worksheet
+- Indeks
+- Tentang Penulis
+
+---
+
+<!-- STATUS: 🟢 Draft Complete — Nomor halaman akan ditambahkan pada tahap layout (Fase 4) -->
--- a/book/front-matter/daftar-tabel.md
+++ b/book/front-matter/daftar-tabel.md
@ -0,0 +1,49 @@
+# Daftar Tabel
+
+---
+
+## Bagian I — Foundation & Problem Framing
+
+| No. | Tabel | Judul | Hal. |
+|-----|-------|-------|------|
+| 1 | Tabel 1.1 | Tiga Jenis Validitas dan Ancamannya dalam Riset TI | — |
+| 2 | Tabel 1.2 | Perbandingan Perspektif Research vs Engineering dalam Mindset | — |
+| 3 | Tabel 2.1 | Perbandingan Perspektif Research vs Engineering dalam Problem Formulation | — |
+| 4 | Tabel 3.1 | Perbandingan Perspektif Research vs Engineering dalam Literature & Gap | — |
+| 5 | Tabel 4.1 | Pertanyaan dalam Research vs Engineering | — |
+| 6 | Tabel 4.2 | Perbandingan Versi Awal dan Revisi | — |
+| 7 | Tabel 4.3 | Analisis Revisi | — |
+
+## Bagian II — Design & Measurement
+
+| No. | Tabel | Judul | Hal. |
+|-----|-------|-------|------|
+| 8 | Tabel 5.1 | Perspektif Metrik: Engineering vs Research | — |
+| 9 | Tabel 6.1 | Perspektif Sistem: Engineering vs Research | — |
+| 10 | Tabel 7.1 | Perspektif Eksperimen: Engineering vs Research | — |
+
+## Bagian III — Execution & Validation
+
+| No. | Tabel | Judul | Hal. |
+|-----|-------|-------|------|
+| 11 | Tabel 9.1 | Perspektif Implementasi: Engineering vs Research | — |
+| 12 | Tabel 10.1 | Perspektif Eksekusi: Engineering vs Research | — |
+| 13 | Tabel 11.1 | Perspektif Validasi Data: Engineering vs Research | — |
+
+## Bagian IV — Analysis & Communication
+
+| No. | Tabel | Judul | Hal. |
+|-----|-------|-------|------|
+| 14 | Tabel 12.1 | Perspektif Penyajian: Engineering vs Research | — |
+| 15 | Tabel 13.1 | Perspektif Preprocessing: Engineering vs Research | — |
+| 16 | Tabel 14.1 | Perspektif Analisis: Engineering vs Research | — |
+| 17 | Tabel 15.1 | Perspektif Penulisan: Engineering vs Research | — |
+| 18 | Tabel 16.1 | Perspektif Presentasi: Engineering vs Research | — |
+
+---
+
+**Total: 18 Tabel** — 1 Validitas + 15 Research vs Engineering + 2 Analisis Revisi
+
+> *Nomor halaman akan diisi pada tahap layout final.*
+
+<!-- STATUS: 🟢 Complete -->
--- a/book/front-matter/halaman-judul.md
+++ b/book/front-matter/halaman-judul.md
@ -0,0 +1,39 @@
+# Halaman Judul
+
+---
+
+## RISET TEKNOLOGI INFORMASI
+### Applied Experimental Research in Information Systems & Software Engineering
+
+**Buku Ajar Berbasis OBE (Outcome-Based Education)**
+
+---
+
+**Penulis:**
+Helmi Bahar Alim, S.Kom., M.Kom.
+
+**Institusi:**
+Universitas Putra Bangsa (UPB), Kebumen
+Fakultas Sains dan Teknologi — Program Studi Teknik Informatika
+
+---
+
+**Penerbit:**
+[Nama Penerbit]
+
+**ISBN:**
+[Nomor ISBN]
+
+**Edisi:**
+Pertama, 2026
+
+---
+
+**Format:** B5 (17.6 cm × 25 cm)
+**Halaman:** 250–350 halaman
+
+---
+
+*© 2026, Helmi Bahar Alim. Hak cipta dilindungi undang-undang.*
+
+<!-- STATUS: 🟢 Complete -->
--- a/book/front-matter/kata-pengantar.md
+++ b/book/front-matter/kata-pengantar.md
@ -0,0 +1,42 @@
+# Kata Pengantar
+
+---
+
+Buku ini lahir dari satu pengamatan sederhana: banyak peneliti di bidang Teknologi Informasi dan Software Engineering yang mampu membangun sistem canggih, tetapi kesulitan ketika diminta merancang eksperimen yang valid, menginterpretasi data secara tepat, atau mempertahankan temuan di hadapan reviewer yang skeptis. Masalahnya bukan di kemampuan teknis — melainkan di cara berpikir.
+
+Riset eksperimental memiliki logika tersendiri. Ia menuntut disiplin yang berbeda dari software development: setiap klaim harus didukung bukti empiris, setiap pengukuran harus dijustifikasi, setiap kesimpulan harus mempertimbangkan alternatif. Buku-buku metodologi penelitian yang tersedia umumnya bersifat generik — berlaku untuk semua bidang tetapi tidak cukup spesifik untuk konteks TI/SE di mana "eksperimen" berarti membandingkan algoritma, mengevaluasi arsitektur sistem, atau mengukur performa framework.
+
+**Riset Teknologi Informasi: Applied Experimental Research in Information Systems & Software Engineering** ditulis untuk mengisi celah tersebut. Buku ini bukan pengganti mata kuliah Metodologi Penelitian. Ia adalah panduan praktis tentang *bagaimana menjalankan riset eksperimental* — dari merumuskan masalah hingga mempertahankan temuan. Setiap bab mengikuti **Research Pipeline** sebagai tulang punggung: masalah → literatur → pertanyaan → desain → eksekusi → analisis → komunikasi.
+
+### Filosofi Pedagogis
+
+Buku ini dirancang berbasis **Outcome-Based Education (OBE)**. Setiap bab memiliki Capaian Pembelajaran Mata Kuliah (CPMK) yang terukur. Konten tidak berhenti di teori — setiap bab menyediakan *signature model* (model konseptual khas), *cognitive traps* (kesalahan berpikir yang umum), *studi kasus* (bad practice vs good practice), *template praktis*, dan *latihan* yang bisa langsung dikerjakan.
+
+Pendekatan ini dipilih karena riset tidak bisa dipelajari hanya dengan membaca. Riset dipelajari dengan **melakukan**: merumuskan masalah yang bisa gagal, merancang eksperimen yang fair, menjalankan percobaan yang reproducible, menganalisis data tanpa cherry-picking, dan menulis temuan yang jujur.
+
+### Cara Menggunakan Buku Ini
+
+Buku terdiri dari empat bagian yang mengikuti alur riset eksperimental:
+
+- **Bagian I — Foundation of Research Thinking** (Bab 1–4): Membangun pola pikir, merumuskan masalah, menemukan posisi di literatur, dan mentransformasi gap menjadi research question.
+- **Bagian II — Research Design & Planning** (Bab 5–7): Mendefinisikan metrik, merancang sistem sebagai instrumen eksperimen, dan mendesain eksperimen terkontrol.
+- **Bagian III — Research Execution** (Bab 8–11): Merakit proposal, mengimplementasikan sistem, menjalankan eksperimen, dan memvalidasi data.
+- **Bagian IV — Analysis & Scientific Communication** (Bab 12–16): Menyajikan hasil, memproses data, menganalisis temuan, menulis paper, dan mempertahankan riset.
+
+Setiap bab bisa dibaca berurutan (untuk pemahaman utuh) atau secara modular (untuk referensi cepat pada tahap riset tertentu). **Lampiran A** menyediakan kumpulan template yang bisa langsung digunakan, dan **Lampiran B** berisi worksheet lengkap dari seluruh latihan.
+
+### Ucapan Terima Kasih
+
+Buku ini tidak akan terwujud tanpa kontribusi banyak pihak. Terima kasih kepada kolega di Fakultas Sains dan Teknologi, Universitas Putra Bangsa yang memberikan masukan pada draft awal. Terima kasih kepada para reviewer yang memberikan kritik tajam dan konstruktif. Dan terima kasih kepada para peneliti — baik yang berpengalaman maupun yang baru memulai — yang menjadi inspirasi dari setiap contoh dan studi kasus dalam buku ini.
+
+### Harapan
+
+Satu hal yang ingin dicapai buku ini: *mengubah cara pembaca berpikir tentang riset*. Bukan sekadar tugas akademik, melainkan proses intelektual yang menuntut kejujuran, ketelitian, dan kerendahan hati. Jika setelah membaca buku ini, pembaca mulai mempertanyakan klaim "95% akurat" alih-alih langsung menerima — maka tujuan buku ini tercapai.
+
+---
+
+**Bekasi, Maret 2026**
+
+Helmi Bahar Alim, S.Kom., M.Kom.
+
+<!-- STATUS: 🟢 Draft Complete -->
--- a/docs/disscus01.md
+++ b/docs/disscus01.md
--- a/docs/disscus02.md
+++ b/docs/disscus02.md
--- a/docs/disscus03.md
+++ b/docs/disscus03.md
--- a/docs/disscus04.md
+++ b/docs/disscus04.md
--- a/templates/WRITING-TEMPLATE.md
+++ b/templates/WRITING-TEMPLATE.md
@ -0,0 +1,271 @@
+# WRITING TEMPLATE — Template Penulisan Per Bab
+
+> Copy template ini saat memulai bab baru.
+> Ganti placeholder `[...]` dengan konten aktual.
+> Pastikan semua section terisi sebelum bab dianggap selesai.
+> Validasi terhadap MASTER-ANCHOR.md dan BOOK-SPEC.md.
+
+---
+
+```markdown
+# Bab [Nomor] — [JUDUL BAB]
+
+> **Sub-CPMK:** [Nomor Sub-CPMK] — [Deskripsi]
+> **CPMK:** [Nomor CPMK] — [Deskripsi]
+> **CPL Utama:** [CPL]
+> **Fase:** [Thinking / Designing / Executing / Scientific Thinking]
+
+---
+
+## Ringkasan Bab
+
+[1 paragraf: apa yang akan dipelajari di bab ini dan mengapa penting]
+
+---
+
+## [Nomor].1 Pembuka
+
+[OPENING BRIDGE — hubungkan dengan bab sebelumnya]
+
+[Narasi semi-formal yang membangun konteks. 3–5 paragraf.
+Bangun dari fenomena/masalah → pertanyaan kunci → mengapa bab ini penting.
+Akhiri dengan pertanyaan utama yang akan dijawab di bab ini.]
+
+---
+
+## [Nomor].2 [Nama Signature Model]
+
+[Gambar/Diagram Signature Model — referensi ke file di assets/diagrams/]
+
+**Gambar [Nomor].1** — [Caption model]
+
+[Penjelasan setiap komponen model. 2–4 paragraf.]
+
+> 💡 **Insight Kunci:**
+> [Satu kalimat insight terpenting dari model ini]
+
+---
+
+## [Nomor].3 Definisi Kunci
+
+> 📌 **[Istilah 1]**
+> [Definisi formal. 1–2 kalimat.]
+
+> 📌 **[Istilah 2]**
+> [Definisi formal. 1–2 kalimat.]
+
+> 📌 **[Istilah 3]** *(jika diperlukan)*
+> [Definisi formal. 1–2 kalimat.]
+
+---
+
+## [Nomor].4 Konsep Inti
+
+### [Nomor].4.1 [Sub-konsep 1]
+
+[Penjelasan mendalam. Bukan deskripsi, tapi reasoning.
+Gunakan contoh, analogi, atau perbandingan.]
+
+### [Nomor].4.2 [Sub-konsep 2]
+
+[Penjelasan mendalam.]
+
+### [Nomor].4.3 [Sub-konsep 3] *(jika diperlukan)*
+
+[Penjelasan mendalam.]
+
+---
+
+## [Nomor].5 Research vs Engineering
+
+**Tabel [Nomor].1** — Perbandingan Perspektif Research vs Engineering
+
+| Aspek | Engineering | Research |
+|-------|------------|----------|
+| [Aspek 1] | [Engineering view] | [Research view] |
+| [Aspek 2] | [Engineering view] | [Research view] |
+| [Aspek 3] | [Engineering view] | [Research view] |
+| [Aspek 4] | [Engineering view] | [Research view] |
+
+> 💡 **Insight:**
+> [Kalimat kunci yang menjelaskan perbedaan fundamental]
+
+---
+
+## [Nomor].6 Research Reality
+
+### Fenomena 1 — [Nama Fenomena]
+[Penjelasan fenomena nyata yang sering terjadi. 1–2 paragraf.]
+
+### Fenomena 2 — [Nama Fenomena]
+[Penjelasan. 1–2 paragraf.]
+
+### Fenomena 3 — [Nama Fenomena] *(opsional)*
+[Penjelasan. 1–2 paragraf.]
+
+> 💡 **Insight:**
+> [Pelajaran utama dari fenomena-fenomena ini]
+
+---
+
+## [Nomor].7 Cognitive Traps
+
+> ⚠️ **Trap 1: "[Kalimat yang sering muncul dalam riset pemula]"**
+> [Penjelasan mengapa ini salah dan apa yang seharusnya. 2–3 kalimat.]
+
+> ⚠️ **Trap 2: "[Kalimat]"**
+> [Penjelasan. 2–3 kalimat.]
+
+> ⚠️ **Trap 3: "[Kalimat]"**
+> [Penjelasan. 2–3 kalimat.]
+
+> ⚠️ **Trap 4: "[Kalimat]"** *(opsional)*
+> [Penjelasan. 2–3 kalimat.]
+
+---
+
+## [Nomor].8 Studi Kasus
+
+### Kasus 1 (Basic): "[Judul Kasus]"
+
+**Konteks:**
+[Deskripsi situasi. 1–2 paragraf.]
+
+**❌ Pendekatan Salah (Bad Approach):**
+[Apa yang biasanya dilakukan. Mengapa salah.]
+
+**✅ Pendekatan Benar (Good Approach):**
+[Apa yang seharusnya dilakukan. Mengapa benar.]
+
+**Perbandingan:**
+
+| Aspek | Bad | Good |
+|-------|-----|------|
+| [Aspek 1] | [Bad] | [Good] |
+| [Aspek 2] | [Bad] | [Good] |
+
+> 💡 **Pelajaran:** [Insight dari kasus ini]
+
+---
+
+### Kasus 2 (Advanced): "[Judul Kasus]"
+
+**Konteks:**
+[Deskripsi situasi. 1–2 paragraf.]
+
+**❌ Pendekatan Salah:**
+[Apa yang salah. Mengapa.]
+
+**✅ Pendekatan Benar:**
+[Apa yang benar. Mengapa.]
+
+**Perbandingan:**
+
+| Aspek | Bad | Good |
+|-------|-----|------|
+| [Aspek 1] | [Bad] | [Good] |
+| [Aspek 2] | [Bad] | [Good] |
+
+> 💡 **Pelajaran:** [Insight dari kasus ini]
+
+---
+
+## [Nomor].9 Template Praktis
+
+> 🔧 **Template: [Nama Template]**
+>
+> ```
+> [Struktur template siap diisi pembaca]
+> ```
+
+---
+
+## [Nomor].10 Mindmap Ringkasan
+
+[Gambar mindmap — referensi ke file di assets/diagrams/]
+
+**Gambar [Nomor].2** — Mindmap Bab [Nomor]
+
+---
+
+## [Nomor].11 Rangkuman
+
+**Poin-poin utama bab ini:**
+1. [Poin 1]
+2. [Poin 2]
+3. [Poin 3]
+4. [Poin 4]
+5. [Poin 5]
+
+[CLOSING BRIDGE — hubungkan ke bab berikutnya]
+
+> 🔥 **Final Statement:**
+> "[Kalimat penutup kuat — ringkasan filosofis bab ini]"
+
+---
+
+## [Nomor].12 Latihan & Refleksi
+
+### Pertanyaan Refleksi
+1. [Pertanyaan reflektif — bukan hafalan, tapi berpikir]
+2. [Pertanyaan]
+3. [Pertanyaan]
+
+### Latihan Praktis
+1. [Instruksi latihan — harus menghasilkan artefak]
+2. [Instruksi latihan] *(opsional)*
+
+---
+
+<!-- METADATA INTERNAL (tidak dicetak) -->
+
+### AI-Ready Prompt
+```
+[Prompt yang bisa digunakan untuk generate/expand konten bab ini menggunakan AI]
+```
+
+### Referensi Bab Ini
+- [Referensi 1 — format APA]
+- [Referensi 2]
+- [Referensi 3]
+
+### Checklist Penyelesaian
+- [ ] Narasi pembuka kuat
+- [ ] Signature model (diagram)
+- [ ] Definisi kunci lengkap
+- [ ] Konsep inti mendalam
+- [ ] Research vs Engineering
+- [ ] Research Reality (2–3 fenomena)
+- [ ] Cognitive Traps (3–4)
+- [ ] Case Study Basic (bad vs good)
+- [ ] Case Study Advanced (bad vs good)
+- [ ] Template praktis
+- [ ] Mindmap
+- [ ] Rangkuman + closing bridge
+- [ ] Latihan & refleksi
+- [ ] Sitasi ≥ 3 referensi
+- [ ] Lulus 3 Quality Gates
+- [ ] Konsisten dengan MASTER-ANCHOR
+```
+
+---
+
+## CARA MENGGUNAKAN TEMPLATE INI
+
+1. **Copy** seluruh konten di atas (dari `# Bab [Nomor]` hingga akhir)
+2. **Buat file baru** di folder bab yang sesuai, misal:
+   `book/bagian-1-foundation/bab-02-problem-formulation.md`
+3. **Ganti semua placeholder** `[...]`
+4. **Tulis** setiap section secara berurutan
+5. **Validasi** terhadap:
+   - `MASTER-ANCHOR.md` (anti-drift)
+   - `BOOK-SPEC.md` (format & gaya)
+   - `REFERENCES.md` (sitasi)
+   - `BLUEPRINT.md` (konsistensi konten)
+6. **Centang** semua item di Checklist Penyelesaian
+7. **Review** menggunakan Quality Gates
+
+---
+
+*Template ini berlaku untuk semua bab (Bab 1–16).*
+*Terakhir diperbarui: 30 Maret 2026*
--- a/worksheets/ws-01-problem-statement.md
+++ b/worksheets/ws-01-problem-statement.md
@ -0,0 +1,109 @@
+# WS-01: Distorsi & Paradigma
+> **Bab Terkait:** Bab 1 — Research Mindset in IT
+> **Tujuan:** Mengidentifikasi potensi distorsi dalam rantai riset dan menentukan posisi paradigma
+> **Referensi:** Lampiran B.1 | Template A.1
+
+---
+
+## Latihan 1 — Identifikasi Distorsi
+
+Pilih satu paper riset di bidang TI yang mengklaim "metode X meningkatkan performa." Telusuri setiap tahap Research Trust Model.
+
+**Paper yang dipilih:**
+> Judul: _______________________________________________
+> Penulis (Tahun): ______________________________________
+
+| Tahap | Apa yang Dilakukan | Potensi Distorsi |
+|-------|-------------------|-----------------|
+| Reality → Data | | |
+| Data → Processing | | |
+| Processing → Analysis | | |
+| Analysis → Inference | | |
+| Inference → Knowledge | | |
+
+**Distorsi paling besar di tahap:** ________________________
+
+**Dua distorsi spesifik yang teridentifikasi:**
+1. ___________________________________________________
+2. ___________________________________________________
+
+---
+
+## Latihan 2 — Analisis Kasus Etika
+
+Skenario: Seorang peneliti menemukan bahwa jika 3 data point outlier dihapus, hasil eksperimennya menjadi signifikan. Dengan outlier, hasilnya tidak signifikan.
+
+**Apa yang seharusnya dilakukan?**
+
+| Perspektif | Analisis |
+|------------|---------|
+| Kejujuran ilmiah | |
+| Transparansi | |
+| Peer review | |
+
+**Keputusan akhir dan justifikasi:**
+> ___________________________________________________
+
+---
+
+## Latihan 3 — Posisi Paradigma
+
+**Topik riset:** ________________________________________
+
+| Kriteria | Positivis | Interpretivis | Design Science |
+|----------|-----------|---------------|----------------|
+| Kesesuaian dengan topik (1–5) | | | |
+| Jenis data yang dikumpulkan | | | |
+| Limitasi paradigma | | | |
+
+**Paradigma yang dipilih:** _____________________________
+**Alasan:** ____________________________________________
+
+---
+
+## Refleksi
+
+> *"Sebelum membaca bab ini, apakah saya pernah mempertanyakan klaim '95% akurat'? Setelah memahami rantai distorsi, pertanyaan apa yang sekarang akan saya ajukan?"*
+
+**Jawaban refleksi:**
+> ___________________________________________________
+> ___________________________________________________
+
+---
+<!-- Worksheet dari Bab 1 — Research Mindset in IT -->
+
+---
+
+## Bagian 2 — Masalah
+
+**Apa masalahnya?**
+> [Tulis masalah spesifik, bukan keluhan umum]
+
+**Siapa yang terdampak?**
+> [Stakeholder]
+
+**Apa akibatnya jika tidak diselesaikan?**
+> [Impact]
+
+---
+
+## Bagian 3 — Problem Statement
+
+**Versi 1 (draft):**
+> [Tulis problem statement pertama]
+
+**Versi 2 (refined):**
+> [Perbaiki setelah review]
+
+---
+
+## Checklist Validasi
+- [ ] Spesifik (bukan terlalu luas)
+- [ ] Measureable (bisa diukur)
+- [ ] Relevan dengan bidang TI/SE
+- [ ] Feasible (bisa diselesaikan dalam scope riset)
+- [ ] Bukan sekedar "implementasi sistem"
+
+---
+
+<!-- Template ini akan di-expand saat Bab 2 selesai ditulis -->
--- a/worksheets/ws-02-literature-matrix.md
+++ b/worksheets/ws-02-literature-matrix.md
@ -0,0 +1,71 @@
+# WS-02: Problem Statement
+> **Bab Terkait:** Bab 2 — Problem Formulation & System Context
+> **Tujuan:** Merumuskan problem statement yang tajam dan terukur
+> **Referensi:** Lampiran B.2 | Template A.2
+
+---
+
+## Refleksi 1 — Masalah atau Solusi?
+
+**Topik riset dalam satu kalimat:**
+> ___________________________________________________
+
+**Apakah ini masalah riset atau solusi yang disamarkan sebagai masalah?**
+- [ ] Masalah riset
+- [ ] Solusi yang disamarkan
+
+**Jika solusi — mundur satu langkah. Masalah yang mendasari:**
+> ___________________________________________________
+
+---
+
+## Refleksi 2 — System Context
+
+| Komponen | Deskripsi |
+|----------|----------|
+| Input | |
+| Process | |
+| Output | |
+| Outcome | |
+| Constraints | |
+| Stakeholders | |
+
+**Komponen yang paling sulit diisi:** ______________________
+**Mengapa:** ___________________________________________
+
+---
+
+## Praktis 1 — Problem Formation Model
+
+| Tahap | Isian |
+|-------|-------|
+| Reality | |
+| Symptom | |
+| Diagnosed Problem | |
+| Researchable Problem | |
+| Measurable Variable | |
+
+---
+
+## Praktis 2 — Problem Quality Evaluation
+
+| Kriteria | Skor (1–5) | Catatan |
+|----------|-----------|--------|
+| Clarity | | |
+| Measurability | | |
+| Relevance | | |
+| Testability | | |
+| Impact | | |
+
+**Skor rekan (independen):**
+
+| Kriteria | Skor Sendiri | Skor Rekan | Selisih |
+|----------|-------------|-----------|---------|
+| Clarity | | | |
+| Measurability | | | |
+| Relevance | | | |
+| Testability | | | |
+| Impact | | | |
+
+---
+<!-- Worksheet dari Bab 2 — Problem Formulation & System Context -->
--- a/worksheets/ws-03-gap-analysis.md
+++ b/worksheets/ws-03-gap-analysis.md
@ -0,0 +1,67 @@
+# WS-03: Literature Mapping & Gap
+> **Bab Terkait:** Bab 3 — Literature Review, Research Gap & Baseline
+> **Tujuan:** Memetakan literatur secara sistematis dan mengidentifikasi gap
+> **Referensi:** Lampiran B.3 | Template A.3
+
+---
+
+## Latihan 1 — Concept-Centric Literature Table
+
+**Topik riset:** ________________________________________
+
+| # | Study | Method | Dataset | Result | Limitasi |
+|---|-------|--------|---------|--------|----------|
+| 1 | | | | | |
+| 2 | | | | | |
+| 3 | | | | | |
+| 4 | | | | | |
+| 5 | | | | | |
+| 6 | | | | | |
+| 7 | | | | | |
+| 8 | | | | | |
+| 9 | | | | | |
+| 10 | | | | | |
+
+**Pola yang terlihat — Metode dominan:** ___________________
+**Limitasi yang berulang:** ______________________________
+
+---
+
+## Latihan 2 — Gap Identification
+
+| Jenis Gap | Ditemukan? | Gap Statement |
+|-----------|-----------|---------------|
+| Performance Gap | [ ] Ya / [ ] Tidak | |
+| Method Gap | [ ] Ya / [ ] Tidak | |
+| Data Gap | [ ] Ya / [ ] Tidak | |
+| Context Gap | [ ] Ya / [ ] Tidak | |
+
+**Gap utama yang dipilih:** _____________________________
+**Justifikasi mengapa gap ini penting:**
+> ___________________________________________________
+
+---
+
+## Latihan 3 — Baseline Selection Challenge
+
+| # | Baseline | Mengapa Relevan | Mengapa Representatif | Sumber Paper |
+|---|----------|----------------|----------------------|-------------|
+| 1 | | | | |
+| 2 | | | | |
+| 3 | | | | |
+
+**Evaluasi fairness — Apakah ini straw man comparison?**
+- [ ] Tidak — baseline cukup kuat
+- [ ] Ya — perlu baseline yang lebih kompetitif
+
+---
+
+## Refleksi
+
+> *"Sebelum membaca bab ini, bagaimana cara saya membaca paper? Apakah saya merangkum atau menganalisis? Apa yang akan saya ubah?"*
+
+**Jawaban refleksi:**
+> ___________________________________________________
+
+---
+<!-- Worksheet dari Bab 3 — Literature Review, Research Gap & Baseline -->
--- a/worksheets/ws-04-rq-formulation.md
+++ b/worksheets/ws-04-rq-formulation.md
@ -0,0 +1,60 @@
+# WS-04: RQ & Hypothesis
+> **Bab Terkait:** Bab 4 — Research Question, Contribution & Hypothesis
+> **Tujuan:** Mentransformasi gap menjadi RQ dan merumuskan hipotesis
+> **Referensi:** Lampiran B.4 | Template A.4
+
+---
+
+## Latihan 1 — Dari Gap ke RQ
+
+**Gap statement (dari WS-03 Latihan 2):**
+> ___________________________________________________
+
+**RQ Draft:**
+> ___________________________________________________
+
+**Checklist RQ:**
+- [ ] Variabel spesifik disebutkan
+- [ ] Metrik jelas
+- [ ] Baseline ada
+- [ ] Konteks disebutkan
+- [ ] Memerlukan eksperimen untuk menjawab
+
+**Jenis RQ:** [ ] Descriptive / [ ] Comparative / [ ] Relational
+
+---
+
+## Latihan 2 — Contribution Statement
+
+| Komponen | Isian |
+|----------|-------|
+| Apa yang akan diketahui setelah riset | |
+| Jenis contribution | |
+| Gap spesifik yang diisi | |
+
+---
+
+## Latihan 3 — Hypothesis Pair
+
+| Komponen | Isian |
+|----------|-------|
+| H$_0$ (Null Hypothesis) | |
+| H$_1$ (Alternative Hypothesis) | |
+| Threshold | |
+| Justifikasi threshold | |
+
+**Apakah hipotesis bisa gagal?**
+- [ ] Ya — jika hasil menunjukkan ________________________________
+- [ ] Tidak → reformulasi diperlukan
+
+---
+
+## Refleksi
+
+> *"Apakah research question saya bisa dijawab dengan 'tergantung'? Jika ya, bagaimana saya membuatnya lebih spesifik?"*
+
+**Jawaban refleksi:**
+> ___________________________________________________
+
+---
+<!-- Worksheet dari Bab 4 — Research Question, Contribution & Hypothesis -->
--- a/worksheets/ws-05-hypothesis-builder.md
+++ b/worksheets/ws-05-hypothesis-builder.md
@ -0,0 +1,63 @@
+# WS-05: Variabel & Metrik
+> **Bab Terkait:** Bab 5 — Metric, Measurement & Data
+> **Tujuan:** Operasionalisasi variabel dan mendefinisikan metrik pengukuran
+> **Referensi:** Lampiran B.5 | Template A.5
+
+---
+
+## Latihan 1 — Operasionalisasi Lengkap
+
+**RQ (dari WS-04):** ___________________________________
+
+### Variabel Independen (IV)
+
+| Konsep | Variabel | Metrik | Skala | Satuan | Cara Mengukur |
+|--------|----------|--------|-------|--------|--------------|
+| | | | | | |
+| | | | | | |
+
+### Variabel Dependen (DV)
+
+| Konsep | Variabel | Metrik | Skala | Satuan | Cara Mengukur |
+|--------|----------|--------|-------|--------|--------------|
+| | | | | | |
+| | | | | | |
+
+### Control Variable (CV)
+
+| Variabel | Nilai yang Dikontrol | Alasan |
+|----------|---------------------|--------|
+| | | |
+| | | |
+
+---
+
+## Latihan 2 — Construct Validity Check
+
+| Metrik | Apakah Mengukur Konsep yang Dimaksud? | Threat | Mitigasi |
+|--------|--------------------------------------|--------|---------|
+| | | | |
+| | | | |
+| | | | |
+
+---
+
+## Latihan 3 — Metric Conflict
+
+**Apakah ada DV yang trade-off?** [ ] Ya / [ ] Tidak
+
+| DV Primer | DV Sekunder | Skenario Konflik | Keputusan |
+|-----------|-------------|-----------------|-----------|
+| | | | |
+
+---
+
+## Refleksi
+
+> *"Jika seseorang mempertanyakan 'apa buktinya bahwa metrik Anda mengukur apa yang Anda klaim?' — bisakah saya menjawab?"*
+
+**Jawaban refleksi:**
+> ___________________________________________________
+
+---
+<!-- Worksheet dari Bab 5 — Metric, Measurement & Data -->
--- a/worksheets/ws-06-research-design.md
+++ b/worksheets/ws-06-research-design.md
@ -0,0 +1,61 @@
+# WS-06: System-Experiment Mapping
+> **Bab Terkait:** Bab 6 — System Design sebagai Experimental Artifact
+> **Tujuan:** Memetakan RQ dan variabel ke arsitektur sistem
+> **Referensi:** Lampiran B.6 | Template A.6
+
+---
+
+## Latihan 1 — Mapping RQ ke Arsitektur
+
+**RQ (dari WS-04):** ___________________________________
+
+| Variabel | Tipe (IV/DV/CV) | Komponen Sistem | Cara Pengukuran di Sistem |
+|----------|----------------|----------------|--------------------------|
+| | | | |
+| | | | |
+| | | | |
+| | | | |
+
+**Diagram arsitektur (gambar atau tempel di bawah):**
+
+> [Ruang untuk diagram arsitektur]
+
+---
+
+## Latihan 2 — Evaluasi 4 Prinsip
+
+| Prinsip | Skor (1–3) | Evaluasi | Perlu Diperbaiki? |
+|---------|-----------|---------|-------------------|
+| Traceability | | | |
+| Variable Isolation | | | |
+| Measurement Integration | | | |
+| Reproducibility | | | |
+
+**Prinsip dengan skor terendah:** __________________________
+**Rencana perbaikan:** __________________________________
+
+---
+
+## Latihan 3 — Skenario "Bagaimana Jika"
+
+| Skenario | Komponen yang Berubah | Dampak |
+|----------|----------------------|--------|
+| Dataset berubah | | |
+| Metrik ditambah satu | | |
+| Baseline baru ditambahkan | | |
+
+**Apakah arsitektur mendukung perubahan tanpa redesign?**
+- [ ] Ya
+- [ ] Tidak → perlu redesign bagian: ______________________
+
+---
+
+## Refleksi
+
+> *"Apakah sistem yang saya bangun adalah produk yang kebetulan diujikan, atau instrumen yang sengaja dirancang untuk menguji hipotesis?"*
+
+**Jawaban refleksi:**
+> ___________________________________________________
+
+---
+<!-- Worksheet dari Bab 6 — System Design sebagai Experimental Artifact -->
--- a/worksheets/ws-07-metric-definition.md
+++ b/worksheets/ws-07-metric-definition.md
@ -0,0 +1,66 @@
+# WS-07: Experimental Design & Validity
+> **Bab Terkait:** Bab 7 — Experimental Design & Validity
+> **Tujuan:** Merancang eksperimen terkontrol dan mengidentifikasi ancaman validitas
+> **Referensi:** Lampiran B.7 | Template A.7
+
+---
+
+## Latihan 1 — Identifikasi Ancaman Validitas
+
+**Paper yang dipilih:** _________________________________
+
+| Jenis Validitas | Ancaman yang Teridentifikasi | Mitigasi yang Diusulkan |
+|----------------|------------------------------|------------------------|
+| Internal | | |
+| External | | |
+| Construct | | |
+| Conclusion | | |
+
+---
+
+## Latihan 2 — Desain Perbandingan yang Fair
+
+**RQ (dari WS-04):** ___________________________________
+
+| Komponen | Isian |
+|----------|-------|
+| Kondisi 1 (treatment) | |
+| Kondisi 2 (baseline/control) | |
+| IV yang dimanipulasi | |
+| DV yang diukur | |
+| CV yang dikontrol | |
+| Jumlah run per kondisi | |
+| Seed/randomization strategy | |
+
+**Fairness Checklist:**
+- [ ] Kedua kondisi menggunakan dataset yang sama
+- [ ] Hanya satu variabel yang berbeda antar-kondisi
+- [ ] Metrik evaluasi sama untuk kedua kondisi
+- [ ] Jumlah run cukup untuk variabilitas
+- [ ] Threshold ditentukan sebelum eksperimen
+
+---
+
+## Latihan 3 — Kausalitas vs Korelasi
+
+| Syarat Kausalitas | Terpenuhi? | Bukti |
+|-------------------|-----------|-------|
+| Kovariansi | [ ] Ya / [ ] Tidak | |
+| Temporal precedence | [ ] Ya / [ ] Tidak | |
+| Eliminasi alternatif | [ ] Ya / [ ] Tidak | |
+
+**Apakah desain mendukung klaim kausal?** [ ] Ya / [ ] Tidak
+**Jika tidak — perbaikan yang diperlukan:**
+> ___________________________________________________
+
+---
+
+## Refleksi
+
+> *"Jika reviewer bertanya 'bagaimana Anda tahu ini bukan kebetulan?' — apakah desain eksperimen saya memberikan jawaban yang meyakinkan?"*
+
+**Jawaban refleksi:**
+> ___________________________________________________
+
+---
+<!-- Worksheet dari Bab 7 — Experimental Design & Validity -->
--- a/worksheets/ws-08-experiment-plan.md
+++ b/worksheets/ws-08-experiment-plan.md
@ -0,0 +1,65 @@
+# WS-08: Proposal Integration
+> **Bab Terkait:** Bab 8 — Proposal & Checkpoint
+> **Tujuan:** Merakit proposal dari output WS-02 hingga WS-07 dan mengevaluasi koherensi
+> **Referensi:** Lampiran B.8 | Template A.8
+
+---
+
+## Latihan 1 — Integration Map
+
+Ambil output dari WS-02 (problem statement), WS-03 (gap), WS-04 (RQ & hipotesis), WS-05 (metrik), WS-06 (arsitektur), WS-07 (desain eksperimen). Susun ke dalam satu dokumen proposal.
+
+| Bagian Proposal | Sumber Worksheet | Status |
+|----------------|------------------|--------|
+| Problem Statement | WS-02 | [ ] Lengkap |
+| Literature Gap | WS-03 | [ ] Lengkap |
+| Research Question | WS-04 | [ ] Lengkap |
+| Hipotesis | WS-04 | [ ] Lengkap |
+| Variabel & Metrik | WS-05 | [ ] Lengkap |
+| Arsitektur Sistem | WS-06 | [ ] Lengkap |
+| Desain Eksperimen | WS-07 | [ ] Lengkap |
+
+**Koneksi yang terputus (jika ada):**
+> ___________________________________________________
+
+---
+
+## Latihan 2 — Self-Assessment
+
+| Kriteria | Skor (1–5) | Catatan |
+|----------|-----------|--------|
+| Koherensi | | |
+| Specificity | | |
+| Feasibility | | |
+| Rigor | | |
+
+**Dua kriteria dengan skor terendah:**
+1. __________________ → Rencana perbaikan: ________________
+2. __________________ → Rencana perbaikan: ________________
+
+---
+
+## Latihan 3 — Peer Review
+
+**Nama reviewer:** ______________________________________
+
+| Item Checklist | Terpenuhi? | Rekomendasi |
+|---------------|-----------|-------------|
+| Problem → Gap terhubung | [ ] Ya / [ ] Tidak | |
+| Gap → RQ terhubung | [ ] Ya / [ ] Tidak | |
+| RQ → Hipotesis terhubung | [ ] Ya / [ ] Tidak | |
+| Hipotesis → Metrik terhubung | [ ] Ya / [ ] Tidak | |
+| Metrik → Arsitektur terhubung | [ ] Ya / [ ] Tidak | |
+| Arsitektur → Eksperimen terhubung | [ ] Ya / [ ] Tidak | |
+
+---
+
+## Refleksi
+
+> *"Jika proposal saya dievaluasi bukan dari panjangnya, melainkan dari koherensi koneksi antar-bagian — apakah ia akan lulus?"*
+
+**Jawaban refleksi:**
+> ___________________________________________________
+
+---
+<!-- Worksheet dari Bab 8 — Proposal & Checkpoint -->
--- a/worksheets/ws-09-data-collection-log.md
+++ b/worksheets/ws-09-data-collection-log.md
@ -0,0 +1,79 @@
+# WS-09: Implementation & Reproducibility
+> **Bab Terkait:** Bab 9 — Implementation & Environment
+> **Tujuan:** Mendokumentasikan setup implementasi untuk reprodusibilitas
+> **Referensi:** Lampiran B.9 | Template A.9
+
+---
+
+## Latihan 1 — Environment Audit
+
+### Hardware
+
+| Komponen | Spesifikasi |
+|----------|------------|
+| CPU | |
+| RAM | |
+| GPU (jika relevan) | |
+| Storage | |
+
+### Software & Dependencies
+
+| Software/Library | Versi Spesifik | Sumber | Keterangan |
+|-----------------|---------------|--------|-----------|
+| OS | | | |
+| Runtime/Compiler | | | |
+| Framework | | | |
+| Library 1 | | | |
+| Library 2 | | | |
+| Library 3 | | | |
+| Database | | | |
+
+### Configuration
+
+| Parameter | Nilai | Justifikasi |
+|-----------|-------|------------|
+| | | |
+| | | |
+| | | |
+
+---
+
+## Latihan 2 — Reproducibility Test
+
+**Nama rekan yang mereproduksi:** __________________________
+
+| Aspek | Berhasil? | Waktu | Catatan |
+|-------|----------|-------|--------|
+| Clone repository | [ ] Ya / [ ] Tidak | | |
+| Install dependencies | [ ] Ya / [ ] Tidak | | |
+| Jalankan kode | [ ] Ya / [ ] Tidak | | |
+| Hasil sesuai | [ ] Ya / [ ] Tidak | | |
+
+**Total waktu setup:** ___________________________________
+**Perbaikan dokumentasi berdasarkan feedback:**
+> ___________________________________________________
+
+---
+
+## Latihan 3 — Configuration Versioning
+
+**Repository URL:** _____________________________________
+
+**Checklist:**
+- [ ] Konfigurasi terpisah dari kode (config file)
+- [ ] Setiap eksperimen bisa dijalankan ulang dari commit tertentu
+- [ ] README berisi instruksi reproduksi minimal
+- [ ] requirements.txt / go.mod / package.json tersedia
+- [ ] .gitignore dikonfigurasi (tidak ada data besar di repo)
+
+---
+
+## Refleksi
+
+> *"Jika laptop saya hilang besok, bisakah saya merekonstruksi seluruh eksperimen dari dokumentasi yang ada?"*
+
+**Jawaban refleksi:**
+> ___________________________________________________
+
+---
+<!-- Worksheet dari Bab 9 — Implementation & Environment -->
--- a/worksheets/ws-10-threat-checklist.md
+++ b/worksheets/ws-10-threat-checklist.md
@ -0,0 +1,64 @@
+# WS-10: Execution & Data Collection
+> **Bab Terkait:** Bab 10 — Experiment Execution & Data Collection
+> **Tujuan:** Menyusun execution plan dan menjalankan pilot run
+> **Referensi:** Lampiran B.10 | Template A.10
+
+---
+
+## Latihan 1 — Execution Plan Lengkap
+
+| Skenario | Deskripsi | Jumlah Run | Seeds | Parameter | Format Output |
+|----------|----------|-----------|-------|-----------|--------------|
+| S1 | | min. 5 | | | |
+| S2 | | min. 5 | | | |
+| S3 | | min. 5 | | | |
+
+**Total run yang direncanakan:** __________________________
+
+---
+
+## Latihan 2 — Pilot Run & Anomaly
+
+**Skenario pilot:** _____________________________________
+
+| Check | Hasil | Status |
+|-------|-------|--------|
+| Output sesuai format? | | [ ] OK / [ ] Fix |
+| Data point lengkap? | | [ ] OK / [ ] Fix |
+| Waktu eksekusi masuk akal? | | [ ] OK / [ ] Fix |
+
+**Anomali yang ditemukan:**
+1. ___________________________________________________
+2. ___________________________________________________
+
+**Tindakan koreksi:**
+> ___________________________________________________
+
+---
+
+## Latihan 3 — Data Integrity Check
+
+| Data Point | Run ID | File Output | Traceable? |
+|-----------|--------|------------|-----------|
+| | | | [ ] Ya / [ ] Tidak |
+| | | | [ ] Ya / [ ] Tidak |
+| | | | [ ] Ya / [ ] Tidak |
+
+**Apakah semua data point bisa ditelusuri ke run spesifik?**
+- [ ] Ya, semua traceable
+- [ ] Tidak — data point yang hilang: ______________________
+
+**Laporan integritas:**
+> ___________________________________________________
+
+---
+
+## Refleksi
+
+> *"Jika saya mengklaim '30 run per skenario' — bisakah saya menunjukkan 30 file output yang masing-masing bisa ditelusuri ke run spesifik?"*
+
+**Jawaban refleksi:**
+> ___________________________________________________
+
+---
+<!-- Worksheet dari Bab 10 — Experiment Execution & Data Collection -->
--- a/worksheets/ws-11-reproducibility.md
+++ b/worksheets/ws-11-reproducibility.md
@ -0,0 +1,67 @@
+# WS-11: Data Validation
+> **Bab Terkait:** Bab 11 — Data Validation & Integrity
+> **Tujuan:** Memvalidasi kelengkapan, konsistensi, dan keandalan data eksperimen
+> **Referensi:** Lampiran B.11 | Template A.11
+
+---
+
+## Latihan 1 — Completeness Check
+
+| Skenario | Data Point Diharapkan | Data Point Tersedia | Hilang | Penanganan |
+|----------|----------------------|--------------------|---------|-----------| 
+| S1 | | | | |
+| S2 | | | | |
+| S3 | | | | |
+
+**Simulasi: 2 run hilang (timeout). Dampak:**
+> ___________________________________________________
+
+**Keputusan penanganan data hilang:**
+- [ ] Re-run
+- [ ] Hapus skenario
+- [ ] Lanjutkan dengan catatan
+
+---
+
+## Latihan 2 — Anomaly Investigation
+
+**Skenario anomali:** Satu skenario menunjukkan performa 10x lebih baik dari rata-rata.
+
+| Langkah Investigasi | Temuan |
+|--------------------|--------|
+| 1. Cek apakah bug di kode | |
+| 2. Cek cache effect | |
+| 3. Cek parameter input | |
+| 4. Cek environment (background process) | |
+| 5. Re-run dengan seed berbeda | |
+
+**Keputusan:** [ ] Bug / [ ] Cache effect / [ ] Genuine result
+**Justifikasi:** ________________________________________
+
+---
+
+## Latihan 3 — Full Validation Report
+
+| Aspek Validasi | Status | Catatan |
+|---------------|--------|--------|
+| Completeness | [ ] Pass / [ ] Fail | |
+| Consistency | [ ] Pass / [ ] Fail | |
+| Range check | [ ] Pass / [ ] Fail | |
+| Logical validity | [ ] Pass / [ ] Fail | |
+
+**Keputusan final:**
+- [ ] Data siap analisis
+- [ ] Perlu cleaning (detail: _________________________)
+- [ ] Perlu re-run (detail: ___________________________)
+
+---
+
+## Refleksi
+
+> *"Jika reviewer meminta raw data dan log eksperimen — apakah saya bisa menyediakannya dalam 10 menit?"*
+
+**Jawaban refleksi:**
+> ___________________________________________________
+
+---
+<!-- Worksheet dari Bab 11 — Data Validation & Integrity -->
--- a/worksheets/ws-12-ethics-review.md
+++ b/worksheets/ws-12-ethics-review.md
@ -0,0 +1,65 @@
+# WS-12: Result Presentation
+> **Bab Terkait:** Bab 12 — Result Presentation & Visualization
+> **Tujuan:** Menyajikan hasil eksperimen dalam tabel dan visualisasi yang efektif
+> **Referensi:** Lampiran B.12 | Template A.12
+
+---
+
+## Latihan 1 — Tabel Hasil
+
+| Skenario | Metrik 1 (mean +/- std) | Metrik 2 (mean +/- std) | Runs | Rank |
+|----------|------------------------|------------------------|------|------|
+| | | | | |
+| | | | | |
+| | | | | |
+| | | | | |
+
+**Apakah tabel self-contained (bisa dipahami tanpa teks)?** [ ] Ya / [ ] Tidak
+
+---
+
+## Latihan 2 — Visualisasi Multi-Metrik
+
+### Grafik 1
+
+**Jenis grafik:** _______________________________________
+**Pesan utama:** ________________________________________
+**Alasan pemilihan jenis grafik:** ________________________
+**Observasi awal:** _____________________________________
+
+> [Ruang untuk grafik atau referensi file]
+
+### Grafik 2
+
+**Jenis grafik:** _______________________________________
+**Pesan utama:** ________________________________________
+**Alasan pemilihan jenis grafik:** ________________________
+**Observasi awal:** _____________________________________
+
+> [Ruang untuk grafik atau referensi file]
+
+---
+
+## Latihan 3 — Bias Detection
+
+| Bias | Grafik 1 | Grafik 2 |
+|------|---------|---------|
+| Truncated axis? | [ ] Ya / [ ] Tidak | [ ] Ya / [ ] Tidak |
+| Missing error bar? | [ ] Ya / [ ] Tidak | [ ] Ya / [ ] Tidak |
+| Cherry-picked data? | [ ] Ya / [ ] Tidak | [ ] Ya / [ ] Tidak |
+| Misleading scale? | [ ] Ya / [ ] Tidak | [ ] Ya / [ ] Tidak |
+
+**Perbaikan yang dilakukan:**
+> ___________________________________________________
+
+---
+
+## Refleksi
+
+> *"Jika grafik saya dilihat tanpa caption — apakah pesannya tetap jelas? Jika tidak, grafik perlu diperbaiki."*
+
+**Jawaban refleksi:**
+> ___________________________________________________
+
+---
+<!-- Worksheet dari Bab 12 — Result Presentation & Visualization -->
--- a/worksheets/ws-13-stat-plan.md
+++ b/worksheets/ws-13-stat-plan.md
@ -0,0 +1,62 @@
+# WS-13: Preprocessing
+> **Bab Terkait:** Bab 13 — Data Preprocessing
+> **Tujuan:** Menangani missing values, membuat pipeline preprocessing, dan mendeteksi leakage
+> **Referensi:** Lampiran B.13 | Template A.13
+
+---
+
+## Latihan 1 — Missing Value Strategy
+
+**Dataset:** ____________________________________________
+**Persentase missing values:** __________________________
+
+| Strategi | Rata-rata Setelah | Kesimpulan Perbandingan Berubah? |
+|----------|------------------|-------------------------------|
+| Listwise deletion | | [ ] Ya / [ ] Tidak |
+| Mean imputation | | [ ] Ya / [ ] Tidak |
+| Flag & report | | [ ] Ya / [ ] Tidak |
+
+**Strategi yang dipilih:** _______________________________
+**Justifikasi:** ________________________________________
+
+---
+
+## Latihan 2 — Preprocessing Pipeline
+
+**Bahasa/tool yang digunakan:** __________________________
+
+| Step | Operasi | Input | Output | Komentar |
+|------|---------|-------|--------|---------|
+| 1 | Cleaning | | | |
+| 2 | Encoding (jika perlu) | | | |
+| 3 | Normalisasi (jika perlu) | | | |
+| 4 | Feature engineering (jika perlu) | | | |
+
+**Script/file referensi:** ______________________________
+
+---
+
+## Latihan 3 — Leakage Detection
+
+| Potensi Leakage | Ditemukan? | Perbaikan |
+|----------------|-----------|----------|
+| Test data masuk ke training | [ ] Ya / [ ] Tidak | |
+| Future information di features | [ ] Ya / [ ] Tidak | |
+| Target variable di preprocessing | [ ] Ya / [ ] Tidak | |
+| Normalisasi sebelum split | [ ] Ya / [ ] Tidak | |
+
+**Kesimpulan leakage check:**
+- [ ] Tidak ada leakage — karena: _______________________
+- [ ] Ada leakage — diperbaiki dengan: ___________________
+
+---
+
+## Refleksi
+
+> *"Jika saya menghapus satu baris data — bisakah saya menjelaskan mengapa, dan apakah orang lain akan setuju?"*
+
+**Jawaban refleksi:**
+> ___________________________________________________
+
+---
+<!-- Worksheet dari Bab 13 — Data Preprocessing -->
--- a/worksheets/ws-14-result-interpretation.md
+++ b/worksheets/ws-14-result-interpretation.md
@ -0,0 +1,75 @@
+# WS-14: Analysis & Interpretation
+> **Bab Terkait:** Bab 14 — Data Analysis, Interpretation & Failure Analysis
+> **Tujuan:** Menganalisis data, menginterpretasi hasil, dan melakukan failure analysis
+> **Referensi:** Lampiran B.14 | Template A.14
+
+---
+
+## Latihan 1 — From Data to Decision
+
+### Statistik Deskriptif
+
+| Metrik | Mean | Std Dev | Min | Max | Median |
+|--------|------|---------|-----|-----|--------|
+| | | | | | |
+| | | | | | |
+
+### Uji Hipotesis
+
+| Uji | Nilai Statistik | p-value | Keputusan |
+|-----|----------------|---------|-----------|
+| | | | [ ] Tolak H0 / [ ] Gagal tolak H0 |
+
+### Effect Size
+
+| Metrik | Effect Size | Kategori (small/medium/large) |
+|--------|------------|------------------------------|
+| | | |
+
+### Confidence Interval
+
+| Metrik | CI 95% | Interpretasi |
+|--------|--------|-------------|
+| | [ __ , __ ] | |
+
+---
+
+## Latihan 2 — Beyond p-Value
+
+| Pertanyaan | Jawaban |
+|-----------|---------|
+| Arti praktis (bukan hanya statistik)? | |
+| Apakah perbedaan cukup besar untuk bermakna? | |
+| Bagaimana dibandingkan temuan di literatur? | |
+
+---
+
+## Latihan 3 — Failure Analysis
+
+### Jika Hipotesis Ditolak:
+
+| Pertanyaan | Jawaban |
+|-----------|---------|
+| Apakah ada boundary condition? | |
+| Apakah kegagalan mengungkap insight baru? | |
+| Apa yang bisa dipelajari? | |
+
+### Jika Hipotesis Diterima:
+
+| Pertanyaan | Jawaban |
+|-----------|---------|
+| Limitation yang mengurangi kekuatan klaim? | |
+| Apa yang tidak bisa disimpulkan? | |
+| Perlu replikasi di konteks lain? | |
+
+---
+
+## Refleksi
+
+> *"p < 0.05 artinya apa secara konkret? Jika efeknya sangat kecil meski signifikan — apakah masih berarti?"*
+
+**Jawaban refleksi:**
+> ___________________________________________________
+
+---
+<!-- Worksheet dari Bab 14 — Data Analysis, Interpretation & Failure Analysis -->
--- a/worksheets/ws-15-paper-outline.md
+++ b/worksheets/ws-15-paper-outline.md
@ -0,0 +1,91 @@
+# WS-15: Scientific Writing
+> **Bab Terkait:** Bab 15 — Scientific Writing
+> **Tujuan:** Menyusun outline paper IMRAD, memeriksa konsistensi, dan melatih alur paragraf
+> **Referensi:** Lampiran B.15 | Template A.15
+
+---
+
+## Latihan 1 — IMRAD Outline
+
+### Introduction
+| # | Konten Utama | Target Kata |
+|---|-------------|------------|
+| 1 | | |
+| 2 | | |
+| 3 | | |
+
+### Method
+| # | Konten Utama | Target Kata |
+|---|-------------|------------|
+| 1 | | |
+| 2 | | |
+| 3 | | |
+
+### Results
+| # | Konten Utama | Target Kata |
+|---|-------------|------------|
+| 1 | | |
+| 2 | | |
+| 3 | | |
+
+### Discussion
+| # | Konten Utama | Target Kata |
+|---|-------------|------------|
+| 1 | | |
+| 2 | | |
+| 3 | | |
+
+### Conclusion
+| # | Konten Utama | Target Kata |
+|---|-------------|------------|
+| 1 | | |
+| 2 | | |
+
+---
+
+## Latihan 2 — Consistency Matrix
+
+| RQ | Introduction | Method | Results | Discussion | Conclusion |
+|----|-------------|--------|---------|-----------|-----------|
+| RQ1 | | | | | |
+| RQ2 (jika ada) | | | | | |
+
+**Inkonsistensi yang ditemukan:**
+> ___________________________________________________
+
+**Perbaikan:**
+> ___________________________________________________
+
+---
+
+## Latihan 3 — Paragraph-Level Flow
+
+**Section yang dipilih:** Discussion
+
+**Paragraf 1:**
+> Kalimat topik: ________________________________________
+> Bukti pendukung: ______________________________________
+> Transisi ke paragraf 2: ________________________________
+
+**Paragraf 2:**
+> Kalimat topik: ________________________________________
+> Bukti pendukung: ______________________________________
+> Transisi ke paragraf 3: ________________________________
+
+**Paragraf 3:**
+> Kalimat topik: ________________________________________
+> Bukti pendukung: ______________________________________
+
+**Evaluasi flow:** [ ] Logis / [ ] Perlu perbaikan transisi
+
+---
+
+## Refleksi
+
+> *"Jika saya membaca paper saya sebagai reviewer yang skeptis — di mana saya akan berhenti dan berkata 'ini tidak convincing'?"*
+
+**Jawaban refleksi:**
+> ___________________________________________________
+
+---
+<!-- Worksheet dari Bab 15 — Scientific Writing -->
--- a/worksheets/ws-16-defense-prep.md
+++ b/worksheets/ws-16-defense-prep.md
@ -0,0 +1,72 @@
+# WS-16: Presentation & Defense
+> **Bab Terkait:** Bab 16 — Presentation & Defense
+> **Tujuan:** Menyusun slide deck, mempersiapkan anticipatory defense, dan berlatih presentasi
+> **Referensi:** Lampiran B.16 | Template A.16
+
+---
+
+## Latihan 1 — Slide Deck
+
+Prinsip: 1 slide = 1 pesan, visual > text, build progression.
+
+| Slide # | Judul | Pesan Utama | Visual/Data |
+|---------|-------|------------|------------|
+| 1 | Title & Context | | |
+| 2 | Problem & Gap | | |
+| 3 | Research Question | | |
+| 4 | Method Overview | | |
+| 5 | System Architecture | | |
+| 6 | Experiment Design | | |
+| 7 | Result — Tabel | | |
+| 8 | Result — Grafik | | |
+| 9 | Analysis & Interpretation | | |
+| 10 | Discussion & Limitation | | |
+| 11 | Conclusion & Contribution | | |
+| 12 | Future Work | | |
+
+**Total slide konten:** _________________________________
+
+---
+
+## Latihan 2 — Anticipatory Defense
+
+Gunakan framework CER: Claim-Evidence-Reasoning.
+
+| Kategori | Pertanyaan Potensial | Claim | Evidence | Reasoning |
+|----------|---------------------|-------|---------|-----------|
+| Problem | | | | |
+| Gap | | | | |
+| Method | | | | |
+| Results | | | | |
+| Generalization | | | | |
+
+---
+
+## Latihan 3 — Presentasi & Feedback
+
+**Durasi presentasi:** __________________________________
+**Audience:** ___________________________________________
+
+| Aspek | Feedback | Perbaikan |
+|-------|---------|----------|
+| Timing | | |
+| Kejelasan narasi | | |
+| Slide yang membingungkan | | |
+| Pertanyaan dari audience | | |
+
+**Elevator pitch (2 menit, tanpa slide):**
+> ___________________________________________________
+> ___________________________________________________
+> ___________________________________________________
+
+---
+
+## Refleksi
+
+> *"Bisakah saya menjelaskan inti riset saya dalam 2 menit tanpa slide — dan tetap meyakinkan?"*
+
+**Jawaban refleksi:**
+> ___________________________________________________
+
+---
+<!-- Worksheet dari Bab 16 — Presentation & Defense -->