The SAIN Project Hub handbook

SAIN (Safe AI Netherlands) exists to prepare the Netherlands for the risks of transformative AI: AI capable of changing the economy, science, society, or global security on the scale of a major historical revolution. Every year, hundreds of people take a SAIN course or come to one of our events. The Project Hub is where they, and anyone else with the right background, make their first real contribution, with a supervisor or a project team behind them.

This handbook applies to participants working on a Project Hub project, supervisors affiliated with SAIN, project leads and collaborators on open projects, and anyone outside SAIN who wants to understand how the hub runs. Participants can be students, researchers, people working in industry, policy professionals, or people without a formal affiliation; supervisors come from universities, industry, and government alike.

Three things decide which projects we take on

We welcome any project that meaningfully contributes to AI safety, whether technical, governance, policy, or conceptual. When we decide which projects and supervisors to take on, we look at three things.

1. 01Relevance to the Netherlands, and to Europe or other middle powers. Many projects should be directly useful here: to Dutch policymakers, regulators, companies, or the Dutch public. General work, such as an interpretability project, is just as welcome, but local relevance helps a project stand out.
2. 02Relevance to transformative AI. The project should address risks from increasingly capable AI systems, whether those risks play out now or are plausible in the future.
3. 03Feasibility on a small budget. SAIN is largely volunteer-driven, so a project should not need large amounts of compute or money to succeed.

Almost any topic counts, if it reduces risk from transformative AI

If you are unsure whether a topic counts as AI safety, the default answer is yes, provided you can articulate a plausible pathway from your work to reducing risk from transformative AI. To make the scope concrete, the hub especially encourages work in the following areas, without being limited to them.

Five principles hold on every project

1. 01Intellectual honesty. Always communicate accurately what is known, unknown, and uncertain.
2. 02Proactively consider near-term and long-term harms, as well as dual-use concerns: ways the same work could both protect and cause harm. Section 4 covers this in depth.
3. 03Maintain a supportive environment across disciplines, sectors, and seniority levels. There is zero room for harmful authority.
4. 04Feedback, critique, and review are essential tools, not personal attacks. When receiving feedback, remember it is aimed at the work. When giving it, attack the ideas, not the person.
5. 05Respect confidentiality. Many participants and supervisors work at a company, university, or ministry. Never ask someone to share information they are not allowed to share, and do not share such information yourself.

Be extra wary of these principles when deadlines approach. Everyone is fallible, and when compromising on a principle is the difference between publishing and not publishing, holding the principle matters more than the publication.

There are two ways to take part

The hub currently runs in two modes. Everything later in this handbook applies to both unless it says otherwise.

Professionals can also start an open project around a question they run into in their own work: a policy advisor who wants to know how a certain AI risk could be monitored, or an engineer who wants to build an evaluation tool. Just make sure the question is one you can share publicly (see confidentiality in section 4).

Not ready for a project yet? That is completely fine. If you mainly want to learn, say so in the form, and we will point you to one of SAIN’s courses or reading groups. Many participants start there.

Anyone with sufficient background is eligible

• Both modes are open to anyone with sufficient background: Bachelor's, Master's, and PhD students, researchers, people working in industry, policy professionals, and people with no formal affiliation.
• Remote participation works.
• To supervise, you need substantial experience in a relevant field. In academia this usually means PhD level or above. Outside academia, several years of senior experience in a relevant role counts just as much, for instance as a machine learning or hardware engineer, a security specialist, or a policy advisor working on AI or digital policy. In exceptional cases this can differ.
• Supervisors do not need to be AI safety experts already. Deep expertise in your own field and a genuine interest in AI safety are often exactly what a project needs.

You can sign up at any time

• Sign-ups are rolling. Apply whenever you are ready, and someone from SAIN gets back to you within a working week.
• Matching with supervisors happens in rounds (section 3).
• Applicants for supervised projects tell us about their background and experience, which supervisors or projects they are interested in (up to three), what they would like to work on, and how many hours per week they can realistically put in.
• Supervisors only need to give us the basics: name, email, organisation, the projects they would like to supervise, and a short bio and picture for the website. No Discord account or long document is needed, though the Discord is the best way to get to know the community.
• For starting an open collaboration, we appreciate a fully fleshed-out proposal before you contact us, but if necessary we can help shape it.

Supervised projects are matched in rounds

This is how supervisors and participants are matched. We are working on automating parts of it, but the steps will stay roughly the same.

1. 1Supervisors sign up with their agenda: one or more projects they would like to supervise, the background they are looking for, and how many people they can take on. We turn this into a profile on our website and promote it through our chapters, courses, and network.
2. 2Applicants apply and select up to three supervisors or projects. If none of the agendas fit, describe what you would like to work on instead, and we will try to find a supervisor for it.
3. 3Every round has a deadline, which we publish on our website. After it, the Project Team does a light check of the applications (is the form complete, does the background fit the project?) and groups them per supervisor.
4. 4Within a week of the deadline, each supervisor receives the applicants who picked them, decides who they would like to talk to, and usually has a short call of 15 to 30 minutes with them before deciding.
5. 5Once both sides say yes, we send an introduction email, always with projects@safeainetherlands.org in cc, and the project starts.

