OMDS v1.0

Overview

OMDS is a domain specialization of VODS (Veydrin Open Data Standard). Every OMDS document is also a valid VODS document. OMDS adds the omds_version field and the domain payload arrays on top of the VODS envelope. Four record types are defined: cultures (one grow run, its substrate, and how it was prepared), environment_logs (temperature, humidity, gas exchange, and light through colonization and fruiting), flushes (yield harvested in successive waves), and contamination (the events that damage or end a run). Refer to the VODS v1.0 specification for the envelope fields, the anonymization model, the extensions system, and the versioning contract. This document specifies only what OMDS adds.

Fungi are their own kingdom and their cultivation does not fit a plant model. A mushroom run has a spawn stage and a fruiting stage triggered by different conditions, it is measured by biological efficiency rather than by mass alone, and it is defined as much by what contaminates it as by what it yields. OMDS is shaped to record that practice: the run is a first-class record, the phase is a first-class field, contamination is a first-class event, and the substrate is described precisely enough that biological efficiency can be computed rather than guessed.

Scope

OMDS covers the records a mushroom grower keeps while running a cultivation: what was inoculated and on what, how the environment was held through colonization and fruiting, what was harvested in each flush, and what went wrong. It is intended for home-scale and community-scale growers, small commercial operations, citizen-science sharing, and app-level interchange, and it scales from a single monotub to a research fruiting room.

OMDS does not try to be: a specimen labeling or QR-encoding format, a lineage or breeding record, a laboratory information system, a foraging or wild-occurrence format, or an analytics platform. Specimen identity, strain lineage, and filial generation are the job of WOLS, which OMDS references rather than restates. Plant and aquatic cultivation in controlled environments is served by OCEADS; the mycelial layer of a food-forest guild is recorded by OPDS. Molecular and genetic data are out of scope for v1.0.

The phase vocabulary

Environment logs and contamination events carry a phase field naming the stage of the run. The permitted values, in order, are: inoculation, spawn_run, consolidation, primordia, fruiting, harvest, rest. A run cycles back from rest to primordia for each subsequent flush. Implementations MUST NOT invent phase values; a measurement that does not fit a phase is recorded without one.

The substrate vocabulary

A culture's substrate field uses one of: straw, sawdust, supplemented_sawdust, hardwood_log, masters_mix, coffee_grounds, grain, cardboard, manure, coco_coir, cvg (coir, vermiculite, and gypsum), soy_hull, other. A substrate that does not fit is recorded as other with detail in notes.

Document Envelope

Every OMDS document begins with the VODS envelope (inherited) followed by the OMDS domain version field.

Minimum content rule

An OMDS export MUST contain at least one non-empty array from: cultures, environment_logs, flushes, or contamination. An envelope with no record arrays is not a meaningful export and MUST be rejected.

Record references

A culture carries an optional culture_ref, a pseudonymous identifier for the run. Environment logs, flushes, and contamination events reference the run they belong to by carrying the same culture_ref. References are resolved within a single export and are advisory (§10, O4).

Location and privacy

A culture MAY carry an opt-in coordinates object, {"lat": number, "lon": number} in WGS 84, with an optional coordinate_uncertainty_m. In anonymous mode, coordinates MUST be coarsened to at most one decimal degree (roughly a ten-kilometre cell), and free-text notes SHOULD be stripped. A grow site is usually someone's home; see §12.

Culture Record

One record per grow run or block. The cultures array contains these records. A culture describes what was inoculated, the substrate and how it was prepared, and the quantities that make yield comparable across runs. Only inoculation_date and species are required; the substrate-science fields are optional but are what let a run be analysed rather than merely logged.

Spent substrate

The optional spent_substrate object records what became of the substrate after the last flush, so that a circular use can be traced rather than lost. Its fields are fate (composted · secondary_cultivation · animal_feed · soil_amendment · biofuel · landfill · other), mass_kg, and reuse_ref, a culture_ref of a downstream run when the spent substrate becomes a new substrate. Roughly one kilogram of fresh mushrooms leaves about five kilograms of spent substrate, so where it goes is a real part of the record.

Environment Log Record

One record per measurement. The environment_logs array contains these records. Colonization and fruiting are driven by temperature, humidity, gas exchange, and light, and the point of a log is to correlate those drivers against colonization progress and yield. Only logged_at is required, so a single hand reading is a valid log and a dense automated stream is the same record repeated.

Flush Record

