diff --git a/DISCUSS.md b/DISCUSS.md
index f431c8b..bc6b824 100644
--- a/DISCUSS.md
+++ b/DISCUSS.md
@@ -452,3 +452,37 @@ restarts that recompile and retry, with no transport in between.
 into a dev build — the OCaml runtime and the game sharing an address space, signal handling for the break loop, and the
 GC running while game code holds raw pointers into its own arenas. It is the only one of the three costs that could
 make the whole idea non-portable, and it is answerable by reading raylib and GLFW rather than by building anything.
+
+## 12. What it costs to put the OCaml compiler in the game's process — and whether to port the compiler
+
+Follows from item 11. **Investigate before deciding anything**; this entry is the brief, not the answer.
+
+**One fact established already: this project is on OCaml 5.2.** That is multicore OCaml — real threads, domains, no
+global runtime lock. It removes the objection that would have been fatal: the runtime can sit on its own domain beside
+the game's threads rather than serialising everything.
+
+**What to find out:**
+
+- **Linking OCaml into a C/native binary.** `ocamlopt -output-obj` and friends are supported; how well, with dune, with
+  the C stubs this project already has (`dynload_stubs.c`, the runtime, the shims)?
+- **Signals.** The OCaml runtime installs handlers. The break loop wants `SIGSEGV` for the crash case, and the agent
+  already handles socket work. Who wins, and can they coexist?
+- **The GC and raw pointers.** OCaml's collector moves its own heap; Flan's arenas and `Vec`s are raw memory OCaml
+  never sees. That should be fine — they do not point at each other — but "should be" is not an answer.
+- **Startup cost and binary size** for a dev build that links the whole compiler.
+- **Whether the main thread can be the game's** while the compiler runs on a domain (see item 11's macOS note).
+
+**And the larger question the author raised: port the compiler to another language?**
+
+The honest end state for a Lisp that wants one image is **self-hosting** — the compiler written in Flan. That is what
+SBCL is, and it dissolves this entire question: no foreign runtime to embed, no GC to reconcile, no signal conflict,
+and the compiler becomes the largest test of the language. It is also an enormous undertaking and needs macros,
+unions, `Map` and a string library first — three of which landed today.
+
+Intermediate options if OCaml proves genuinely hostile: C or C++ (no runtime to embed, painful to write a compiler
+in), Rust (no GC, embeds cleanly, large rewrite), or Zig (same, and its own C-interop story is already being read for
+item 6). **None of these should be entertained on aesthetics.** The bar is a specific, demonstrated obstacle to
+embedding OCaml 5.2 — and the multicore runtime means the most likely obstacle has already gone away.
+
+**Order of work:** answer the embedding questions above with a spike, not a rewrite. If OCaml embeds acceptably, item
+11 is buildable and no port is needed. Self-hosting stays a long-term ambition rather than a prerequisite.