Building MyZubster: Turning Community Kefir Practices into Traceable Knowledge
From a jar of kefir to an evidence-aware community knowledge system
Many software projects begin with an abstract problem.
MyZubster began with something much more concrete: a jar of milk kefir, a practice developed through experience, and a simple question:
How can practical knowledge passed from one person to another become structured, reusable and traceable without pretending that personal experience is scientific evidence?
That question led to the creation of the MyZubster Kefir Community Knowledge Library.
The experiment is deliberately small. The current domain is milk kefir. But the architecture behind it addresses a much larger problem: how communities can capture practical knowledge while preserving provenance, uncertainty, observations and external evidence.
This article describes the architecture, data model, contribution workflow and engineering principles behind the project.
1. The original problem
I make milk kefir at home.
Over time, I developed several ways of using it.
I ferment milk with kefir culture, strain the result, separate the thicker fraction from the liquid whey, season the thicker fraction to make fresh spreadable preparations, and reuse the whey in other experiments.
I have also used kefir in:
- pizza;
- focaccia;
- sweet cornetti;
- cakes;
- muffins;
- other baked preparations;
- dehydrated mixtures with cereals and nuts.
This is useful practical knowledge.
But there is an important distinction.
The fact that I have successfully performed a process does not automatically mean that every part of that process has been scientifically validated, standardized or demonstrated to be safe under every condition.
That distinction became one of the central architectural principles of MyZubster.
Instead of storing:
recipe = truth
the system needs to represent something closer to:
practice
+ provenance
+ parameters
+ observations
+ reproductions
+ external evidence
+ uncertainty
The goal is not merely to collect recipes.
The goal is to build traceable community knowledge.
2. The core design principle: evidence first
A community member should be able to say:
“This is what I do.”
without the platform silently transforming that statement into:
“This is scientifically verified guidance.”
MyZubster therefore separates several evidence states.
PERSONAL_PRACTICE
TRADITIONAL_PRACTICE
OBSERVATION
EXTERNAL_SOURCE
VERIFIED_GUIDANCE
PERSONAL_PRACTICE
The contributor reports having performed the process.
Example:
Daniel reports draining fermented milk kefir through a cloth.
That statement documents provenance.
It does not yet establish an optimal temperature, safe storage duration or standardized process.
TRADITIONAL_PRACTICE
The process comes from community or traditional knowledge.
Where possible, its provenance should also be recorded.
OBSERVATION
Something was actually observed during a documented attempt.
For example:
temperature: 22 °C
duration: 18 h
result: thick consistency
The important difference is that these are recorded experimental parameters rather than reconstructed memories.
EXTERNAL_SOURCE
An identifiable external source supports a specific statement.
The source should not simply be attached to the entire recipe.
Instead, the system should record what the source actually supports.
VERIFIED_GUIDANCE
This state should only be used when the relevant claim has genuinely been checked against appropriate evidence or authoritative guidance.
Adding a scientific paper to a card does not automatically make the entire card verified.
3. Knowledge Cards instead of ordinary recipes
The first implementation uses Markdown files stored in Git.
Each unit of knowledge receives a stable identifier.
The current library includes cards such as:
KF-001-MILK-KEFIR-BASE.md
KF-002-STRAINED-SPREADABLE.md
KF-003-WHEY-REUSE.md
KF-004-BAKING.md
KF-005-DEHYDRATED-MIX.md
KF-006-NICOLA-PILOT.md
KF-007-COMMUNITY-RECIPE-TEMPLATE.md
The ID is intentionally independent from the title.
For example:
KF-003
should continue to identify the same knowledge object even if its title is improved later.
This gives the library stable references between cards.
4. A Knowledge Card data model
A useful community knowledge object needs more structure than a traditional recipe.
Conceptually, a card looks like this:
card:
id: KF-###
title: ""
contributor: ""
evidence_state: PERSONAL_PRACTICE
culture_input: ""
experiment_date: UNKNOWN
ingredients: []
equipment: []
procedure: []
process_conditions:
duration: UNKNOWN
temperature: UNKNOWN
result:
appearance: ""
texture: ""
aroma: ""
taste: ""
yield: ""
observations: ""
outputs: []
media: []
reproductions: []
sources: []
safety_boundary: ""
next_iteration: []
There is a deceptively important value in this model:
UNKNOWN
5. UNKNOWN is data
One of the easiest ways to corrupt community knowledge is to make incomplete information look complete.
Imagine somebody says:
“I normally leave the kefir in the refrigerator for a few days.”
A conventional recipe system may be tempted to normalize that into something like:
duration: 72 hours
temperature: 4 °C
But those numbers were never provided.
They would be invented data.
MyZubster instead records:
duration: UNKNOWN
temperature:
environment: refrigerator
measured_value: UNKNOWN
This preserves the difference between:
known
and:
assumed
That distinction becomes extremely important when AI is involved.
A language model is very good at filling gaps with plausible values.
For an evidence-aware system, that can be exactly the wrong behavior.
Therefore one of the main invariants of MyZubster is:
Never invent missing quantities,
temperatures,
durations,
or outcomes.
Missing information becomes a task for the next experiment, not an invitation for the system to guess.
6. From memory to observation
The first Knowledge Cards deliberately document existing practices without pretending that every parameter was measured.
Consider a base kefir method.
We may initially know:
vessel: glass jar
culture: milk kefir
environment: refrigerator
duration: "a few days"
filter: aluminium strainer
But we may not know:
milk_volume: UNKNOWN
grain_mass: UNKNOWN
exact_duration: UNKNOWN
exact_temperature: UNKNOWN
Instead of considering the card incomplete or useless, MyZubster treats it as the beginning of an evidence process.
The next real preparation can record:
milk_volume: 1000 ml
grain_mass: 35 g
start_time: ...
end_time: ...
temperature: ...
result: ...
The system therefore turns memory into a future measurement plan.
7. Reproduction must not overwrite history
Suppose another community member reproduces KF-002.
A typical collaborative document might simply update the recipe.
That destroys valuable information.
MyZubster uses another model.
The original practice remains intact.
A reproduction becomes a new observation:
reproduction:
participant: ""
date: ""
source_card: KF-002
ingredients: []
procedure_differences: []
duration: ""
temperature: ""
result: ""
feedback: ""
This produces an accumulating evidence graph:
original practice
|
+---- reproduction A
|
+---- reproduction B
|
+---- reproduction C
Differences become data instead of noise.
8. Circular knowledge
Kefir also provided an interesting example of why recipes should not always be modeled as isolated objects.
Consider this process:
milk
↓
kefir
↓
cloth draining
↓
+----------------+
| |
thick fraction whey
| |
spreadable dough experiments
preparation other reuse
The output of one process becomes the input of another.
That led to the MyZubster circular knowledge model:
input
→ transformation
→ output
→ by-product
→ reuse
→ new experiment
→ observation
→ community knowledge
This is different from a traditional recipe database.
The relationships between preparations are themselves valuable knowledge.
9. The community contribution pipeline
The next architectural problem was allowing another person to contribute a recipe.
The current workflow is defined as:
community submission
↓
preserve raw submission
↓
normalize without inventing
↓
mark missing fields UNKNOWN
↓
completeness check
↓
assign next KF-###
↓
render Knowledge Card
↓
add to library
↓
collect reproductions
↓
attach external evidence separately
In pseudo-code:
receive_submission()
→ preserve_raw_submission()
→ normalize_without_inventing()
→ mark_missing_fields_UNKNOWN()
→ determine_next_KF_id()
→ render_from_template()
→ save_new_card()
→ add_card_to_library_index()
→ request_reproduction_observations()
→ attach_external_evidence_separately()
This is the basis for future automation.
10. Preserve the raw contribution
Normalization is useful.
Destructive normalization is dangerous.
Suppose somebody submits:
I put some kefir in a cloth overnight and the next morning
it was much thicker.
The system can safely extract:
process:
draining: true
duration:
description: overnight
exact_hours: UNKNOWN
result:
consistency: thicker
It should not infer:
duration: 8h
temperature: 20C
unless those values were actually supplied or measured.
The raw contribution should therefore remain available as provenance.
Conceptually:
RAW CONTRIBUTION
↓
STRUCTURED REPRESENTATION
rather than:
RAW CONTRIBUTION
↓
REPLACED BY AI INTERPRETATION
11. Stable identifiers
The current convention is:
KF-###
When the highest published card is:
KF-007
the next community knowledge object should become:
KF-008
The number should never depend on sorting by title.
And published identifiers should not be reused.
This gives us durable references:
KF-002 → produces whey → KF-003
Later this can naturally become a graph relationship in a database.
12. Markdown first
Why Markdown?
Because at this stage MyZubster needs inspectability more than infrastructure.
Markdown provides several useful properties:
- human-readable;
- Git-friendly;
- diffable;
- portable;
- easy to review;
- easy to generate;
- easy to migrate later.
A Git commit also provides an initial form of historical traceability.
If somebody changes:
UNKNOWN
to:
18 hours
we can see when the change happened.
For an early evidence-aware prototype, that is extremely useful.
13. Git as the first knowledge ledger
Git is not the final database architecture, but it provides several desirable properties immediately.
Every change can have:
author
timestamp
commit
diff
history
That means the knowledge library gains version history without requiring a custom provenance system on day one.
For example:
community submission
↓
Knowledge Card
↓
Git commit
↓
future observation
↓
new commit
This makes the project auditable while the domain model is still evolving.
14. The community template
To make future cards consistent, the project now includes:
KF-007-COMMUNITY-RECIPE-TEMPLATE.md
The template asks contributors to record:
identity
purpose
culture/input
ingredients
equipment
procedure
process conditions
observable result
outputs/by-products
photos/media
feedback
reproduction observations
external sources
evidence boundary
next iteration
The template intentionally asks for both results and unknowns.
This changes the psychology of documentation.
Instead of asking:
“Can I write a perfect recipe?”
the contributor can ask:
“What do I actually know about this attempt?”
15. The Nicola pilot
A knowledge architecture needs a real-world test.
The project therefore includes a small pilot around transferring kefir culture and its associated knowledge to another person.
Instead of using a vague status such as:
pilot_started = true
the process uses observable states:
INTERESTED
↓
REQUESTED
↓
CULTURE_RECEIVED
↓
GUIDE_USED
↓
RECIPE_TRIED
↓
FEEDBACK_RECORDED
A state should only be marked complete when corresponding evidence exists.
That rule is important.
Otherwise software tends to confuse:
intended action
with:
completed action
The pilot is therefore testing two things at once:
- movement of the physical culture;
- movement of the knowledge required to use it.
16. Physical objects and knowledge objects
This is where the experiment becomes more interesting than a kefir recipe repository.
A kefir culture is a physical object.
A Knowledge Card is a digital knowledge object.
The two can travel together conceptually:
PHYSICAL CULTURE
+
KNOWLEDGE CARD
↓
NEW PARTICIPANT
↓
NEW ATTEMPT
↓
NEW OBSERVATION
↓
UPDATED COMMUNITY KNOWLEDGE
This creates a feedback loop.
The recipient is not only consuming information.
They can become a contributor.
17. Evidence as a graph
As the library grows, a flat directory will eventually become insufficient.
The natural next model is a graph.
For example:
Daniel
|
| contributed
v
KF-002
|
| produces
v
WHEY
|
| reused in
v
KF-003
|
| reproduced by
v
Participant B
External evidence can also become nodes:
KF-003
|
| claim
v
"whey used in process X"
|
| supported/refuted/qualified by
v
External Source
This is much more expressive than attaching a generic bibliography to a recipe.
18. Claim-level evidence
A future version should move beyond card-level evidence.
Consider a card containing three claims:
A: Daniel performed this process.
B: The process produced a thicker preparation.
C: The preparation is safe for X days.
These claims have completely different evidence requirements.
Claim A might be supported by contributor provenance.
Claim B might be supported by a documented observation.
Claim C could require appropriate food-safety evidence.
So eventually the model should become:
claims:
- statement: "Contributor performed the process"
evidence:
- PERSONAL_PRACTICE
- statement: "The observed result was thicker"
evidence:
- OBSERVATION
- statement: "Safe for X days"
evidence:
- UNKNOWN
This prevents evidence from leaking from one claim to another.
19. AI should structure knowledge, not manufacture certainty
AI can be extremely useful in this system.
For example, it can transform:
I left it hanging in a cloth overnight
and used the liquid afterward in dough.
into:
process:
method: cloth draining
duration:
reported: overnight
measured: UNKNOWN
outputs:
- thick_fraction
- liquid_whey
whey_reuse:
application: dough
That is valuable normalization.
But the AI should not turn it into:
duration: 8 hours
temperature: 22 °C
function: natural leavening agent
unless those facts are supported.
The AI contract therefore becomes:
extract
structure
connect
identify missing information
suggest what to measure next
BUT DO NOT
invent
silently upgrade evidence
erase provenance
confuse inference with observation
This principle is useful far beyond fermentation.
20. Proposed application architecture
The Markdown prototype can evolve into a service architecture.
One possible design is:
┌───────────────────┐
│ Community Client │
└─────────┬─────────┘
│
▼
┌───────────────────┐
│ Submission API │
└─────────┬─────────┘
│
▼
┌───────────────────┐
│ Raw Intake Store │
└─────────┬─────────┘
│
▼
┌───────────────────┐
│ Knowledge Parser │
│ / AI Normalizer │
└─────────┬─────────┘
│
▼
┌───────────────────┐
│ Validation Layer │
└─────────┬─────────┘
│
▼
┌───────────────────┐
│ Knowledge Store │
└─────┬───────┬─────┘
│ │
┌────────┘ └─────────┐
▼ ▼
┌─────────────────┐ ┌─────────────────┐
│ Evidence Store │ │ Relationship │
│ │ │ Graph │
└─────────────────┘ └─────────────────┘
The important architectural boundary is between:
submission
and:
normalized knowledge
The original input should remain recoverable.
21. Possible database model
A future relational implementation could start with entities such as:
users
knowledge_cards
card_versions
submissions
ingredients
card_ingredients
procedures
observations
reproductions
outputs
card_relationships
sources
claims
claim_evidence
media
consents
For example:
knowledge_cards
---------------
id
public_id
title
contributor_id
created_at
current_version_id
And:
observations
------------
id
card_id
participant_id
experiment_date
duration
temperature
result
created_at
Relationships could look like:
card_relationships
------------------
source_card_id
target_card_id
relationship_type
with types such as:
PRODUCES
USES_OUTPUT_OF
REPRODUCES
DERIVED_FROM
RELATED_TO
22. Provenance should be a first-class object
A conventional application might treat provenance as metadata.
For MyZubster it should eventually become part of the domain model.
Something like:
provenance:
contributor: user_123
submission_id: sub_456
submitted_at: ...
transformation:
method: AI_NORMALIZATION
model_version: ...
reviewed_by: ...
published_at: ...
Then we can answer not only:
What does this card say?
but:
Where did this statement come from?
That is a much stronger knowledge system.
23. Consent is part of the data model
Community knowledge may include:
- names;
- photographs;
- feedback;
- experiment histories.
Therefore consent cannot be an afterthought.
For example:
media:
file: experiment-001.jpg
consent:
publish: true
reuse_for_project: true
The exact implementation will evolve, but the invariant should remain:
No personal media or non-public feedback
is published without appropriate consent.
24. Safety boundaries are product features
It is tempting to treat disclaimers as text added at the bottom of a page.
That is not sufficient.
For MyZubster, evidence boundaries belong inside the data architecture.
A Knowledge Card explicitly asks:
Established by this card:
...
Not established by this card:
...
Questions requiring verification:
...
This turns uncertainty into structured information.
That is much more useful than pretending uncertainty does not exist.
25. The next technical milestone
The repository now has the conceptual contract for automated contributions.
The next implementation step is to build an actual submission processor.
Conceptually:
def create_knowledge_card(submission):
raw = preserve_submission(submission)
normalized = normalize(raw)
normalized = mark_unknowns(normalized)
validate_no_invented_data(raw, normalized)
card_id = allocate_next_kf_id()
card = render_template(
card_id=card_id,
data=normalized
)
save_card(card)
update_library_index(card)
return card
The difficult function is not:
render_template()
The difficult function is:
validate_no_invented_data()
Because that is where the system protects the boundary between helpful normalization and fabricated certainty.
26. Automated evidence checks
A future validation layer could flag transformations such as:
SOURCE:
"a few days"
GENERATED:
"72 hours"
as:
UNSUPPORTED_PRECISION
Likewise:
SOURCE:
"kept in refrigerator"
GENERATED:
"4 °C"
should be flagged.
Other useful validation categories could include:
UNSUPPORTED_PRECISION
UNSUPPORTED_CAUSATION
UNSUPPORTED_SAFETY_CLAIM
MISSING_PROVENANCE
MISSING_CONSENT
EVIDENCE_STATE_ESCALATION
SOURCE_NOT_TRACEABLE
This turns evidence discipline into software behavior instead of relying entirely on editorial caution.
27. Why this matters beyond kefir
Kefir is the pilot domain.
The architecture is much more general.
The same model could represent community knowledge about:
fermentation
gardening
seed saving
repair
craft
cooking
traditional processes
maker projects
local environmental observations
In all of these domains, the same problem appears:
someone knows something useful
but:
we do not want to erase where it came from
or pretend it has stronger evidence than it does
That is the larger MyZubster problem.
28. Community knowledge as an evolving dataset
The long-term objective is not a static encyclopedia.
It is a living dataset.
A card begins as:
PERSONAL_PRACTICE
Then another person reproduces it:
+ OBSERVATION
Another participant changes one variable:
+ OBSERVATION
Relevant literature is attached:
+ EXTERNAL_SOURCE
Specific claims are checked:
+ VERIFIED_GUIDANCE
The knowledge object becomes richer without rewriting its history.
Conceptually:
practice
↓
observation
↓
reproduction
↓
comparison
↓
external evidence
↓
better questions
↓
better experiments
↓
better community knowledge
29. What I learned from building the first version
The most interesting lesson so far is that uncertainty is not missing data to hide.
It is data.
UNKNOWN tells the next contributor what needs to be measured.
A disagreement between two reproductions is data.
A failed attempt is data.
A by-product becoming the input of another recipe is a relationship.
A source supporting only one claim instead of an entire recipe is evidence structure.
And the identity of the person who contributed the original practice is provenance.
Once those concepts become explicit, a simple recipe collection starts becoming a knowledge system.
30. Where MyZubster goes next
The immediate roadmap is straightforward:
Markdown Knowledge Cards
↓
structured submission format
↓
automatic KF identifier allocation
↓
AI-assisted normalization
↓
evidence validation
↓
automatic card generation
↓
community reproduction tracking
↓
claim-level evidence
↓
knowledge graph
The project can remain deliberately small while testing each assumption with real community interactions.
That is important.
There is no reason to build a massive knowledge platform before proving that people can actually:
share
→ understand
→ reproduce
→ observe
→ improve
a piece of knowledge together.
Conclusion
MyZubster started with kefir, but the interesting engineering problem is not fermentation itself.
It is the boundary between experience and evidence.
Community platforms are very good at collecting content.
They are much less good at preserving:
who said it
what they actually did
what was measured
what was missing
what another person reproduced
what an external source supports
and what remains unknown
The MyZubster Kefir Community Knowledge Library is an experiment in making those distinctions part of the architecture.
The core idea can be summarized in one rule:
Do not manufacture certainty. Preserve provenance, record observations, expose unknowns, and let evidence accumulate.
A jar of kefir is a very small place to start.
But it may be large enough to test how community knowledge should work.
