At this level
org.cannadb · 9- org.cannadb.breeder record A breeder identity claim describing a cannabis breeder or seed company. Trust is determined by the publisher DID's relationship to the subject (a record published from a handle matching the breeder's domain is treated as the authoritative self-claim); third-party-attributed records are typically displaced when the breeder publishes their own.
- org.cannadb.grow record 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 di
- org.cannadb.growEntry record 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,
- org.cannadb.growPhoto record 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
- org.cannadb.like record A lightweight engagement signal — the publisher's like of another CannaDB record. Likes are the polymorphic-subject pattern: one record type covers multiple subject collections via an additive allowlist on `subject`. For v1 the allowlist is `org.cannadb.strain` and `org.cannadb.review`. Future indexable record types (e.g., grows, lists) get added to the allowlist additively without a lexicon revision; consumers gracefully ignore likes pointing at unknown collections. The AppView aggregates likes
- org.cannadb.plant record 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
- org.cannadb.review record A review of a cannabis strain or cut. Reviews are where subjective experience lives — the reviewer's perceived flavors and effects, multi-axis ratings, prose body, and optional images. Reviews reference exactly one strain record via `subject` and aggregate at the AppView layer into per-strain summaries (community-derived effect/flavor percentages, average ratings). Publishing this record IS the claim — every field is contextualized by the publisher DID at display time. CannaDB editorial accounts
- org.cannadb.strain record 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
- org.cannadb.strainEdit record A field-level edit to a strain's living document (collaborative editing). Targets a strain via `subject` (the anchor record of the entity) and carries a sparse patch: scalar field overwrites in `set`, additive ops on open array fields in `add`/`remove`, and field clears in `unset`. The AppView folds accepted edits over the anchor record to materialize the canonical document; this record is one signed contribution, attributed to its publisher DID. See docs/05-collaborative-strains.md.