Most complex software systems are designed incrementally. Decisions accumulate over time, each one made in context, few of them recorded, almost none of them traceable to the principles that originally motivated them. This works well enough — until someone needs to understand why the system is the way it is, or needs to adapt it to a new requirement without breaking what already exists.

Derivable Architectures (DA) is a methodology that attempts to solve this problem at the root.

The central observation is simple: some systems — software, legal, biological, or otherwise — appear to have a stable abstract structure from which all their concrete variants can be systematically derived. The abstract structure does not change when implementations change. The implementations do not redefine the structure. The relationship between the two is not accidental — it is constrained, traceable, and in principle verifiable.

Where the idea came from

The observation was first made during the development of an institutional architecture — a constitutional framework designed to span multiple legal jurisdictions. What was surprising was not that the framework worked, but how it worked: jurisdiction-specific artifacts could be derived from a stable constitutional core through constrained transformations, without the core needing to change. The derivation was not a manual translation. It followed structural rules, preserved identity, and left an auditable trail.

That behavior suggested something broader might be going on. The research program was designed to find out whether it was domain-specific or a property of a recognizable class of systems.

What the theory proposes

DA proposes that some architectures have the following property: their concrete realizations are not independently designed — they are derived from the abstract architecture through semantics-preserving transformations. When this property holds, several things become possible that are otherwise very difficult:

  • Traceability from any implementation decision back to the architectural principle that authorized it
  • Multiple independent implementations that are verifiably consistent with the same abstract architecture
  • Detection of implementations that deviate from the architecture — not by opinion, but by structural comparison
  • Governance of architectural evolution without breaking existing derivations

The theory also proposes that the primary object generated by a derivable architecture may not be its implementations — it may be its decision graph: the structured record of all admissible architectural choices and the paths between them. Implementations are, in that picture, simply the terminal vertices of that graph.

The method

The question DA asks is not “how should we design this system?” It is “what does this system require in order to exist at all?”

The process is one of elimination. Take a proposed architectural concept. Ask whether it can be removed without changing the architectural identity of the system. If it can disappear without consequence, it was not fundamental — it was derived, redundant, or a label for something more basic. If removing it makes the architecture impossible, it is a candidate primitive.

This is repeated across many concepts, many systems, and many domains. Every proposed concept is treated as guilty until proven necessary. What survives becomes part of the architecture. What reduces gets eliminated.

The discipline this requires is unusual. Most architectural work adds concepts to explain observed behavior. This method removes them. The architecture shrinks toward a minimum — the smallest set of concepts that cannot be further reduced without losing something essential.

The result is not a design. It is a discovery.

Core concepts

Architecture — an abstract structural specification that defines identity, admissible relationships, invariants, and derivation constraints. An architecture is independent of any particular realization.

Derivation — an operation that produces one artifact from another while preserving architectural identity. A derivation is constrained: it must follow rules, and those rules must be traceable to the originating architecture.

Identity — the properties preserved across valid derivations. Informally: identity is persistent distinguishability. If something remains distinguishable through persistence, it has identity. That definition strips the concept of philosophical baggage and reduces it to one irreducible criterion.

Constitutional traceability — the property that every artifact, every decision, and every constraint remains permanently associated with the exact architectural context under which it was produced. Twenty years later, the reasoning should still be reconstructable.

Where it has been tested

The methodology has been applied to three cases so far.

The first was the institutional architecture that originated the idea — a constitutional framework spanning multiple legal jurisdictions, with jurisdiction-specific artifacts derived from a stable constitutional core.

The second was an independent validation study against biological systems: the relationship between DNA and the cell. The structural parallel — a stable molecular specification generating constrained biological realizations — was examined in Paper 001 of the validation series.

The third, and most substantial, is MyNumber.is — a canonical number registry system whose entire architecture, from abstract capabilities to concrete service implementations, was derived using DA methodology. A knowledge graph preserves full constitutional traceability across all derivation decisions.

Independent validation studies against TCP/IP and the Linux kernel are planned.

What we do not claim

DA is not a finished theory. The validation program is active and the outcome is not predetermined. The theory may prove to apply broadly, or it may turn out to be a useful methodology for a narrower class of problems. We do not know yet.

What exists today is a coherent methodology, a growing body of evidence that it applies beyond its original domain, and a set of open questions that future cases will either confirm or falsify.

One of those open questions — worth stating explicitly — is whether DA itself constitutes a genuinely new class of phenomenon, or whether it will eventually reduce to something already well understood in mathematics or computer science. We treat that question as an empirical one, not a rhetorical one.

Extraordinary theories deserve extraordinary scrutiny. Derivable Architectures is an invitation to test whether architecture itself can become an empirical science.

Further reading

  • Potential Applications — domains where DA has been applied, is under investigation, or remains an open question
  • MyNumber.is — the most detailed application of the methodology to date
  • Contact — if you have a system that exhibits these properties and want to discuss it