Every pod runs alone — that is what makes it safe to change. But the knowledge inside one travels well, and hoarding it helps nobody. The community layer is how a pod design leaves the machine it was built on.
What the pod is for, and the adjacent concepts it deliberately excludes.
The examples that define the concept — the most valuable and most arguable part.
Where the lines sit, with the reasoning that put them there.
What an affected party sees when this pod drives a decision.
Components are the interesting part. A distance metric tuned for clinical shorthand may be exactly what a veterinary intake pod needed. A receipt template written for a regulated industry saves a small team a month of drafting.
Forking a pod records its lineage, so the person whose phrase set you started from stays visible however far the design travels.
Pod registry — browse published designs by domain, read the phrase set before you commit to it.
Lineage & attribution — forks carry their ancestry, with a diff of what changed and why.
Component library — metrics, thresholds, receipt templates and calibration sets, shareable on their own.
Shared calibration runs — pool anonymised distance distributions so a new pod starts closer to sane defaults. Only if it can be done without anyone's samples leaving their own instance.
None of this is built yet, which means the people who join first get to argue about it. If you have run a shared taxonomy before — a species key, a defect catalogue, a coding manual — we would rather hear from you now than after we have picked the wrong defaults.