Inspiration
The idea for WildSafeShare comes partly from my background in biology.
Years ago, while studying biology in Colombia, I helped a friend organize field observation records from a primate research project involving woolly monkeys (Lagothrix, locally known as churucos). Those records included the type of information commonly collected in biodiversity research: species observations, dates, locations, and field notes.
At the time, I was mostly thinking about the scientific value of documenting where animals were found. Years later, while thinking about wildlife conservation for AnimalHack, I returned to that experience from a different perspective: the same location data that are valuable for research can become sensitive when the species is vulnerable to hunting, illegal collection, trafficking, or disturbance.
This creates an important tension. Conservation science benefits from open and reusable biodiversity data, but sharing every location at full precision is not always appropriate.
WildSafeShare was created around a simple question:
"How can researchers share useful biodiversity data without unnecessarily exposing the wildlife they are trying to protect?"
What it does
WildSafeShare is a lightweight pre-publication safety tool for biodiversity occurrence datasets.
A researcher provides two CSV files:
an occurrence dataset, containing observations such as scientific name, coordinates, date, and locality; a sensitivity-rules dataset, defining how much spatial protection should be applied to each taxon.
WildSafeShare then:
validates the input data; checks scientific names against the GBIF taxonomic service; connects accepted taxonomic names with researcher-defined sensitivity rules; withholds or generalizes coordinates according to the assigned sensitivity level; removes sensitive textual locality descriptions; documents every transformation; runs a final Safety Gate before allowing the dataset to be exported as public-safe.
If a species has no sensitivity rule, it is classified as UNASSESSED rather than assumed to be safe.
Likewise, uncertain taxonomic matches require human review.
How we built it
WildSafeShare was built in Python using a deliberately small architecture:
Pandas for data validation and transformation; GBIF API for taxonomic validation; Streamlit for the user interface; Pytest for automated checks.
The application is divided into three main components:
core.py handles validation, sensitivity rules, spatial protection, auditing, and the Safety Gate; taxonomy.py handles GBIF taxonomic matching; app.py provides the interactive workflow.
The application does not need a persistent database. Uploaded biodiversity data are processed during the session, and only scientific names are sent to GBIF for taxonomic validation. Coordinates and locality information are not sent to the external taxonomic API.
Challenges we ran into
Challenges
One of the most important challenges was deciding what WildSafeShare should not automate.
It would have been easy to classify every threatened species as spatially sensitive, but conservation status and disclosure risk are not the same thing. A species may be threatened primarily by habitat loss, while another species may face a strong collection or poaching risk even under a different conservation category.
For this reason, WildSafeShare does not attempt to decide which species are sensitive. Instead, it applies policies supplied by researchers, institutions, conservation programs, or relevant authorities.
Another challenge was designing the system to fail safely.
WildSafeShare therefore follows two conservative rules:
no sensitivity rule does not mean “not sensitive”; it means UNASSESSED; uncertain taxonomy does not mean “close enough”; it means human review is required.
Both conditions prevent the final Safety Gate from passing.
What we learned
This project reinforced something that is easy to overlook when working with scientific data: data quality and data openness are not the only considerations—data disclosure can also have consequences.
I also learned that protecting biodiversity data does not necessarily require a complex AI system. A relatively small software tool can create value by combining existing scientific standards, transparent rules, careful validation, and a workflow designed around responsible data sharing.
WildSafeShare is therefore intentionally simple.
Its goal is not to replace conservation experts or institutional policies, but to give them a practical tool for applying those decisions consistently before biodiversity data become public.
What's next for WildSafeShare
Future versions could support temporal sensitivity, institutional rule libraries, additional biodiversity formats such as GeoJSON, configurable spatial policies, and integration with additional authoritative conservation data sources.
The core principle, however, would remain the same:
"Make biodiversity data as open as possible, while protecting the information that could put wildlife at risk."
Log in or sign up for Devpost to join the conversation.