Flight rules: from pilot to practice.

Protect the data before you protect your time

Rule: patient data (PHI) and unpublished results go only into tools the institution has approved for that data, with training on your inputs turned off. Never into a consumer chat account. If you are not sure a tool is approved for this data, treat it as not approved and ask.

Why: In 2023, Samsung engineers pasted confidential source code into a consumer chatbot, and the company responded by restricting the tools for everyone. Eric's FAQ answered “does it learn from my chat?” with no. Whether the provider keeps and can read what you sent is a separate question, and for patient data it is the one that matters.

Identifiers are wider than names. Dates of service, ZIP codes, record numbers, and full-face photos all count under HIPAA.

You are the author, and you are accountable

Rule: AI is never an author. Major journals, including the Nature and Science families, do not accept AI tools as authors, because a tool cannot take responsibility for the work. Every claim in your paper is yours.

Disclose what you used, for what, and how you checked it

Rule: name the tool and version, the task it did, and the verification you ran. Follow the venue's policy. Session 2 builds a reusable disclosure template.

We follow this rule too: see the AI use disclosure for these materials.

Log it so someone can trace it

Rule: record the model and version, the date, settings such as temperature when you control them, and the prompts. With a coding agent, keep the session transcript and commit the code it wrote. As Tommy put it, you may not get the same output twice, but you should always be able to show how you got this one.

Expect the bias you would expect from the literature

Rule: read AI output the way you read a field's older papers. Training text over-represents some populations, tissues, and model organisms, and the model repeats that skew fluently.

Hand AI the labour, keep the judgement

Rule: AI may do recoverable labour: formatting, first drafts of code, polishing language, summarizing a source you will check. It must not replace the judgement that defines research: framing the question, calling an outlier, interpreting a surprise, answering a reviewer, or anything clinically consequential without expert review. Leave AI out entirely when you cannot check its answer.

Start from context, not from a prompt

Every project has a CLAUDE.md: what the project is, how it is laid out, and the rules the agent follows there. I also keep a global one with rules for every project. Before any change, the agent writes a plan, and I read it before it acts.

Same idea as Tommy's “always start with a /plan”, made permanent so I do not have to repeat myself each session.

Skills are our lab's standard operating procedures

A skill is a markdown file with instructions, the SKILL.md from Tommy's slides. We write them for the procedures we do not want improvised:

• Submitting a job to the HPC cluster: which LSF queue, how to request memory and time, how to run inside an Apptainer container, and how to generate a job script safely.
• Launching a Foundry Connect pipeline run: build a dataset from the FASTQ files on disk, duplicate a known-good run, change only the inputs, then launch.

A skill is a protocol written once, reviewed by a person, and followed the same way every time. That is what makes an agent's work traceable.

Connect it to Foundry Connect

Through the Foundry Connect connector (the fourth green light from 1.0), I ask in plain language:

• “Which of my runs failed this week, and why?” It reads run status and logs.
• “Pull the QC report for this RNA-seq run and summarize anything unusual.” It reads result files.
• “Rerun it with the corrected sample sheet.” It prepares the change and stops to ask for confirmation before launching anything.

The data and the compute stay on the cluster. The assistant sees what the connector exposes, and every write waits for a person.

Guardrails: instructions are requests, hooks are enforcement

A chat assistant sees only what a connector shows it. A coding agent on your own machine can do anything your terminal can do. That is why permission modes matter, and why auto mode belongs in a throwaway project, not next to credentials or patient data.

A true story from this summer. While debugging a database connection, an agent helpfully printed a live access token and a database password into its session transcript. Nothing malicious happened, and nothing was misused. Both credentials still had to be revoked and replaced, because anything printed into a transcript is kept.

What changed afterwards:

• A written rule in my global CLAUDE.md: never print a credential, never type a password into a command.
• Deny rules so the agent cannot open credential files at all.
• A hook: a small script that runs before every command the agent issues and blocks anything that would print a secret. It has no bypass. It occasionally blocks something harmless, and that is the right trade.

The model can forget or misread a rule in its instructions. A hook runs every time, whatever the model decides.

Verification is a procedure, not a feeling

• Independent review: a fresh subagent, or a model from a different family, critiques the analysis without seeing the author's reasoning. The same model cannot be both author and critic.
• Check the numbers at the source: sample counts, gene counts, and p-values in the summary must match the pipeline's own report.
• Watch for agreement: if the agent enthusiastically agrees with your hypothesis, treat that as a prompt to check, not as support.
• Git is the flight recorder: every change the agent makes is a commit a person can read.

Keep it sharp: small context, fresh sessions

Long sessions get slower, more expensive, and less accurate. I send exploration to subagents and keep only their conclusions, and I start a fresh session once a task ships. This is Tommy's /compact and subagents slide, applied as a habit.