When two edges left a node and both conditions were true, the edge with the higher weight went first. That was the entire rule. One number on one edge, and it changed the order of execution.
Justin noticed something on a Friday afternoon. Pipeline nine—the one that generated the integration test harness for the Jira twin—had two paths out of its architecture node. One path led to schema generation. The other led to API stubbing. Both were valid next steps. Both conditions were met. The weights were equal: weight=1 on both edges.
The pipeline always chose the schema path first, because alphabetical ordering was the tiebreaker. Schema generation would complete, then API stubbing would start. But the API stubbing node's codergen call often referenced types defined in the schema. When schema generation ran first, those types existed in context. When both ran in parallel—which happened in some fan-out configurations—the API stubbing agent sometimes hallucinated type definitions because it couldn't see the schema.
Justin changed one number. He set the schema edge to weight=2. Nothing else changed. Same nodes, same conditions, same handlers, same model stylesheet.
He ran the pipeline ten times. The satisfaction metric, which had been averaging 0.83, averaged 0.93. A ten-point improvement from changing a single integer.
"One number," Jay said, looking at the before-and-after graphs on the dashboard. "You changed one number and the factory got twelve percent better."
"I changed the priority of one edge. The schema generates before the API stubs. The types are in context when the stubbing agent needs them. The hallucination rate drops. The satisfaction improves."
"How did you know?"
"I read the event stream. I saw the API stubbing agent inventing types that didn't match the schema. I traced it back to ordering. The fix was obvious once the cause was visible."
Navan was staring at the DOT file. "One integer. The entire behavioral difference between 0.83 and 0.93 satisfaction was one integer on one edge."
"Weight is the smallest possible intervention," Justin said. "It doesn't change what the pipeline does. It changes the order in which the pipeline does it. And order matters. In factories, in recipes, in arguments. The same ingredients in a different sequence produce a different result."
Navan wrote in his notebook: weight = sequence = context = correctness.
Jay looked at the improvement graph one more time. Twelve percent. One integer. He thought about all the complex optimizations he'd done over the years—cache invalidation strategies, query optimizer hints, load balancer tuning. And here, the lever that moved the world was a single digit in a text file that anyone could read.
"That's either terrifying or beautiful," Jay said.
"Both," Justin said. "All the important things are both."
"Weight = sequence = context = correctness." Navan's notebook has become the Rosetta Stone of the factory's philosophy. Each entry compresses a whole lesson into a single line.