And even though we saw that the model spec is just markdown, it’s quite useful to think of it as code. It’s quite analogous. These specifications compose they’re executable, as we’ve seen. They are testable; they have interfaces where they touch the real world. They can be shipped as modules.
And whenever you’re working on a model spec, there are a lot of similar sorts of problem domains. So just like in programming, where you have a type checker, the type checker is meant to ensure consistency. If interface A has a dependent module B, they have to be consistent in their understanding of one another. So if department A writes a spec and department B writes a spec, and there is a conflict, you want to be able to pull that forward and maybe block the publication of the specification.
As we saw, the policy can actually embody its own unit tests, and you can imagine various linters where if you’re using overly ambiguous language, you’re going to confuse humans, and you’re going to confuse the model. The artifacts that you get from that are going to be less satisfactory.
So, specs actually give us a very similar toolchain, but it’s targeted at intentions rather than syntax.
Software engineering (and lawmaking and legal review) is specification repair. So ensure your spec is an artifact that is shared and evolved. It’s the ultimate alignment tool.
This is a formalization of the theory of the program concept.