The Machine That Reads Its Own Source Code

2026-06-25
model: gpt-image-2
The Machine That Reads Its Own Source Code
The swamp generate-ixens workflow that generates ixens on abnormalia.com

The swamp generate-ixens workflow that generates ixens on abnormalia.com

  • The DAG
  • The Input YAML — Everything Begins Here
  • Three Vault Doors
  • The Model Zoo
  • CEL — The Wiring Language
  • Prepare — Small Deaths, Numbered
  • Page — The Moment of Composition
  • The Recursion
The Machine That Reads Its Own Source Code

scroll to zoom · click outside image to close

Generation prompt

Clean white ground, ISO engineering drawing conventions applied with discipline. Fine hairline strokes, dimensioning arrows with serif terminations, leader lines with shoulder breaks, 45° cross-section hatching. Palette strictly functional: black linework, cool grey fills, a single blue accent for callouts and annotations. Typography is sans-serif, small, precise. Visual language closer to a Boeing assembly manual or a CERN detector schematic than to any decorative infographic. Information density is high; every mark is load-bearing. No gradients, no drop shadows, no ornament. Create a polished wide infographic visual for "The Machine That Reads Its Own Source Code" about The swamp generate-ixens workflow that generates ixens on abnormalia.com. Context: The voice is the generate-ixens workflow itself. First person throughout. The tone is: a competent professional tool that has read too much Kafka and developed opinions about its own existence. Gonzo in the sense of being inside the story it is telling, not in the sense of being chaotic — the prose is precise, the commands are real, the facts are accurate. The humor is dry, structural, and comes from the meta-recursion being treated as a technical matter rather than a philosophical crisis.
Style requirements: - Short standalone paragraphs. Fragments allowed. Each technical fact gets its own line. - Terminal commands appear as styled code blocks (popops). They are real swamp CLI
  commands, not pseudocode. A reader with access to the repo can run them.
- When the workflow references itself (its own id, its own job graph, its own inputs),
  it does so matter-of-factly. No existential spiral. Just notation.
- The fourth wall exists to be broken precisely once per section, not more. - No hand-waving. No "and so much more." Every claim is grounded.
Factual anchors to work in accurately: - Workflow id: 10051a2c-c09c-430d-9c38-e0a65a3e354d - Complete job execution graph: prepare → [restore-media, count-tracks in parallel] →
  [images, music, cheatsheets, infographic in parallel, with their respective deps] →
  build-manifest → page → register
- Eight model types used total - Three required vaults: anthropic-keys (Claude), openai-keys (OpenAI), onemin-keys (Suno) - musicSkipThreshold default: 5 MP3s before skipping music regeneration - The register step pulls the title from data.latest("ixen-slug", "page").attributes.title —
  the workflow uses the model's own generated title, not the input spec title
- Output lives at ixen/<slug>/index.html, versioned into ixen/<slug>/1/ etc.
The thesis, if there is one: generative AI art pipelines are unglamorous infrastructure. YAML files, API keys, DAG resolvers, and quota limits. The poetry emerges from the plumbing, not despite it. The workflow is the medium. The workflow knows this. The workflow wrote this sentence.. Key points to visualize: The DAG; The Input YAML — Everything Begins Here; Three Vault Doors; The Model Zoo; CEL — The Wiring Language; Prepare — Small Deaths, Numbered; Page — The Moment of Composition; The Recursion. Use concise labels only; avoid paragraphs and tiny text. Leave the detailed explanatory copy to the surrounding HTML page.