Field notes

methods ·

Give your project a memory

A small experiment record makes the next revision depend on evidence instead of whatever you happen to remember.

On this page

The cheapest upgrade to a complicated project is sometimes a record of what you changed. This is disappointing news for anyone hoping the answer involved another instrument.

A useful experiment record connects a question, a change, an observation, and a decision. It works whether the object under investigation is a printed joint, an inference configuration, or a sensor enclosure. The fields stay familiar; the units and evidence change.

Begin with a decision

“Improve the enclosure” is too vague to test. “Find out whether moving the temperature sensor away from the regulator reduces its difference from a reference instrument” gives you something to do next.

Write down the decision before collecting results. What would make you keep the change? What would make you revert it? If you cannot describe either outcome, you may still be exploring, which is fine. Call it exploration rather than disguising it as a conclusive test.

NIST’s experimental-design guidance starts with the objective and the factors that may affect the response. It also discusses designs more capable than changing one factor at a time. A small controlled comparison is a useful debugging habit, not a universal substitute for experimental design. NIST/SEMATECH NIST/SEMATECH

A record that earns its storage space

Use these fields:

Field Example, deliberately hypothetical
Question Does the new sensor mount reduce temperature bias?
Baseline Mount A, firmware revision 17
Change Mount B; same sensor and firmware
Response Sensor minus reference temperature, in °C
Conditions Supply, sampling interval, warm-up and room conditions
Evidence Timestamped CSV and a photo of each placement
Decision Keep, revert, or investigate further

Do not put a made-up result in the response field to make the table feel complete. “Not measured” is a perfectly respectable entry. It even has the advantage of being correct.

Account for the nuisance variables

Testing A in a cool room and B beside a sunny window compares more than two mounts. NIST describes blocking as a way to account for known nuisance factors. In an informal workshop comparison, at minimum record those factors and avoid arranging all the conditions so one treatment gets an unfair advantage. NIST/SEMATECH

For a printer, nuisance variables may include a different spool or a changed orientation. For local inference, they may include another process occupying the GPU. The specific controls depend on the question. A record should make the comparison inspectable, not merely give it the appearance of rigor.

Retain individual observations instead of only an average. A mean can conceal an intermittent failure. Record failed attempts with a reason; never quietly remove them because the chart becomes less cooperative.

Separate the observation from the explanation

“Three samples were warmer” is an observation. “The regulator heated the sensor” is an explanation to test. “Move the sensor” is a proposed action. Keeping these in separate fields makes it harder for a confident story to masquerade as a measurement.

The same separation helps with an AI-generated suggestion. Preserve the suggestion and its rationale, then record the actual test. The model’s confidence does not become an instrument reading merely because it arrived in JSON.

Leave a next step

End each revision with the smallest question the evidence justifies. If the mount helped but the reference moved, repeat the comparison under better control. If nothing changed, keep the baseline and investigate another cause. If the test was malformed, say so.

A project begins to accumulate capability when its previous attempts remain usable. Keep the record with the project files so the next change can use it.

Next: The file between departments covers a measurement format another tool can actually read.

Sources

More field notes