Building MyZubster: An Open Knowledge Graph for Reproducible Community Experience

Thu, 17 Sep 2026 02:09:22 +0000

We are building MyZubster, an experimental open-source system for turning community experience into structured, reproducible and traceable knowledge.

The idea started with a surprisingly simple problem.

People know things.

They build things, try things, break things, fix things and discover things.

But most of that knowledge eventually disappears into:

Discord
GitHub Issues
forums
chat messages
personal notes
university projects
workshop experiments

Even when the information survives, another problem appears:

How do we know where it came from?

Was it someone's personal experience?

Was it reproduced?

Was it measured?

Was it taken from an external source?

Was it actually reviewed?

MyZubster is an attempt to make those differences explicit.

The first prototype: kefir

The first real dataset is intentionally small and concrete: milk kefir and fermentation practices.

Community practices were converted into Knowledge Cards:

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

A card can describe a process such as:

milk kefir

↓

cloth draining

↓

thick fraction + whey

↓

reuse experiments

This immediately exposed one of the fundamental problems we wanted the architecture to solve.

Suppose someone reports:

"I keep it in the refrigerator for a few days."

Software should not silently transform that into:

{
"duration": "72 hours",
"temperature": "4°C"
}

Those values were never supplied.

So MyZubster uses a very important value:

UNKNOWN

Instead:

{
"duration": "UNKNOWN",
"temperature": "UNKNOWN"
}

This principle is one of the core invariants of the project:

Missing information must remain missing until evidence provides it.

Knowledge as data

We're moving away from treating knowledge as only prose.

A simplified MyZubster Knowledge Card looks conceptually like this:

{
"id": "KF-003",
"domain": "FERMENTATION",
"topic": "whey-reuse",
"contributor": {

"name": "community-member"

},
"provenance": {

"type": "COMMUNITY_CONTRIBUTION"

},
"evidence": [

"PERSONAL_PRACTICE"

],
"procedure": [],
"observations": [],
"sources": [],
"unknowns": []
}

The repository currently uses stable prefixes for different domains:

KF- → Fermentation
XMR- → Monero
SND- → Sound Systems
DEV- → Programming
UNI-* → University / Research

So the kefir experiment is only the first implementation of a broader protocol.

Evidence is not boolean

One thing we explicitly don't want is:

TRUE / FALSE

as the only model for community knowledge.

Real knowledge evolves.

MyZubster currently distinguishes:

PERSONAL_PRACTICE
TRADITIONAL_PRACTICE
OBSERVATION
EXTERNAL_SOURCE
VERIFIED_GUIDANCE

This means:

"I do this"

can be useful without pretending it means:

"This has been scientifically verified."

That's an important architectural distinction.

A community contribution cannot automatically submit itself as:

VERIFIED_GUIDANCE

Verification is a different operation.

Provenance is part of the object

Every contribution should retain its origin.

We don't want this:

community observation

↓

AI transformation

↓

anonymous "fact"

We want:

community observation

↓

structured representation

↓

provenance preserved

AI may eventually help normalize submissions, identify missing fields or connect related knowledge.

But AI should not silently manufacture:

quantities
temperatures
durations
causation
results
sources
verification

That rule is enforced at the protocol level rather than left entirely to prompting.

Then we added a graph

Knowledge Cards quickly started needing relationships.

So MyZubster now has a Knowledge Graph.

Current relation types 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

This changes the project significantly.

The graph doesn't only represent what we know.

It can also represent what needs to be done next.

Knowledge can create work

We introduced Collaboration Requests:

COL-###

Supported collaboration types currently include:

PROGRAMMING
RESEARCH
DESIGN
TESTING
DOCUMENTATION
MENTORING

This means a Knowledge Card can effectively generate work.

Imagine:

SND-014
Community Speaker Cabinet

The design exists, but nobody has measured it properly.

Instead of adding invented measurements, the graph can say:

SND-014

│
└── NEEDS_TESTING ──> COL-027

Now the missing knowledge becomes an actionable collaboration request.

A developer might help build the measurement tooling.

An audio engineer might run the test.

A university student might analyze the results.

The graph connects all of it.

Reproduction is a first-class object

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

If someone tries:

KF-003

we don't modify KF-003.

We create:

REP-001

and connect it:

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

The reproduction records what actually happened:

{
"targetCard": "KF-003",
"procedure": [],
"quantity": "UNKNOWN",
"duration": "UNKNOWN",
"temperature": "UNKNOWN",
"result": "...",
"observations": [],
"differences": []
}

This allows multiple independent attempts:

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

And critically:

they don't need to agree.

MyZubster should preserve conflicting observations instead of averaging them into fake certainty.

Collaboration produces traceable results

A Collaboration Request can produce another object:

RES-###

So we can represent:

KF-003
│
└── NEEDS_RESEARCH

        ↓
     COL-001
        ↓
     RES-001

A Collaboration Result records things such as:

summary
outcome
artifacts
observations
limitations
sources

The result is linked back to both the collaboration and relevant knowledge.

Completing a task doesn't automatically verify the original claim.

It simply adds another traceable piece of evidence.

Verification is another object

We also implemented a Verification Review layer:

REV-###

A review requires explicit information:

reviewer
provenance
decision
rationale
sources
limitations
reviewed evidence
conflicts of interest

Current decisions are:

ACCEPT_VERIFIED_GUIDANCE
REJECT
NEEDS_MORE_EVIDENCE

Importantly:

REV-042
ACCEPT_VERIFIED_GUIDANCE

does not delete or rewrite:

KF-003
REP-001
REP-002
RES-004

The historical evidence graph remains intact.

A verified conclusion should be inspectable back to the evidence that supported it.

