DEV Community

Daniel Ioni
Daniel Ioni

Posted on

Building MyZubster: Turning Community Kefir Practices into Traceable Knowledge

#kefir #community #myzubster #traceable

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
Enter fullscreen mode Exit fullscreen mode

the system needs to represent something closer to:

practice
+ provenance
+ parameters
+ observations
+ reproductions
+ external evidence
+ uncertainty
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

PERSONAL_PRACTICE

The contributor reports having performed the process.

Example:

Daniel reports draining fermented milk kefir through a cloth.
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

The ID is intentionally independent from the title.

For example:

KF-003
Enter fullscreen mode Exit fullscreen mode

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: []
Enter fullscreen mode Exit fullscreen mode

There is a deceptively important value in this model:

UNKNOWN
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

But those numbers were never provided.

They would be invented data.

MyZubster instead records:

duration: UNKNOWN
temperature:
  environment: refrigerator
  measured_value: UNKNOWN
Enter fullscreen mode Exit fullscreen mode

This preserves the difference between:

known
Enter fullscreen mode Exit fullscreen mode

and:

assumed
Enter fullscreen mode Exit fullscreen mode

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.
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

But we may not know:

milk_volume: UNKNOWN
grain_mass: UNKNOWN
exact_duration: UNKNOWN
exact_temperature: UNKNOWN
Enter fullscreen mode Exit fullscreen mode

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: ...
Enter fullscreen mode Exit fullscreen mode

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: ""
Enter fullscreen mode Exit fullscreen mode

This produces an accumulating evidence graph:

original practice
       |
       +---- reproduction A
       |
       +---- reproduction B
       |
       +---- reproduction C
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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()
Enter fullscreen mode Exit fullscreen mode

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.
Enter fullscreen mode Exit fullscreen mode

The system can safely extract:

process:
  draining: true

duration:
  description: overnight
  exact_hours: UNKNOWN

result:
  consistency: thicker
Enter fullscreen mode Exit fullscreen mode

It should not infer:

duration: 8h
temperature: 20C
Enter fullscreen mode Exit fullscreen mode

unless those values were actually supplied or measured.

The raw contribution should therefore remain available as provenance.

Conceptually:

RAW CONTRIBUTION
        ↓
STRUCTURED REPRESENTATION
Enter fullscreen mode Exit fullscreen mode

rather than:

RAW CONTRIBUTION
        ↓
REPLACED BY AI INTERPRETATION
Enter fullscreen mode Exit fullscreen mode

11. Stable identifiers

The current convention is:

KF-###
Enter fullscreen mode Exit fullscreen mode

When the highest published card is:

KF-007
Enter fullscreen mode Exit fullscreen mode

the next community knowledge object should become:

KF-008
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

to:

18 hours
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

the process uses observable states:

INTERESTED
   ↓
REQUESTED
   ↓
CULTURE_RECEIVED
   ↓
GUIDE_USED
   ↓
RECIPE_TRIED
   ↓
FEEDBACK_RECORDED
Enter fullscreen mode Exit fullscreen mode

A state should only be marked complete when corresponding evidence exists.

That rule is important.

Otherwise software tends to confuse:

intended action
Enter fullscreen mode Exit fullscreen mode

with:

completed action
Enter fullscreen mode Exit fullscreen mode

The pilot is therefore testing two things at once:

  1. movement of the physical culture;
  2. 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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

External evidence can also become nodes:

KF-003
   |
   | claim
   v
"whey used in process X"
   |
   | supported/refuted/qualified by
   v
External Source
Enter fullscreen mode Exit fullscreen mode

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.
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.
Enter fullscreen mode Exit fullscreen mode

into:

process:
  method: cloth draining

duration:
  reported: overnight
  measured: UNKNOWN

outputs:
  - thick_fraction
  - liquid_whey

whey_reuse:
  application: dough
Enter fullscreen mode Exit fullscreen mode

That is valuable normalization.

But the AI should not turn it into:

duration: 8 hours
temperature: 22 °C
function: natural leavening agent
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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           │
    └─────────────────┘        └─────────────────┘
Enter fullscreen mode Exit fullscreen mode

The important architectural boundary is between:

submission
Enter fullscreen mode Exit fullscreen mode

and:

normalized knowledge
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

For example:

knowledge_cards
---------------
id
public_id
title
contributor_id
created_at
current_version_id
Enter fullscreen mode Exit fullscreen mode

And:

observations
------------
id
card_id
participant_id
experiment_date
duration
temperature
result
created_at
Enter fullscreen mode Exit fullscreen mode

Relationships could look like:

card_relationships
------------------
source_card_id
target_card_id
relationship_type
Enter fullscreen mode Exit fullscreen mode

with types such as:

PRODUCES
USES_OUTPUT_OF
REPRODUCES
DERIVED_FROM
RELATED_TO
Enter fullscreen mode Exit fullscreen mode

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: ...
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

The exact implementation will evolve, but the invariant should remain:

No personal media or non-public feedback
is published without appropriate consent.
Enter fullscreen mode Exit fullscreen mode

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:
...
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

The difficult function is not:

render_template()
Enter fullscreen mode Exit fullscreen mode

The difficult function is:

validate_no_invented_data()
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

as:

UNSUPPORTED_PRECISION
Enter fullscreen mode Exit fullscreen mode

Likewise:

SOURCE:
"kept in refrigerator"

GENERATED:
"4 °C"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

In all of these domains, the same problem appears:

someone knows something useful
Enter fullscreen mode Exit fullscreen mode

but:

we do not want to erase where it came from
or pretend it has stronger evidence than it does
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Then another person reproduces it:

+ OBSERVATION
Enter fullscreen mode Exit fullscreen mode

Another participant changes one variable:

+ OBSERVATION
Enter fullscreen mode Exit fullscreen mode

Relevant literature is attached:

+ EXTERNAL_SOURCE
Enter fullscreen mode Exit fullscreen mode

Specific claims are checked:

+ VERIFIED_GUIDANCE
Enter fullscreen mode Exit fullscreen mode

The knowledge object becomes richer without rewriting its history.

Conceptually:

practice
   ↓
observation
   ↓
reproduction
   ↓
comparison
   ↓
external evidence
   ↓
better questions
   ↓
better experiments
   ↓
better community knowledge
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)