The Balean Handbook

• 1: IT
• 1.1: Tech stack
• 2: Engineering
• 2.1: Test Cases Guidelines
• 3: Community
• 3.1: Code of Conduct
• 4: Compliance
• 4.1: ANBI Status
• 4.2: Travel and meeting policy
• 4.3: Confidentiality
• 5: Strategy
• 5.1: Balean Values

Dear Balean handbook maintainer,

I would like to propose a contribution to your handbook for the following page: <link to page>

Please consider the following:

* [ ] Add a child page to this page with the content below
* [ ] Change a section of this page with the content below
* [ ] Add the following content to this page

Content to be added:
<Add content here>

(optional) Content to be changed:
<Add current content here, if applicable>

With kind regards,
<your name>

1 - IT

Documentation of the platform design

To keep track of architectural decisions, functional and technical design, a separate docs site (Internal only) is made available.

Architectural design records

Building a platform requires architectural decisions to be made continuously. Tracking this in issues / epics creates the danger of loosing track of what is current and actual. Architectural decision records provide an easy way to document decisions and link newer decisions to previous ones. Since architectural decisions are directly linked to the technical and functional design, these decision records are kept in the same place as the system documentation.

Use case diagram

When building a new platform from scratch, many new features and functions need to be created and designed. To keep an overview of all the functions, systems and subsystems, a use-case diagram seemed the best approach to document this. Another way of making design decisions is to use issues or epics to create new designs and decide on what to build. The disadvantage is that this is isolated to the context of the issue. You miss the broader overview and interactions with other parts of the system. Even though Balean is using an agile approach, using use-cases enables us to keep overview and make holistic decisions on the design of the platform.

1.1 - Tech stack

Office applications

Development

2 - Engineering

Coding styles

At Balean we strive for readable and maintainable code. This requires all developers to adhere to a certain standard. This guideline will give details on that coding standard.

Source code style

When writing new source code at Balean, all code must be indented with 2 spaces. Lines should always end with the lf character to ensure the build runs successfully in linux-based containers. Windows developers should ensure that source code is pushed with the lf line-ending. The default character set is utf-8. Please ensure, before pushing, that your source file uses this character set.

In oder to automatically apply this standard to your source code, a file called .editorconfig should be added to all repositories to ensure correct styleguides. See Editor config below for more information.

Cross-platform compatibility

It is up to the developer to develop on the system of their choice, whether it’s Windows, Mac or Linux. Deployment targets, build images and scripts tend to run on Linux systems though. It is therefore important that the code-bases are all compatible with Linux but should be usable on other platforms as well.

There are certain scripts and config files that are specifically sensitive to the correct encoding and line-ending. Within Balean, the following settings are being used:

• Text file encoding: UTF-8
• Line ending: lf (equivalent to \\n)

Git settings

Git is the main source of truth and should contain the correct encoding and line-ending, regardless of what individual contributors may want to use. In order to ensure that files are in the right configuration, repositories should have a .gitattributes file that configures the expected line-ending. See also the git-attributes docs

To configure your local system to normalize files to the proper line-ending, the core.autocrlf setting must be set: git config --global core.autocrlf true This does not force normalization of text files, but does ensure that text files that you introduce to the repository have their line endings normalized to LF when they are added, and that files that are already normalized in the repository stay normalized. See git docs

By default, git supports files in UTF-8 encoding. Other encodings are handled as binary files.

Example .gitattributes file

# Automatically normalize all text files to lf
* text=auto eol=lf

# Exceptions and specific configurations
*.bat text eol=crlf
*.sh text eol=lf

VS Code settings

Use the following settings in VS Code for compatibility with Balean’s settings:

"files.encoding": "utf8"
"files.eol": "\n"

IDE Config

Editor config

Adding a file called .editorconfig to your repository will help set the correct coding standard. The editorconfig file is based on an open standard maintained by editorconfig.org.

An example .editorconfig is given below. When adding this file to the root of your repository will automatically apply the Balean standard to your repository.

# editorconfig.org

root = true

[*]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

2.1 - Test Cases Guidelines

Introduction

