[rlupi]

Rigidity in inputs lock down your system's evolution. The whole system need to evolve in lockstep if you need to change what the systems processes.

In practice, you either end up with an enlarging monolith or introducing state evolution (either explicitly, or by adding incremental input types that the system processes and expanding its API surface).

Beyond a certain inflection point of complexity, flexibility in introducing change becomes necessary.

[SpicyG]

I think that’s a real tradeoff, but I’d frame it slightly differently. The rigidity here is intentional at the gate, not across the whole system. The constraint is that admissibility rules must be explicit and versioned, not that they never change. Evolution happens by introducing new admissible inputs (new proofs, new schemas, new validators), while the old ones continue to fail or succeed deterministically. If the system requires coordinated internal evolution to handle change, then yes, you drift toward a monolith. But if evolution is pushed to the edges (new request types, new validators, new execution paths) while the gate remains simple, the core doesn’t need to evolve in lockstep. I see this less as “rigidity vs flexibility” and more as where change is allowed to accumulate. If change accumulates inside the core, complexity grows superlinearly. If it accumulates at the boundary as new admissible forms, the core stays boring even as the surface evolves. There’s definitely an inflection point where negotiated state becomes unavoidable, but the goal is to push that point as far out as possible, not pretend it doesn’t exist.