Building MyZubster: Turning Community Experience Into Traceable Knowledge

Building MyZubster: Turning Community Experience Into Traceable Knowledge

Most communities already contain an enormous amount of useful knowledge.

The problem is that much of it disappears.

It lives in chat messages, forum threads, Discord conversations, GitHub issues, personal notes, university discussions, workshop experiments, or simply in someone's memory.

Someone discovers something useful.

Someone else tries it.

Maybe they improve it.

Maybe they discover that it doesn't work under different conditions.

Then the conversation moves on.

The knowledge becomes difficult to find, difficult to reproduce, and almost impossible to verify.

We're building MyZubster around a simple question:

What if community experience could evolve into structured, reproducible and traceable knowledge without pretending that every observation is already a verified fact?

That's the experiment we're working on.

And strangely enough, it started with kefir.
Why kefir?

Our first dataset comes from real fermentation practices.

For example:

producing milk kefir;

filtering it;

draining it into a thicker preparation;

collecting the resulting whey;

experimenting with that whey in dough and cheesemaking;

using kefir in pizza, focaccia and baked desserts;

experimenting with dehydration.

These are useful community practices.

But they immediately expose an important knowledge problem.

Imagine someone says:

"I leave the kefir in the fridge for a few days and then filter it."

A conventional knowledge system might be tempted to transform that into something more precise:

Ferment for 72 hours at 4°C.

But nobody said that.

We don't know that it was exactly 72 hours.

We don't know the actual refrigerator temperature.

Adding those numbers would make the documentation look better while making the knowledge less truthful.

MyZubster therefore follows a fundamental rule:

Never silently invent missing information.

Instead:

duration: UNKNOWN
temperature: UNKNOWN

UNKNOWN is not bad data.

Sometimes it is the most accurate data we have.
The Knowledge Card

We started representing contributions as stable Knowledge Cards.

For example:

KF-001
KF-002
KF-003
...

Different domains have different prefixes:

KF-* Fermentation
XMR-* Monero
SND-* Sound systems
DEV-* Programming
UNI-* University / research

A simplified Knowledge Card might contain:

{
"id": "KF-003",
"domain": "FERMENTATION",
"topic": "whey-reuse",
"contributor": {
"name": "community-member"
},
"evidence": [
"PERSONAL_PRACTICE"
],
"procedure": [],
"observations": [],
"sources": [],
"unknowns": []
}

But the important part isn't the JSON.

It's the evidence model.
Not all knowledge is the same

MyZubster currently distinguishes several evidence states:

PERSONAL_PRACTICE
TRADITIONAL_PRACTICE
OBSERVATION
EXTERNAL_SOURCE
VERIFIED_GUIDANCE

If somebody tells us:

"This is how I make it."

that can be valuable knowledge.

But it is PERSONAL_PRACTICE.

It doesn't automatically become:

VERIFIED_GUIDANCE

If ten people repeat it successfully, that becomes interesting evidence.

But ten reproductions still don't magically turn a community observation into a scientific conclusion.

The distinction matters.

We're trying to preserve both usefulness and epistemic honesty.
Provenance first

Every piece of knowledge should answer:

Where did this come from?

A contribution can carry provenance such as:

{
"contributor": {
"name": "Daniel"
},
"provenance": {
"type": "COMMUNITY_CONTRIBUTION"
}
}

Later transformations shouldn't erase that history.

AI can normalize formatting.

Automation can create IDs.

Software can connect records.

But the system should preserve the difference between:

what the contributor actually reported

and:

what software inferred or transformed

This is especially important as AI becomes part of knowledge-processing pipelines.
From documents to a Knowledge Graph

Knowledge rarely exists in isolation.

One practice may produce something used by another practice.

One experiment may reproduce another.

One card may require research.

Another may require programming work.

So MyZubster also maintains a Knowledge Graph.

Relations currently include:

DERIVED_FROM
PRODUCES
USES_OUTPUT_OF
REPRODUCES
NEEDS_RESEARCH
NEEDS_PROGRAMMING
NEEDS_TESTING
RELATED_TO

For example:

KF-002
│
└── PRODUCES ──> KF-003

Or:

KF-003
│
└── NEEDS_RESEARCH ──> COL-001

The graph lets knowledge become actionable.

Instead of simply saying:

"We don't know."

