Thanks! It's of interest for at least one person here: me 😄 Readability, or maybe better explorability, is one of the main criteria for my current work. As is communicating intent. My context is quite different, so the approach of circuit diagrams is probably not for me, but the layering approach is probably quite universal.

Rete.js needs a feature for this. It allows you to group things, but not hide contents.

Layering and eliding requires a change to the implementation of connections. To do layering, connections need to be triples {direction, sender, receiver}, but, the usual implementation of connections is as doubles {sender, receiver}. This is trivial to implement, but requires a change in mindset. My guess is that thinking in terms of "infinite canvases" blinds one to seeing this minor extension to connections. [Likewise, the code to route messages needs to take direction into account, requiring 4 slightly different methods].

I don't know what direction means. Is the direction not from sender to receiver?

Direction is one of [down | across | up | through]. The common idea is to use only 'across' connections from sender to receiver. Adding 'down' and 'up' makes it possible to compose little networks inside of containers. The containers send their inputs 'down' to their children and get outputs from their children 'up' to their own output ports. The 4th direction 'through' rounds things out and lets you stub out functionality. In analogy, /bin/bash scripts do this kind of thing - they allow one to compose groupings of commands, where commands might be other bash scripts recursively. Same here. You track which way connections point, which lets you compose little networks recursively. [aside, tracking direction also provides a way to wrap "scope" around timing issues, but, that's another discussion].

Can you not derive the container's "ports" by whether the connections start or terminate outside the container? Or is the point that the architect gets to pick the interface of the container, too? Or is there some other reason the connection needs to be segmented at the container boundary?

The Architect builds completely stand-alone Parts. This means that it is impossible to see where external inputs come from or go to. You can't see the whole outside network because each Part is stand-alone and is not privy to information about how it will be used. Analogy: building circuits and buying ICs - the manufacturer gives you a spec sheet which says what the input and output interface is for each IC (it's "pins"), but, only the Architect determines how the IC will be used in a circuit - the manufacturer cannot predict how an IC will be used. Parts are little black boxes with input ports and output ports. Containers ("Choreographer Parts") compose little networks using child Parts. Parts inside a container might be code Parts ("Worker Parts") or might be other containers, there is no way to tell at Architecting time. FP tries to accomplish something similar, but the building block of FP is the function, which effectively has 1 input port and effectively 0 output ports. The fact that functions can hard-wire blocking calls to other functions in their code complicates things. "Return signatures" syntactically look kinda like outputs, but really aren't outputs. [I have to step away now, but, will resume in the morning.]

The first two sentences were all I needed, thanks.