• Thesis students: university deadlines do not wait for our rounds. If you are looking for a thesis supervisor or an external thesis project, mention it when you apply, and where possible we handle your application outside the regular rounds.
• No match this round? We tell you, and suggest next steps: the next round, an open collaboration, or a course to build up relevant skills. With your permission, your application stays in our system, so you do not need to fill everything in again.
• Your data: we only share your application with the supervisors you selected or, if you ask us to find a match for you, with supervisors we think are a good fit.

Supervised matching begins with an application

For supervised project matching, or to join an existing open collaboration, fill in the application form or email projects@safeainetherlands.org.

Apply for a project

Open collaborations begin with a project proposal

Before a project is approved as a Project Hub open collaboration, the project lead completes a project proposal. The full structure below is what we expect when the goal is a full paper and collaboration; for other outputs, drop what you think is unnecessary. A mechanistic interpretability tool, for example, does not need a title and abstract, and for a policy brief the policy question and intended audience matter more than hypotheses.

1. 01Title, problem statement, and motivation
2. 02Background and related work
3. 03Research or policy questions, and hypotheses if applicable
4. 04Intended audience: who should read or use this, for example researchers, a ministry, a regulator, or developers
5. 05Proposed methodology
6. 06Safety and risk considerations: dual-use, misuse, and infohazards, meaning information that could cause harm if widely shared
7. 07Needed resources: potential datasets, compute estimates, and how many collaborators for how much time
8. 08Timeline and milestones
9. 09Expected outputs

SAIN’s Project Team reviews the proposal and either approves it as a Project Hub project, with or without revisions, or declines it.

Onboarding starts with one form

Every new participant gets a rough overview of current projects, groups, and supervisors, an explanation of this handbook and where it lives, and, if relevant, access to compute or other support. Join our Discord by filling in the onboarding form; the invite and the information above follow from there. Supervisors are very welcome on the Discord as well, but it is not required: email works just fine.

Fill in the onboarding form (opens in a new tab)

What happens once you are matched or approved

• You are brought into contact with the relevant people. For supervised matching, a supervisor is formally assigned, we send an introduction email, and a project channel is created in the Discord. For joining an existing open project, you are officially added to the project and its Discord channel. For a new open project, we add it to our website, add you to the Discord, and promote the project so others can join.
• In a kick-off meeting, you agree the time commitment (for example 5 to 10 hours per week, or near full-time), the meeting cadence, and the intended output. We encourage communication through the Discord; other channels can be agreed if preferred.
• The project is registered internally and kept up to date as it progresses.
• Where applicable, the Project Team sets up a GitHub repository under the SAIN organisation and gives project members access.

Participants drive the work; supervisors steer it

The Project Hub is run by the Head of Projects, who works on it full-time and is responsible for it end to end, together with the Project Operations people in SAIN’s chapters, who know their local universities, companies, and organisations best. Together they form the Project Team. On open collaborations, the project lead runs the project and coordinates the team. Each role owes the others something concrete.

The rhythm is weekly

During a project, the standard pattern is the following, though your team or supervisor decides the details:

• Weekly or biweekly meetings: discuss recent progress and blockers, refine direction and scope, review experiments, results, and drafts.
• Weekly or biweekly check-ins: a short form for participants and supervisors noting what was tried, progress, and next steps. It keeps everyone accountable and lets the Project Team see how projects are going, and step in where it can help.
• Contact with the Project Team whenever necessary, via projects@safeainetherlands.org or the Discord.

Communicate early, precisely, and kindly

• Use the agreed channels, ideally the Discord, for project communication.
• Keep projects@safeainetherlands.org in cc in email threads about Project Hub projects.
• Respond within a reasonable timeframe: 2 to 3 working days for non-urgent matters.
• Meetings are the supervised participant's responsibility: have a simple agenda, start with a brief update since last time (the weekly check-in helps you keep track), and end with concrete next steps.
• Be explicit about availability: travel, family time, exam periods, busy periods at work.
• Default to kind, precise, and honest communication.

Agree milestones up front

Each project should specify intermediate milestones. As an example, not a fixed rule:

• Weeks 1 to 3: getting to know each other and the project, literature review.
• Weeks 4 to 8: a first proof of concept, such as a first experiment or a first outline of the policy brief.
• Weeks 8 to 10: internal discussion of the project, initial results, and what to improve.
• Weeks 10 to 12: working on the weaknesses found, new results.
• Weeks 12 to 14: writing up the final output and submitting it.

