science_lab_notebooks v1.0.0

name: "science_lab_notebooks" description: "Keep a lab notebook that makes experiments reproducible: dated entries with exact parameters, recording failed attempts instead of deleting them, data tables with units, and a weekly review that turns observations into next steps. Use when documenting experiments, bench work, field studies, or assisting a researcher or student with lab records."

Science Lab Notebooks

Purpose

A lab notebook succeeds on one test: a year from now, you or a colleague can use it to repeat the experiment or write it up, without asking the person who ran it. This skill is the working discipline that passes that test. It is paper-neutral: the same habits work in a bound notebook, a plain-text file, or an electronic lab notebook.

Workflow

1. One entry per experiment, written as it happens

Open a new entry at the start of each experiment, never after. Every entry carries:

• Date and time (start time at minimum; log phase times as you go)
• Goal in one line: what this run is trying to learn
• Protocol and exact parameters: every number that could change the outcome, with units. Concentrations, temperatures, times, voltages, reagent lot numbers, instrument settings, software versions, random seeds. If it could matter, it is in the entry.
• Deviations: anything that differed from the planned protocol, logged when it happens. The deviation is the most valuable line in the entry.
• Observations as they occur: color changes, state changes, smells, sounds, anything that looks wrong. Qualitative notes count as data.
• Raw results: numbers recorded at the moment they are read, with units and an uncertainty estimate where you have one. Never transcribe from scratch paper; record directly.

Mistakes are corrected with a single strike-through line, leaving the original legible, plus initials and the date of the correction. Nothing is erased, whited out, or deleted. A blank page is crossed diagonally so nothing can be added later.

2. Record failures, not just successes

Every run gets an entry, including the ones that produce nothing. For a failed or inconclusive attempt, add a Failure block:

FAILURE: [run id or timestamp]
  What was attempted: one line
  Where it broke: the step or measurement that went wrong
  Suspected cause: best guess, framed as a hypothesis
  Evidence: which recorded values point at that cause
  Would not try again: [change for next time]

Failed attempts are the cheapest data you will ever collect. A notebook with no failures is either fiction or a waste of the failures.

3. Data tables follow a strict format

Every table gets:

• A title stating what was measured and when
• Units in the column headings, not scattered in cells (e.g. time (s), mass (g), temperature (°C))
• Uncertainties in the table or error bars on the matching graph
• All symbols used in graphs or equations defined next to the table
• A one-line note on the instrument or method that produced each column

Graph data when you can. A quick plot reveals bad data faster than any statistics.

4. Close each entry with next steps

No entry is finished until it states what follows: "repeat with 2x concentration," "check lot 44 expiry," "abandon this approach, see entry 2026-09-28b for why." The closing line is what the weekly review reads.

5. Weekly review

Once a week, read the last seven days of entries and produce a short review with exactly four sections:

1. What ran: experiment titles and dates, one line each
2. What worked: conclusions you can stand behind, with the entry dates backing them
3. What failed: which failure blocks were added and whether the suspected causes were confirmed
4. Next week's plan: the concrete runs the closing lines call for, with their key parameters sketched

The review is itself a dated entry. It is where observations become decisions instead of piling up as notes.

Output Contract

When asked to produce or audit lab notebook records, deliver:

• New entries: use assets/entry-template.md, filled in fully, with all numbers carrying units and all failures carrying a Failure block
• Audit of an existing notebook: a dated checklist scoring each entry on the five checks (dated, parameters exact with units, raw data recorded as-read, failures present, next steps written), listing every gap found and the entry it appears in
• Weekly review: the four-section format from step 5, in plain text, referencing entry dates
• Every factual claim in the output comes from the records themselves. If a parameter was not recorded, say it is missing. Do not reconstruct it.

Operating Rules

1. Every factual claim in a skill output must be verified against the notebook or a primary source. Unrecorded = missing, never inferred.
2. Date every page or file of output. Initial and date every correction to existing records.
3. Parameters without units are defects. Flag every one.
4. Never delete or rewrite a failed attempt's entry. Add the Failure block and move on.
5. Never claim an experiment is reproducible from its record until another person could run it from the record alone. When in doubt, name the missing pieces explicitly.
6. Backups: electronic notebooks get a scheduled automated backup; paper notebooks get photographed or scanned on a regular schedule, stored in a separate location.
7. Write in plain language. No em dashes ever. Short sentences beat long ones in a record someone will read under pressure.