Authoring a recipe

A recipe is one YAML file under recipes/<goal>/. The gallery pages under Sensors & recipes and the per-recipe pages in the sidebar are generated from these files at build time — never hand-write a gallery page.

Required shape

Every recipe needs, at minimum: id, version, goal, machine_classes, method, physics, sensor (with generic_spec, signal_kind, unit, range_min, range_max), example_parts, mounting, wiring, sample_rate_hz, edge_hardware, processing, detector (name + default_params), validation (check + expected), cost_band (low, high, currency), safety_notes, difficulty, install_downtime_min, pros, cons, and i18n_keys (the list of fields that need translating per locale).

Hard rules for a recipe

• sensor.generic_spec is a generic spec, never a brand. example_parts is where two or three illustrative vendor/part examples go, so the generic spec stays shoppable without being tied to one vendor.
• cost_band is a range with a stated basis, never a single number. Base it on the example_parts you listed; never state a price as if it were a quote.
• safety_notes must cover lockout/tagout and PPE wherever a live electrical or pressurised system is opened. Write them for someone who has done LOTO before but has never touched this specific signal.
• validation.check must be something an installer can actually do with a handheld instrument on site — not something that needs lab equipment.

Checking your recipe

uv run rw recipes lint recipes/

This validates every recipe under the given directory against its schema and reports the count of recipes checked and any errors, by file.

Regenerating the gallery

npm -w docs run build

The build script regenerates every recipe page from the current YAML before building the site (this hand-written page is preserved across that regeneration), so a new or edited recipe appears automatically — there is nothing else to wire up.