A garden patch is a self-contained collection of garden nodes placed alongside external content — a specification, a codebase, a document set — to reveal connections through the garden lens without modifying the original content. The patch does not critique or replace what it sits alongside; it offers a dialogue — showing how the same ideas look through typed knowledge forms.
A patch carries everything needed to read it:
A patch uses six link types to distinguish provenance and availability:
| Link | Meaning |
|---|---|
[[Node Name]]↑ |
Grafted — present in patch, copied from source garden |
[[Node Name]]↑⊙ |
Patch-native — present in patch, born here |
[[Node Name]]↑ |
Upstream — in source garden, not in patch |
[[Node Name]]↑ (plain text) |
Ghost link — does not exist yet |
[[Node Name]]↗ |
Cross-garden — in another gardener’s published garden |
[text](url) |
Regular link — external web resource |
These markers encode provenance at the point of reference, so a reader always knows where a concept lives and whether they can navigate to it.
A garden patch functions like a git fork of the source garden. Grafted nodes start as copies but diverge as the patch grows — new connections to the target content, refined explanations, additional context. These changes can be merged back to the source garden, carrying insights discovered through application.
Patch-native nodes⊙ may also flow upstream. A gloss or model created to interpret external content may prove valuable beyond the patch context. The patch is not a static excerpt; it is a living branch of the knowledge graph.
Patches are composable fragments. Two patches from different source gardens can coexist in the same repository. The form type system ensures structural compatibility — a [[Model Form]] in one patch follows the same structural contract as a Model Form in any other garden. A patch author’s interpretation is distinct from the source garden’s authority, and the markers make this visible.