diff --git a/docs/process/definition-of-done.md b/docs/process/definition-of-done.md
new file mode 100644
index 0000000..e97d81d
--- /dev/null
+++ b/docs/process/definition-of-done.md
@@ -0,0 +1,65 @@
+# Definition of Done (DoD)
+
+This document defines the criteria that must be satisfied before an algorithmic
+problem is considered complete inside the `moltiful-algorithms` repository.
+
+The goal is to enforce consistency, correctness, clarity, and long-term maintainability.
+A problem is not considered done simply because it passes tests.
+
+---
+
+## 1. Structural Requirements
+
+A problem is considered structurally complete when:
+
+- [ ] The folder follows the canonical naming convention: `NNNN-slug`
+- [ ] A `README.md` file exists inside the problem folder
+- [ ] `solution.ts` or `solution.py` (or both) exists
+- [ ] Corresponding test file exists (`solution.test.ts` / `test_solution.py`)
+- [ ] Tests pass locally
+- [ ] CI pipeline passes successfully
+
+If any of the above is missing, the problem is not complete.
+
+---
+
+## 2. Correctness & Analysis
+
+The solution must demonstrate formal understanding, not just functional output.
+
+- [ ] Brute-force approach is understood (even if not implemented)
+- [ ] Final approach is clearly documented
+- [ ] A correctness argument is written
+- [ ] Time complexity is derived and explicitly stated
+- [ ] Space complexity is derived and explicitly stated
+- [ ] Relevant edge cases are explicitly listed
+
+The correctness argument must explain *why* the solution works,
+not merely describe what it does.
+
+---
+
+## 3. Code Quality Standards
+
+The implementation must meet basic engineering standards:
+
+- [ ] Clear and meaningful variable naming
+- [ ] No unnecessary variables or redundant logic
+- [ ] No hidden side effects unless intentional
+- [ ] No magic numbers without explanation
+- [ ] Handles empty input (if applicable)
+- [ ] Handles minimal valid input
+- [ ] Handles duplicates and negative values (if applicable)
+
+Readable and predictable code is preferred over clever but opaque solutions.
+
+---
+
+## 4. Conceptual Integration
+
+Each problem must be integrated into the broader knowledge structure of the repository.
+
+- [ ] Problem is categorized correctly (e.g., `arrays/`, `graphs/`, `dp/`)
+- [ ] Related foundations are referenced
+- [ ] No duplicated theoretical explanations across files
+- [ ] Reusable patterns are linked instead of rewritten
diff --git a/docs/process/definition-of-learnt.md b/docs/process/definition-of-learnt.md
new file mode 100644
index 0000000..7c72eea
--- /dev/null
+++ b/docs/process/definition-of-learnt.md
@@ -0,0 +1,112 @@
+# Definition of Learnt (DoL)
+
+This document defines the criteria required for a problem to be considered
+*internalized* rather than merely completed.
+
+A problem may be marked as "Done" when it satisfies structural and correctness
+requirements. It is considered "Learnt" only when the underlying reasoning has
+been retained and can be reproduced independently.
+
+The purpose of this document is to prevent shallow familiarity and ensure
+long-term mastery.
+
+---
+
+## 1. Time-Delayed Recall
+
+A problem is considered learnt only if:
+
+- [ ] It can be solved again correctly after at least 7 days
+- [ ] The solution is reproduced without reading the original code
+- [ ] The core idea is recalled from first principles
+
+If the solution requires rereading the previous implementation,
+the problem is not yet internalized.
+
+---
+
+## 2. Conceptual Recall
+
+- [ ] The main insight can be explained in under 2 minutes
+- [ ] The invariant can be stated clearly
+- [ ] The complexity can be derived without notes
+- [ ] The edge cases can be listed from memory
+
+The goal is reconstruction, not recognition.
+
+---
+
+## 3. Transferability
+
+A problem is learnt when:
+
+- [ ] The same pattern can be applied to a new variation
+- [ ] The underlying technique is recognized in a different context
+- [ ] The foundation it relies on is clearly understood
+
+Example:
+If a problem uses a sliding window technique, the technique must be
+recognizable in other array or string problems without hesitation.
+
+---
+
+## 4. Compression Test
+
+If you cannot compress the solution into a short explanation,
+you do not fully understand it.
+
+- [ ] The solution can be summarized in 3–5 sentences
+- [ ] The key idea can be expressed in one sentence
+- [ ] The failure of the brute-force approach can be explained
+
+Clarity implies understanding.
+
+---
+
+## 5. Reimplementation Constraint
+
+A problem is considered stable in memory when:
+
+- [ ] It can be reimplemented in under 15 minutes
+- [ ] No syntax guessing is required
+- [ ] No structural confusion occurs
+- [ ] The solution feels mechanical rather than exploratory
+
+---
+
+## 6. Pattern Extraction
+
+After solving the problem, the following must be identified:
+
+- [ ] What pattern was used?
+- [ ] What signals indicated that pattern?
+- [ ] What constraints eliminated alternative approaches?
+- [ ] What is the generalized version of this problem?
+
+The goal is to extract reusable thinking units.
+
+---
+
+## 7. Forgetting Rule
+
+If a problem cannot be re-solved after 14 days without review,
+it should be moved back to active rotation.
+
+Relearning is part of the process.
+
+Retention is measured by reconstruction ability, not familiarity.
+
+---
+
+## Guiding Principle
+
+A problem is learnt when:
+
+- The reasoning survives time.
+- The structure can be rebuilt.
+- The idea transfers.
+- The explanation is simple.
+- The implementation is reproducible.
+
+Completion measures output.
+Learning measures permanence.
\ No newline at end of file