作者的博客流水线始于 Org-mode 文档，这些文档作为单一事实来源，包含散文、可执行代码块、d2 图以及参考文献。通过一直停留在 Emacs 中，作者避免了上下文切换，并保持了一个一致的写作环境，在此环境中支持内容的所有计算可以就地求值。这一设计反映了之前以 Emacs 为中心的尝试的演进，如今经过改进使得发布端更小、类型化且更易理解，同时仍将 Emacs 作为创作的中心枢纽。
当需要发布时，基于 Gleam 的转换器会处理每个 Org 文件：它调用 Pandoc 将 Org 转换为带有引用处理的 GitHub 风格 Markdown，应用三个自定义 Lua 过滤器以实现诗句保存、参考文献分组和路径翻译，然后将结果交给 Blogatto 生成最终的 HTML 结构。与此同时，Gleam 和 Lustre 协同工作，为站点布局生成经过类型检查的 HTML 元素，确保生成的页面在结构上是可靠的。作者以一个 Gleam 函数为例，该函数接受一个帖子列表并返回一个 Lustre 元素作为帖子索引页面，以此展示整个流水线在静态类型检查方面的益处。
此图像说明了第二段所述的转换流水线，其中 Org 文件先由 Pandoc 和 Lua 过滤器处理，随后由 Blogatto 生成 HTML。
Nix flakes 和 devenv 提供了一个可重现的开发环境，其中锁定了 Gleam、Pandoc、make 及其他依赖的确切版本，使作者能够通过简单的 ‘nix develop’ 命令进入一个完全配置好的 shell。这种可重现性消除了对全局安装工具的依赖，并保证在任何机器上都能重建相同的构建环境，从而支持作者在 Emacs 中获得愉快且可预测工作流的目标。
作者认为，Org-mode 在此用例中优于 Markdown，正是因为它在编辑器内部保持交互性——源代码块、图表和引用等功能可以实时操作和验证，而无需单独的构建步骤来查看结果。尽管 Org‑Publish 能够自动化流水线的很大部分，但作者发现要在生成 HTML 时实现诸如语法高亮这样的理想质量‑of‑life 功能相当困难，这进一步加强了将转换步骤保持显式和分离的决定。