From a Knowledge Card to an On-Chain Proof: What We Built and Tested Tonight at MyZubster

From a Knowledge Card to an On-Chain Proof: What We Built and Tested Tonight at MyZubster
Tonight we ran a real end-to-end experiment on MyZubster with one of our contributors, Nicola / N4K48.
The goal was not simply to deploy another smart contract.
We wanted to test a larger question:
Can a person's knowledge profile be connected to the actual work they produced, and can that chain of evidence remain independently inspectable?

During the experiment we moved through several layers of the MyZubster stack:
Person
↓
Knowledge Profile
↓
Knowledge Card
↓
Real activity
↓
GitHub artifact
↓
Canonical payload
↓
SHA-256
↓
Ethereum Sepolia
↓
Knowledge Graph

And along the way, we discovered something equally important:
the blockchain layer may not be the part MyZubster needs to reinvent.

1. Starting with a real contributor Instead of designing the system around synthetic test data, we used Nicola's actual MyZubster profile. The first objective was to create a knowledge profile representing different kinds of experience. Three Knowledge Cards were created:
2. truck driving and transport organization;
3. Docker and AI-chat experiments for myzubster-mvp;
4. learning and collaboration during the MyZubster development process. This immediately forced us to confront an important distinction. A statement such as: "I have professional skill X"

is not equivalent to:
"Here is an artifact showing that I performed activity Y."

So the Knowledge Card model keeps claims and evidence conceptually separate.
That distinction became important later when we started anchoring data on-chain.

1. The first bugs came from the real user journey The experiment immediately exposed problems that our isolated tests had not fully represented. Nicola encountered an expired authentication session: jwt expired

The onboarding flow also failed to properly reuse information already supplied during the conversation.
Then another problem appeared: the Knowledge Profile Builder URL was resolving to the MyZubster homepage instead of the actual Builder.
We corrected the route and improved the expired-session behavior so the user could authenticate again without unnecessarily losing the locally prepared answers.
This was a useful reminder that a cryptographically sophisticated verification system is not useful if the user cannot reliably reach the screen where the evidence is created.

1. Private drafts before public claims After the fixes, Nicola successfully created all three Knowledge Cards as private drafts. We tested: create → save private draft → reload → inspect → edit → preview

Only after that did we enable the publication step.
The resulting workflow became:
PRIVATE DRAFT
↓
REVIEW
↓
PUBLICATION
↓
PUBLIC KNOWLEDGE CARD

A published card can also be withdrawn before modification.
This gives us an important product property: publishing knowledge is an explicit user action rather than an accidental consequence of creating a profile.

1. Moving from declared knowledge to actual work We then asked Nicola to perform a small, concrete software task in his myzubster-mvp project. He worked on: scripts/ingest_knowledge.py

and improved the knowledge-ingestion chunking process.
The subsequent ingestion test reported:
46 knowledge chunks loaded into Qdrant
1 empty document skipped

The related Git commit was then added as evidence to the corresponding Knowledge Card.
That changed the nature of the card.
Instead of containing only:
Nicola says he worked on the project.

we could represent something closer to:
Nicola
↓
Knowledge Card
↓
software activity
↓
GitHub repository
↓
specific commit
↓
observable implementation

This is the direction we mean when we describe MyZubster as evidence-first.

1. Testing the RAG pipeline The experiment also exercised the local AI/knowledge stack. The tested environment included components such as: Docker Compose Ollama Qdrant API Open WebUI

During retrieval testing, the available context proved insufficient.
The test therefore increased:
AI_CONTEXT_LIMIT

from:
1

to:
5

so the RAG flow could retrieve enough relevant context.
This activity itself then became another piece of inspectable evidence associated with the Knowledge Card.
That creates an interesting feedback loop:
work
→ artifact
→ evidence
→ knowledge representation

rather than simply:
user
→ self-declared skill

1. Adding the Knowledge Graph The next step was to make those relationships navigable. We connected the public knowledge information to the MyZubster Knowledge Graph so the contributor could be represented as a node linked to Knowledge Cards and their sources. Conceptually: N4K48 ├── Knowledge Card: Docker / AI │ ├── repository │ ├── commit │ └── technical evidence │ ├── Knowledge Card: MyZubster learning │ └── Knowledge Card: transport

This test also exposed an infrastructure issue.
The graph deployment was initially protected by Vercel, preventing Nicola from accessing it. We changed the deployment accessibility and continued testing, including navigation from a mobile device.
Later we also corrected a catalog link that was returning a "Catalog unavailable" state.
Again, the real-user test found things that architecture diagrams do not.

1. Proof v1: our first Sepolia experiment We then moved into cryptographic verification. A small MyZubsterProof contract was deployed on Ethereum Sepolia. The first experiment stored a SHA-256 digest associated with the Knowledge Card. But there was a methodological problem. The digest represented the Knowledge Card URL, rather than the complete card content. That means Proof v1 could demonstrate something about the supplied URL string, but it could not establish the integrity of the actual Knowledge Card contents. We documented that limitation instead of treating the transaction as stronger evidence than it really was. That distinction became the basis for Proof v2.
2. Proof v2: hash the content, not the URL For the second experiment we changed the model. We first generated a canonical representation of the Knowledge Card content. Then: canonical Knowledge Card payload ↓ SHA-256 ↓ bytes32 ↓ MyZubsterProof ↓ Ethereum Sepolia

