Compatibility Through Connectivity: Testing Across Artifact Types

The companion to the cornerstone: compatibility as a measurement, not a declaration.

Why it is here

Written the same day as Thinking in Graphs and declaring a dependency on it, this is the thesis pushed to a working conclusion. An architect writes prose, a developer writes code, a runtime produces traces: these are different languages for what should be the same truth, and the question worth asking is not does the code work but does the system work the way the architect thinks it works. Compatibility becomes something you compute by comparing the graphs extracted from each representation, which is where this site's compatibility is computed, not declared comes from.

What it says

• Compatibility is measured by comparing graphs extracted from different representations of the same system.
• The question is not whether the code works, but whether all representations agree.
• Two types of test: within a representation, and across representations.
• Five layers, from prose to runtime trace, each yielding a graph.
• Compatibility is a spectrum with an assessment, not a boolean anyone declares.

Worth re-reading for. Part 7 extends meaning through connectivity beyond where the cornerstone leaves it. It is the half of the thesis this book has argued least.

Where this document lands on the site

The document is the peak. Below it hang the concepts measured in its text and the places on this site that rest on it — and the two are different kinds of link, drawn differently: a measured edge is dashed and carries its count, an authored edge is solid. The method is stated in full on the hub.

Read it