Clear and consistent test cases are essential to ensure software quality, reproducibility of results, and effective collaboration across the team.
These guidelines define Balean’s best practices for designing test cases, prioritizing them, and reporting defects.
Following this standard helps us:

• Improve communication between testers, developers, and stakeholders
• Ensure test coverage and traceability of requirements
• Reduce ambiguity and duplication in testing
• Provide a consistent format for documenting and tracking results

Standard Test Case Format

Here is a standard format to write test cases:

Test Case Format:

• Test Case ID
• Title
• Test Scenario
• Test Steps
• Prerequisites
• Test Data
• Expected Results
• Actual Results
• Test Status – Pass/Fail

While writing test cases, remember to include:

• A reasonable description of the requirement
• A description of the test process
• Details related to the testing setup: version of the software under test, browser, OS, environment, date, time, prerequisites, etc.
• Any related documents or attachments testers will require
• Alternatives to prerequisites, if they exist

Test Case Example

Here is a sample case based on a specific scenario:

• Test Case ID: #TC-001
• Test Scenario: Authenticate a successful user login on Gmail.com
• Test Steps:
  1. The user navigates to Gmail.com
  2. The user enters a registered email address in the “email” field
  3. The user clicks the “Next” button
  4. The user enters the registered password
  5. The user clicks “Sign In”
• Prerequisites: A registered Gmail ID with a unique username and password
• Browser: Chrome v86
• Device: Samsung Galaxy Tab S7
• Test Data:
  • Username: aquaman@gmail.com
  • Password: aquaman_123
• Expected/Intended Results: Once username and password are entered, the web page redirects to the user’s inbox, displaying and highlighting new emails at the top.
• Actual Results: As Expected
• Test Status – Pass/Fail: Pass

Test Case Prioritization

This is vital while writing test cases in software testing. Running all the test cases in a test suite requires much time and effort. As the number of features increases, testing the entire suite for every build is practically impossible. Test case prioritization helps overcome these challenges.

Testing should be automated as much as possible. This will overcome the limitation of the number of test cases to test before each build. With automated tests you can run as many tests as you want before each build, testing the application more thoroughly. But as with manual testing, time and resources are still limited. So prioritization will also help in test automation in two different ways:

1. It will help determine in which order to develop automated tests.
2. With continuous integration, you want quick and early feedback. So you probably can’t run the entire test suite for every commit, since that would take too long. The priority can then help build different test suites for quick tests and for the pre-production validation.

Test Case Priority Levels

While deciding how to assign priority to your test cases, consider the following levels:

• Priority 1: The test cases MUST be executed, or the consequences may worsen after the product is released. These are critical test cases where the chances of a functionality being disrupted due to a new feature are high.
• Priority 2: The test cases COULD be executed if enough time is available. These are not very critical cases but can be executed as a best practice for a double check before launch.
• Priority 3: The test cases are NOT important to be tested prior to the current release. These can be tested later, shortly after the release of the current software version, as a best practice. However, there is no direct dependency on them.
• Priority 4: The test cases are NEVER important, as their impact is nearly negligible.

What is a Defect or Bug Report?

A Defect Report is a document created during the software testing process to identify, describe, and track any issues or defects found in a software application.

It provides detailed information about the defect, including how it was discovered, the environment in which it occurred, and steps to reproduce it. A defect report includes complete details about the application/software defects, sources, actions needed to resolve them, and the expected result.

How to Write a Bug Report

Below is a short summary of what to include for each component of a full bug report:

Components of a Defect Report:

• Defect ID
• Defect Title
• Action Steps (Steps to Reproduce):
  The Steps to Reproduce section should list each step required to reproduce the bug in chronological order.
• Expected Result
  The Expected Results section should state how the app should behave according to its intended behavior.
  Example: The authorization phase completes successfully, the user is logged into the newly created account, and redirected to the home page of the app.
• Environment
  Each bug report must include details of the specific environment, device, and operating system used during testing to identify the bug.
• Actual Result
  This section should expand on the title by stating the behavior observed when the issue occurs.