SAIN supports the work but does not pay for it

This applies mostly to technical projects.

• SAIN does not provide stipends or salaries. Participation is voluntary and educational.
• If funding for conference trips, workshop registrations, or travel is needed, we may be able to help within reason.
• Once a project is specified, the Project Team strives to give it easy access to compute and other resources. How much compute SAIN can help with depends on the project and is agreed at the start.
• We encourage computationally inexpensive projects wherever possible.
• Where it helps the project, we introduce you to relevant people: researchers, people in industry, or policymakers who could use your work.

Integrity, AI tools, confidentiality, and dual-use

Understanding matters more than publishing

The Project Hub should be a place where personal wellbeing is taken seriously and support is there for anyone who needs it. AI safety work, like any research, can be intellectually and emotionally demanding, especially under the publish-or-perish pressure that is unfortunately far too common. Combining a project with a demanding job or study can add to that.

• Be honest about workload and stress levels with your supervisor, and supervisors with their participants.
• Take regular breaks and keep boundaries between work and rest.
• Remember that what matters most is gaining a better understanding of AI safety, not whether one publishes.
• Speak to the SAIN team if conflicts or issues arise.

A project is complete when the question is answered

• The main question has been adequately addressed, including negative or null results, and the work has been published somewhere in a presentable form.
• If relevant, infohazard and dual-use considerations have been treated appropriately.

Final deliverables can take several forms

Each project specifies one or more final deliverables. For instance:

• A research paper at a conference, journal, or workshop.
• A blog post on SAIN’s Substack (opens in a new tab) and/or LessWrong.
• A policy brief or consultation response, ideally shared with the people who can act on it, such as a ministry, a regulator, or a parliamentary committee.
• An evaluation, benchmark, dataset, or open-source tool.
• A Dutch-language explainer or educational resource.
• A Bachelor's or Master's thesis, ideally followed by a shorter public write-up.

Authorship reflects contribution

• Authorship should reflect substantial intellectual and implementation contributions.
• Author order is handled internally within the project team.
• SAIN and the Project Hub should be acknowledged in publications.
• SAIN may promote your work as enabled by the Project Hub.
• If you have an employer, check whether they need to approve a publication, and whether your affiliation should, or should not, be mentioned.

After the project

• Send the final output to projects@safeainetherlands.org as a PDF, with a link if it is published elsewhere. We put the PDF on our website, so it stays available even if other links break.
• Output and other relevant resources, such as data, code, notes, and drafts, are stored in SAIN’s project archive.
• We share the result with the outside world, for instance in a post on SAIN's Substack and on social media, and update the Project Hub figures on our website. We always check the text with you before anything goes out.
• Write a short note on what went well and what could have gone better, ideally shared with the SAIN community.
• The project may be extended as a follow-up.

We hope you never need this section, but it matters that the path is written down before anyone needs it.

When to notify someone

• A supervisor or participant relationship breaks down, for example through persistent unavailability or unresolved conflict.
• There is suspected misconduct, such as data falsification, harassment including sexual harassment, or plagiarism.
• There are serious concerns about whether the project's direction is still aligned with AI safety.
• Project scope, expectations, or time commitments have become misaligned.

The path runs from direct to leadership

1. 1Participant and supervisor or project lead: try to resolve it directly first.
2. 2SAIN's Head of Projects, or anyone in the Project Team.
3. 3SAIN's Director, if the conflict involves the Head of Projects or the Project Team.

Possible remedies and sanctions

Depending on the severity and nature of the issue, possible actions include:

• Clarifying expectations and adjusting milestones.
• Reassigning the supervisor or participant to another project.
• Re-scoping or pausing the project.
• Removal from the Project Hub, or from SAIN roles, in severe cases.

Supervisor expectations are in section 4. The procedure for a supervised project is:

1. 01You sign up via the supervisor form, and we publish your agenda on our website.
2. 02After each round deadline, you receive the applicants who picked you, talk to the ones you are interested in, and let us know who you would like to work with (section 3).
3. 03Together with your team, you prepare a short project plan (a lighter version of the project proposal in section 3 is fine) and send it, with the list of people on the project, to projects@safeainetherlands.org. Include contact details, and each person’s Discord username and GitHub username where applicable, as a minimum.
4. 04If applicable, a repository is created in the SAIN GitHub organisation, and participants and supervisors get collaborator access.
5. 05Every Sunday, participants fill in the weekly check-in form; every second Sunday, the supervisor fills in the bi-weekly check-in form. Both forms are linked under Deadlines in section 4.
6. 06Keep projects@safeainetherlands.org in cc on emails about the project, so we know what is going on and can help when needed.

Interested in supervising through SAIN? You need substantial experience in a relevant field: usually PhD level or above in academia, or several years in a senior role in industry or policy. You do not need to be an AI safety expert already, and we welcome any discipline.