The resulting SHA-256 was:
6097e05866bafceec24663d2638cb1dae5742ac78284abbfd45cc9c3b0bfb845

and the on-chain bytes32 representation was:
0x6097e05866bafceec24663d2638cb1dae5742ac78284abbfd45cc9c3b0bfb845

Reading knowledgeHash() from the deployed contract returned the same value.
More importantly, the canonical payload and verification procedure were committed to GitHub.
That makes independent verification possible:
retrieve canonical payload
↓
calculate SHA-256
↓
compare with documented digest
↓
read on-chain knowledgeHash()
↓
compare again

This is considerably stronger than simply saying:
"We put something on a blockchain."

1. What Proof v2 actually proves This became one of the most important lessons of the experiment. Suppose the Knowledge Card contains: Nicola knows Docker.

and we cryptographically commit the exact payload containing that statement.
The blockchain can help demonstrate that:
these exact bytes
↓
produced this digest
↓
and this digest was publicly anchored

It does not magically prove:
Nicola knows Docker.

Those are completely different claims.
Our current proof concerns integrity and provenance of an artifact, not automatic verification of every semantic assertion contained inside it.
We deliberately preserve this distinction in the MyZubster model.

1. Connecting the proof back into the graph After Proof v2, we extended the conceptual graph again. Now the path looks more like: N4K48 ↓ Knowledge Card ↓ documented activity ↓ GitHub artifact ↓ canonical payload ↓ SHA-256 ↓ Sepolia Proof v2 ↓ verification documentation

The interesting part is not any individual node.
It is the ability to traverse the provenance chain.
Someone inspecting the profile should eventually be able to move from a human-readable claim all the way down to the underlying technical evidence.

1. Then Nicola asked the right architecture question After completing the experiment, Nicola compared what we were building with existing systems and standards. He looked at concepts represented by projects such as Talent Protocol, Ethereum Attestation Service, cheqd and Open Badges. That led to an important observation: Many of the individual primitives we need already exist. There are established approaches for: attestations Verifiable Credentials badges identities reputation cryptographic proofs blockchain anchors

So the question should not be:
How can MyZubster invent its own version of every one of these things?

A more useful question may be:
What does MyZubster contribute by connecting them?

1. The architecture we are now exploring The experiment suggests a possible future architecture: MyZubster │ ▼ PERSON │ ▼ KNOWLEDGE CLAIM │ ▼ KNOWLEDGE CARD │ ┌──────────┴──────────┐ ▼ ▼ EVIDENCE ARTIFACT │ │ └──────────┬──────────┘ ▼ GitHub │ ▼ canonical payload │ ▼ SHA-256 │ ┌──────────┴──────────┐ ▼ ▼ Attestation layer Credential layer (potentially EAS) (VC / Open Badges) │ │ └──────────┬──────────┘ ▼ MYZUBSTER KNOWLEDGE GRAPH

In this model, MyZubster does not need to become another blockchain protocol.
It can concentrate on the relationship between:
people, claims, activities, artifacts, evidence, attestations and credentials.

1. Why a graph matters A reputation score might tell you: Builder Score: 82

A badge might tell you:
Docker Contributor

A credential might tell you:
Issuer X attests achievement Y.

Those can all be useful.
But the experiment we ran tonight asks whether another interface is possible:
Who is this person?
↓
What are they claiming?
↓
What did they actually do?
↓
Where is the artifact?
↓
Who produced it?
↓
What evidence supports the claim?
↓
Was the evidence modified?
↓
Was something independently attested?
↓
Who issued that attestation?

That is why the Knowledge Graph may ultimately be more important to MyZubster than the smart contract itself.

1. What we are not claiming There is an important boundary around this experiment. We are not claiming that we invented cryptographic attestations. We are not claiming that putting a hash on Ethereum proves a person's competence. We are not claiming that a GitHub commit automatically makes a professional claim true. And we are not yet claiming that MyZubster's particular composition is unique. What we demonstrated tonight is narrower and more useful: a real contributor can move from a knowledge profile to documented work, connect that work to a public artifact, derive a deterministic cryptographic commitment from a Knowledge Card, anchor that commitment publicly, and connect the resulting evidence back into a navigable knowledge model. That's a real system property we can continue testing.
2. What comes next Before creating MyZubsterProofV3.sol, we want to investigate whether we should stop creating custom primitives where standards already solve the problem. A logical next experiment is therefore: current Proof v2 ↓ map Knowledge Card fields ↓ EAS schema experiment + Open Badges / VC mapping ↓ preserve MyZubster evidence graph

If that works, the architecture becomes cleaner.
MyZubster can focus on its own problem:
making the path from a human claim to its supporting evidence understandable, navigable and independently inspectable.

Tonight's experiment started with a contributor trying to create three Knowledge Cards.
It ended with us questioning where the boundary of the protocol itself should be.
That's exactly the kind of result we want from a proof of concept.