MyZubster: What Happens When an Open-Source Project Meets the Physical World?
Most software projects begin with a simple assumption:
the important events happen inside the software.
MyZubster is being developed around a different question:
What happens when software needs to understand, document and verify events happening in the physical world?
This is where our current development direction is heading.
From an app to an evidence infrastructure
MyZubster started as a digital platform, but the architecture we are exploring is becoming broader.
The model can be represented as:
Physical World
↓
Sensors / Users / Devices
↓
Raw Data
↓
Provenance
↓
AI Processing
↓
Evidence
↓
KPI / MRV
↓
Scientific Validation
↓
Digital Services
The difficult part isn't collecting data.
The difficult part is answering:
Where did this data come from?
Can we trust it?
Has it been modified?
Can another organization reproduce the result?
Can an AI explain why it reached a conclusion?
These questions are pushing MyZubster toward an evidence-first architecture.
Why environmental data is interesting
Environmental applications give us a useful testing ground because claims eventually have to meet measurable reality.
Consider irrigation water reuse.
A platform could claim:
Water saved: 35%
But that number means very little without context.
We need something closer to:
Sensor / Source
↓
Timestamp
↓
Location / Context
↓
Raw Measurement
↓
Methodology
↓
Transformation
↓
KPI
↓
Evidence
↓
Independent Validation
This is where concepts such as MRV — Measurement, Reporting and Verification become interesting from a software-engineering perspective.
The scientific layer
We're now beginning discussions with researchers and organizations about how this architecture could eventually be tested against real environmental datasets.
Current conversations are exploring areas including:
environmental and agronomic data;
circular water;
irrigation water reuse;
KPI/MRV;
data governance;
scientific methodology;
field monitoring;
reproducibility.
These are exploratory discussions.
They should not be interpreted as announced partnerships.
That distinction matters.
Open-source development should document not only what exists, but also what is still being investigated.
LIFE 2027
We're also exploring whether part of this architecture could eventually become the basis for a future LIFE 2027 proposal.
The idea isn't to put every MyZubster feature into one European project.
A much more interesting approach would be to isolate a measurable problem.
For example:
Environmental problem
↓
Pilot site
↓
Data acquisition
↓
Digital evidence
↓
MRV methodology
↓
Scientific validation
↓
Measured impact
↓
Replication
That would give software development a very different objective.
Instead of asking:
“Can we build this feature?”
we start asking:
“Can we demonstrate that this feature produces a measurable result?”
Open source changes the equation
There is another reason we're interested in this model.
If the architecture is open, external developers can inspect how evidence moves through the system.
They can challenge assumptions.
They can reproduce experiments.
They can improve adapters.
They can find bugs.
They can propose alternative verification mechanisms.
And sometimes tests will fail.
That's not necessarily bad.
A failed CI workflow can reveal an assumption that shouldn't reach production.
A rejected hypothesis can improve a scientific methodology.
An unsuccessful prototype can tell us what shouldn't be built.
Verification requires the possibility of failure.
AI should not become the source of truth
This is especially important as AI becomes part of software infrastructure.
Our direction isn't:
Data → AI → Truth
It should be closer to:
Evidence
↓
AI interpretation
↓
Traceable reasoning
↓
Verification
↓
Human / scientific review
AI can help analyze evidence.
It should not magically transform an unverified input into a verified fact.
That separation could become increasingly important for environmental systems, digital identity, IoT and decentralized infrastructure.
Where MyZubster is today
MyZubster is still under development.
Some components exist.
Some are prototypes.
Some remain research directions.
And some are simply future architecture.
We think maintaining those distinctions publicly is important.
We're not trying to make the repository look finished.
We're trying to make the development process inspectable.
The next challenge
The next phase isn't about adding another hundred features.
It's about connecting a small number of components end-to-end:
REAL EVENT
↓
DATA
↓
PROVENANCE
↓
EVIDENCE
↓
AI
↓
KPI
↓
VERIFICATION
↓
REPRODUCIBLE RESULT
If that pipeline works on a real pilot, then we have something worth scaling.
If it doesn't, we learn where the architecture fails.
Both outcomes are useful.
That's the direction we're taking with MyZubster:
Build → Measure → Verify → Connect → Replicate.
For developers, the interesting question is no longer only:
What can software generate?
It may increasingly become:
What can software prove?