The split into sub-workflows is the right call, and there is one thing worth knowing before you make it: it fixes the reading problem and quietly makes the archaeology problem harder, unless you do one extra thing.
A sub-workflow called through Execute Sub-workflow gets its own execution. So the parent’s Execution Data — the conversationId and intent saved at the top — lives on the parent’s row, and the six child runs that actually did the work do not carry it. Filter the Executions list by that conversationId and you get the parent back, which tells you the conversation happened and not much else. Open it and you are clicking through to each child by hand, which is exactly the archaeology you were trying to stop, just with tidier boxes.
The fix is small and easy to forget: put an Execution Data node at the top of every sub-workflow too, populated from its Workflow Inputs, so the same conversationId is written on each child. Then one filter returns the whole conversation as a set of rows rather than one row that hides five. Define the inputs so the conversationId is a declared input rather than something you reach for in $('...') — that way a sub-workflow that gets called from somewhere new cannot silently lose its tag.
Two things that pushed me the same way you went, for what they are worth:
Rename Output earns its keep beyond readability. Once branches are named, the branch name is a value you can save into the execution data, so “which path did this answer come from” becomes a filter instead of a re-read of the canvas. That is the specific question you described as archaeology, and it turns into a query.
The failure that survives all of this is the branch that ran and did nothing. A router that sends a conversation down a stage where the write is on the path not taken produces a green execution with correct-looking data. Structure does not catch it, because nothing is wrong with the structure; the run genuinely finished. What catches it is asserting on the count after each write — items written greater than zero — so the silent case becomes an ordinary red run instead of a customer telling you weeks later.
On the builder question: I use the same create-only rule for the parent, and I do not think it is superstition. Not because the tool is bad at editing, but because the parent is the only file where the shape is the documentation. A regenerated parent that is functionally identical and visually rearranged costs you the mental map you built, and you find that out at the worst moment. Sub-workflows are cheap to let it touch, because their contract is the declared inputs — if those still line up, a rewritten body is a body you can read fresh.
The honest limit of all of this: it makes the answer findable after the fact. Nothing here shortens the gap between a flow going quiet and someone noticing, and in my experience that gap is where the real cost sits.