So there's a type of mathematical structure I'm interested in exploring, I figure it already has been explored, so I'm curious if someone can point me in the right direction.
It's inspired by trying to think of programming languages as graphs. However the structure I've come across is not really a graph
So here's the setup:
"Nodes/Components" are defined as sets of "Edges/Relations". So if a node/component's edges/relations are modified, it becomes a new node/component and the previous node/component may or may not still exist in the graph.
"Edges/Relations" are 2-tuples, with the left being a reference to a "instruction node/component" and the right being a reference to the "target node/component". You could think of the left side as being a an evaluation operation or some kind of relationship between the component of which it's a part, as well as the target component
I'll start referring them them as Components and Relations to avoid confusing them with actual graphs. Hopefully those names don't cause confusion as well.
We start with the empty component C_{0}, which contains no relations. We can then create 1 more component, which is the set containing the Relationship (C_{0}, C_{0}). We can call this the unit component or C_{1}.
Since C_{0} is the "instruction component", it must define an operation which can take C_{1} => C_{0}. This could be for instance a constant function which always returns the empty component. It could also be a function which randomly removes 1 relationship from the component if possible. Any function which maps C_{1} to C_{0} should suffice.
From there, it explodes. We can create 14 more components. We could define C_{2} as the set containing the Relationship (C_{0}, C_{1}). This would constrain our previous definition of C_{0} such that it maps C_{2} => C_{1}. If we define C_{3} as the set containing the Relationship (C_{1}, C_{0}), then we have the constraint on C_{1} that is must map to a function that takes C_{3} to C_{0}.
We don't have to accept all of these 14 new possible components as well-formed. The goal is to define the evaluation functions corresponding to some set of components, as well as a way to generate new evaluation functions for new components from the relationships that compose them. Then we try to create and evaluate graphs with those instructions and see if we can develop a set of instructions which allow us to turn this into a Turing complete data structure.
tl;dr Your structure doesn't have a name. So invent one.
Longer version
I haven't read through the question, That said, there's no reason you can't start with a graph (directed or not as you wish) and then decorate the edges with any objects that suit your application. Graphs with weighted edges are common. In your case the "weights" are just pairs of objects. Then write down axioms for how the weights interact. Standard algorithms that traverse graphs may then help you prove what you need.
If I have misread your wish to base your theory on graphs, just invent names for all the notions you need. Be sure to illustrate your formal definitions with examples.