MyZubster After the Institutional Hearing: From the Metaverse to Real-World Pilots and Verifiable Knowledge

MyZubster After the Institutional Hearing: From the Metaverse to Real-World Pilots and Verifiable Knowledge
September 22, 2026 — MyZubster
Today we presented MyZubster starting from what already exists: a virtual environment that could be opened and tested live, a real pilot involving a real person, a technical history that can be linked to GitHub, a Knowledge Layer for Zorgax, and an initial structured workflow designed to transform verified knowledge into development work.
The occasion was an institutional hearing connected to the ongoing work around Italy’s national strategy for Artificial Intelligence.
For us, the most important part of the meeting was practical. We did not have to describe only a future vision. We were able to show how several parts of the ecosystem are already beginning to connect.
Showing the MyZubster Metaverse
During the hearing, we opened the MyZubster metaverse and allowed the participants to explore and test it directly.
This gave us the opportunity to explain that, in our vision, a metaverse is not simply a virtual environment where an avatar moves around.
The goal is to progressively build an environment where a person can enter with a digital identity, interact with other people and services, use a wallet, and connect those interactions with a verifiable history of contributions and activities.
In this model, GitHub can play an important role.
A commit, a pull request, a resolved issue, or a piece of software can represent technical evidence of work that was actually performed.
A wallet can represent another component of identity and interaction.
The metaverse therefore becomes the visible interface of a broader chain:
person → identity → activity → contribution → evidence → knowledge → new interaction
Nicola as a Real Pilot Case
To make the concept concrete, we presented the case of Nicola.
We did not present Nicola as a theoretical example, nor as scientific validation.
He is a real person who has participated in the MyZubster ecosystem and in practical experimentation.
One of the first cases was deliberately simple: a physical handover of kefir.
The workflow recorded the delivery, the confirmation of receipt, and the final completion of the process.
The handover was free, with no payment involved, and in this specific case it was not recorded as a blockchain transaction.
The purpose of this small pilot was not to scientifically validate anything about kefir.
The purpose was to test whether a real-world activity could be represented digitally and leave behind usable evidence.
This leads to one of the central questions behind MyZubster:
How can a simple activity become evidence, and how can a collection of evidence become usable knowledge?

From User to Contributor and Developer
Nicola's involvement did not stop with the pilot.
He also tested parts of MyZubster, reported issues, and worked on his own technical software.
During the hearing, we also explained the software he has been developing using artificial intelligence.
The concept behind that work is to use AI to assist the creation of software, virtual environments, metaverse-related systems, and technical ideas that can potentially connect back into the MyZubster ecosystem.
This gives us a broader model of participation:
user → tester → contributor → developer → producer of new evidence and knowledge
GitHub becomes important again at this stage.
The goal is not to automatically assign value to someone simply because they have a wallet or a GitHub account.
The goal is to be able to reconstruct, when necessary, what was actually built, tested, changed, or contributed.
Zorgax: A Conversation Is Not Knowledge
Another important part of the presentation focused on Zorgax.
One of the principles behind our recent development work is simple:
A conversation is not knowledge.

An AI model can generate a convincing answer and still be wrong.
For this reason, we have started separating different stages:
Conversation
↓
Candidate Information
↓
Sources and Evidence
↓
Review
↓
Verified Knowledge
↓
Use by Zorgax
We have implemented a Knowledge Layer that can preserve information such as provenance, versioning, visibility, sources, evidence, and relationships between knowledge items.
The direction is clear:
Zorgax can assist with research, organization, retrieval, and development, but information should not automatically become verified knowledge simply because an AI generated it.
Turning Knowledge Into Development
The next problem was equally important.
Once knowledge has been verified, how do we transform it into software development?
This led us to implement the first vertical slice of DevelopmentRequest.
A DevelopmentRequest is designed to act as a neutral technical contract between verified knowledge and implementation work.
The current lifecycle is:
DRAFT
↓
OPEN
↓
IN_PROGRESS
↓
SUBMITTED
↓
VERIFIED / REJECTED
A DevelopmentRequest can contain requirements, acceptance tests, required evidence, and references to the verified Knowledge from which the request originated.
Before creating the persistent request, the system generates a preview and a digest and requires explicit confirmation.
The Knowledge references are also captured with their content hash and version, creating a snapshot of the information on which the development request was based.
This is important because knowledge can evolve over time.
A development task should be able to show which version of the knowledge it was based on.
Development Is Separate From Payment
We also made another architectural decision:
A DevelopmentRequest does not automatically mean a bounty, reward, or payment.

