MyZubster Is Entering Its Hardest Phase: Connecting Code to Reality

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