Final Project — for students

← Back to the Final Project overview

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 three steps that matter most, in order: ① find someone else’s problem (not your own) and register it through your invite link → ② get it approved by the teaching team before you build → ③ run the two 1-hour meetings and hand back something that runs on their machine.

Your dates

If you have agreed an individual extension with us, your dates are the ones in that email.

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.

How much work this is — for you

The two hours above are the client’s commitment. Your side is the real work of the course, and it is meant to be substantial: the final project is the capstone, worth 3.0 of the course’s 7.5 credits. In practice that is on the order of 70–90 hours of your own work across the three-week window — plan for it like a serious piece of coursework, not a weekend.

“The agent does the labour, you supply the judgement” does not mean there is little to do — the judgement is the work, and it is not quick. Your time goes into:

• Preparing and running the interview, then turning it into a clear brief and spec.
• Directing the agent across many iterations — most first answers are wrong or shallow, and steering it is hands-on.
• Verifying every result against the data and the literature. This is the slowest part, and the part that is actually graded.
• Building the deliverable — a runnable app or code the client can use.
• Writing the report, and (Master’s) preparing the oral.

“A finished small thing beats an unfinished large one” is still the rule — but a checked, honest small thing takes real, sustained effort. Scope it accordingly, and start early.

Before Meeting 1 — prepare, then book it

Meeting 1 is the whole project in one hour: it is where the real question comes out and where the data changes hands. Walk in prepared. Book it as soon as you are matched — do not leave it to the last week.

Booking. Once you are matched, your project page shows your client and their stated availability. The teaching team arranges the slot and a Zoom room from that — the time and link appear on your project page (and theirs). If a week passes with no slot, email ddls-course@scilifelab.se and we will chase it. Aim to meet in the first half of the project window so you have time to build and iterate.

Your preparation checklist — tick every box before the call:

• Read everything the owner already told us on your project page — the question, the data, what they have tried, their constraints.
• Rehearse against your preparation agent. Every matched project has a private practice interviewer — a stand-in for your data owner — on your project page. Interview it until your questions feel sharp; it answers a good question well and a vague one poorly, on purpose.
• Write your interview script — the 5–8 must-ask questions that make the problem precise (see the example below). You will improvise too, but never walk in without a plan.
• Prepare a recorder and TEST it first. Zoom’s built-in local recording, a phone on the desk (turn the speaker on so it captures both sides), or your laptop. Do a 20-second test recording and play it back before the meeting — a silent recording you discover afterwards is a lost interview.
• Confirm consent to record at the top of the call (see Record the interview).
• Plan the data hand-over. Decide what to ask: can they give you a copy? Can you download it, or upload it to your project page in the portal (our recommended route — it keeps everything in one place)? Or is it sensitive enough that you should analyse it without a copy via Safe-Colab (see Handling the data)? Know the three options before you ask.
• Plan to walk them through their project page (see How your data owner follows along).

After the interview: upload your recording and the transcript to your project page in the portal (there is a slot for each). The transcript is part of what you hand in, and it is how the teaching team follows your reasoning.

Record the interview

Meeting 1 is where the real context comes out, and you cannot write it all down while also asking good questions. Record it, then work from the transcript — and, as in the labs, the transcript is part of what you hand in.

• Ask first, always. Sweden is a one-party-consent country, so you are legally allowed to record a conversation you are part of. But asking is basic courtesy and keeps your client comfortable — say plainly “Is it OK if I record this so I can focus on listening and work from an accurate transcript afterwards? It’s only for my coursework.” If they say no, take notes instead.
• How to record. The simplest options: Zoom → Record (local recording saves an audio/video file when the call ends); or your phone (voice-memo app next to the speaker); or your computer (QuickTime / Voice Recorder / OBS). Any of these is fine — you only need clear audio.
• Turn it into text. Use the course’s free DDLS transcription app (Whisper on our GPU — drop in the audio, get a transcript back to copy or download; long recordings are handled in the background, so an hour-long interview works):
  • Open the DDLS transcription app →
  Prefer to run it yourself? Any Whisper-based tool works too — whisper.cpp, faster-whisper, WhisperX, or the free tier of MacWhisper. Your Pi analyst agent can also transcribe straight onto your project via the course API (see the transcription app page for the one-liner).
• Upload it. Put the transcript on your project page in the portal (there’s an upload slot on the project).

Handling the data

Your client’s data is theirs, and some of it is sensitive. By default we give every project a protected environment, so a nervous data owner can say yes without their data ever leaving a server they trust. You are the one who explains this to them — so understand how it works.

How the protected environment works. We run a small, locked workspace on a course server (KTH SciLifeLab Kubernetes). Your client uploads their data into it. You get a link that lets your AI agent run analysis inside that workspace and see the results — but you cannot download or copy the data out. Every command and every output is checked, so the data stays put while you still get your answer. When the project ends, the workspace is torn down.

The owner picks the sensitivity level:

Or the owner runs it on their own machine. If they would rather not upload anything at all, that is completely fine — they can run the analysis you design on their own workstation or server. Some owners will prefer this, and it is a perfectly good answer.

What you must do: raise this in Meeting 1, explain the options in plain words (there’s a script on your project page), and respect what your client decides. Never upload or move data you do not have explicit permission to move.

• Data-protection service (Safe-Colab)

Questions about protecting a specific dataset, or setting up the environment: email joanna.hard@scilifelab.se (and your project page shows the current status once we prepare it).

How your data owner follows along

Your client has their own private project page — a link we send them, no account or password. It is the single place the whole engagement lives, so nothing gets lost in scattered email. On it they can:

• upload their data and a sample file — this is the tidiest way to receive the data (it lands straight on the project, and you can pull it with your analysis agent);
• see the stage stepper move — matched → meeting 1 → building → meeting 2 → delivered;
• read your progress updates and reports — intermediate ones as you build, and the final report;
• raise a question or an issue in a thread the teaching team and you can answer;
• get the occasional email nudge on the big moments (matched, final report) — which they can turn off.

During Meeting 1, take two minutes to show them their page: where to upload the data, where the progress and reports will appear, and how to message you. An owner who knows how to follow along stays engaged — and it is you, not the portal, who sets that expectation.

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 propose a project

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.

How, where, and when you hand in

You hand in to the teaching team, through the course portal — not to your client directly. (We share the finished results back with your client afterwards.)

1. Open the portal and sign in. On your Dashboard you will see a “Your final project” card — click “Open your project page to hand in.”
2. On your project page, upload three things: your written report, your runnable app or code (zip the folder), and your interview + analysis transcripts (your AI-use disclosure). You can upload as you go and re-upload to replace a file.
3. Prefer to let your agent do it? Pi can deliver straight to the project with the course API — the “Give your agent the project API” card on your project page has the one-line setup.

Deadline: hand in by 23 October. Master’s students also give the oral presentation on Tuesday 27 October, 10:00–12:00 (mandatory — this is where the A–F grade comes from). If you have agreed an individual extension with us, your dates are the ones in that email.

• Open your project page in the portal →

Assessment

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

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.