🌍 Zorgax for Public-Interest Pilots: Free Access, LIFE Experiments and How Developers Can Join Through GitHub
One of the questions we are starting to face as MyZubster moves from software experiments toward real-world pilots is very simple:
Who should actually have to pay for Zorgax?
For a commercial SaaS product, the obvious answer would be:
Everyone who uses more resources pays.
But Zorgax is becoming something slightly different.
We are building it as an intelligence, research and orchestration layer inside the MyZubster ecosystem, and some of the most interesting potential applications are not ordinary commercial use cases.
They involve:
- environmental monitoring;
- research;
- universities;
- municipalities and public-interest organisations;
- NGOs and non-profit initiatives;
- open-source communities;
- citizen-science projects;
- circular-economy experiments;
- water monitoring;
- biodiversity;
- urban laboratories;
- IoT infrastructure;
- LIFE-oriented environmental pilots;
- reproducible scientific and technical experiments.
For these contexts, we want to explore a different model.
🆓 A Free Zorgax Pilot Layer
Zorgax already has a normal access model for individual users and developers.
The current public architecture includes Free, Pro and Developer access levels, with Developer access providing higher limits, automation and direct research API capabilities.
But institutional and public-interest experimentation creates a different problem.
If a university laboratory, municipality, environmental association or open-source research group wants to test a small Zorgax workflow, the first interaction should not necessarily be:
“Where is your credit card?”
It should be:
“What are you trying to measure?”
That is why we are defining a free pilot-access direction for eligible public-interest and research experiments.
The objective is not unlimited free AI infrastructure.
The objective is to remove the economic barrier from the validation stage.
🏛️ Who Could Qualify?
The model we are exploring is intended primarily for organisations and projects where the objective is research, validation, environmental evidence, public interest or open experimentation.
Examples include:
🎓 Universities and Research Groups
A university laboratory could use Zorgax to experiment with:
- environmental datasets;
- sensor analysis;
- literature research;
- evidence extraction;
- data provenance;
- reproducibility;
- digital twins;
- research workflows;
- human-reviewed AI recommendations.
The important condition is that Zorgax remains an assistant to researchers, not an autonomous scientific authority.
Human scientific and technical review remains essential.
🏛️ Municipalities and Public Administrations
Local authorities could potentially test Zorgax for bounded experiments involving:
- environmental observations;
- public datasets;
- urban infrastructure;
- accessibility;
- circular economy;
- waste monitoring;
- water;
- citizen reports;
- evidence organisation;
- decision-support prototypes.
Again, this does not mean Zorgax should autonomously make public decisions.
The architecture we are developing follows a much more conservative model:
DATA
↓
ZORGAX
↓
ANALYSIS
↓
RECOMMENDATION
↓
HUMAN REVIEW
↓
AUTHORIZED DECISION
The final decision remains with the authorised human or institution.
🌱 NGOs, Environmental Organisations and Citizen Science
Another category is environmental and non-profit experimentation.
Imagine a local association monitoring a river.
Or volunteers collecting observations about biodiversity.
Or a citizen-science project measuring temperature, water quality or environmental conditions.
The architecture could look like:
SENSOR / HUMAN OBSERVATION
↓
DATA
↓
PROVENANCE
↓
ZORGAX
↓
ANALYSIS
↓
HUMAN REVIEW
↓
VERIFIED EVIDENCE
Zorgax can help organise and analyse information.
It should not magically transform unverified data into truth.
That distinction is fundamental.
💧 Water and Environmental Infrastructure
Water is one of the areas we are currently exploring for potential European pilots.
The architecture is particularly interesting because water projects naturally combine physical infrastructure and measurable evidence.
For example:
SENSORS
↓
WATER DATA
↓
BASELINE
↓
ZORGAX ANALYSIS
↓
HUMAN-APPROVED INTERVENTION
↓
NEW MEASUREMENT
↓
COMPARISON
↓
MRV
MRV means:
Measurement, Reporting and Verification.
This is critical.
If we claim that an AI-assisted system improved an environmental process, there should be measurable evidence before and after the intervention.
Not:
AI
↓
CLAIM
But:
BASELINE
↓
MEASUREMENT
↓
ANALYSIS
↓
INTERVENTION
↓
MEASUREMENT
↓
VERIFICATION
That is the kind of architecture we want Zorgax to support.
🇪🇺 The LIFE Direction
This becomes particularly relevant to the environmental direction we are preparing around LIFE 2027.
MyZubster is currently working on a preparatory environmental pilot architecture that could eventually support a possible LIFE pathway.
This includes concepts around:
- environmental evidence;
- data provenance;
- sensors and IoT;
- KPI definition;
- Measurement, Reporting and Verification;
- Zorgax-assisted analysis;
- automation;
- digital twins;
- human scientific review;
- reproducibility;
- replication kits.
But there is an important boundary.
These are preparatory pilots and technical directions.
They do not mean that MyZubster currently has an approved LIFE project.
They do not imply European Commission or CINEA endorsement.
They do not imply EU funding.
They do not automatically make an organisation a consortium partner.
We want the public GitHub history to make those distinctions visible.
🧪 What Is a MyZubster LIFE Pilot?
For us, a pilot should not begin with a huge promise.
It should begin with a measurable question.
For example:
Can we measure a specific environmental condition using existing sensors?
Then:
Can Zorgax analyse that evidence without taking unauthorized actions?
Then:
Can a qualified human review the recommendation?
Then:
Can an intervention be performed?
Then:
Can we measure the result?
A pilot therefore becomes an engineering loop:
PROBLEM
↓
BASELINE
↓
DATA SOURCE
↓
ZORGAX
↓
HUMAN REVIEW
↓
INTERVENTION
↓
MEASUREMENT
↓
VERIFICATION
↓
REPRODUCTION
This is much more interesting to us than simply attaching the words AI, blockchain or LIFE to a project.
🤖 What Does Zorgax Actually Do?
Zorgax should operate inside clearly defined boundaries.
For a pilot, we want to define things such as:
What can Zorgax read?
What can it analyse?
What can it recommend?
What is it forbidden from doing?
Who approves actions?
Where is evidence stored?
Who owns the data?
Which information can become public?
Which information must remain private?
What defines success?
When should the pilot stop?
This is why governance is becoming part of the software architecture.
When AI interacts with real infrastructure, permissions are not paperwork added after development.
Permissions are part of the system design.
🔐 Free Does Not Mean Uncontrolled
This is important.
A free pilot plan should not mean:
unlimited tokens + unlimited automation + unrestricted APIs.
Instead, we are thinking about bounded pilot environments.
Conceptually:
ORGANISATION
↓
PILOT REQUEST
↓
SCOPE DEFINITION
↓
DATA / PRIVACY REVIEW
↓
ZORGAX PILOT ACCESS
↓
EXPERIMENT
↓
MEASUREMENT
↓
PUBLIC / SANITIZED EVIDENCE
↓
CONTINUE / MODIFY / STOP
The purpose of free access is to make experimentation possible.
The limits are there to make experimentation responsible.
🧑💻 And This Is Where GitHub Becomes Extremely Important
We do not want participation in these pilots to happen only through private meetings.
Developers should be able to enter the project through GitHub.
The MyZubster source, issues, documentation and contribution paths are public.
That means you don't necessarily need to know us personally.
You don't need to wait for someone to invite you into a private development group.
You can start by inspecting the code.
Step 1 — Explore the MyZubster GitHub Organisation
Visit:
MyZubster-Ecosystem
Look at the repositories.
Read the documentation.
Look at open issues.
Look at pull requests.
Look at the project history.
Don't trust a marketing post.
Inspect the repository.
🔎 Step 2 — Find Something Small
You do not need to understand the entire ecosystem before contributing.
Find one problem.
It might involve:
- backend;
- frontend;
- Node.js;
- Python;
- APIs;
- Docker;
- CI/CD;
- testing;
- IoT;
- data processing;
- AI;
- automation;
- documentation;
- privacy;
- security;
- accessibility;
- environmental data;
- digital twins;
- mapping.
Start small.
This is extremely important.
We would rather see one reproducible improvement than a giant architectural proposal that nobody can test.
🍴 Step 3 — Fork the Repository
The normal open-source workflow applies.
MYZUBSTER REPOSITORY
↓
FORK
↓
BRANCH
↓
CODE
↓
TEST
↓
COMMIT
↓
PUSH
↓
PULL REQUEST
Create your own fork.
Create a dedicated branch.
Implement one bounded change.
Test it.
Document what you changed.
Then open a Pull Request.
🧪 Step 4 — Bring Evidence, Not Just Code
A contribution becomes much more useful when it includes evidence.
For example:
"I fixed the API."
is weaker than:
"I fixed the API.
Here is the failing test.
Here is the change.
Here is the passing test.
Here is the CI result.
Here is how to reproduce it."
This philosophy is central to MyZubster.
We want development to produce reproducible evidence.
GitHub is perfect for this because the history becomes inspectable.
🧩 Step 5 — Turn Contributions Into Capabilities
This is where the larger architecture becomes interesting.
Imagine one developer builds a better sensor ingestion module.
Another developer improves provenance.
Another adds an environmental-data adapter.
Another creates a visualization.
Another builds a digital twin.
Another creates an automation workflow.
Another improves Zorgax analysis.
Individually, these are small contributions.
Together they become:
SENSOR
↓
INGESTION
↓
PROVENANCE
↓
DATABASE
↓
ZORGAX
↓
AUTOMATION
↓
DIGITAL TWIN
↓
HUMAN INTERFACE
The ecosystem grows by accumulating capabilities, not simply users.
🌍 Step 6 — Replicate the Pilot
This is one of the most important long-term goals.
A successful pilot should not remain trapped in one organisation.
Where legally and technically possible, we want to produce reusable documentation.
Something closer to a:
Replication Kit.
A second organisation should eventually be able to say:
We want to reproduce that experiment.
And GitHub should help them understand:
- hardware requirements;
- software;
- deployment;
- configuration;
- data schema;
- measurement methodology;
- privacy requirements;
- KPIs;
- automation boundaries;
- test procedures;
- verification;
- known limitations.
Then we can move from:
ONE PILOT
to:
ONE PILOT
↓
DOCUMENTATION
↓
REPLICATION KIT
↓
INDEPENDENT PILOT
↓
COMPARABLE EVIDENCE
That is much more powerful than simply saying we have users in different countries.
🏆 Contributions and Bounties
MyZubster is also experimenting with public GitHub bounties.
Some issues can carry defined contribution rewards or points.
But we want to keep an important distinction clear:
an open issue is not automatically a paid contract.
Rewards should be governed by the specific bounty conditions and by verifiable settlement rules.
The important thing is that developers have a public surface where they can discover concrete work rather than simply being told:
“Join our community.”
Instead:
Here is the issue.
Here are the acceptance criteria.
Here is the repository.
Show us the code.
🔬 Who Are We Looking For?
Not only AI developers.
We are interested in people working with:
Python
JavaScript / Node.js
APIs
Docker
DevOps
Data engineering
IoT
Embedded systems
Environmental sensors
GIS
Digital twins
Automation
AI agents
Privacy
Cybersecurity
Open-source governance
Scientific reproducibility
UX / accessibility
3D / metaverse interfaces
And importantly:
domain experts.
If we're monitoring water, we need people who understand water.
If we're working with biodiversity, we need people who understand biodiversity.
If we're testing urban systems, we need people who understand cities.
AI cannot replace that expertise.
🤝 Organisations Can Participate Too
An organisation does not necessarily need to become a formal MyZubster partner to experiment with the architecture.
There are several possible levels of participation:
OBSERVE
↓
REVIEW
↓
CONTRIBUTE
↓
REPRODUCE
↓
PILOT
↓
VERIFY
↓
FORMAL COLLABORATION — IF APPROPRIATE
Those distinctions matter.
A GitHub contributor is not automatically a partner.
A pilot discussion is not a partnership.
A test is not an endorsement.
An organisation receiving experimental access does not automatically endorse MyZubster.
And a LIFE-oriented pilot does not mean LIFE funding.
We want those boundaries to remain explicit.
🚀 Why Offer Zorgax Free for These Pilots?
Because at this stage the most valuable currency is not subscription revenue.
It is evidence.
Can Zorgax help researchers organise environmental information?
Can it work with sensor evidence?
Can it assist without replacing human authority?
Can workflows remain auditable?
Can independent organisations reproduce an experiment?
Can developers improve the architecture through public Pull Requests?
Can we measure whether an intervention actually worked?
If the answer to those questions eventually becomes yes, then we have created something valuable.
If the answer is no, we need to know that too.
That is what pilots are for.
🧠 The Bigger Vision
The architecture we are exploring looks increasingly like this:
REAL WORLD
↓
SENSORS / OBSERVATIONS
↓
DATA
↓
PROVENANCE
↓
ZORGAX
↓
ANALYSIS
↓
HUMAN APPROVAL
↓
AUTOMATION / INTERVENTION
↓
MEASUREMENT
↓
VERIFICATION
↓
GITHUB EVIDENCE
↓
REPLICATION
↓
NEW PILOT
And around that loop:
developers, researchers, institutions, NGOs, makers, scientists and open-source communities.
That is the project.
Not an AI that magically runs everything.
An open infrastructure where humans and AI can work together around measurable, inspectable real-world evidence.
👨💻 Want to Join?
You don't need permission to start reading.
You don't need to buy anything to inspect the open-source work.
Start with the repository.
Read.
Question it.
Break something locally.
Find an issue.
Propose an improvement.
Fork.
Build.
Test.
Open a Pull Request.
And if you represent a university, municipality, NGO, research organisation, environmental initiative or another legitimate public-interest project and have a concrete pilot idea:
bring us the problem first.
Tell us:
What do you want to measure?
What data already exists?
What would success look like?
Who would verify the result?
Because the goal of the Zorgax pilot program isn't:
“Give organisations free AI.”
The goal is:
Give serious experiments an open technical environment in which AI-assisted workflows can be tested, measured, challenged and independently reproduced.
And if the experiment works?
Publish the evidence.
Then let somebody else reproduce it.
That's how we want MyZubster to grow.
Not through claims.
Through code, pilots and verifiable evidence.
Top comments (0)