On reasoning backwards from architecture to implicit requirements

Part of my series on common misconceptions in space journalism.

Rigor is the underpinning of success when designing any kind of technological application. Throughout my career I have found myself on the frontiers not only of my own knowledge, but human knowledge in general. There is no handy reference or list of answers to check my work, so I was forced to develop my intuition for detecting problematic reasoning. I routinely employ these skills both to defend my own work against errors and to constructively critique the work of others.

In this vein, I have previously I discussed the dangers of reasoning by analogy instead of first principles.

In this blog, I explain another powerful reasoning technique for avoiding errors of reasoning, namely reasoning backwards from architecture to implicit requirements.

The basic idea is simple to state. If you have a pair of recipes that transform data between two different formats, then applying them together, in either order, should return the original data. This is known by all sorts of fancy terms in mathematics and physics, but is also intuitively obvious.

The most familiar example (H/T to Christine Moran) is Google translate. When using Google translate between a native and an unknown language, one can copy the resulting text into the inverse translator to check for obvious errors. For additional amusement, one can add a string of other languages in between.

Another more quantitative example are coordinate transforms. If the transform and its inverse don’t return the identity, then something is very wrong.

Surprisingly, despite a lack of formal rigor, this concept extends beautifully to any process where data is transformed. In this blog, I will focus on the design process.

When a new embodiment of technology is designed, a team of designers translate a set of customer-determined requirements into a final product. There are many intermediate steps, some of which involve making trades based on a relatively small number of fundamental properties, but for the purposes of this exercise, we can regard the design process as a black box that eats requirements and produces designs.

If one is designing a new car or airplane, it is relatively straight forward to look at the design and determine, by analogy with existing exemplars of the form, whether the design is likely to be useful. But what if the design is of a new kind of thing, such as a Hyperloop or some exotic spacecraft?

If one has access to the designers, one could ask them directly, but it is often instructive to simulate the design process. Only one does not normally have access to precise numerical requirements, which may be proprietary. Instead, start with the final design product and reason backwards to determine a likely set of requirements.

There are two interesting aspects to this process.

The first is that the forward and reverse processes are not completely well-defined, so typically the requirements space for a given design is a bit fuzzy, just as the design space for a given set of requirements can admit some variation in form. In mathematics, we sometimes think of this as compact mappings. Given a set of competing designs, it is instructive to find the domain boundaries in requirements space. That is, a closely related set of requirements maps to one design or even product architecture. Vary the requirements a bit and the same architecture results. But vary the requirements enough and the architecture will “snap” over some unseen boundary and result in a different outcome. Repeating this process can eventually map out all these boundaries, allowing the user to completely understand the design space. If, in the course of this exercise, one finds a region of requirements space without a corresponding design, this may be a market opportunity!

This requirements and design space mapping is often part of the design iteration process. Even if solving the given problem is impossible in a single pass, reasoning backwards will enable steady progress and build design space understanding. It is also often much more efficient to operate forward and back between requirements and end product, interpolating a little more of the design space with each step, until a complete logical bridge is built between the two domains.

The second is that there are two broad families of requirements; explicit and implicit. Explicit requirements are the obvious ones, and so while they’re relatively easy to discover, they won’t deliver much insight because anyone could think of them. Implicit requirements are seldom committed to paper, but frequently must be surfaced to complete a successful design. Instead, they form part of the universal thought background, a set of common cultural assumptions and practices. Sometimes these practices are unfathomably esoteric, particularly where the designers came from a different time or place. Sometimes they make a deep sort of sense. Often they reveal a lot about the state of knowledge within an organization, or how that organization is structured. And in aerospace, implicit requirements almost always carry the political data payload.

In addition to its original purpose of checking calculations, reasoning backwards from architecture to requirements is a powerful tool precisely because it allows adept users to infer information about inaccessible organizations or power structures which is otherwise impossible to obtain.

In some cases this enables rediscovery of Conway’s Law, which states:

organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.

In other cases, one can reliably derive the unstated political goals of the Lunar Gateway program, or the addressable market for the SpaceX Starship.

For more detail on a concrete example of reasoning backwards, check out my blog on the differences between different Lunar exploration architectures.