The Normativity Manifesto

I previously wrote about Normativity in Configuration Management. I think the concept of normativity as I define it therein sufficiently important to bang its drum a little. Thus, I here attempt to distill the concept into a succinct form.

The concepts I articulate here aren't really new. You already know what I'm talking about if you're familiar with any of the following:

Essentially the idea is this: Any data which is derived from other data is non-normative. Data which is not derived from any other data is normative.

There is generally an expectation that the process of derivation will be automatable, though in some cases it might necessarily be a manual process. For example, it could be argued that source code implementing a business policy is non-normative because it is directly derived from a natural language document setting out the policy. In this case it is the document that is truly authoritative, and if the document is updated the source code implementing it will need to be updated. However, since derivation of the source code from the document is not automatable, the source code must be considered quasi-normative for the purposes of build and operations automation.

The Normativity Manifesto

See also

This concept of normativity is serendipitous with the concept of Kolmogorov complexity. In some senses, it can be viewed as a particular instance of what I might term the “Kolmogorov problem”, which is of course the fundamental task of data compression: given some piece of data, generate a computer program that, when executed, produces that data as output, such that the size of that program is minimised. (Formats such as DEFLATE can be considered computer programs targeting a simple, non-Turing-complete virtual machine.)