Zosen LabNCMBM · University of Oslo

Resources

Methods, records and ground rules, kept in the open

A result is only as good as the method behind it and the record that shows what was done. This page says where the lab keeps both, how we share what we know, and the rules we follow when AI helps with the work.

Protocols

A new lab member should not have to learn a method by guessing what a methods section left out.

I wrote step-by-step protocols from the methods of my own papers. They cover cell culture and neuronal differentiation, chicken embryo work, organoids, imaging, electrophysiology, western blots, reporter assays, small RNA, drug measurement in tissue, and statistics. Each one separates what the paper reported from general laboratory practice, quotes catalogue numbers as printed, and ends with a list of what the paper did not say.

The methods are published and were used in the work behind my papers. The step-by-step versions here are version 0.1, written out from those published methods sections, so they carry any gap a methods section leaves. Methods that collaborators performed are marked as reference methods. A protocol moves to version 1.0 when someone has run it from the page, written down what they changed, and a second person has repeated it. Validated versions will be deposited on protocols.io, so that papers can cite them by DOI.

Browse the protocols on GitHub Read the lab handbook

How to use them

  • Read the whole protocol before you touch anything, including the section on approvals.
  • Run a pilot. Write down every change and the reason for it.
  • Ask for the approvals your own project needs. The permits named in the papers belong to the original studies.
  • Found an error or a gap? Open an issue or a pull request. Corrections are welcome from anyone.

Text is licensed CC BY 4.0. Reuse and adapt it with credit.

Records: SciSure (eLabNext)

Protocols say what to do. The notebook says what was done.

Lab work at the University of Oslo is recorded in SciSure for Research, the university's electronic lab notebook. It was formerly called eLabJournal and is also known as eLabNext. Everyone in the lab writes in it, so the record is shared, searchable and kept in one place.

The GitHub protocols are the master text. A notebook entry names the protocol and the version it used, so any result can be traced back to its method.

What every entry holds

  • The question the experiment asks, and what result would change the plan.
  • The protocol and version, with every deviation from it.
  • Materials, with lot numbers for the ones that matter.
  • Where the raw data are stored.
  • The result, and the next step.

The test for a good entry: someone else can repeat the work from the page alone.

Sharing what we know

What is mine to share, I share early.

Protocols and the lab handbook are open under CC BY 4.0, code under the MIT licence, and papers are posted as preprints where the journal allows. Unpublished data, and anything involving human participants, stay inside the lab until the approvals and the co-authors allow otherwise.

Visitors and students are welcome to use these materials, and to tell me where they fail. A method that only its author can follow is not yet a method.

Using AI in research

AI tools can help with parts of the work. They cannot take responsibility for it.

These are the rules in this lab. They follow the European Commission's guidelines on generative AI in research, the European Code of Conduct for Research Integrity, and University of Oslo guidance. Funders and journals differ in the details, and the rules are changing, so check the call or the journal before you submit. Last reviewed October 2026.

Do

  • Take responsibility for every claim, figure, reference and line of code, whoever or whatever drafted it.
  • Open every reference you cite and check that it says what you claim.
  • Tell the funder, the journal and your co-authors when AI did more than fix the language, in the words their policy asks for.
  • Keep a short record of substantial AI use: the tool, its version, the date and the purpose. Keep AI-assisted code under version control with tests.
  • Use only university-approved tools for unpublished, personal or patient-related material, matched to the data's protection class.
  • Use AI for language editing and translation without embarrassment, especially in a second language.
  • Practise reading, analysis, writing and troubleshooting unaided, and bring AI in after you have made a first attempt.
  • Keep the question, the experimental design, the bench work and the sign-off with people.

Do not

  • List an AI tool as an author.
  • Use AI to make up or change data, results, references, or images of experimental data.
  • Upload unpublished work, personal data or anyone else's confidential material to an external tool.
  • Put a manuscript or a grant proposal you are reviewing into any AI tool, or let AI write or judge a review.
  • Present AI output as checked fact: a summary of a paper, a statistical result, or code that "ran fine".
  • Hide substantial use of AI.
  • Let AI replace your own reading, reasoning and bench work.
  • Take an AI's verdict on novelty or importance in place of an expert's.

What a human scientist brings

Choosing the question is the first contribution, and the hardest to automate. In one test, ideas written by a language model looked more novel than experts' ideas until experts carried them out. Then the model's ideas lost ground and the experts' held.1

Hands and judgement come next. Wet-lab work still needs a person at the bench, who sees that the cells look wrong before any number says so. In a published case of an AI research agent, people ran every bench experiment, and the AI's own analysis of the data overstated an effect compared with a human re-analysis of the same data.2

Last comes accountability. A signature, a retraction notice and a conversation with a patient group all need a name behind them. Every policy cited here says the same: the human stays responsible.

Where AI helps

  • Language editing and translation for people writing in a second language.
  • Finding and sorting literature, when you then read what it found.
  • Image analysis and structure prediction, where the tools are validated and the method is reported.
  • Drafting and explaining code, when you can read the code and a test shows it works.

I have not claimed numbers here because they date quickly. The sources below are the place to look.

Sources and where to check the rules