The condition expression language was the quietest piece of Attractor's design and, in Navan's opinion, the most elegant. It lived on the edges of the graph—small strings of text that determined whether flow could pass from one node to another. And it had exactly one design goal: be readable by someone who had never seen it before.
satisfaction >= 0.9
That was a condition. You didn't need a tutorial to understand it. You didn't need documentation. You didn't need to know what language it was written in, because it wasn't really a language. It was arithmetic with comparisons.
iteration_count < 5 AND satisfaction < 0.9
Two conditions joined by AND. Still readable. Still obvious. A pipeline should loop back to codergen if it hasn't converged and hasn't exceeded five iterations. The condition said exactly that, in words and symbols a twelve-year-old could parse.
"The temptation," Justin said during a design review, "is always to make the expression language more powerful. Add OR. Add NOT. Add nested parentheses. Add function calls. And then suddenly you've invented a programming language and you're back where you started."
"So where's the line?" Jay asked.
"The line is readability. If a condition expression requires more than five seconds of thought to understand, it's too complex. Split it into multiple edges. Each edge should express one idea."
Navan tested this. He wrote a condition with three AND clauses: satisfaction >= 0.85 AND test_coverage > 0.7 AND iteration_count <= 3. Readable, but dense. He split it into two edges with simpler conditions and a small intermediary node that served as a junction point. The graph got one node larger, but each edge was trivially clear.
"The graph absorbs the complexity," Navan explained to Jay. "If a condition is too complex for one edge, you decompose it into topology. More nodes, simpler edges. The graph grows, but the readability stays constant."
"That's a different kind of expressiveness," Jay said. "Most languages express complexity through syntax. Attractor expresses complexity through structure."
"Through shape," Navan corrected. "The shape of the graph tells you how complex the logic is. You can see it. A complex pipeline is a wide graph. A simple pipeline is a narrow one. The visual form encodes the logical complexity."
Jay rendered Navan's two versions side by side. The single-edge version: one thick arrow with a dense label. The decomposed version: two thin arrows with short labels, joined by a small diamond-shaped junction node. The second version was larger, but it was the one you could understand at a glance.
"Simple enough to read," Jay said. "Powerful enough to route."
"That should be the tagline," Navan said.
It was never officially adopted as the tagline. But from that day forward, every condition expression in the factory was written to that standard.
"The graph absorbs the complexity." This is the same principle behind good policy design. Don't make individual rules more complex. Make more rules that are each individually simple.