• Severity
  • Critical – The bug prevents critical functionality within the app from working. This includes crashing or freezing where no workaround is possible, and a fix is required immediately.
  • High – The bug affects major functionality within the app. However, it can be temporarily avoided with a workaround.
  • Medium – The bug does not cause a failure and does not interfere with the fluent work of the system. It has an easy workaround.
  • Low – The bug does not affect functionality or data, or require a workaround. It is a result of non-conformance to a standard that does not impact productivity (e.g., typos, aesthetic inconsistencies).
• Usability – A suggestion that would improve how an app is understood, experienced, or used efficiently.
• Other Notes/Error Messages
  Include necessary and relevant evidence to show the problem you are describing. Evidence may include: screenshots, videos, or logs (if available).

3 - Community

Volunteering

Communication

Volunteers are encouraged to join our Balean Discord server. All communication and also publication of challenges, etc. is happening via Discord. If you sign up as a volunteer, you also agree to the Balean’s volunteering Code of Conduct.

Challenges

To channel volunteering work, all things to work on as a volunteer are tracked as challenges in the Balean Coding Challenges project. Challenges can range from marketing challenges to software development or infrastructure challenges. Everyone can apply by signing up for the balean-oss group and assing a challenge to their name.

The software that Balean uses to build the platform is mostly open-source software, published via the Balean OSS group on GitLab. The challenge listed should indicate what the challenge is about. Even though software may be owned by a 3rd party, every challenge is created to bring the platform and therefore Balean forward in their mission.

3.1 - Code of Conduct

This Code of Conduct outlines the standards of behaviour we expect from everyone involved in Balean, including team members, partners, collaborators, and users of our platform. By participating in our ocean sustainability community on Discord, you agree to abide by this Code of Conduct.

We value your contribution and we hope you will welcome other members with an open mind as well.

Our Standards

Balean’s community standards are based on our values.

1. Be Respectful: Treat others with kindness, empathy, and understanding.
2. Keep it Civil: Avoid using language or tone that might be perceived as aggressive, discriminating, condescending, or dismissive.
3. Accountability and Transparency: Be honest and open in your actions, take responsibility for your contributions, and strive to foster an environment of trust.
4. Constructive Feedback and Improvement: Focus on helping each other grow and improve rather than discouraging others.
5. Focus on the Issue: Engage in constructive discussions without resorting to personal attacks or inflammatory rhetoric.
6. Respect Diverse Perspectives: Recognize and appreciate differing viewpoints while maintaining a commitment to respectful dialogue.

Our Responsibilities

As a member of the Balean community, we are committed to providing an environment that is:

1. Safe: Welcoming and free from harassment, hate speech, and other forms of unacceptable behaviour.
2. Inclusive: Welcoming individuals with diverse backgrounds, perspectives, and experiences.
3. Respectful: Fostering a culture where all members feel valued, heard, and respected.

To achieve this goal, we:

1. Monitor community interactions: Regularly review online discussions to ensure they align with our Code of Conduct.
2. Address concerns promptly: Respond quickly to reports of unacceptable behaviour or other issues that may impact the community’s well-being. Balean holds the right to remove content that is against Balean’s Code of Conduct.
3. Foster open communication: Encourage members to share their thoughts, ideas, and respect each other’s opinions, perspectives, and dignity.

Unacceptable Behaviour

1. Harassment: No form of harassment, including but not limited to:
   • Verbal abuse
   • Threats
   • Intimidation
2. Hate Speech: Language or behaviour that discriminates against individuals based on their identity (e.g., race, ethnicity, nationality, sex, gender, sexual orientation, disabilities).
3. Unwelcoming Behaviour: Dismissive or exclusionary behaviour, or making others feel unwelcome contradicts our standard of inclusivity.
4. Spamming: Posting excessive content with the intention of disrupting discussions.
5. Advertisement: Posting advertisement for other initiatives than Balean, being commercial or non-commercial, without notice and written approval by Balean.

Reporting Incidents

If you experience or witness any behaviour that doesn’t align with this Code of Conduct, please report it by:

1. Reaching out directly: Contacting the individual involved (if comfortable doing so).
2. Using our reporting mechanism: Utilizing Balean’s designated reporting system to alert moderators.

All reports will be handled with confidentiality and with the safety and well-being of our community members as a priority.

Consequences

Repeated instances of unacceptable behaviour may result in consequences such as:

