In the configuration space there's a certain irreducible complexity. Depending on what angle you come at things, you can try to abstract away details, but you n

In the configuration space there's a certain irreducible complexity. Depending on what angle you come at things, you can try to abstract away details, but you need to mentally evaluate the abstractions anyway to figure out the effective configuration, to see if it makes sense. I've long thought that configuration can be modeled as intersecting N-dimensional subspaces, where N is the number of configuration axes (e.g. production vs test vs dev is one axis, as are datacenter location, machine role, etc). You can say that all test machines enable feature flag X, or everything in datacenter Y should use network setting Y.net - and these are cross-cutting concerns that don't lend themselves to hierarchical composition (and thus inheritance is out). The configuration settings themselves have a scope in the configuration space. But then you need to evaluate it mentally to sanity-check it: are all the spaces covered correctly? Are there any odd overlaps? There's a pairing with table-based exhaustive testing. Perhaps the cartesian product of all the axes results in too many distinct N-cubes to test individually, but predicates might be written that act as sanity checks, and testing for exhaustive coverage of predicates over the configuration space is possible (e.g. "every box has a disk space allocation", "boxes running service D have at least X disk space", etc.). Anyhow, it's rattled away in my head for decades and has leaked out into implemented systems a couple of times, but never in a fully formalized or packaged way.