Final Project

The final project is the whole course in one piece of work. Every lab has been a rehearsal for it: you interviewed a data owner you had never met, wrote a brief, directed an agent, and delivered something you had checked. The difference now is that the data owner is a real person, the data is theirs, and the answer matters to them.

This is a client relationship, not a submission. You are not handing us a notebook at the end of term. You are taking on someone’s unanswered question, and giving them back something they can run without you.

The rule you cannot bend

It must be someone else’s problem, and it must be different from what you already work on.

Using your own dataset is the worst way to learn this. The context is already in your head, so you never have to state it — and you never notice that you did not. Being the outsider forces the context out into the open, where the agent can read it. That is the entire skill.

You can solve your own problem any time. You can only learn this by being the outsider.

Where your client comes from

Three routes, in order of preference.

1. Someone you find yourself — the best outcome

A group you know, a facility, a former supervisor, someone two desks away, someone you met at a conference. They do not have to be at SciLifeLab or even in Sweden — an online meeting is an online meeting.

You have a personal invite link for exactly this. See the next section.

2. A volunteer from the pool

We have put out a public call to the SciLifeLab and KTH community, and researchers are signing up projects. If you have not found anyone, we will assign you one from that pool.

• See the call we published →

Read it. It is what your client will have read before they said yes, and it is the clearest statement of what we promised them.

3. A simulated owner — last resort only

An agent playing a data owner, as in the weekly labs. This is a genuine last resort, not an easy option: the answer never leaves the classroom, and the project is harder to make interesting. If you are struggling to find someone, tell us early — that is what the pool is for, and early is much easier to fix than late.

Your personal invite link

Every student has a unique sign-up link. When a researcher registers a project through your link, that project is tagged to you, and you get first claim on it when we match people to projects.

How to get it

1. Sign in to the course portal.
2. On your dashboard, find the section “Your final-project client”.
3. Press Copy link. It looks like …/signup-projects?ref=XXXXXXXX — the code at the end is yours.

• Open the course portal

The same section lists every project that has come in through your link, and what stage it is at, so you can see whether your outreach is working.

Where to share it

Anywhere you would be comfortable being read by a colleague:

• Message people directly. By far the most effective. A short, specific note to one researcher beats a broadcast to a hundred.
• Post it on LinkedIn, Mastodon or Bluesky. Say what you are offering in your own words.
• Ask your group, your department, your old lab, a core facility.
• Send it to people outside Sweden. Everything is online; there is no geographic limit.

Whoever you send it to only needs about two minutes: the sign-up is a short chat with an assistant, not a form.

What you are promising them

We advertised a specific, deliberately small commitment, and you have to honour it. Do not quietly turn a two-hour ask into a ten-hour one.

Being told you are wrong in meeting 2 is the expected outcome, not a failure. That is what the round is for. A student whose prototype survives contact with the client unchanged has usually not shown it properly.

Proposal and approval

Every project has to be approved by the teaching team before you start building. This is not a formality — we decline projects, and we would much rather do that in week one than watch one fail in week three.

How to submit

If you have found someone, submit the project together, through the portal, during the proposal phase:

1. Send them your invite link.
2. Ideally, sit with them (or on a call) while they sign it up — it takes two minutes, and you will hear the problem described in their own words, which is useful later.
3. The project appears in our registry, tagged to you.
4. We read it and either approve it, come back with questions, or decline it.

You and the owner can both see the project’s status on its page at any time.

What we are checking

Four things. A project can be declined on any one of them.

Data volume and compute. You have a metered budget on the course gateway and no cluster. A project that only becomes interesting at 500 GB, or that needs days of GPU training, will not fit. Ask early what the data actually weighs — a subsample or a single plate is often enough, and “we agreed to work on a 2 GB extract” is a perfectly good scope decision.

Three weeks. With an agent you can attempt considerably more than would conventionally be possible in three weeks — that is much of the point — but it is still three weeks, alongside labs and seminars. Scope it so that a working, checked answer exists at the end. A finished small thing beats an unfinished large one, every time.

Not too easy. This is the criterion students underestimate. A project we can see through in an afternoon — one clean table, one obvious test, no judgement calls — will not pass. There has to be something for you to get wrong: a confound, a batch effect, a metadata mess, a choice of measurable quantity that is not obvious. If you cannot name the thing that might go wrong, the project is probably too easy.

Someone else’s problem. As above. We check.

What you hand in

Three things, exactly as in the labs but larger.

The product — something that works. Code, figures, a pipeline or a small app that runs on the client’s data and can be handed over. This is the primary deliverable.

The talk — you, defending it. What the problem was, what you built, what you checked, and what you would not claim.

The report — written, AI-assisted, disclosed. Drafted with your agent, and accurate because you checked every number in it.

As in every lab, we read the transcript, not only the result: the interview log and the analysis log. We are looking for where you found the question behind the question, where you refused what the agent gave you, and what you checked versus what you took on faith.

Assessment

Credit breakdown: labs 2.0 hp · project 3.0 hp · oral exam 2.5 hp (7.5 hp total).

Dates

Start looking for a client now. The single best predictor of a good final project is having found the person early.

The AI policy, again

1. Use it. Any model, any tool. The tools are the subject of the course.
2. Disclose it. Attach your chat history to graded work.
3. Own it. Every number in your report is yours. If it is wrong, it is wrong under your name.
4. Protect the data. Never upload data you do not have the right to upload — ask your client explicitly what may leave their machine, and respect the answer.
5. Verify references. A plausible DOI is not a real one.

Questions about a client, a scope, or anything above: Wei Ouyang, Songtao Cheng and Nils Mechtel, or email ddls-course@scilifelab.se. If you are stuck finding a client, say so early.