1. Temporary or permanent suspension: Restricting access to specific features, forums, or the entire community.
2. Removal from roles: Revoking responsibilities related to community management and content curation.

By adhering to this Code of Conduct, we can foster a positive environment that encourages collaboration, learning, and growth within our ocean sustainability community.

Acknowledgement

By participating in Balean’s online forums or engaging with the platform, you acknowledge having read and understood these guidelines. If you have any questions or concerns about this Code of Conduct, please don’t hesitate to reach out.

4 - Compliance

4.1 - ANBI Status

Dutch text below

Details

The Balean foundation is legally registered under the following name and address:

Stichting Balean
Provincialeweg 21
5835 CZ Beugen
The Netherlands

KvK (Chamber of Commerce) registration: 95267565
RSIN number: 867065710

Public Interest Organisation

Balean has requested to be identified as an organisation for public interest (ANBI status). This request is pending and not yet approved.

Purpose

According to our statutes (in dutch), Balean has the following purpose:

1. The aim of the Foundation is to connect organisations active in the conservation, protection and recovery of oceans and seas worldwide on the one hand and society, individuals, organisations, businesses and (semi-)governments on the other hand, as well as all anything that is related to the above in the broadest sense, is related to the above and/or can be conducive to the above.
2. The Foundation tries to achieve its objective by, among other things:
   • raising funds;
   • providing information;
   • creating a dialogue between the parties mentioned above; and
   • all other legally permissible ways.
3. The objective of the Foundation includes: accepting (or rejecting or not accepting) acquisitions by inheritance or gift, also if a charge or obligation is attached thereto.
4. The Foundation aims at the general interest and has no objective of making profit.

The above mission statement is translated from the statutes. The Dutch version is the original text.

Statutes

A copy of the statutes of the Balean Foundation is publicly available for review via this link. The statutes are in dutch and provided as is. The formal copy is deposited at the notary (Notariskantoor Teeuwen in Boxmeer, The Netherlands).

Strategy plan

The Balean Foundation (Stichting Balean) wrote a strategy plan in Dutch with justification and policies around the goals of the Foundation and a multi-year plan from inception through 2026. If you are interested in this plan, you can download it via this link.

Dutch

ANBI

Balean heeft een verzoek ingedient om aangemerkt te worden als ANBI. Dit verzoek is nog in behandeling.

Doelstelling

Zoals beschreven in onze statuten heeft de stichting het volgende doel:

1. De Stichting heeft ten doel het verbinden van organisaties actief in het behoud, bescherming en herstel van oceanen en zeeën wereldwijd enerzijds en de maatschappij, individuen, organisaties, ondernemingen en (semi-)overheden anderzijds alsmede al hetgeen in de ruimste zin met één en ander verband houdt, daartoe behoort en/of daartoe bevorderlijk kan zijn.
2. De Stichting tracht haar doel onder meer te bereiken door:
   • het werven van fondsen;
   • het geven van voorlichting;
   • het creëren van een dialoog tussen de hiervoor gemelde partijen; en - alle overige wettelijk toegestane manieren.
3. Tot de doelstelling van de Stichting is mede begrepen: het aanvaarden (of verwerpen dan wel niet aanvaarden) van verkrijgingen krachtens erfrecht of schenking, ook als daar een last of verplichting aan is verbonden.
4. De Stichting beoogt het algemeen belang en heeft niet ten doel het maken van winst.

Statuten

Een kopie van de statuten van de stichting zijn te downloaden via deze link. Deze statuten zijn een kopie van de oorspronkelijk door de notaris opgestelde statuten. De officiële statuten zijn gedeponeerd bij Notariskantoor Teeuwen te Boxmeer.

Beleidsplan

Stichting Balean heeft een beleidsplan opgesteld met een verantwoording en het beleid rondom de doelen van de Stichting en een meerjarenplan vanaf oprichting tot en met 2026. Dit beleidsplan is te downloaden via deze link.

4.2 - Travel and meeting policy

Summary

Balean is a foundation for ocean restoration and conservation. Based on the principle “practice what you preach”, we also have sustainability on our mind for all our internal activities. We have no office, no commute, mostly online meetings, and we are working on making our IT as green as possible as well.