Development work should exist independently from its economic model.
A technical request can therefore be created, assigned, implemented, submitted, and verified without automatically triggering funding or settlement.
Payment systems can be attached later, where appropriate, as a separate layer.
This separation is important for universities, open-source contributors, research environments, volunteers, funded work, and community experimentation.
They do not all operate under the same economic model.
Evidence Before Verification
Another principle we are strengthening is the difference between submission and verification.
Submitting code does not mean the work is verified.
Adding a commit reference does not automatically prove that every requirement has been satisfied.
For this reason, DevelopmentRequest includes explicit evidence requirements.
The current work is strengthening the rule that a request should only reach VERIFIED when every required evidence item has been properly covered and reviewed.
We also separate the contributor from the reviewer.
The person who created or implemented the work should not automatically be the person who independently verifies it.
This gives us a much clearer chain:
Knowledge
↓
DevelopmentRequest
↓
Developer
↓
Implementation
↓
Tests and Evidence
↓
Independent Review
↓
Verified Result
↓
New Knowledge
Connecting Everything Together
When these pieces are combined, the broader MyZubster architecture becomes easier to understand:
Real Person
↓
Real-World Activity
↓
Data / Evidence
↓
MyZubster
↓
Knowledge
↓
Zorgax / AI Assistance
↓
DevelopmentRequest
↓
Developer
↓
Code / GitHub
↓
Tests
↓
Independent Verification
↓
New Knowledge
↓
Wallet / Identity
↓
MyZubster Metaverse
↓
New Activities
This also helps explain what MyZubster is not trying to become.
We are not trying to build only a chatbot.
And we are not trying to build only a metaverse.
We are trying to build the connection between people, artificial intelligence, knowledge, software development, identity, evidence, and verifiable contributions.
The University Path
During the hearing, we also explained the dialogue we have started with universities and research groups.
We have contacted academic teams working in areas such as artificial intelligence, agriculture and food science, fermentation, circular economy, LCA/LCSA, water management, monitoring, and impact measurement.
We were careful not to present these discussions as formal partnerships.
In several cases we have shared documentation, received requests for additional information, or started preliminary conversations.
At this stage, we are waiting for further evaluations and feedback.
During the institutional discussion, we were encouraged to continue exploring the university path, with particular attention to the University of Bologna for the AI-related aspects of the project.
A possible future discussion involving Professor Michela Milano was also mentioned.
At this stage, this should be understood as a possible next contact or academic direction, not as an already established collaboration.
Why Universities Matter
This university dimension is important because it defines a boundary between what software can do and what requires scientific expertise.
MyZubster can build workflows, traceability systems, software, knowledge infrastructure, and evidence mechanisms.
But when a pilot becomes a scientific experiment, other requirements become necessary:
protocols, methodology, measurements, controls, ethics, safety, scientific interpretation, KPIs, and validation.
This is where universities and research institutions can play an essential role.
The AI should assist the process.
It should not replace scientific responsibility.
The LIFE 2027 Direction
We also discussed the exploratory LIFE 2027 path.
At this stage, there is no approved or funded MyZubster LIFE project.
The work is still exploratory.
The idea is to start from small real-world cases and determine whether some of them can evolve into scientifically structured pilots.
Areas we have explored include:
kefir and fermentation, circular water, circular economy, Living Labs, traceability, and measurable environmental or social impact.
The important principle remains the same:
MyZubster can help collect data, structure evidence, connect people and tools, and preserve knowledge.
Scientific validation must come from the appropriate experts and institutions.
AI as an Assistant, Not as the Final Authority
The hearing also gave us the opportunity to clarify how we see the role of artificial intelligence.
The objective is not to automate responsibility.
The objective is to use AI to:

• help people navigate complex information;
• connect problems with relevant knowledge;
• assist software development;
• organize evidence;
• improve traceability;
• preserve useful knowledge;
• help transform verified knowledge into actionable development work. The final responsibility for consequential decisions should remain with people. What We Learned From the Hearing The hearing forced us to explain MyZubster without hiding behind technical complexity. That was useful. The project can ultimately be described in a much simpler way: We start from real people, collect real evidence, use artificial intelligence to assist the process, and try to make the path from an idea to something actually built increasingly verifiable.

The metaverse is one interface.
The wallet is one tool.
GitHub preserves part of the technical history.
Zorgax connects assistance and knowledge.
DevelopmentRequest connects knowledge with development work.
Developers build.
Other people review.
Universities can help define the scientific method when the process enters the research domain.
What Comes Next
The next step returns to engineering.
We are continuing to strengthen DevelopmentRequest, especially the relationship between required evidence and verification.
After that, the goal is to progressively connect DevelopmentRequest with the Contribution Graph and GitHub activity.
At the same time, we will continue developing the Zorgax Knowledge Layer and wait for the next steps emerging from the institutional and university discussions.
The hearing was not an endpoint.
It was another real test of the question behind MyZubster:
Can we build an ecosystem where people, AI, software, and virtual environments collaborate without automating trust — but instead making what happened increasingly verifiable?

That is what we are trying to build.
MyZubster
Open Source • Verified Knowledge • Zorgax • Metaverse • Developers • Community • Research