Skip to content

How the pipeline works

Two pipelines feed one site. Manuals are converted to sectioned markdown with provenance; Eurorack specifications are fetched into evidence files that keep the exact line each number came from. Human decisions sit on top in a separate file, so a judgment call is visible instead of buried in code.

Build pipelineManual PDFs are converted to sectioned markdown (local only). Eurorack source pages are fetched into evidence, combined with human overrides and the inventory, and built into generated pages and a static site. Five quality gates run on every change.Manufacturer PDFs(local only)convert_manual.pysplit + tag + provenanceSectioned markdown(local only)Source pages anddatasheets (listed)fetch_specs.pynumbers + raw linesEvidence (JSON)value + exact lineoverrides.yamldecisions + reasoninginventory.yamlgear, status, formatbuild_site.pybuild_eurorack.pygenerate everythingGenerated pagesbudget, status, specsStatic siteQuality gates (run on every change)validate.pystructure, tags, linkscheck_coverage.pydid conversion lose text?regression diffdid a change alter results?mkdocs --strictbroken links fail buildgolden questionsdoes retrieval find it?local only, never published (copyright)codecommitted datagenerated output

Yellow, dashed boxes stay on the author's machine (copyright). Nothing in this pipeline calls a language model.

How to read it

  • Left to right is the flow of data. Blue boxes are code, green boxes are committed data, pink boxes are generated.
  • The five gates at the bottom run on every change. They check different things, so no single one is trusted alone. The next pages show why: what the checks caught.

More detail: architecture, runbook.