In line with this, we also created a policy to help determine when to travel physically and when to meet online. The goal is to minimize our ecological footprint while ensuring effective collaboration.

Guidelines

Core Principles

• Avoid first: Prefer remote meetings unless they significantly compromise outcome quality.
• Reduce second: If physical travel is necessary, opt for the lowest-carbon alternative.
• Offset third: Only unavoidable emissions are compensated via verified schemes.

Avoid first

Online meetings and home office has allowed us to prevent carbon emissions from travel significantly. Online meetings is therefore the default option at Balean.

Reduce second

Sometimes a meeting can only be effective when you meet in person. See When to meet in person for more guidelines on this topic. If you need to meet in person, choose the travel option with the lowest carbon emissions.

1. Go by bike of by foot where possible
2. Prefer public transport (train/bus) over a car
3. Only use a car when public transport is not allowing you to reach your destination in time.
4. Use flying as a last resort.
5. If you do need to take a long journey, try to extend your stay by combining events. For example plan a vacation at the same destination to extend your stay.

Offset third

We see carbon offsetting as a last resort. Our priority is to reduce the amount we travel as much as possible. We pay to offset our carbon emissions from air, road and rail travel.

Meeting guidelines

When to meet online

• Online meetings always have the first preference.
• If you can meet in-person without carbon emission, prefer that over online.
• Only meet in person when online meetings are not an option. See When to meet in person for guidelines on when to consider an offline meeting.
• If the meeting takes less than 4 hours, always prefer online over meeting in person.

When to meet in person

• Strategic or Creative Collaboration is Critical
  • Multi-day workshops, design sprints, or innovation labs where brainstorming and co-creation are central.
• High-Trust Relationship Building is Required
  • Kick-offs with new partners, key donor negotiations, or sensitive stakeholder meetings where rapport and trust are essential.
• Complex or Sensitive Discussions Need Rich Communication
  • Conflict resolution, organizational change discussions, or high-stakes negotiations.
• Tactile or Physical Work is Involved
  • Hands-on activities like prototyping, field site visits, equipment training, or working with physical data/maps.
• Cross-Cultural or Interdisciplinary Teams Benefit from Rich Interaction
  • When face-to-face dynamics reduce misunderstanding and build common ground more effectively.
• Meeting Length and Intensity Justifies It
  • Extended workshops (e.g., 6+ hours/day over multiple days) where online fatigue would impair productivity.
• Multiple Goals Can Be Combined into One Trip
  • When several high-value engagements can be bundled (e.g., site visits + partner meetings + training) to maximize impact per trip.
  • It is also encouraged to extend your stay for personal reasons.
• Significant Long-Term Impact is Expected
  • When in-person interaction is likely to produce outcomes that shape strategy, partnerships, or funding in a lasting way.
• There is Clear Added Value Over Online
  • The organizer must demonstrate how physical presence will materially change the outcome compared to online.

Events and conferences

When you want to visit conferences or events, the same principles apply as with in person meetings. But also consider the following:

1. Does this event help us achieve outcomes we couldn’t achieve otherwise?
2. Justify travel if your visibility or influence is expected to create measurable impact.
3. Check if the event offers livestreams, hybrid participation, or recorded sessions and prioritize those options if they meet your needs.
4. Consider in-person attendance when critical partners, funders, or collaborators are confirmed to be present, and online networking would not provide the same opportunity.
5. Prefer local or regional conferences reachable by train or bus
   • Flights should only be considered if the event’s value and outcomes strongly outweigh the emissions impact.
6. Limit multiple team members attending the same event unless their roles are clearly distinct and necessary.
7. After the event, assess outcomes: Did we build valuable partnerships, raise our profile, or secure funding? If not, reconsider attending similar events in the future.

Travel guidelines

• Always prefer the lowest-carbon alternative.
• One-way rail journeys to other countries in Europe that take less than 10 hours, should be made by train at least one way; both ways where possible.
• One-way journeys that take less than 6 hours should be completed both ways by train.
• For journeys less than 200 km, consider public transport unless a destination is not reasonably accessible by public transport (e.g. public transport would take three hours or more).
• Also consider the lowest-carbon alternative when travelling from your destination airport/train station to your final destination. Prefer public transport or a shared bike over taking a taxi.
• If your destination is only reachable through flying, consider other alternatives first (like meeting online). Only fly as a last resort.

