MyZubster Is Not Trying to Build Another App — We're Exploring a Verifiable Digital Ecosystem
For years, software development has largely followed the same pattern:
User → Application → Database → Service
AI changed part of that equation.
IoT changed another part.
Blockchain introduced new models for provenance and ownership.
But there is still a difficult problem connecting all of them:
How can a digital system verify what actually happened in the real world?
This is one of the questions driving the development of MyZubster.
MyZubster is an Italian open-source digital ecosystem currently under development.
It hasn't reached its final public form yet.
And that's important.
Because we're not presenting a finished platform.
We're documenting how the architecture evolves.
From application to ecosystem
Calling MyZubster simply an "app" increasingly feels incomplete.
The architecture we're exploring connects several layers:
MYZUBSTER
┌─────────────────┐
│ REAL WORLD │
│ people / places │
│ devices / events│
└────────┬────────┘
│
▼
┌─────────────────┐
│ DATA │
│ sensors / users │
│ external sources│
└────────┬────────┘
│
▼
┌─────────────────┐
│ PROVENANCE │
│ source / time │
│ context / proof │
└────────┬────────┘
│
▼
┌─────────────────┐
│ AI │
│ interpretation │
│ automation │
└────────┬────────┘
│
▼
┌─────────────────┐
│ EVIDENCE │
│ verification │
│ reproducibility │
└────────┬────────┘
│
▼
┌─────────────────┐
│ DIGITAL SERVICES│
└─────────────────┘
The goal isn't to put every technology imaginable into one application.
The interesting part is the connection between these layers.
AI needs evidence
Generative AI can produce extraordinary outputs.
But generation and verification are fundamentally different operations.
An AI system can say:
"This intervention reduced water consumption by 30%."
But where did that number come from?
What sensor produced the original measurement?
What period was compared?
What methodology was used?
Was the dataset modified?
Can somebody reproduce the calculation?
This leads to a principle we're increasingly using when thinking about MyZubster:
AI ≠ Source of Truth
Instead:
Evidence
↓
AI
↓
Interpretation
↓
Verification
↓
Decision
AI becomes a tool operating on evidence, rather than a machine expected to manufacture truth.
Connecting software to physical reality
This becomes particularly interesting with IoT.
Imagine an environmental pilot containing:
soil sensors
water meters
weather data
field observations
images
timestamps
GPS/context information
Collecting those values isn't enough.
We need provenance.
A measurement should ideally answer:
WHAT was measured?
WHERE?
WHEN?
BY WHICH DEVICE?
USING WHICH METHOD?
WHO/WHAT processed it?
WHAT transformation occurred?
CAN IT BE REPRODUCED?
Only then can we begin transforming raw measurements into meaningful digital evidence.
Why we're exploring MRV
This is also why we're increasingly interested in MRV: Measurement, Reporting and Verification.
A simplified pipeline might look like:
REAL EVENT
↓
MEASUREMENT
↓
RAW DATA
↓
PROVENANCE
↓
PROCESSING
↓
KPI
↓
REPORT
↓
VERIFICATION
This model is useful far beyond environmental projects.
It could eventually matter for:
sustainability;
circular economy;
agriculture;
digital identity;
decentralized systems;
IoT;
supply chains;
community contributions;
public-interest infrastructure.
The LIFE 2027 direction
We're currently exploring whether a focused part of this architecture could eventually support a future LIFE 2027 proposal.
The important word is exploring.
This is not an announcement of EU funding or a finalized consortium.
The work happening now is about understanding what could realistically be measured and validated.
We're beginning conversations around areas such as environmental data, agronomic information, circular water, irrigation reuse, scientific methodology, KPI/MRV and data governance.
The question isn't:
How do we fit MyZubster into a European project?
The better question is:
Is there a measurable environmental problem where this architecture can demonstrate something useful?
That's a much harder question.
And therefore a much more interesting engineering problem.
Open source becomes part of verification
Open source normally means that people can inspect the code.
But imagine extending that principle.
Developers inspect the implementation.
Researchers inspect the methodology.
Machines inspect structured evidence.
Communities inspect results.
Independent contributors attempt reproduction.
CODE
+
DATA
+
METHODOLOGY
+
EVIDENCE
+
REPRODUCIBILITY
=
TRUST
Not absolute trust.
Inspectable trust.
That distinction matters.
GitHub isn't just where the code lives
In this architecture, repositories can become part of the project's historical record.
Commits document changes.
Pull requests document discussion.
Issues document problems.
CI documents whether assumptions survive automated tests.
Releases document specific states of the system.
This doesn't make GitHub a source of real-world truth.
But it can provide something extremely valuable:
software provenance.
And software provenance can be connected to data provenance.
Failure needs to remain visible
There's another principle we're trying to preserve.
If everything always appears successful, the evidence isn't very useful.
Tests must be allowed to fail.
Experiments must be allowed to produce negative results.
AI conclusions must be challengeable.
Scientific hypotheses must be falsifiable.
Open-source contributors must be able to say:
"This doesn't work."
A trustworthy system isn't one where failure disappears.
It's one where failure becomes observable information.
What exists today?
MyZubster remains under active development.
There is code.
There are repositories.
There are experimental components.
There are prototypes.
There are architectural proposals.
And there are ideas that still need to survive contact with reality.
Those categories shouldn't be confused.
We don't want to call a roadmap feature "production."
We don't want to call an exploratory discussion a "partnership."
And we don't want to call an AI-generated conclusion "verified evidence."
The distinction between these states is becoming part of the architecture itself.
What comes next
The biggest challenge isn't adding more features.
It's proving one complete pipeline.
Something like:
Physical Event
↓
Measurement
↓
Provenance
↓
Evidence
↓
AI Analysis
↓
KPI
↓
Independent Validation
↓
Reproducible Result
If we can make that pipeline work on a real use case, we have something meaningful.
Then it can be improved.
Then replicated.
Then scaled.
If it fails, we document why.
That's still progress.
The future may belong to software that can show its work
The first generation of the web connected documents.
Social networks connected people.
Cloud platforms connected services.
IoT connected devices.
AI is connecting knowledge and computation in entirely new ways.
The next challenge may be connecting all of this to verifiable reality.
That's the direction we're exploring with MyZubster.
Not:
"Trust the platform."
But:
"Inspect the evidence."
MyZubster
Build → Measure → Verify → Connect → Replicate
