Certo. Per CoderLegion lo imposterei come secondo capitolo della serie: non “abbiamo ricevuto feedback”, ma come una review tecnica può diventare conoscenza tracciabile e influenzare l’architettura senza essere confusa con una certificazione automatica.
From Technical Review to Knowledge Attestation: What We Learned from CoderLegion
Open-source knowledge does not only arrive through code.
Sometimes the most valuable contribution is a question.
A reviewer looks at an architecture and asks:
Who is actually confirming this claim?
Or:
If the same system creates the evidence and verifies it, is that really independent verification?
Those questions can change a system more deeply than another feature.
At MyZubster, feedback from Mike Dabydeen and the CoderLegion community pushed us to think more carefully about provenance, verification, blockchain finality, and what it really means to call knowledge “verified.”
This became part of the thinking behind our Contributor Knowledge Passport and Knowledge Attestation model.
The problem with verification: confirmed
Imagine a system produces a record like:
{
"contribution": "some contribution",
"verification": "confirmed"
}
It looks reassuring.
But there is an obvious question:
Confirmed by whom?
If the same pipeline creates the claim and writes:
verification = confirmed
then we have not necessarily created independent verification.
We may only have created a stronger-looking self-assertion.
That distinction matters.
A verification claim needs provenance
The feedback helped reinforce a principle that now sits at the center of our attestation design:
Do not only store:
VERIFIED
Store:
who observed it
what was observed
how it was checked
what evidence was used
when the observation happened
Conceptually:
Contribution
↓
Evidence
↓
Observer / verifier
↓
Verification method
↓
Attestation
Instead of:
claim = true
we want something closer to:
claim
+
evidence
+
observer
+
method
+
time
+
provenance
Observation is not the same as verification
This led us to another important distinction.
A GitHub pull request being merged is observable.
A test suite passing is observable.
A transaction existing on a blockchain is observable.
But an observation does not automatically mean:
independently verified knowledge
So our current model deliberately allows states such as:
OBSERVED
VERIFIED
REJECTED
That gives us room to express what actually happened.
For example:
GitHub PR merged
→ OBSERVED
does not automatically become:
Contributor is independently certified as an expert
That would be a larger claim than the evidence supports.
Knowledge should inherit the quality of its evidence
This is particularly important for the Contributor Passport we are building.
Our model is moving toward:
Contributor
↓
Contribution
↓
Knowledge
↓
Evidence
↓
Attestation
↓
Reward
↓
Reputation
But the arrow from Contribution to Knowledge should not magically create truth.
It needs provenance.
A contributor might demonstrate:
NFC API integration
through a merged pull request.
Another contributor might demonstrate the same concept through:
documentation
tests
architecture review
security analysis
technical design
The type of evidence matters.
Review itself can transmit knowledge
This is where the CoderLegion discussion became especially interesting for us.
A reviewer does not need to submit production code to contribute knowledge.
Consider an architectural review that identifies:
self-attestation
missing verifier identity
weak finality semantics
insufficient evidence provenance
privacy weakness in deterministic hashes
That review is itself a knowledge contribution.
It may demonstrate knowledge of:
verification architecture
provenance design
blockchain finality
privacy-preserving evidence
trust boundaries
The contribution is different from writing a feature, but the knowledge transfer is real.
Who verifies the verifier?
One of the hardest problems in knowledge systems is recursive trust.
If MyZubster says:
Mike demonstrated knowledge of verification architecture
you can reasonably ask:
Why should I trust MyZubster?
The answer should not be:
Because MyZubster says so.
Instead the system should preserve the underlying evidence.
Conceptually:
Knowledge claim
↓
Evidence
↓
Original technical discussion
↓
Reviewer identity
↓
Attestation method
The Passport becomes an index into evidence, rather than an authority demanding blind trust.
Blockchain evidence needs finality context
Another important lesson concerned blockchain evidence.
A transaction hash alone is useful, but sometimes incomplete.
For stronger provenance, systems may need information such as:
chain
block number
observation time
confirmation/finality state
And on layered blockchain systems:
L2 transaction
↓
batch inclusion
↓
L1 settlement
may matter.
The broader lesson is simple:
“Seen on-chain” and “finalized according to the relevant chain model” are not always identical statements.
Our current implementation does not yet encode every possible finality field.
That remains an area we want to improve.
Hashes are not automatically private
Another useful challenge concerned evidence hashes.
It is tempting to think:
SHA-256(value)
means:
value is now private
That is not necessarily true.
If the original value comes from a small or predictable set, an attacker can hash candidate values and compare them.
For low-entropy restricted data, stronger approaches may include:
salted digests
keyed hashes / HMAC
commitment schemes
depending on the threat model.
This is another example of why an attestation architecture needs more than a field called evidenceHash.
The cryptographic construction and the data being protected both matter.
What changed in MyZubster
The feedback influenced our direction toward a first explicit Knowledge Attestation model.
Conceptually, an attestation can capture information such as:
contributionId
evidenceType
evidenceReference
verifier
verificationMethod
observedAt
evidenceHash
status
This gives us something more expressive than:
verified: true
It also lets the Contributor Passport distinguish between:
knowledge demonstrated
knowledge observed
knowledge independently verified
knowledge rewarded
These should not be collapsed into a single badge.
What we have not solved yet
It is equally important to say what is unfinished.
We have not implemented every architectural recommendation that came out of these discussions.
For example, we still want to improve areas including:
richer blockchain finality metadata
stronger privacy treatment for low-entropy evidence
independent verifier models
multi-attestation consensus
reputation for reviewers
That distinction matters.
Technical feedback should not be turned into a marketing claim that everything has already been solved.
Reviewers should have a Passport too
This leads to an interesting consequence.
If contributors can build a Knowledge Passport through code, why should reviewers not build one through review?
Imagine:
Mike / CoderLegion
↓
Technical Review
↓
Knowledge Contribution
↓
Verification Architecture
↓
Evidence
↓
Attestation
↓
Reputation
A reviewer could accumulate demonstrated knowledge across projects without needing to own the project or write every implementation.
That would make review itself a first-class contribution.
A shared Knowledge Graph
Eventually we want the graph to connect contributors through shared knowledge concepts.
For example:
Contributor A
↓
Pull Request
↓
DEMONSTRATES
↓
Verification Architecture
↑
DEMONSTRATES
↑
Technical Review
↑
CoderLegion Reviewer
Now the graph is not merely recording activity.
It is recording how knowledge moved through the ecosystem.
Code is only one form of knowledge transfer
Open source traditionally measures things like:
commits
pull requests
issues
stars
Those metrics are useful.
But they leave out an enormous amount of intellectual work.
Architecture critique.
Security review.
Documentation.
Research.
Testing strategy.
Design decisions.
Questions that reveal hidden assumptions.
A useful knowledge system needs to recognize those contributions too.
What CoderLegion helped us see
The core lesson we took from the discussion was not a specific database schema.
It was a design principle:
Verification should expose its provenance.
And a second principle followed naturally:
A reviewer can contribute knowledge without contributing code.
Those ideas now influence how we think about Contributor Passports, Knowledge Attestations, and the broader MyZubster Knowledge Graph.
Where this goes next
The architecture we are exploring is moving toward:
Person
↓
Contribution
↓
Demonstrated Knowledge
↓
Evidence
↓
Attestation
↓
Reputation
where Contribution might be:
code
review
documentation
research
testing
design
architecture feedback
The objective is not to create another collection of unverifiable skill badges.
The objective is to preserve the path from:
knowledge → evidence → provenance.
Knowledge should not merely be declared.
The path through which it was demonstrated should remain visible.
Thanks to Mike and the CoderLegion community for pushing on exactly the questions that make systems like this stronger.
DEV metadata
Title
From Technical Review to Knowledge Attestation: What We Learned from CoderLegion
Description
How technical review around provenance, independent verification, blockchain finality and privacy influenced the MyZubster Contributor Knowledge Passport.
