Define the information a trial needs to carry.

An experiment record should support a particular activity. Identify who creates it, when information becomes available, and who needs to read it later. A field requested before the person can know the answer may encourage a guess or a meaningless default.

Describe what the record refers to: a planned activity, an actual attempt, a group of observations, or a review of existing work. These are different objects. Keeping them distinct makes it easier to explain why some information is expected at one stage but not another.

A field definition should explain the value, the unit or category where relevant, and the situation in which it is required. A column called “result” may need to become several clearly defined observations. Free text can provide context, but it should not be the only place where important distinctions are stored.

Specify how the record represents an unknown value, a value that was not collected, and a value that does not apply. None of those states automatically means zero. The interface should make the distinction understandable to the person entering the information and the person interpreting it.

A record can be incomplete for a legitimate reason. Define which information is needed before it can move to the next task and what remains open. A completion label should not quietly imply that a result is technically accepted, independently reviewed, or scientifically valid.

Corrections need their own behavior. The specification should explain what changes, which earlier context must remain available, and how a reader recognizes the current version. An interface prototype can demonstrate those rules with invented examples without claiming to provide a production audit trail.

Potential outputs include a record model, a field dictionary, completion rules, missing-value definitions, and examples of ordinary and difficult cases. The review should check that the structure supports the intended task rather than merely reproducing the current spreadsheet layout.

The handoff should identify unresolved domain questions and implementation responsibilities. It does not establish data validation, access control, regulatory suitability, or long-term storage by itself. Those properties depend on the actual software and operating arrangements that a later phase implements.