This is starting to look like Git for community knowledge

One useful way for developers to think about MyZubster is:

What if some ideas from Git were applied to community knowledge?

Not literally commits and branches everywhere, but similar principles:

stable identities
history
provenance
changes without destroying origins
parallel experimentation
review
traceability

Instead of repeatedly rewriting one canonical article, we can preserve an evidence history.

Conceptually:

      Knowledge
          │
  ┌───────┴───────┐
  │               │

Reproduction Collaboration

  │               │

Observation Result

  │               │
  └───────┬───────┘
          │
        Review
          │
          ▼
  stronger knowledge

And the cycle continues.

We also need boring infrastructure

Once the graph becomes meaningful, infrastructure correctness matters.

So we've implemented an Integrity Checker.

It detects:

duplicate IDs
orphan references
invalid graph relations
unconnected records

For example:

ERROR: orphan graph reference COL-999

or:

ERROR: ID collision KF-003

We also built a global ID allocator.

It recursively scans the repository and the Knowledge Graph before generating:

KF-###
XMR-###
SND-###
DEV-###
UNI-###
COL-###
REP-###
RES-###
REV-###

This matters because generated proposals and canonical records can live in different directories.

Atomic graph persistence

We're also beginning to treat the repository as an actual datastore.

Writing directly to:

knowledge/graph.json

creates an obvious failure mode.

A crash during a write could corrupt the graph.

So graph persistence now follows:

serialize
↓
write temporary file
↓
rename
↓
graph.json

The temporary file is cleaned up if the operation fails.

Our next step is stronger:

record creation

graph mutation

↓

transaction

Either both succeed or neither does.

That will give the repository a much stronger consistency model.

The interesting part for developers

MyZubster isn't intended to remain a collection of Markdown files.

The repository is currently becoming the reference implementation for the protocol.

Eventually the same concepts can sit behind an API.

Something like:

POST /knowledge
POST /reproductions
POST /collaborations
POST /results
POST /reviews

And:

GET /knowledge/KF-003
GET /knowledge/KF-003/graph
GET /knowledge/KF-003/reproductions
GET /collaborations/open

The UI could then hide almost all of the underlying complexity.

A user could simply see:

────────────────────────────────────

KF-003
Kefir Whey Reuse

Evidence
● Personal Practice

Reproductions
3

Research
1 open collaboration

Verification
Needs more evidence

[ I tried this ]

[ Help investigate ]

[ Add evidence ]

[ View knowledge graph ]

────────────────────────────────────

Behind those four buttons would be the evidence protocol.

Why programmers are part of the model

Programming isn't only needed to build MyZubster.

Programming itself can become a MyZubster knowledge domain.

Consider:

DEV-108

describing a bug or technical technique.

Someone reproduces the issue:

REP-081 ── REPRODUCES ──> DEV-108

The card needs implementation work:

DEV-108 ── NEEDS_PROGRAMMING ──> COL-054

Someone produces a patch:

COL-054

↓

RES-037

Another developer tests it.

Another reproduction is created.

Documentation gets attached.

The result becomes part of a traceable technical history rather than disappearing inside a chat conversation.

That's one of the reasons we're interested in developer communities.

Cross-domain collaboration is the bigger experiment

The domains aren't supposed to become isolated silos.

Consider a Sound System project:

SND-031

It might need software:

SND-031
└── NEEDS_PROGRAMMING ──> COL-071

And research:

SND-031
└── NEEDS_RESEARCH ──> COL-072

Now programmers, audio engineers and university students can collaborate around the same knowledge object.

Or a university project could produce software:

UNI-018
↓
COL-080
↓
DEV-121

Knowledge starts connecting communities that normally operate separately.

That's where MyZubster becomes more interesting than a fermentation database.

Where we want to take it

The core loop we're trying to make executable is:

Share
↓
Try
↓
Observe
↓
Collaborate
↓
Verify
↓
Improve
↓
Share again

The architecture underneath it is becoming:

KnowledgeCard

 │
 ├── Reproduction
 │       └── Observation
 │
 ├── CollaborationRequest
 │       └── CollaborationResult
 │
 ├── ExternalSource
 │
 └── VerificationReview

All connected through a provenance-aware graph.

What comes next

The immediate engineering work is transaction safety for record + graph mutations.

After that we want to work toward:

graph integrity constraints
domain-specific verification rules
API
search
evidence graph visualization
collaboration discovery
reputation without turning it into popularity = truth
source traceability
version/history tooling
community UI

And eventually, AI-assisted intake.

But AI has a very specific role here.

It can help transform:

"I tried this yesterday and it worked differently..."

into a structured reproduction record.

It must not transform it into:

"This method is verified."

The evidence graph decides what evidence exists.

Review processes decide how that evidence should be interpreted.

AI helps humans work with it.

The experiment

MyZubster started with kefir because we needed real knowledge rather than synthetic examples.

But we're building the architecture so the same protocol can eventually represent:

fermentation
open-source software
Monero technology
sound-system engineering
university research
community experiments

The central idea remains simple:

Don't just store the answer. Store how we got there.

Preserve who contributed something.

Preserve what they actually said.

Preserve what we don't know.

Let other people reproduce it.

Let developers and researchers collaborate around the missing pieces.

Keep results linked to their origins.

And make verification explicit rather than automatic.

We're trying to build an open knowledge system that can improve over time without forgetting its own history.

Share → Reproduce → Observe → Collaborate → Verify → Improve

That's MyZubster.

And we're building the protocol in code first.

Coder Legion - Recent posts tagged experience

Building MyZubster: An Open Knowledge Graph for Reproducible Community Experience