Building Verifiable Knowledge in Public: What MyZubster Can Prove Today — and What Comes Next

Building Verifiable Knowledge in Public: What MyZubster Can Prove Today — and What Comes Next
We have been building MyZubster around a deceptively simple question:
If a system says that something happened, what can it actually prove?
A Knowledge Card may describe useful work. A GitHub pull request may show that code was merged. A transaction ID may point to a payment. A blockchain may contain a hash.
But none of those things, individually, mean:
“Everything described here is true.”

That distinction has shaped the architecture we are building.
This is a progress report on what is implemented today, what we deliberately refuse to infer, and where we want to take the system next.
From Knowledge Cards to an Evidence Graph
Our first iterations treated knowledge primarily as structured content.
That quickly became insufficient.
We wanted to distinguish the person making a claim from the claim itself, the evidence supporting it, the artifact containing it, the canonical bytes we actually hash, the resulting digest, and any external attestation of that digest.
That led us to an Evidence Graph.
A simplified path looks like this:
Person
↓ CLAIMS
Claim
↓ DESCRIBED_BY
Knowledge Card
↓ SUPPORTED_BY
Evidence
↓ PRODUCED
Artifact
↓ CANONICALIZED_AS
Canonical Payload
↓ HASHED_AS
Digest
↓ ATTESTED_BY
Attestation

The important part isn't the number of nodes.
It's that every edge has a deliberately narrow meaning.
HASHED_AS does not mean “proven true.”
ATTESTED_BY does not mean “certified.”
A Knowledge Card existing does not automatically mean its claims were independently verified.
And the hash of the graph itself only establishes integrity of that graph representation.
That restraint turned out to be one of the most important parts of the project.
Zero attestations is a valid result
One of our most useful tests produced an Evidence Graph with:
attestation nodes: 0

Initially, that might look like an incomplete result.
We now consider it a feature.
If the system cannot establish a confirmed blockchain anchor, it should not manufacture an attestation merely to make the graph look complete.
The Evidence Graph can still contain a Knowledge Card, its evidence, canonical payload and digest.
It can still calculate a deterministic graph hash.
But:
graphHash != blockchain attestation

and:
blockchain attestation != truth

This gives us a useful rule for the entire system:
absence of evidence should remain visible as absence of evidence.
We already have a real reproducibility experiment
One of our Knowledge proofs gave us an especially useful distinction.
The canonical Proof v2 payload is stored in Git as exactly 3,168 bytes.
Those stored bytes produce this SHA-256 digest:
6097e05866bafceec24663d2638cb1dae5742ac78284abbfd45cc9c3b0bfb845

That digest was used in our Sepolia experiment.
Separately, an Evidence Graph representation produced:
7dffe770d139da4a0beaf27d0b2d7e72a03bf26c5cd2180c93e1741fa8d3625e

Those hashes are different because they represent different things.
That sounds obvious after the fact.
It wasn't obvious enough before we built it.
The lesson became:
Hash the thing you mean.

But a public technical review of our work exposed the second half of that rule.
Hash the thing you mean — and specify how you produced the bytes
Mike Dabydeen left a very useful comment on our previous Evidence Graph article.
His point was essentially this:
Today a verifier can retrieve the 3,168-byte Proof v2 payload and hash those exact bytes again.
But can a future verifier start with the Knowledge Card and independently reproduce those exact same 3,168 bytes?
Not necessarily.
That requires the canonicalization algorithm itself to be specified.
So we're turning that feedback into an implementation requirement.
Instead of an ambiguous transformation:
Knowledge
↓
Canonical Payload

we want something closer to:
Knowledge
↓
CANONICALIZED_AS
│
├── scheme
└── version
↓
Canonical Payload

RFC 8785 / JSON Canonicalization Scheme is an obvious candidate.
But we're deliberately not claiming that our existing Proof v2 uses RFC 8785.
First we need to test whether the existing serialization reproduces the stored payload byte-for-byte.
If it doesn't, we won't rename history.
Proof v2 remains Proof v2.
A new canonicalization scheme can become a new explicitly labelled version.
We have now tracked this work as MYZ-212: Evidence Graph — version canonicalization and explicit blockchain attestation semantics.
What should ATTESTED_BY actually mean?
The same review raised another important question.
What does a blockchain attestation give us that storing the payload in Git does not?
We think the answer should be deliberately narrow.
An attestation should support a statement approximately like:
The committed digest existed no later than the referenced block on the identified chain.