the system can say:

"We don't know, and here is the research task created to investigate it."

That's a very different model.
Collaboration becomes part of knowledge

We introduced another entity:

COL-###

A Collaboration Request.

A Knowledge Card can generate a request for:

PROGRAMMING
RESEARCH
DESIGN
TESTING
DOCUMENTATION
MENTORING

Imagine a Sound System card describing a community-built speaker cabinet.

Measurements are missing.

The graph could contain:

SND-014
│
└── NEEDS_TESTING ──> COL-021

A university student, audio engineer or community member could pick up that collaboration.

The knowledge graph therefore isn't only describing information.

It can describe work that still needs to happen.
Reproduction is where things get interesting

One of the most important parts we've implemented is the Reproduction Engine.

Suppose somebody reads:

KF-003

and actually tries the reported practice.

Instead of editing KF-003, MyZubster creates a new record:

REP-001

And connects it:

REP-001
│
└── REPRODUCES ──> KF-003

The reproduction records what that person actually did:

procedure
quantity
duration
temperature
observations
result
differences
sources

Missing measurements remain:

UNKNOWN

Most importantly:

The reproduction never rewrites the original contribution.

That means disagreement is allowed.

We could eventually have:

           KF-003
          /   |   \
         /    |    \
    REP-001 REP-002 REP-003

Maybe two people observe something similar.

Maybe one doesn't.

That's useful.

The graph should preserve the disagreement instead of collapsing it into a fake consensus.
Collaboration Results

A collaboration also needs somewhere to put its results.

So we introduced:

RES-###

For example:

KF-003
│
└── NEEDS_RESEARCH
│
▼
COL-001
│
▼
RES-001

A result can contain:

summary
outcome
artifacts
observations
limitations
sources
related knowledge

Again, completing a research task doesn't automatically prove anything.

A collaboration result can contribute evidence.

It cannot silently promote the original claim.
Verification must be explicit

Eventually some knowledge may deserve a stronger evidence state.

But verification should be an auditable process.

So we created:

REV-###

A Verification Review.

A review requires things such as:

reviewer
provenance
decision
rationale
sources
limitations
reviewed evidence
conflicts of interest

Current decisions are:

ACCEPT_VERIFIED_GUIDANCE
REJECT
NEEDS_MORE_EVIDENCE

Importantly, even:

ACCEPT_VERIFIED_GUIDANCE

doesn't delete the previous history.

The original contribution still exists.

The reproductions still exist.

Conflicting observations still exist.

The review becomes another node in the evidence graph.

So instead of:

community claim
↓
"TRUTH"

we want something closer to:

Community Practice
│
├── Reproduction
├── Reproduction
│
├── External Sources
│
├── Research Result
│
└── Verification Review

The path to the conclusion remains inspectable.
Protecting the graph itself

Once IDs become references, integrity becomes important.

A relation like:

KF-003 → NEEDS_RESEARCH → COL-001

is useless if COL-001 doesn't actually exist.

So we built an Integrity Checker.

It detects things like:

orphan graph references
duplicate stable IDs
invalid relations
unconnected records

For example:

ERROR: orphan graph reference: COL-999

or:

ERROR: ID collision KF-001

We also built a global ID allocator.

It scans both repository records and graph references before allocating identifiers.

So IDs remain stable even when records live in different directories.
Atomic graph writes

This sounds like a small implementation detail, but it's important.

Imagine creating a Knowledge Card and modifying the graph at the same time.

If the process crashes while writing:

knowledge/graph.json

we don't want half a JSON document.

The graph persistence layer now writes to a temporary file first:

graph.json.tmp

and only replaces the real graph after the write succeeds.

Conceptually:

write temporary file
↓
validate
↓
atomic rename
↓
graph.json

We're moving toward a stronger transactional model where:

record + graph mutation

behave as one operation.

Either both succeed or both roll back.
The loop we're trying to build

All of these components point toward the same loop:

SHARE
↓
TRY
↓
OBSERVE
↓
IMPROVE
↓
SHARE AGAIN

But now each transition can be represented explicitly.

A more technical representation looks like:

Knowledge Card
│
├───────────────┐
▼ ▼
Reproduction Collaboration
│ │
▼ ▼
Observation Result
│ │
└───────┬───────┘
▼
Review
│
▼
Improved Knowledge
│
└──────────────> repeat