Emissions and offset

When calculating CO2 emissions, we use the CO2e standard. Use the calculators by MyClimate.org for a standardized way of calculation.

Decision criteria

1. Can the meeting be conducted effectively online?
   • Check Meeting guidelines
   • Yes -> Hold it online.
   • No -> Proceed to step 2.
2. Clearly describe the reason for meeting in person based on the guidelines.
   • Proceed to step 3
3. Select how to travel to the meeting based on the travel guidelines.
   • No carbon emissions -> Travel to the meeting
   • Otherwise -> Explain why necessary
4. Can you combine the trip with other events?
   • Yes -> Please elaborate on which events
   • No -> Reconsider meeting online

Roles & Accountability

• All significant travels must have a decision record which is reviewed by at least one other person.
• Travel logs and justifications are logged in a central system.

Decision template

Use the following decision template as an example to log specific decisions for meetings that include flying.

# Decision Overview: `Travel or Online Meeting`

**Date:** `[fill in]`
**Meeting Subject:** `[short description]`

## Meeting Details

* **Can the meeting be online?** `[yes/no]`
* **Distance between participants:** `[e.g., Europe - Canada]`
* **Meeting length:** `[e.g., 2 days]`
* **Justification for in-person:** `[e.g., yes, better brainstorming]`
* **Can the meeting be combined with other events?** `[Short motivation]`

## Decision

* **Decider(s):** [Name, Role]
* **Chosen option:** `[online/physical]`
* **Chosen transport:** `[bike/car/train/flight]`
* **Reason and justification:** `[short motivation]`

## Emissions & Offset

* **Estimated CO₂ emissions (kg):** [...]
* **Offset applied?** [Yes / No] — Details: [...]

Use Case Example

Meeting Details

To consider collaboration with a canadian organisation, we planned a 2-day workshop to work on a mutual business plan and discuss strategic details for that plan.

• Can the meeting be online? Yes - when split in multiple shorter meetings
• Distance between participants: Netherlands - Canada East Coast
• Meeting length: 2 days
• Justification for in-person: It is a meeting where Strategic or Creative Collaboration is Critical and High-Trust Relationship Building is Required. Significant Long-Term Impact is Expected with this meeting.
• Can the meeting be combined with other events? Yes, there is an opportunity to meet with other business partners.

Decision

• Decider(s): [Name, Role]
• Chosen option: Physical
• Chosen transport: Flight
• Reason and justification: The destination is only reachable by air. Due to timezone difference, a full day online meeting is not very practical. Relationship building in online meetings is less effective. The meeting is much more effective when held in person. Therefore the decision is made to fly.

Emissions & Offset

• Estimated CO₂ emissions (kg): 000
• Offset applied? [Yes / No] — Details: […]

4.3 - Confidentiality

Content confidentiality

Every organisation manages information with different levels of confidentiality. Based on its confidentiality, different protection levels will be in place.

To identify the confidentiality of an asset, we use the following confidentiality ratings:

Safety measures

For each confidentiality rating, different safety measures apply.

Public information

Information that is public to everyone will be published in this handbook. The handbook is open to everyone in the world. This public handbook makes how Balean works open and transparent. Any procedures, processes or other information related to Balean can be treated as public if it cannot harm Balean, its team members or any of Balean’s partners or customers in any way. Keep in mind that information can be used for phishing attempts and social engineering hacks. Giving away too much information may be used for such attempts. If you are unsure if information can be public, treat it as internal instead and ask for internal guidance.

Examples of non-public information include: data about people or partner organisations, specific details inside of a process, policy or procedure that could potentially help to gain access to systems owned by Balean. Think about details like usernames, IP-addresses, server names, network details, internal URL’s, bank account details, etc.

Anyone can propose changes to public pages by opening a merge request or an issue in the corresponding project. Every handbook page has a link to edit the page. Every change request will be reviewed by a Balean team member before being published in the handbook. Every Balean team member can approve changes and merge changes to public pages.