Not:
The claim is true.

Not:
The person owns the underlying work.

Not:
MyZubster certifies this knowledge.

And not:
A blockchain independently verified the real-world event.

This means our attestation representation needs enough information to check the statement independently.
We therefore want explicit metadata such as:
{
"chainId": "...",
"blockNumber": "...",
"transactionHash": "...",
"digest": "..."
}

The exact schema is part of the work still in progress.
Sepolia is an experiment, not permanence
This distinction also changed how we talk about testnets.
We have used Sepolia for real technical experiments.
That's useful.
But “anchored on a testnet” should never silently become “permanently preserved.”
Testnets can be retired.
So we are designing the Evidence Graph so that a digest can have multiple attestations:
┌── ATTESTED_BY → Sepolia
Digest ──────┼── ATTESTED_BY → future L2
└── ATTESTED_BY → future durable anchor

An experimental attestation doesn't need to disappear when a stronger one is added later.
The history can remain visible.
From knowledge evidence to contributor evidence
The next question was harder.
Could the same evidence architecture describe actual open-source contribution history?
For example:
Contributor
↓
GitHub contribution
↓
Merged PR
↓
Bounty
↓
Payment

The dangerous shortcut would be to treat all those states as equivalent.
They aren't.
So we extended the Evidence Graph vocabulary with contributor-specific concepts:
contribution
bounty
settlement

and relations:
CONTRIBUTED_TO
ACCEPTED_AS
SETTLED_AS

The semantics matter more than their names.
Merged does not mean paid
We used a real merged contribution as a regression case.
The system can represent:
Person
↓ CONTRIBUTED_TO
Contribution
↓ ACCEPTED_AS
GitHub Artifact

when the GitHub evidence supports that state.
But it deliberately produces no SETTLED_AS edge merely because the contribution was accepted.
That gives us another invariant:
MERGED != PAID

Likewise:
REWARDED != independently confirmed settlement

A ledger can say that a contribution has reached a reward state without that alone proving an external blockchain payment.
Making SETTLED_AS difficult to fake
Our contributor Evidence Graph work now enforces stricter requirements around settlement.
A SETTLED_AS relation requires a bounty source and a settlement target.
The settlement must be in a paid state.
The relation must represent confirmed verification.
And the settlement needs transaction evidence plus an independent source reference.
Conceptually:
Bounty
↓ SETTLED_AS
Settlement
├── status: paid
├── txId
└── independent sourceReference

This is intentionally stricter than checking whether a transaction ID string exists.
A transaction being submitted isn't the same as a confirmed settlement.
The targeted Evidence Graph suite currently has:
23 tests
23 passed

This contributor work is currently represented by our open contributor-evidence pull request, so we're also making a distinction between tested implementation work and merged production state.
Privacy belongs in the evidence model
Evidence systems have another failure mode: proving too much publicly.
A payment may need a wallet address internally.
A Knowledge Card may contain restricted material.
An evidence record may contain personally identifiable information.
None of that implies that it should be placed into a public graph.
Our evidence work distinguishes visibility classes including:
PUBLIC
RESTRICTED
PARTICIPANT_ONLY
EPHEMERAL

Missing classification fails closed.
We also don't infer research consent from participation.
And contributor settlement projection does not need to publish a payout wallet just because the settlement internally used one.
This is an architectural requirement, not a UI preference:
Verifiability should not require unnecessary disclosure.

The next test: create knowledge through the actual product
So far, a lot of our work has focused on getting the underlying contracts right.
The next important milestone is not another hand-crafted demonstration.
We want to use MyZubster and Zorgax themselves.
The target pipeline is:
Human
↓
MyZubster / Zorgax
↓
Knowledge candidate
↓
Human confirmation
↓
Independent review
↓
Verified Knowledge
↓
Canonicalization
↓
Digest
↓
Evidence Graph
↓
GitHub provenance

We want Knowledge created through the product to reach GitHub automatically and reproducibly.
That means testing the boring but essential pieces too:

• authentication;
• repository permissions;
• deterministic paths;
• idempotent writes;
• commit SHA capture;
• provenance linking;
• retries;
• duplicate prevention;
• visibility enforcement. We specifically don't want to manually create the GitHub artifact and then call the workflow automated. The automation itself is what needs testing. Where this leads: development work Verified Knowledge becomes more interesting when it can identify something that needs to be built. Our roadmap therefore introduces a neutral DevelopmentRequest lifecycle: Verified Knowledge ↓ DevelopmentRequest ↓ DRAFT ↓ OPEN ↓ IN_PROGRESS ↓ SUBMITTED ↓ VERIFIED / REJECTED

GitHub is an optional materialization layer.
A bounty is another optional layer.
Payment remains another lifecycle again.
That separation lets us avoid statements such as:
request created = bounty promised

or:
work verified = contributor paid

Those implications are intentionally absent.
Where this leads: verifiable contributor history
Eventually we want the pieces to compose.
Something like:
Human / Contributor
↓
MyZubster + Zorgax
↓
Knowledge
↓
Human confirmation + review
↓
Canonical payload
(scheme + version)
↓
SHA-256 digest
↓
Evidence Graph
↓
GitHub provenance
↓
optional blockchain attestations
↓
DevelopmentRequest
↓
GitHub contribution
↓
accepted work
↓
optional bounty
↓
independently confirmed settlement
↓
verifiable contributor history

That history could then be consumed by MyZubster, Zorgax, public Knowledge pages or Metaverse experiences.
But we want the applications to consume evidence — not silently upgrade evidence into claims it cannot support.
A PAID_CONTRIBUTOR application role, for example, does not automatically mean “employee.”
A GitHub contribution does not prove every skill attributed to a person.
And a blockchain hash doesn't transform subjective knowledge into objective truth.
What is implemented today?
Several foundations are now real:
Verified Knowledge foundations — provenance, deterministic content hashes, versioning, visibility boundaries and review semantics.
Evidence Graph v1 — typed nodes and relations, deterministic graph hashing, Knowledge Card composition and integrity-chain representation.
Privacy boundaries — evidence classification, fail-closed handling and separation between public evidence and sensitive data.
Contributor Evidence implementation — contribution, bounty and settlement nodes with guarded CONTRIBUTED_TO, ACCEPTED_AS and SETTLED_AS semantics.
Real regression cases — we're testing against real contribution history rather than only synthetic examples.
And, importantly, the system is allowed to say:
we don't have evidence for that yet

What is not implemented yet?
This list matters just as much.
We still need to finish and merge the contributor Evidence Graph work.
We need to implement the canonicalization hardening tracked in MYZ-212.
We need to determine whether our current canonical payload is actually RFC 8785-compatible before assigning that label.
We need explicit chain and block semantics for future ATTESTED_BY records.
We need the real:
MyZubster/Zorgax
→ Knowledge
→ GitHub
→ provenance
→ Evidence Graph

automatic end-to-end test.
We still need a real contributor settlement to move from an accepted contribution to a genuinely evidenced SETTLED_AS.
And Sepolia remains an experimental environment rather than our answer to long-term attestation permanence.
Those aren't footnotes.
They're the roadmap.
What we're trying to build
The end goal isn't “put résumés on a blockchain.”
It isn't “hash everything.”
And it isn't to make every piece of knowledge public.
We're trying to build an evidence layer where software can answer more precise questions:
What is being claimed?
Who or what produced the evidence?
Which exact bytes were hashed?
How were those bytes produced?
Where is the original artifact?
Was an external attestation actually confirmed?
What does that attestation prove — and what does it not prove?
Was a contribution merely submitted, actually accepted, or independently confirmed as paid?
Which parts can safely be public?
If the system can't answer one of those questions, the missing answer should remain visible.
That may be less impressive than declaring everything “verified.”
But we're increasingly convinced that this is what makes a verifiable system useful.
One principle keeps surviving every iteration
We started with:
Hash the thing you mean.

The Evidence Graph pushed us toward:
Model the relationship you actually have evidence for.

And public review added an important third part:
Record how you produced the bytes.

That's where MyZubster is today.
The next milestone is to stop demonstrating these pieces separately and make the complete path run through the actual product — from a human creating Knowledge in MyZubster/Zorgax, through reproducible evidence and GitHub provenance, all the way to independently checkable contribution and settlement history.
We'll publish the results when that path is real.