← Garden Patch Home · Form Definitions
is_a::[[Form Type]] has_status::[[Seed Stage]] in_domain::[[Deep Context Architecture]] in_precinct::[[Garden Precinct]]
Core question: “What am I saying here, how does it connect, and can I prove I said it?”
A compound garden node for the author’s own substantial intellectual works. The lead file contains the work itself – a living document in the author’s voice. Companion files provide self-reflexive analysis, extractable garden insights, and tracking of the work’s various published forms. Grounded in three traditions: FRBR’s Work-Expression-Manifestation hierarchy from library science, IndieWeb’s identity-consolidation patterns, and the principal-agent framework from agency law and Self-Sovereign Identity.
The name “opus” (Latin: work product, plural: opera) connects etymologically to cooperation (from operari, to produce from opus) – the same root that organizes the cooperation-collaboration distinction in the Synpraxis domain.
An Opus is reserved for substantial intellectual works that merit compound treatment: works you develop, publish, and maintain over time. The test: does this work have its own name, purpose, and ongoing development?
Is an Opus: A book. A substantial essay or article. A presentation with original argument. A pattern language. A specification you authored. A course curriculum.
Is not an Opus: A quick social post. An email reply. A meeting note. A clipping of someone else’s work (use Citation Form). A single pattern within a pattern language (use Pattern Form).
Graduating to Opus: Authored content in Authored/ can graduate to Garden/opuses/ when it warrants compound treatment (analysis, insights, expression tracking). Lighter authored content stays in Authored/.
Opuses nest: a parent Opus can contain child Opuses. A trilogy is an Opus whose children are individual book-Opuses. A blog series may be a parent Opus containing individual article-Opuses. The parent lead file describes the arc and purpose; child Opuses are self-contained compounds within it.
Garden/opuses/[Parent Title]/
[Parent Title].md -- parent lead file
[Child Opus A]/ -- child compound
[Child Opus A].md
analysis.md
insights.md
Expressions/
[Child Opus B]/ -- child compound
The nesting depth is not limited. A book-Opus within a trilogy-Opus might itself contain chapter-Opuses if they warrant independent treatment.
[Opus Title]/
[Opus Title].md -- lead file (the work itself)
analysis.md -- self-reflexive analysis
insights.md -- extractable garden nodes
Expressions/ -- published venues and forms
[venue-sidecar].md -- metadata pointer per publication
Renditions/ -- drafts and derived versions
[draft-or-derivative].md -- historical or lossy versions
Archives/ -- binary source artifacts
[file].key, .pdf, .pptx -- gitignored binaries
Lead file: The work itself, in the author’s voice. Free-form structure – the work determines its own sections. Living document: updated, revised, extended over time.
analysis.md: Self-reflexive analysis of the work’s arguments, framework, lineage, limitations. Garden-connected (wikilinks to related nodes). Can be revised when the work evolves substantially (unlike Citation Form’s append-only analysis).
insights.md: Extractable takeaways – concepts, patterns, models, inquiries that could become standalone garden nodes. Maps connections to existing garden domains.
Expressions/: Metadata sidecars tracking where the work is published and in what form. Each sidecar has frontmatter: expresses:, published_at:, published_on:, form: (manifestation, variant), verified:. When an expression has multiple files that must work together (a website with HTML/CSS/JS, a slide deck), place them in a named sub-folder (e.g., Expressions/web/) so the expression is self-contained and functional — you should be able to open index.html and have the site work. The sidecar sits alongside the sub-folder and serves as the manifest (listing which files are published vs. development-only).
Renditions/: Early drafts, abbreviated versions, lossy transformations, archived snapshots of the work at specific points in time. Preserves historical states.
Archives/: Binary artifacts (Keynote files, PDFs, images). Typically gitignored. Referenced by Expression or Rendition sidecars.
Attribution uses role-specific predicates grounded in the principal-agent framework. Predicates capture the CURRENT state of attribution; git history preserves the full record. Roles evolve over time – when a co-author becomes lead author, update the predicates and document the change in the Attribution section.
authored_by::[\[\[Person\]\]↑](../NODES.html#:~:text=Person) – who wrote the contentprincipal::[\[\[Person\]\]↑](../NODES.html#:~:text=Person) – who directed the work and bears ultimate responsibility (from agency law; see [[Principal Authority as Agency Law for Digital Identity]])copyright_held_by::[\[\[Person\]\]↑](../NODES.html#:~:text=Person) – legal ownership (distinct from authorship)produced_by::[\[\[Person\]\]↑](../NODES.html#:~:text=Person) – who made the work happen as a creative project (from film/game industry usage; often the same as principal but carries different connotation)foreword_by::[\[\[Person\]\]↑](../NODES.html#:~:text=Person) – foreword contributorillustrated_by::[\[\[Person\]\]↑](../NODES.html#:~:text=Person) – illustratorcontributed_by::[\[\[Person\]\]↑](../NODES.html#:~:text=Person) – catch-all for other rolesedited_by::[\[\[Person\]\]↑](../NODES.html#:~:text=Person) – editortranslated_by::[\[\[Person\]\]↑](../NODES.html#:~:text=Person) – translatorThe distinction between authorship and responsibility matters for AI-assisted works: a human may not author a single word yet bears full responsibility as principal. “The augmentation is the method, not the author.”
is_a::[\[\[Opus Form\]\]](Opus%20Form.html)has_status::[\[\[Seed Stage\]\]](Seed%20Stage.html) (or Growing, Evergreen)in_domain::[\[\[Domain Name\]\]↑](../NODES.html#:~:text=Domain%20Name)in_series::[\[\[Series Title\]\]↑](../NODES.html#:~:text=Series%20Title) – membership in a thematic collectioninspired_by::[\[\[Source\]\]↑](../NODES.html#:~:text=Source) – intellectual lineageextends::[\[\[Other Opus\]\]↑](../NODES.html#:~:text=Other%20Opus) – when one work builds on anotherdevelops_from::[\[\[Other Opus\]\]↑](../NODES.html#:~:text=Other%20Opus) – earlier work this one grew out ofpresents::[\[\[Garden Node\]\]↑](../NODES.html#:~:text=Garden%20Node) – references garden Pattern, Model, or other nodes the work discussessame_work_as::URL – identity consolidation: “this work also exists here” (the IndieWeb rel-me concept applied to works)created: – when the Work was first conceivedpublished: – when first publicly releasedauthor: – vault author (standard garden field)brief_summary:, tagline: – standard garden fieldssigning_key: – optional SSI provenance pointerOpus presents Patterns: A pattern book (Opus) references garden Pattern Form nodes via presents::. The garden Pattern nodes are the living truth; the Opus captures how the pattern appeared in a specific published Expression.
Opus presents Models: An article that introduces a framework references its garden Model Form node. Multiple Opuses can reference the same Model.
Opus is not Citation: Citation Form captures a dossier ABOUT someone else’s work. Opus Form contains YOUR work itself. The attribution predicates differ: Citation uses cites_work_by:: (third-person); Opus uses authored_by:: and principal:: (first-person).
Opus may contain Cases: A book with case studies can reference garden Case Form nodes. Cases are immutable historical records; the Opus provides narrative context.
Opus Form acknowledges that works can carry verifiable authorship credentials without specifying the mechanism. The principal-agent framework from agency law provides the conceptual foundation. Practical verification may use:
The form definition remains mechanism-agnostic. The SSI layer sits alongside the garden, not inside it.
in_series:: predicate + lightweight index page. May warrant its own form type if series develop consistent internal structure.Structural form – captures what I am saying and how it connects.