In the tapestry model, new knowledge usually takes the form of new nodes and/or edges, so I think we’re all 3 aligned on that. Sometimes there can be deletions, updates and/or reorganizations, but additions would be the main method. The core insight of tapestry model is that the vast majority of new knowledge comes from my trusted peers. The need to arrive at consensus / develop conventions with my peers over seemingly mundane but nevertheless vital details of semantics and ontology — like what’s the word we use to describe this writing instrument in my hand, or do we use created_at or createdAt for the timestamp in nostr events — is what dictates the architecture of the tapestry model. The rules that govern the knowledge graph (class thread principle and maybe one or two other constraints) need to be as few and as frugal as possible. Isaac Newton didn’t come up with 10 thousand or 100 thousand or a million laws of motion, he came up with three. (Hamilton later replaced these 3 laws with a single unifying principle — an improvement, getting from 3 all the way down to 1.) The tapestry method of arriving at social consensus only works if all peers adopt the same initial set of rules as a starting point, and that doesn’t happen if the set of rules are more complicated (or greater in number) than they have to be. The class thread principle is a simple starting point. Only a handful of “canonical” node types (~ five) and “canonical” relationship types (also ~ five) are needed to get if off the ground. Once off the ground, an unlimited number of node types and relationship types can be added — usually learned from trusted peers. And the class thread principle allows concepts to be integrated vertically and horizontally. (So it’s not like you end up with a huge number of mostly disconnected sql tables. Class threads support multiple meaningful ways to weave disparate concepts together, even without adding any new node types or relationship types.)