org.cannadb.grow

A grow — one documented cultivation run (a tent, a garden, a season's cycle). The grow is a lightweight container: it groups one or more `org.cannadb.plant` records and carries the shared setup and a publisher-chosen listing preference. Per-plant lifecycle, activities, notes, and measurements live in `org.cannadb.growEntry` records that reference a plant; photos live in `org.cannadb.growPhoto` records. Publishing this record IS the claim — every field is contextualized by the publisher DID at display time. NOTE on visibility: all atproto records are public regardless of `listed`; `listed` controls only whether the AppView includes this grow (and its plants/entries/photos) in public listing, search, and per-strain aggregation. Unlisted is not private.

Repository @cannadb.org did:plc:lrtzzib3ycggsodkfidzuorw namespace authority
Details · record, key tid
Kindrecord
Record keytid
Authoritycannadb.org
Indexed

Record

record · key tid

Properties

One representative image for the grow's listing card and header. Richer photo galleries belong in `org.cannadb.growPhoto` records. Capped at 2 MB to keep PDS storage burden modest; SVG is excluded for XSS safety.

  • maxSize: 2000000
  • accept: image/png, image/jpeg, image/webp

createdAt

requiredstring · datetime

Client-declared timestamp when this grow record was originally created.

Markdown-formatted overview of the grow — setup, intent, lighting/nutrient regimen, room notes. Per-plant and per-event detail belongs in `org.cannadb.growEntry` records; this is the grow-wide writeup.

  • maxLength: 100000
  • maxGraphemes: 10000

endedAt

string · datetime

When the grow run ended (final harvest, or the run was abandoned/archived). Optional.

Static setup descriptor for where the grow runs. Live sensor/environment/controller telemetry is out of scope for CannaDB (it remains the domain of self-hosted tools like Isley). Open vocabulary.

  • knownValues: indoor | outdoor | greenhouse | mixed

listed

boolean

Publisher's index preference. Absent or true means the AppView MAY include this grow — and its plants, entries, and photos — in public listing, search, and per-strain grow aggregation. False means the AppView SHOULD exclude the whole grow subtree from those public surfaces. This controls indexing only: the records remain public on the PDS and resolvable by direct AT-URI regardless. It is independent of AppView moderation (a listed grow may still be editorially hidden).

medium

string

Static setup descriptor for the growing medium. Open vocabulary.

  • knownValues: soil | living_soil | coco | hydro | rockwool | aeroponic | other

name

requiredstring

Display name for this grow, e.g., "Wedding Cake — Spring '26 Tent". Capped to keep listing cards tidy.

  • maxLength: 2000
  • maxGraphemes: 200

startedAt

string · datetime

When the grow run began (typically the first germination/plant date). Optional.

status

string

Coarse grow-level status. Distinct from per-plant lifecycle stage (which is event-sourced via `org.cannadb.growEntry`). Open vocabulary — clients should accept unknown values and fall back to generic display.

  • knownValues: active | harvested | archived | abandoned

Similar lexicons

semantic match

Lexicons whose schemas describe something close to this one. Check them before publishing a new one that overlaps.

  • A single plant within a grow. The plant is the lifecycle unit: it references the `org.cannadb.grow` it belongs to and (optionally) the `org.cannadb.strain` it is. Its lifecycle stage is NOT stored as a mutable field here — stage transitions are append-only `org.cannadb.growEntry` events (kind "stage"), and the AppView computes the current stage from the latest such event. Measured harvest outcomes, once known, are recorded in the optional `harvest` object so the AppView can aggregate real cultiv

  • A single photo in a grow's gallery. Modeled as its own record (rather than blobs embedded in entries) so galleries can grow without bloating other records and so each photo carries its own caption, ordering, and capture date. A photo attaches to a plant (the usual case — per-plant galleries) and/or to the grow (group/room shots, the cover), and may optionally link to the `org.cannadb.growEntry` it documents. The image blob lives on the publishing PDS; the record carries the blob ref plus metadat

  • One append-only event on a plant's timeline. A single record type unifies what other journals split into status changes, activities, measurements, and notes — because they are all the same shape (a timestamped thing that happened to a plant) and the distinguishing detail is an open `kind` vocabulary. Stage transitions (kind "stage") are how lifecycle is tracked: the AppView reads the latest stage entry as the plant's current stage and the full set as its lifecycle history. Activities (watering,

  • Cannabis genetic identity. The same record type covers two levels of specificity, distinguished by the `kind` field: "strain" denotes a broad genetic identity (e.g., "Wedding Cake"); "cut" denotes a specific phenotype, clone, or keeper pheno (e.g., "Forum cut of GSC"). Captures intrinsic identity, structured cultivation profile, and the publisher's contextualized field assertions; subjective experience and measured outcomes live in separate record types (`org.cannadb.review`, future `org.cannadb