One record per harvest wave. The flushes array contains these records. Mushrooms fruit in successive flushes, the first the largest and later ones declining, so yield is recorded per flush with a flush_number rather than as a single total.

Assays

For medicinal and functional species, the assays array carries laboratory measurements of the compounds that give the mushroom its value. Each entry has analyte (beta_glucan · alpha_glucan · total_glucan · triterpenes · ergothioneine · hericenones · erinacines · cordycepin · other), value, an optional unit (percent for glucans and triterpenes, mg/g for ergothioneine), a basis (dry_weight · fresh_weight · extract), and optional method and lab_ref. The basis matters: an assay result is meaningless without knowing what it was measured against.

Contamination Record

One record per contamination event. The contamination array contains these records. Knowing what struck, when in the run, and what was done about it is often the most valuable data a grower keeps, because it is what changes between a batch that succeeds and one that fails. Only detected_date and type are required.

Suggested contaminant vocabulary

Units and Interoperability

OMDS is a plain-JSON interchange. Rather than carry a linked-data context inline, which would add an online dependency that works against an offline-first log, it reuses established term names and unit codes and documents the crosswalks below. Reusing the names is what lets an OMDS export be read by tools that have never heard of OMDS.

Canonical units (UCUM)

Numeric fields carry the units below, given as UCUM codes so that a value is unambiguous without a conversion engine. A producer MUST record values in these units.

Taxon identity (species and species_id)

The species field is a free-text scientific name, matching Darwin Core scientificName. Because names change and are ambiguous, a record MAY also carry a resolvable species_id, matching Darwin Core scientificNameID, as a prefix:id string. For fungi the nomenclatural authorities recognised under the International Code of Nomenclature are MycoBank, Index Fungorum, and Fungal Names, so a species_id SHOULD reference one of those: mycobank:551634 or indexfungorum:551634. A GBIF backbone key (gbif:2536181) or an NCBI taxonomy id (ncbi:5145) MAY be used as a matching key, but a GBIF key is not a stable nomenclatural anchor because backbone keys can change when the backbone is rebuilt. Storing the name and the identifier together is the interoperable pattern: the name survives when an identifier de-references, and the identifier survives when a name is revised.

WOLS specimen reference

A culture MAY carry a specimen_ref pointing at a WOLS specimen passport, of the form wemush:<id>. WOLS owns the specimen's identity, strain, filial generation, and parent references; OMDS owns the grow log. OMDS does not model lineage or generation, so that identity resolves through WOLS and is never duplicated or contradicted here.

Darwin Core crosswalk

For citizen-science and biodiversity tools, the fields below map to Darwin Core terms. A consumer producing a Darwin Core record from an OMDS culture uses this crosswalk; the geodetic datum is WGS 84 (EPSG:4326) throughout.

Full Example

An anonymous export with one of each record type. It validates against the OMDS v1.0 schema.

{
  "vods_version": "1.0",
  "export_id": "7c9e6a41-3b2d-4e88-9a1f-0d5c2e7b4a63",
  "export_date": "2026-08-18T09:15:00Z",
  "export_mode": "anonymous",
  "omds_version": "1.0",
  "cultures": [
    { "culture_ref": "c1", "specimen_ref": "wemush:clx1a2b3c4d5e6f7g8",
      "inoculation_date": "2026-06-01", "species": "Hericium erinaceus",
      "species_id": "mycobank:551634", "common_name": "Lion's mane",
      "substrate": "supplemented_sawdust", "spawn_type": "grain", "method": "bag",
      "treatment": "sterilized", "sterilization_method": "autoclave",
      "sterilization_temp_c": 121, "sterilization_duration_min": 150,
      "substrate_wet_weight_kg": 2.5, "substrate_dry_weight_kg": 0.5,
      "moisture_content_pct": 62, "spawn_ratio_pct": 25, "container_count": 4,
      "supplement_type": "wheat_bran", "supplement_pct": 18,
      "spent_substrate": { "fate": "composted", "mass_kg": 2.1 } }
  ],
  "environment_logs": [
    { "culture_ref": "c1", "logged_at": "2026-06-20T08:00:00Z", "phase": "fruiting",
      "source": "sensor", "device_id": "tub-a-sht31", "temperature_c": 20.5,
      "substrate_temp_c": 22.1, "humidity_pct": 92, "co2_ppm": 700, "fae_per_day": 4,
      "light_hours": 12, "light_lux": 600, "colonization_pct": 100, "vpd_kpa": 0.19 }
  ],
  "flushes": [
    { "culture_ref": "c1", "harvest_date": "2026-06-28", "flush_number": 1,
      "fresh_weight": 320, "unit": "g", "dry_weight": 32, "fruitbody_count": 2,
      "biological_efficiency_pct": 64,
      "assays": [ { "analyte": "beta_glucan", "value": 22.5, "unit": "%",
                    "basis": "dry_weight", "method": "Megazyme_K-BGLU" } ] }
  ],
  "contamination": [
    { "culture_ref": "c1", "detected_date": "2026-06-10", "category": "mold",
      "type": "trichoderma", "phase": "spawn_run", "severity": "localized",
      "identification_method": "visual", "action": "isolate", "outcome": "contained" }
  ]
}

