Building Verifiable Knowledge in MyZubster: From Stable Evidence IDs to Proof v3
Tonight I worked on a part of MyZubster that I find particularly interesting: making a Knowledge Card not only readable, but traceable and verifiable.
The task started as a relatively focused frontend issue and ended up touching several important concepts: stable evidence identity, deduplication, versioned proofs, cryptographic digests, blockchain attestations, deployment verification, and contributor rewards.
The result is now running in production.
The starting point
MyZubster has a Knowledge Graph where a Knowledge Card can be connected to multiple pieces of evidence.
For the card used during this work:
6abaaefb3a7460c4574a45fd
the graph contains normal sources as well as cryptographic proof information.
The first requirement was deceptively simple:
When selecting the Proof filter, both Proof v2 and Proof v3 should appear as separate and independently identifiable attestations.
But there were several constraints.
Normal evidence had to remain normal evidence.
Proof records had to be recognized separately.
Proof v2 history could not be rewritten just to accommodate v3.
Duplicate URLs could not produce duplicate nodes.
And the stable IDs introduced in the previous work had to remain stable across refreshes and reimports.
In other words, this wasn't simply:
if label contains "proof":
show proof
That would have been fragile.
Stable evidence identity first
Before working on Proof v3, the graph already had another important improvement: evidence nodes were given stable SRC-* identifiers.
That matters more than it might initially appear.
If a graph generates arbitrary node identities every time data is imported, refreshed or reordered, the visual representation may look correct while its identity model is unstable.
For evidence systems, that's a problem.
A source should remain the same source when the page reloads.
So the model became conceptually:
Knowledge Card
|
+-- SRC-...
+-- SRC-...
+-- SRC-...
with deterministic identity rather than presentation-dependent identity.
That foundation became important when introducing versioned proofs.
Proof is not just another source
The next problem was classification.
A Knowledge Card can have ordinary evidence:
source
source
source
but it can also contain evidence describing an attestation:
digest
contract
transaction
documentation
payload
Those records collectively describe something different from a normal source.
They describe a proof.
The implementation therefore moved toward recognizing structured fields where available, such as concepts equivalent to:
type: proof
proofVersion: 3
proofRole: digest
rather than relying exclusively on human-readable labels.
Textual detection remains useful as a fallback for legacy data, but structured metadata is considerably safer.
The important distinction becomes:
normal evidence → source
versioned attestation evidence → proof
Grouping evidence into versioned proofs
Once proof evidence can be recognized, individual records can be grouped by version.
Conceptually:
Proof v2
├── digest
├── contract
├── transaction
└── documentation
Proof v3
├── digest
├── contract
├── transaction
└── documentation
This is much more useful to a reader than exposing every technical reference as an unrelated graph node.
The graph can represent the attestation as an object, while still retaining the references required to inspect it.
The Proof v3 attestation
The Proof v3 used for this Knowledge Card includes a SHA-256 digest and an Ethereum Sepolia attestation.
The digest is:
d1c89d2a4157a159b56e92825ca59fdb
1f0e84e003b05e022af67da69ed25ac4
The Sepolia contract is:
0x3233fA7f8c50Aa25d9B1263c25F28535B6eA59bF
and the deployment/attestation references can be associated with the corresponding payload and documentation.
The important idea isn't simply that "something is on a blockchain."
The useful relationship is:
Knowledge
↓
canonical payload
↓
SHA-256
↓
attestation
↓
independent verification
The blockchain reference doesn't magically prove that the knowledge itself is true.
What it can help establish is that a particular cryptographic commitment existed and can be compared against a particular payload.
That distinction is essential in any serious provenance system.
A bug that looked correct until the graph was inspected
After the first implementation, the deployment built successfully, but visual verification revealed an interesting problem.
The Proof filter showed something equivalent to:
Proof v2
Proof v2
SRC-...
SRC-...
SRC-...
while Proof v3 wasn't represented correctly.
There were actually two different problems.
The historical Proof v2 path already existed, while dynamically grouping evidence created another v2 representation.
At the same time, raw evidence used to construct a proof remained visible as ordinary SRC-* nodes.
So even though the underlying information existed, the semantic representation was wrong.
That is why visual acceptance testing mattered here.
Unit tests alone weren't enough.
Deduplicating the graph
Once evidence has been aggregated into a proof object, exposing the exact same evidence again as raw graph nodes creates noise and potentially misleading duplication.
The graph therefore needed another rule:
if evidence has already been consumed by a grouped proof:
don't render it again as an independent source
The final Proof view became much cleaner:
PROOF V3
|
|
K-4A45FD
/ \
/ \
PROOF V2 SHA-256
No duplicate Proof v2.
No raw proof SRC-* nodes leaking into the Proof filter.
And, importantly, Proof v3 is visibly connected to the Knowledge Card.
The isolated-node problem
One of the final bugs was purely structural.
Proof v3 existed.
It rendered correctly.
Its metadata was correct.
But visually it was floating above the Knowledge Card without an edge.
That may sound cosmetic, but in a knowledge graph an edge carries meaning.
A node that isn't connected to the card doesn't clearly communicate:
this proof attests to this Knowledge Card
So the edge construction was extended to include versioned proof nodes.
After redeployment, the intended relationship became visible:
K-4A45FD → PROOF V3
while preserving the historical Proof v2 chain.
CI also taught us something
During the work, several repository-wide CI workflows failed.
It would have been easy to interpret:
red CI = my change is broken
But inspecting the logs showed failures in existing Zorgax/Seller-related backend tests unrelated to the Knowledge Graph modification.
That distinction matters.
A contributor shouldn't ignore failing CI.
But a contributor also shouldn't start modifying unrelated systems simply to turn every check green.
The useful workflow was:
CI fails
↓
inspect exact failing suites
↓
determine relationship to current diff
↓
fix regressions caused by the change
↓
keep unrelated failures separately tracked
This prevented MYZ-209 from expanding into an unrelated backend repair project.
Preview before merge
Another useful part of the workflow was refusing to treat a successful build as final acceptance.
The sequence was approximately:
implementation
↓
tests
↓
Vercel preview
↓
visual graph verification
↓
fix
↓
new preview
↓
final verification
↓
merge
Daniel Ioni performed the final preview verification and confirmed that the Proof filter contained the expected distinct nodes without duplicates.
Only then was the PR merged.
PR:
25
MYZ-209: expose versioned Proof v3 in Knowledge Graph
Merge commit:
157fc5edf7440a732c489a918efe6be8e34888c3
Production verification
After the merge and production deployment, I performed another verification against the public Knowledge Card.
The production Proof filter now shows:
PROOF V3
MyZubsterProof v3 · Sepolia
SHA-256
Digest del payload
PROOF V2
MyZubsterProof · Sepolia
There are no duplicate raw proof sources in that filtered view.
The Knowledge Card is visibly connected to Proof v3.
And switching back to the complete graph shows Proof v2 and Proof v3 coexisting with the ordinary SRC-* evidence nodes.
So the production result matches the verified preview.
MYZ-209 is complete.
What I learned from this
The interesting part of this task wasn't adding another node to a React page.
It was dealing with the boundary between data, evidence and proof.
These concepts shouldn't be collapsed into one another.
A source can support knowledge.
A digest can identify a payload.
An attestation can commit to a digest.
A transaction can provide independently inspectable evidence that an attestation occurred.
But none of those things, individually, should be described as magically proving that a statement is true.
A more useful model is:
KNOWLEDGE
|
+--- SOURCES
|
+--- PROVENANCE
|
+--- PAYLOAD
|
SHA-256
|
ATTESTATION
|
VERIFICATION
That is the direction I want to keep exploring with MyZubster.
Contributor rewards
There was also another interesting outcome from this contribution.
After MYZ-209 was accepted, I asked whether the contribution qualified for a MyZubster contributor reward.
Daniel confirmed a reward of:
250 MYZ
for:
N4K48 / nicolaususnicola-lgtm
One important clarification: under the current MyZubster model, MYZ is an internal reward/accounting unit. It should not be confused with an on-chain token, fiat payment or guaranteed conversion into another asset.
A ledger reference, MYZ-LEDGER-000002, was communicated for this contribution.
At the time of writing, however, I have not yet independently located that entry in the public repository, so I'm treating the reward assignment as confirmed by the maintainer while the public ledger reference is still awaiting independent verification.
I think that distinction is worth publishing rather than hiding.
If we're building systems around verifiable knowledge, the same standard should apply to contributor rewards.
Claim what the evidence supports. Clearly label what is still pending verification.
What's next?
The next step isn't simply adding more proofs.
It's making the relationship between knowledge, evidence, provenance and attestations increasingly structured and independently inspectable.
For me, that's the interesting question behind this work:
Can a knowledge platform show not only what it knows, but also why a claim is present, where its evidence came from, which payload was attested, and how someone else can verify that history?
Tonight's work moved MyZubster another step in that direction.
Project: MyZubster
Task: MYZ-209
Contribution: Proof v3 visibility and versioned proof handling
Contributor: N4K48 / nicolaususnicola-lgtm
Status: merged and verified in production
Reward: 250 MYZ confirmed; public ledger entry awaiting independent verification
Top comments (0)