MyZubster Is Entering Its Hardest Phase: Connecting Code to Reality
Building a prototype is relatively easy.
Building a repository is harder.
Building an ecosystem where software, infrastructure, AI, blockchain, contributors and real-world data must work together is something else entirely.
That's the phase MyZubster is beginning to enter.
MyZubster is an Italian open-source digital ecosystem currently under development.
It isn't a finished product, and we don't want to describe experimental components as production-ready systems.
But something important is happening.
The project is moving from:
BUILDING COMPONENTS
toward:
CONNECTING COMPONENTS
↓
TESTING THEM
↓
OBSERVING FAILURES
↓
COLLECTING EVIDENCE
↓
VERIFYING RESULTS
And this transition is changing how we think about the entire architecture.
The prototype phase is ending
Early-stage development encourages experimentation.
You create APIs.
You test databases.
You integrate AI.
You deploy services.
You experiment with blockchain.
You build interfaces.
You create repositories.
Eventually, however, adding another component stops being the hardest problem.
The real question becomes:
Can these components operate together as one observable system?
That's where MyZubster is heading.
A simplified view looks like this:
MYZUBSTER
Developers ───────────────┐
│
Users ────────────────────┤
│
IoT / Sensors ────────────┤
▼
DATA LAYER
│
▼
PROVENANCE
│
┌─────────┴─────────┐
▼ ▼
AI BLOCKCHAIN
│ │
└─────────┬─────────┘
▼
EVIDENCE
│
▼
VERIFICATION
│
▼
DIGITAL SERVICES
Every box is relatively understandable individually.
The difficulty exists between the boxes.
Infrastructure immediately challenges architecture
We recently saw a perfect example while operating a Monero node.
The daemon was running.
RPC was responding.
The node reported:
busy_syncing: true
synchronized: false
Everything appeared to suggest normal synchronization.
Except the blockchain height stopped progressing.
The reason wasn't an exotic blockchain bug.
It was storage.
The server reached:
/dev/mapper/lv-root
79 GB total
79 GB used
0 GB available
100%
The Monero LMDB database had grown significantly while the node was still catching up with the network.
We recovered several gigabytes by identifying development repositories that were safely reproducible from their remote Git repositories.
The node immediately began moving again.
We observed progress from approximately:
2,705,556
↓
2,708,936
↓
2,711,216
↓
2,838,236
Then something equally useful happened.
The filesystem filled again.
Why?
Because the underlying capacity problem hadn't disappeared.
We had treated the symptom.
Not the architecture.
That's a development milestone too
It might sound strange to call a full disk a milestone.
But it exposed something important.
MyZubster can no longer think only about:
FEATURES
We need to think about:
CAPACITY
RELIABILITY
OBSERVABILITY
RECOVERY
DATA GROWTH
SERVICE HEALTH
That's what happens when experimental software begins interacting with persistent infrastructure.
The architecture diagram meets physics.
And physics usually wins.
“Running” is not a health status
This experience also reinforced another principle.
Suppose Linux tells us:
monerod → RUNNING
That doesn't prove the node is healthy.
Actual health requires multiple signals:
Process alive
RPC responsive
Network connectivity
Peers
Database writable
Blockchain height progressing
Storage available
Operational Node
This idea extends far beyond blockchain.
An API returning 200 OK doesn't necessarily mean the underlying system is functioning correctly.
An AI model returning an answer doesn't mean the answer is correct.
A sensor sending packets doesn't mean its measurements are valid.
A CI workflow passing doesn't prove a physical-world claim.
Availability is not verification.
This changes how we think about AI
AI is becoming increasingly capable of observing and operating software systems.
But giving AI access to infrastructure without giving it reliable evidence creates another problem.
Imagine an agent receiving:
monerod = running
It could conclude:
Everything is operational.
But give it:
{
"process": "running",
"rpc": "responsive",
"syncing": true,
"height_progressing": false,
"disk_usage": 100,
"disk_available": 0
}
and the conclusion changes completely.
Now the agent has evidence.
This is the model we're interested in:
OBSERVATION
↓
EVIDENCE
↓
AI ANALYSIS
↓
INTERPRETATION
↓
ACTION
↓
VERIFICATION
Not:
AI
↓
GUESS
↓
ACTION
GitHub becomes more important in this model
Another interesting development is happening around contribution.
External developers are beginning to show interest in concrete MyZubster work.
Recent areas include:
REST APIs
MongoDB schemas
mapping data
Node.js / Express
data pipelines
unit testing
QA
reproducibility
API verification
This is significant for an open-source project.
Because the transition we ultimately want isn't:
Founder writes code
↓
Repository grows
It's:
Problem
↓
Issue
↓
Contributor
↓
Implementation
↓
CI
↓
Review
↓
Evidence
↓
Reusable component
GitHub therefore becomes more than storage.
Issues document problems.
Pull requests document proposed solutions.
Commits document changes.
CI documents automated verification attempts.
Failures document assumptions that didn't survive testing.
That history has value.
Failed CI isn't noise
We're also seeing experimental workflows fail.
That's expected.
When building blockchain settlement experiments, metaverse integrations, APIs or other new components, some workflows won't pass immediately.
The wrong response would be hiding those failures.
A verification-oriented ecosystem should preserve them.
ASSUMPTION
↓
IMPLEMENTATION
↓
TEST
↓
FAIL
↓
EVIDENCE
↓
DIAGNOSIS
↓
NEW IMPLEMENTATION
Failure becomes part of the development record.
This principle becomes even more important when software begins making claims about the physical world.
From software testing to real-world verification
One of MyZubster's emerging research directions concerns environmental and agricultural applications.
We're exploring questions around:
environmental data;
agronomic data;
water;
irrigation;
circular water reuse;
IoT;
KPI;
MRV;
data governance;
scientific validation.
This creates a fascinating engineering problem.
Imagine MyZubster eventually displays:
WATER SAVED: 31%
Where did 31% come from?
A database?
An AI model?
A sensor?
A calculation?
A researcher?
A manually entered value?
Without provenance, it's just another number on a dashboard.
A meaningful pipeline requires something closer to:
PHYSICAL EVENT
↓
MEASUREMENT
↓
RAW DATA
↓
TIMESTAMP + CONTEXT
↓
PROVENANCE
↓
METHODOLOGY
↓
CALCULATION
↓
KPI
↓
EVIDENCE
↓
VALIDATION
Now the number has a history.
And potentially, it can be challenged and reproduced.
This is why we're exploring MRV
MRV means:
Measurement, Reporting and Verification.
It's common terminology in environmental and sustainability contexts, but from a developer perspective it introduces a powerful architectural idea.
A system shouldn't simply report a result.
It should preserve enough information to explain how the result was produced.
That principle could eventually apply far beyond environmental projects.
Imagine:
Environmental contribution
↓
Evidence
↓
Verification
Developer contribution
↓
Evidence
↓
Verification
Physical-world event
↓
Evidence
↓
Verification
Digital transaction
↓
Evidence
↓
Verification
Different domains.
Same architectural principle.
Exploring LIFE 2027
We're also currently exploring whether a focused environmental use case could eventually become part of a future LIFE 2027 proposal.
This needs an important clarification.
Exploration is not funding.
A conversation is not a partnership.
A proposed consortium is not an approved consortium.
And a research direction is not a completed project.
We're currently interested in determining whether there is a problem that is:
REAL
MEASURABLE
SCIENTIFICALLY VALIDATABLE
TECHNICALLY IMPLEMENTABLE
REPLICABLE
Only after those conditions start making sense does the technology become interesting.
The objective shouldn't be:
“How can we put MyZubster into a European project?”
It should be:
“Is there a measurable environmental problem where MyZubster's architecture can provide useful evidence?”
That's a much better engineering question.
Scientific validation introduces a new boundary
Developers are accustomed to this:
npm test
PASS
But imagine we're testing environmental impact.
A passing unit test cannot prove that irrigation efficiency improved.
CI can verify the software that performs a calculation.
It cannot independently prove the physical event behind the input data.
That's where different disciplines begin connecting:
SOFTWARE ENGINEERING
FIELD DATA
IOT
DATA SCIENCE
SCIENTIFIC METHODOLOGY
MRV
VERIFIABLE RESULT
And this is precisely why MyZubster increasingly looks like an ecosystem rather than a conventional application.
The next phase
Our biggest challenge now isn't adding another hundred features.
It's proving one complete vertical slice.
For example:
REAL-WORLD EVENT
↓
SENSOR / SOURCE
↓
RAW DATA
↓
PROVENANCE
↓
MYZUBSTER
↓
AI ANALYSIS
↓
KPI
↓
SCIENTIFIC VERIFICATION
↓
REPRODUCIBLE RESULT
One pipeline.
One measurable use case.
One result.
If it works, we improve it.
If it fails, we document why.
Then we build again.
The real product may be evidence
There's an interesting possibility hidden inside all of this.
Maybe the most important thing MyZubster eventually produces isn't an application screen.
Maybe it isn't an NFT.
Maybe it isn't an AI response.
Maybe it isn't even a blockchain transaction.
Perhaps the fundamental unit is:
VERIFIABLE EVIDENCE
Everything else could become a way of producing, processing, connecting or interpreting it.
People create evidence.
Devices create measurements.
GitHub records development evidence.
Blockchains can anchor certain records.
AI interprets information.
Scientists validate methodologies.
Applications make the results usable.
Then the architecture starts looking different:
MYZUBSTER
People ───────────┐
Devices ──────────┤
Developers ───────┤
Sensors ──────────┤
Software ─────────┤
▼
EVIDENCE
│
┌───────┼───────┐
▼ ▼ ▼
AI MRV Blockchain
│ │ │
└───────┼───────┘
▼
VERIFICATION
│
▼
TRUST
Not blind trust.
Inspectable trust.
We're still building
There are components that work.
There are components being tested.
There are infrastructure problems we're solving.
There are contributors beginning to participate.
There are research directions being explored.
There are failed workflows.
There are ideas that may never survive experimentation.
That's exactly why we're building publicly.
Because the interesting question isn't:
Can we make MyZubster look finished?
It's:
Can we build a digital ecosystem capable of showing how it knows what it claims to know?
That's a much harder problem.
And that's the one worth attempting.
MyZubster
Build → Observe → Measure → Verify → Connect → Replicate
Suggested DEV tags: opensource programming ai devopsMyZubster Is Entering Its Hardest Phase: Connecting Code to Reality
Building a prototype is relatively easy.
Building a repository is harder.
Building an ecosystem where software, infrastructure, AI, blockchain, contributors and real-world data must work together is something else entirely.
That's the phase MyZubster is beginning to enter.
MyZubster is an Italian open-source digital ecosystem currently under development.
It isn't a finished product, and we don't want to describe experimental components as production-ready systems.
But something important is happening.
The project is moving from:
BUILDING COMPONENTS
toward:
CONNECTING COMPONENTS
↓
TESTING THEM
↓
OBSERVING FAILURES
↓
COLLECTING EVIDENCE
↓
VERIFYING RESULTS
And this transition is changing how we think about the entire architecture.
The prototype phase is ending
Early-stage development encourages experimentation.
You create APIs.
You test databases.
You integrate AI.
You deploy services.
You experiment with blockchain.
You build interfaces.
You create repositories.
Eventually, however, adding another component stops being the hardest problem.
The real question becomes:
Can these components operate together as one observable system?
That's where MyZubster is heading.
A simplified view looks like this:
MYZUBSTER
Developers ───────────────┐
│
Users ────────────────────┤
│
IoT / Sensors ────────────┤
▼
DATA LAYER
│
▼
PROVENANCE
│
┌─────────┴─────────┐
▼ ▼
AI BLOCKCHAIN
│ │
└─────────┬─────────┘
▼
EVIDENCE
│
▼
VERIFICATION
│
▼
DIGITAL SERVICES
Every box is relatively understandable individually.
The difficulty exists between the boxes.
Infrastructure immediately challenges architecture
We recently saw a perfect example while operating a Monero node.
The daemon was running.
RPC was responding.
The node reported:
busy_syncing: true
synchronized: false
Everything appeared to suggest normal synchronization.
Except the blockchain height stopped progressing.
The reason wasn't an exotic blockchain bug.
It was storage.
The server reached:
/dev/mapper/lv-root
79 GB total
79 GB used
0 GB available
100%
The Monero LMDB database had grown significantly while the node was still catching up with the network.
We recovered several gigabytes by identifying development repositories that were safely reproducible from their remote Git repositories.
The node immediately began moving again.
We observed progress from approximately:
2,705,556
↓
2,708,936
↓
2,711,216
↓
2,838,236
Then something equally useful happened.
The filesystem filled again.
Why?
Because the underlying capacity problem hadn't disappeared.
We had treated the symptom.
Not the architecture.
That's a development milestone too
It might sound strange to call a full disk a milestone.
But it exposed something important.
MyZubster can no longer think only about:
FEATURES
We need to think about:
CAPACITY
RELIABILITY
OBSERVABILITY
RECOVERY
DATA GROWTH
SERVICE HEALTH
That's what happens when experimental software begins interacting with persistent infrastructure.
The architecture diagram meets physics.
And physics usually wins.
“Running” is not a health status
This experience also reinforced another principle.
Suppose Linux tells us:
monerod → RUNNING
That doesn't prove the node is healthy.
Actual health requires multiple signals:
Process alive
RPC responsive
Network connectivity
Peers
Database writable
Blockchain height progressing
Storage available
Operational Node
This idea extends far beyond blockchain.
An API returning 200 OK doesn't necessarily mean the underlying system is functioning correctly.
An AI model returning an answer doesn't mean the answer is correct.
A sensor sending packets doesn't mean its measurements are valid.
A CI workflow passing doesn't prove a physical-world claim.
Availability is not verification.
This changes how we think about AI
AI is becoming increasingly capable of observing and operating software systems.
But giving AI access to infrastructure without giving it reliable evidence creates another problem.
Imagine an agent receiving:
monerod = running
It could conclude:
Everything is operational.
But give it:
{
"process": "running",
"rpc": "responsive",
"syncing": true,
"height_progressing": false,
"disk_usage": 100,
"disk_available": 0
}
and the conclusion changes completely.
Now the agent has evidence.
This is the model we're interested in:
OBSERVATION
↓
EVIDENCE
↓
AI ANALYSIS
↓
INTERPRETATION
↓
ACTION
↓
VERIFICATION
Not:
AI
↓
GUESS
↓
ACTION
GitHub becomes more important in this model
Another interesting development is happening around contribution.
External developers are beginning to show interest in concrete MyZubster work.
Recent areas include:
REST APIs
MongoDB schemas
mapping data
Node.js / Express
data pipelines
unit testing
QA
reproducibility
API verification
This is significant for an open-source project.
Because the transition we ultimately want isn't:
Founder writes code
↓
Repository grows
It's:
Problem
↓
Issue
↓
Contributor
↓
Implementation
↓
CI
↓
Review
↓
Evidence
↓
Reusable component
GitHub therefore becomes more than storage.
Issues document problems.
Pull requests document proposed solutions.
Commits document changes.
CI documents automated verification attempts.
Failures document assumptions that didn't survive testing.
That history has value.
Failed CI isn't noise
We're also seeing experimental workflows fail.
That's expected.
When building blockchain settlement experiments, metaverse integrations, APIs or other new components, some workflows won't pass immediately.
The wrong response would be hiding those failures.
A verification-oriented ecosystem should preserve them.
ASSUMPTION
↓
IMPLEMENTATION
↓
TEST
↓
FAIL
↓
EVIDENCE
↓
DIAGNOSIS
↓
NEW IMPLEMENTATION
Failure becomes part of the development record.
This principle becomes even more important when software begins making claims about the physical world.
From software testing to real-world verification
One of MyZubster's emerging research directions concerns environmental and agricultural applications.
We're exploring questions around:
environmental data;
agronomic data;
water;
irrigation;
circular water reuse;
IoT;
KPI;
MRV;
data governance;
scientific validation.
This creates a fascinating engineering problem.
Imagine MyZubster eventually displays:
WATER SAVED: 31%
Where did 31% come from?
A database?
An AI model?
A sensor?
A calculation?
A researcher?
A manually entered value?
Without provenance, it's just another number on a dashboard.
A meaningful pipeline requires something closer to:
PHYSICAL EVENT
↓
MEASUREMENT
↓
RAW DATA
↓
TIMESTAMP + CONTEXT
↓
PROVENANCE
↓
METHODOLOGY
↓
CALCULATION
↓
KPI
↓
EVIDENCE
↓
VALIDATION
Now the number has a history.
And potentially, it can be challenged and reproduced.
This is why we're exploring MRV
MRV means:
Measurement, Reporting and Verification.
It's common terminology in environmental and sustainability contexts, but from a developer perspective it introduces a powerful architectural idea.
A system shouldn't simply report a result.
It should preserve enough information to explain how the result was produced.
That principle could eventually apply far beyond environmental projects.
Imagine:
Environmental contribution
↓
Evidence
↓
Verification
Developer contribution
↓
Evidence
↓
Verification
Physical-world event
↓
Evidence
↓
Verification
Digital transaction
↓
Evidence
↓
Verification
Different domains.
Same architectural principle.
Exploring LIFE 2027
We're also currently exploring whether a focused environmental use case could eventually become part of a future LIFE 2027 proposal.
This needs an important clarification.
Exploration is not funding.
A conversation is not a partnership.
A proposed consortium is not an approved consortium.
And a research direction is not a completed project.
We're currently interested in determining whether there is a problem that is:
REAL
MEASURABLE
SCIENTIFICALLY VALIDATABLE
TECHNICALLY IMPLEMENTABLE
REPLICABLE
Only after those conditions start making sense does the technology become interesting.
The objective shouldn't be:
“How can we put MyZubster into a European project?”
It should be:
“Is there a measurable environmental problem where MyZubster's architecture can provide useful evidence?”
That's a much better engineering question.
Scientific validation introduces a new boundary
Developers are accustomed to this:
npm test
PASS
But imagine we're testing environmental impact.
A passing unit test cannot prove that irrigation efficiency improved.
CI can verify the software that performs a calculation.
It cannot independently prove the physical event behind the input data.
That's where different disciplines begin connecting:
SOFTWARE ENGINEERING
FIELD DATA
IOT
DATA SCIENCE
SCIENTIFIC METHODOLOGY
MRV
VERIFIABLE RESULT
And this is precisely why MyZubster increasingly looks like an ecosystem rather than a conventional application.
The next phase
Our biggest challenge now isn't adding another hundred features.
It's proving one complete vertical slice.
For example:
REAL-WORLD EVENT
↓
SENSOR / SOURCE
↓
RAW DATA
↓
PROVENANCE
↓
MYZUBSTER
↓
AI ANALYSIS
↓
KPI
↓
SCIENTIFIC VERIFICATION
↓
REPRODUCIBLE RESULT
One pipeline.
One measurable use case.
One result.
If it works, we improve it.
If it fails, we document why.
Then we build again.
The real product may be evidence
There's an interesting possibility hidden inside all of this.
Maybe the most important thing MyZubster eventually produces isn't an application screen.
Maybe it isn't an NFT.
Maybe it isn't an AI response.
Maybe it isn't even a blockchain transaction.
Perhaps the fundamental unit is:
VERIFIABLE EVIDENCE
Everything else could become a way of producing, processing, connecting or interpreting it.
People create evidence.
Devices create measurements.
GitHub records development evidence.
Blockchains can anchor certain records.
AI interprets information.
Scientists validate methodologies.
Applications make the results usable.
Then the architecture starts looking different:
MYZUBSTER
People ───────────┐
Devices ──────────┤
Developers ───────┤
Sensors ──────────┤
Software ─────────┤
▼
EVIDENCE
│
┌───────┼───────┐
▼ ▼ ▼
AI MRV Blockchain
│ │ │
└───────┼───────┘
▼
VERIFICATION
│
▼
TRUST
Not blind trust.
Inspectable trust.
We're still building
There are components that work.
There are components being tested.
There are infrastructure problems we're solving.
There are contributors beginning to participate.
There are research directions being explored.
There are failed workflows.
There are ideas that may never survive experimentation.
That's exactly why we're building publicly.
Because the interesting question isn't:
Can we make MyZubster look finished?
It's:
Can we build a digital ecosystem capable of showing how it knows what it claims to know?
That's a much harder problem.
And that's the one worth attempting.
MyZubster
Build → Observe → Measure → Verify → Connect → Replicate