π» Weβre Opening Zorgax to Real-World Pilots β And Developers Can Join Through GitHub
I've been thinking about a problem while building MyZubster and Zorgax:
What happens when AI stops being just a chatbot and starts interacting with real-world projects?
Environmental sensors.
IoT devices.
Water monitoring.
Automation.
Digital twins.
Research data.
Citizen science.
Public-interest infrastructure.
At that point, the difficult problem isn't simply:
βWhich AI model should we use?β
The real questions become:
Where does the data come from?
Can we verify it?
Who is allowed to act on it?
What happens when the AI is wrong?
Can another developer reproduce the experiment?
And most importantly:
Can we prove that the system actually produced a useful result?
This is where we're taking Zorgax.
π A Free Pilot Model for Public-Interest Projects
We're exploring a free Zorgax pilot-access model for selected projects where the primary objective is experimentation, research, environmental evidence or public benefit.
That could include:
π Universities and research groups
ποΈ Municipalities and public-interest organisations
π± Environmental NGOs
π¬ Open-science projects
π₯ Citizen-science communities
π§ Water-monitoring initiatives
β»οΈ Circular-economy experiments
πΏ Biodiversity projects
π‘ IoT and environmental sensor networks
π§π» Open-source communities
The idea isn't to provide unlimited free AI compute.
It's to remove the financial barrier during the experimental stage.
Instead of asking:
βWhich subscription do you want?β
I'd rather start by asking:
βWhat are you trying to measure?β
π€ Zorgax Should Not Be the Authority
This is extremely important.
I don't want to build a system where an AI model receives sensor data and autonomously decides what happens in the real world.
The architecture I'm interested in looks more like this:
Sensor / Dataset
β
Data provenance
β
Zorgax analysis
β
Recommendation
β
Human review
β
Authorized action
β
New measurement
β
Verification
The AI helps interpret information.
The human remains responsible for consequential decisions.
That boundary becomes especially important when we're talking about environmental infrastructure or public-interest projects.
π Evidence Before Claims
Another principle I'm trying to enforce is simple:
Don't tell me the AI improved something. Show me.
For a real pilot, we need a baseline.
Then an intervention.
Then another measurement.
So instead of:
AI β βWe improved the system!β
we want:
Baseline β Measurement β Analysis β Human-reviewed intervention β Measurement β Comparison β Verification
In environmental projects this connects naturally to MRV: Measurement, Reporting and Verification.
And I think this is where AI becomes genuinely interesting.
Not as a machine generating impressive claims.
But as one component inside an auditable evidence pipeline.
πͺπΊ We're Also Preparing LIFE-Oriented Pilot Architecture
Another reason we're working this way is that MyZubster is exploring preparatory environmental pilots that could eventually contribute to a LIFE 2027 direction.
I want to be very clear about the wording here.
Preparatory.
This does not mean we currently have an EU-funded LIFE project.
It does not imply endorsement from the European Commission or CINEA.
It doesn't automatically make anyone contributing to the repository a project partner.
We're building the technical groundwork first:
Sensors β Evidence β Provenance β Zorgax β Human Review β Automation β MRV β Reproducibility
Then we can see whether the architecture is strong enough for larger collaborations.
π§π» And Developers Don't Need to Wait for an Invitation
This is probably the part most relevant to Coder Legion.
I don't want the only way to participate to be:
βContact us and maybe we'll schedule a meeting.β
Developers should be able to enter through GitHub.
Inspect the repositories.
Read the documentation.
Look at the issues.
Fork something.
Run it.
Break it.
Fix it.
Test it.
Open a Pull Request.
That's a much better introduction than a pitch deck.
π§ The Contribution Loop
The workflow I'm trying to encourage is straightforward:
Issue
β
Fork
β
Branch
β
Code
β
Test
β
Evidence
β
Pull Request
β
Review
β
Merge
But there's one thing I'd like contributors to add whenever possible:
Evidence.
Don't just say:
βI fixed it.β
Show:
the failing case β your change β the passing case.
If it's a performance improvement, show measurements.
If it's an IoT integration, show the data.
If it's an automation, document the trigger and result.
If it's an API change, provide a reproducible example.
If it's a bug, provide a test that catches it.
I want the repository to become not only a history of code.
I want it to become a history of evidence.
π§© Small Contributions Can Build a Much Bigger System
Imagine different developers independently contributing:
One builds a sensor adapter.
Another improves data ingestion.
Another works on provenance.
Another builds an API.
Another creates an automation engine.
Another improves Zorgax.
Another builds a dashboard.
Another creates a digital twin.
Another works on privacy.
Another improves documentation.
Individually, they're small projects.
Together:
Physical World
β
Sensors
β
Data ingestion
β
Provenance
β
Zorgax
β
Human decision
β
Automation
β
Digital Twin
β
Verification
That's the architecture I'm interested in.
π± Build Once. Reproduce Somewhere Else.
There's another challenge I find particularly interesting.
Suppose we create an environmental pilot in one location and it works.
That's not enough.
Can somebody else reproduce it?
Can another university, developer group, municipality or community understand:
which hardware was used,
which software was deployed,
how the data was collected,
which metrics were measured,
how Zorgax was configured,
where human approval was required,
how success was evaluated,
and what failed?
That's why I'm interested in eventually producing something similar to replication kits.
Not:
βLook at our amazing pilot.β
But:
βHere's the repository. Here's the methodology. Try to reproduce it.β
If another independent team gets comparable results, then things become interesting.
π GitHub Bounties Can Be Part of This
We're also experimenting with public development bounties.
That gives contributors another entry point:
Find a defined problem β read the acceptance criteria β build the solution β submit evidence.
But an open GitHub issue shouldn't automatically be interpreted as a paid contract.
Any reward needs explicit bounty conditions and verifiable acceptance criteria.
Again:
evidence before assumptions.
π§ Who Am I Looking For?
You don't have to be an AI engineer.
Actually, this architecture becomes more interesting when people from completely different technical backgrounds participate.
I'm interested in talking to people working with:
Python β’ JavaScript β’ Node.js β’ APIs β’ Docker β’ DevOps β’ IoT β’ Embedded Systems β’ Sensors β’ Data Engineering β’ GIS β’ Automation β’ Digital Twins β’ AI Agents β’ Cybersecurity β’ Privacy β’ Open Source β’ Accessibility β’ 3D
But also domain experts.
If we're working with water, someone needs to understand water.
If we're working with biodiversity, someone needs to understand biodiversity.
If we're building environmental measurements, someone needs to understand measurement.
AI doesn't remove the need for expertise.
It makes connecting different forms of expertise even more important.
π So Here's My Challenge to Coder Legion
Don't join because I tell you the project is interesting.
Inspect it.
Find something badly designed.
Find an assumption you disagree with.
Find a security problem.
Find an architectural weakness.
Find something that cannot be reproduced.
Then open an issue.
Or even better:
build a better version and open a Pull Request.
That's how I'd like developers to enter MyZubster.
Not as followers.
As contributors.
The bigger experiment is whether we can connect:
OPEN SOURCE + IoT + AI + AUTOMATION + REAL-WORLD DATA + HUMAN OVERSIGHT + DIGITAL TWINS + VERIFIABLE EVIDENCE
into something that can actually be reproduced outside our own environment.
If we can do that, Zorgax becomes much more interesting than another AI interface.
It becomes part of an open experimental infrastructure.
And if we can't?
GitHub should make the failures visible too.
That's part of building in public.
π¨π» Want to participate?
Start with the MyZubster Ecosystem on GitHub.
Read the code before believing the claims.
Find an issue.
Fork the repository.
Build something small.
Test it.
Bring evidence.
Open the PR.
Then let's see what we can build together.
CoderLegion #MyZubster #Zorgax #OpenSource #GitHub #Developers #Programming #SoftwareEngineering #IoT #AI #Automation #DigitalTwin #EnvironmentalTech #OpenScience #CitizenScience #ResponsibleAI #DevOps #Python #JavaScript #APIs #BuildInPublic #LIFE2027 #OpenInnovation