That is becoming the core of MyZubster.
Kefir is only the first dataset

Fermentation is useful because it exposes the difficult parts of community knowledge very quickly.

Measurements can be missing.

Procedures vary.

People use different equipment.

Observations conflict.

Safety claims require care.

Tradition and scientific evidence aren't the same thing.

But the architecture itself isn't specific to kefir.

We're designing the protocol for several domains.
Monero

Potential knowledge could include:

node operation
privacy technology
open-source development
documentation
community infrastructure
technical experiments

The evidence boundaries would be different.

The system should distinguish technical observations from financial claims and shouldn't transform technical privacy discussions into promises of anonymity.
Sound systems

This domain is especially interesting for reproducibility:

speaker design
cabinet construction
DSP
measurements
room acoustics
electronics
repairs
event setups

A community cabinet design could generate reproduction records from builders around the world.

Measurements could later be attached.

Testing requests could connect engineers and students.
Programming

A Knowledge Card could describe:

a bug
an architecture
a workaround
an experiment
a tool
an implementation technique

Then:

DEV-042
│
└── NEEDS_PROGRAMMING ──> COL-018

Somebody contributes a patch.

The result becomes traceable back to the problem that generated it.
Universities and research

This may eventually be one of the most interesting applications.

Students and researchers could contribute:

experiments
methodologies
failed attempts
literature
datasets
research questions
reproductions

Instead of research questions disappearing inside isolated projects, they could become collaboration nodes.

For example:

UNI-031
│
├── NEEDS_RESEARCH ──> COL-040
│
└── NEEDS_PROGRAMMING ──> COL-041

A researcher might need a programmer.

A programmer might need domain expertise.

A Sound System project might need acoustic measurements from university students.

A fermentation observation might need microbiological research.

That's where separate communities can start connecting.
Knowledge and resources

There's another idea behind MyZubster that we haven't fully implemented yet.

Knowledge is often connected to a resource.

For example:

kefir culture + knowledge

source code + documentation

speaker design + measurements

research dataset + methodology

Instead of sharing only the object, we can share the knowledge required to reproduce, understand and improve it.

And when somebody receives that resource, they can contribute their observations back into the graph.

The resource travels.

The knowledge evolves.
What we're building next

The repository already contains the beginnings of an executable knowledge protocol rather than just documentation.

We now have:

Knowledge Cards
Evidence states
Provenance
UNKNOWN preservation
Knowledge Graph
Collaboration Requests
Reproduction records
Collaboration Results
Verification Reviews
Integrity checking
Global ID allocation
Atomic graph persistence

The next engineering work is to make record + graph mutations transactional.

After that, we can move upward toward the application layer.

The goal is that nobody should need to understand Markdown files or JSON schemas to participate.

Eventually someone should be able to open MyZubster and see something like:

KF-003
Kefir Whey Reuse

Evidence
PERSONAL_PRACTICE

Reproductions
3

Research requests
1 open

Verification
Needs more evidence

[ I tried this ]
[ Add an observation ]
[ Help research this ]
[ View evidence graph ]

Clicking I tried this would start a reproduction.

Clicking Help research this could join a collaboration.

Clicking View evidence graph would show where the information came from and what happened afterward.
What MyZubster is really experimenting with

We're not trying to build another wiki.

And we're not trying to create an AI system that decides what is true.

We're experimenting with something slightly different:

A community knowledge network where claims, practices, experiments, uncertainty, reproduction, collaboration and verification remain connected to their provenance.

AI can help structure contributions.

Automation can maintain the graph.

Developers can build tools around it.

Researchers can examine evidence.

Communities can reproduce practices.

But the system should resist the temptation to manufacture certainty.

Sometimes the correct state of knowledge is:

UNKNOWN

Sometimes it is:

PERSONAL_PRACTICE

Sometimes:

OBSERVATION

And only after an explicit evidence and review process should something become:

VERIFIED_GUIDANCE

If we can preserve those distinctions while making knowledge easy to share, reproduce and improve, MyZubster could become much more than the kefir experiment that started it.

It could become infrastructure for community knowledge that learns without forgetting where it came from.

MyZubster is still an experiment.

But the loop is becoming executable:

Share → Try → Observe → Collaborate → Verify → Improve → Share again

And that's what we're building.