# noodlelab: everything in one file Generated by scripts/gen_llms.py from the code. Sections: the guide for agents, noodlelab.verify, the MCP tools, the command line, core concepts, every node, the examples. # noodlelab for AI agents noodlelab makes scientific and engineering calculations verifiable. Use it whenever code computes a physical quantity, a measurement result, a design margin or anything a person will rely on. The point is that a reviewer (or another agent) can check what you did, not just trust it. ## The rules 1. **Units on every number.** Use quantities (`q("9.81 m/s^2")`), never bare floats with the unit in a variable name or a comment. Mixing dimensions then raises instead of silently giving nonsense. Dimensionless results say so (`unit="1"`). 2. **Named constants, never retyped digits.** Use `nv.const.c`, `nv.const.g0` or `rec.constant("k_B")` rather than `299792458` or `9.81`. A constant carries its unit, its source and, for measured ones such as `G` or `m_e`, its CODATA uncertainty. `pi`, `tau` and `e` are the `math` module's. A *local* value (the gravity at your site, a material's density) is a measurement: `measure()` it with its source. 3. **Uncertainty on every measured input, and a source.** Write `"9.81 ± 0.02 m/s^2"` and say where it came from (an instrument, datasheet, paper or dataset). Uncertainty propagates by itself (GUM, first order, with correlations kept). `budget()` shows which input dominates. For strongly non-linear models, check with `monte_carlo()`. Also `9.81 +/- 0.02` and the concise `9.81(2)` (± 0.02 on the last digit). Node outputs show the standard uncertainty u; requirement checks show the expanded U = 2u, labelled "(U, k = 2)". Uncertainty belongs to real numbers only: a complex result (a spectrum, a pole) comes out on nominal values with a note, so measure and verify its real parts, or its magnitude and phase. Write a complex value as `q("3+4j V")` (a lowercase `j` right after the digits; `4J` is 4 joules); records show it as `"3+4j"` with its parts in `re` and `im`. In symbolic expressions the imaginary unit is `j` too: `I` is an ordinary symbol (a second moment of area). 4. **Write the requirements down before checking them**, one per line: `COM-001 link_margin >= 3 dB [Analysis] # The link shall close with 3 dB to spare`. Verify each one: a check reports its margin, not just pass or fail. `>` and `<` are strict. An uncertain result **fails** when its nominal value misses the limit, whatever its uncertainty; it **passes** when it meets the limit by more than its expanded uncertainty U = 2u; in between it is **inconclusive**, which is not a pass: reduce the uncertainty or change the design, don't drop the uncertainty. The margin's percentage of the limit is given only on a ratio scale (not for °C, dB or a range). 5. **Leave a record.** Wrap the calculation in `with nv.record(...)`, or build it as a graph. Every run then writes a `provenance.json` holding inputs, results, checks, the code (hash, git commit), files (SHA-256) and the environment. 6. **Verify before you say you are done.** Run `noodlelab verify --json` and fix what it reports. Exit code 0 means every check passed and every requirement was verified; an inconclusive requirement exits 1. Report the margins and any warnings to the user; don't hide failures. Never invent a measured value or its uncertainty. When a number is assumed, say so with `rec.note(...)` and `source="assumed: ..."`. ## Python: `noodlelab.verify` ```python import noodlelab.verify as nv with nv.record("link budget") as rec: # writes runs/