I’ll be there — Czech lager it is 🍻 In the meantime I’ll work on answering your questions about the query algos we’ll be using so you can build them into Orly. For starters, here’s the cypher query to return all class threads in the database: MATCH classPath = (listHeader)-[:IS_THE_CONCEPT_FOR]->(superset:Superset)-[:IS_A_SUPERSET_OF *0..5]->(subset:Set)-[:HAS_ELEMENT]->(element) RETURN classPath If we want the list of all widgets, we’d add: WHERE listHeader.uuid = (the list header for the list of widgets, which is an event id or a-tag) and use RETURN element If we want all widgets made by Acme Corporation, we’d need to have previously organized the list of widgets into sets and subsets, one of which would have to be “the set of widgets made by acme corporation” and we’d add something like WHERE subset.uuid = (the node that represents the set of widgets made by acme corporation) btw an alternative naming system for the three relationship types you see above are: CLASS_THREAD_INITIATION = IS_THE_CONCEPT_FOR CLASS_THREAD_CONTINUATION = IS_A_SUPERSET_OF CLASS_THREAD_TERMINATION = HAS_ELEMENT Every class thread has one initiation and one termination edge, and any number (0 or above) continuation edges. The class thread rule specifies, in effect, that you can’t make a Widget an item on the list of, say, Cats. And you can write algos to detect such category errors by looking at data formats. Widgets have a property called “brand”, Cats don’t. So if I have an item in my database on the list of Cats and a record it was made by Acme Corporation, the code throws a flag that the class thread rule has been broken and the error should be addressed.