Conformance Rules

An application claims OMDS v1.0 conformance by satisfying all VODS v1.0 conformance rules (see VODS spec §6) and the following OMDS-specific rules. A machine-readable schema for automated validation is available at omds-v1.0.schema.json.

• M1
  Version field present. Every OMDS document MUST carry omds_version with a value whose major number the consumer recognises.
• M2
  Minimum content satisfied. Every export MUST contain at least one non-empty array from cultures, environment_logs, flushes, or contamination.
• M3
  Controlled vocabularies honoured. The substrate, spawn_type, method, treatment, sterilization_method, supplement_type, phase, source, unit, category, severity, identification_method, action, outcome, and assay analyte and basis fields MUST use only their defined values. The type field on a contamination event is deliberately open (§7). A value that does not fit a closed vocabulary is omitted, not invented.
• M4
  References resolve within the document. A culture_ref on an environment log, flush, or contamination event SHOULD match a culture_ref on a culture in the same export, and a spent_substrate.reuse_ref SHOULD match another culture. A dangling reference MUST NOT cause a consumer to reject the document; it is retained and treated as unresolved.
• M5
  Biological efficiency is computed. Where a producer emits biological_efficiency_pct, it MUST equal fresh_weight / substrate_dry_weight_kg × 100 (with matching units). A consumer SHOULD recompute it when both inputs are present and MUST NOT trust a cached value that disagrees (§6).
• M6
  Canonical units used. Numeric fields MUST carry values in the units declared in §8. A producer MUST NOT emit a value in another unit without converting it first.
• M7
  Anonymous mode floor. In anonymous mode, coordinates MUST be coarsened to at most one decimal degree, and an implementation MUST NOT emit a site identifier that a third party can resolve to an address.

Glossary

Security and Privacy Considerations

Grow-site location

A cultivation is usually run at someone's home. Precise coordinates, a resolvable site identifier, or a photograph with embedded location can disclose where a person lives. In anonymous mode, coordinates MUST be coarsened (§3, M7), site identifiers MUST be pseudonymous, and implementations SHOULD strip embedded location metadata from any referenced photo.

Legal sensitivity of species

The legal status of some cultivated species varies by jurisdiction. OMDS is neutral as to what is grown and records only what a grower enters, but a consumer aggregating or re-publishing OMDS data SHOULD consider that a species value tied to a resolvable location can expose a grower to legal risk, and SHOULD treat location and species together as sensitive.

Free-text field sanitization

The notes fields are free text and can carry personal information a user did not mean to publish. In anonymous mode these SHOULD be omitted; when retained they MUST be treated as untrusted input by any consumer that renders them.

Inference from records

A sequence of runs, yields, and contamination events can reveal a household's activity and routines. Consumers aggregating OMDS data SHOULD avoid re-publishing record-level detail tied to a single pseudonymous site in a way that re-identifies it.

Known Limitations

• Lineage is out of scope. OMDS records the grow log, not the specimen's identity or ancestry. Strain lineage and filial generation live in WOLS, which OMDS references through specimen_ref.
• Species identity is free text by default. OMDS does not require a taxon identifier, only recommends one (§8). A consumer that needs canonical taxa must resolve species strings, or the optional species_id, against an external authority.
• Not linked-data by default. The wire format is plain JSON, chosen so an export needs no network to be produced or read. A JSON-LD context is a candidate for a later optional export profile, not part of v1.0.
• Environment logs are point samples. A log is one reading at one time. OMDS does not model a continuous sensor stream's sampling rate or gaps; a dense stream is simply many records.
• References are advisory. Cross-record references (M4) are checked only within a single export and are not required to resolve, so a partial export remains valid.

References

Normative

These define what a conforming OMDS document must satisfy.

Informative

These are referenced for interoperability and context; a document is valid without them.

Changelog