Protected information

Protected information is still publicly visible in the handbook but has a more thorough process for reviewing. Information is protected when the information in question is strategic to Balean in general or if the information in question applies to processes or procedures related to team members of Balean. Examples are Balean’s values since it is strategic to Balean in general, or community code of conduct since it applies to team members of Balean.

Changes to pages that are rated as protected must be reviewed and merged by a designated team within Balean.

Internal information

Information is rated as internal when it would harm Balean in any way if people outside Balean would see it. Examples of internal information are for example meeting minutes of meetings, non-public roadmaps or business plans. Internal information should never be added to the handbook, since the handbook stores information in a public space.

If information is internal, then that information is typically stored in Balean’s Google Drive or in applications that are only accessible by Balean team members. Any new information must be treated as internal unless you are sure that it can be shared to the public.

Confidential information

Information should be treated as confidential when it can be used to identify single people, organisations, servers, systems or other. Information must also be treated as confidential when it can be used to harm Balean, individual people or other organisations. Information that is rated as confidential should only be visible to the people with whom it is explicitly shared and who should have access to that information to do their job. Access to confidential information must be tracked and reviewed regularly.

When information is confidential it should never be stored in a public space, like the Balean handbook. When stored in Google Drive, then it must be stored in a location where specific people have been giving access to. Confidential information stored in a folder that is shared with certain groups has the risk of being shared with more people than desired when people are being added to that group.

When confidential information is stored in other systems than Google Drive, then that system must be reviewed separately. Especially when systems contain personal data, it must be reviewed for GDPR compliance.

5 - Strategy

Purpose

Our purpose is to connect people with the ocean.

We believe that protecting and restoring marine ecosystems starts by involving everyone; from individuals to institutions.

Through digital tools, storytelling, and shared knowledge, we make it easy to support science-based ocean conservation.

Together, we build a movement that transforms care into action. By connecting individuals, businesses, institutions, and governments to actionable marine efforts, we accelerate scalable impact on oceans and coasts, globally and locally.

Vision

Imagine what’s possible when we come together, fuelling a growing movement to protect and preserve nature for generations to come.

By growing a strong community of people, funding, and knowledge, we enable scalable solutions for nature conservation.

Our platform empowers partners to scale their conservation impact by connecting with a growing community—bringing together capital, data, and public engagement to drive systemic change.

Mission

We empower people to restore oceans together. Through our Balean platform, everyone can support conservation projects, follow their real-world impact, and feel connected to nature. Powered by a growing network of partners, we turn collective data into meaningful change.

Balean’s data-driven platform enables transparent and scalable ocean conservation through funding, awareness and visibility. The Balean platform creates a feedback loop between partners and the public, fostering trust, engagement, and insight, where everybody can be part of positive solutions.

Business architecture

To position Balean in the world at large, a business architecture is developed. This architecture is available in a draw.io diagram (For internal use only).

5.1 - Balean Values

The values we believe in

Balean is a purpose organisation that wants to make a positive impact. Everything we do to make this positive impact, should be guided by our 5 core values: Sustainability - Collaboration - Open mind - Honesty & Transparency - Trust.

What each of these values means to us is explained below.

Sustainability

In our organization, sustainability is our guidance and moral compass in everything we do and decisions we make. The United Nations Sustainable Development Goals 13 (climate action), 14 (life below water) and 17 (partnerships for the goals) are central for Balean, where we help partners achieve their own sustainability ambition.

Collaboration

In our global vision, collaboration outperforms competition for a positive impact. We search actively for mutually beneficial collaboration across disciplines. We continuously improve and embrace long term partnerships.

Honesty and transparency

We are transparent and honest about what we do and how we do it, in everything we do. Collaborative learning is central in public discussions both within Balean as towards 3rd parties.

Open mind

To make impact we need new ideas and perspectives. For our mission, anyone can contribute from their perspective, where we respect each others views and opinions. Diversity in background, culture, gender, or other any other factor enhances creativity and solutions.

Trust

Authenticity, empathy, and reliability is the basis for Balean. Everyone can make mistakes and we assume positive intent in our mission to a positive impact. Help each other in fixing things and learn collaboratively to improve together.