💻 computer science

A Minimal Executable Proof for Multi-Language Contract Traceability

This paper presents a minimal, falsifiable executable proof demonstrating how a multi-language contract, implementation graph, traceability chain, and review gate can be validated through six "Hello, world!" programs in different languages, yielding five successful pass outcomes and one skip due to missing tooling.

Original authors: Werner Kasselman

Published 2026-05-28

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Werner Kasselman

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are a judge in a very strict courtroom. You have a single, tiny rule for a game: "Say 'Hello, world!' exactly as written, with no extra noise, and stop immediately."

This paper is not a grand theory about how to build the whole legal system of software. Instead, it is a deliberately tiny, self-contained proof showing that we can build a "courtroom" where we can check if different people (writing in different languages) followed that one simple rule.

Here is how the paper breaks down, using everyday analogies:

1. The "Contract" (The Rulebook)

The authors created a digital rulebook called a Contract.

The Rule: The computer program must print the exact letters Hello, world! followed by a "new line" (like hitting Enter). It cannot print anything to the "error" channel (no shouting), and it must finish with a "0" (a perfect score).
The Analogy: Think of this like a baking contest where the only rule is: "The cake must be exactly 10 inches wide." If it's 10.1 inches, or if it's burnt, you lose.

2. The "Witnesses" (The Testers)

To prove the rule was followed, the paper uses Witnesses. These are automated scripts (little robots) that check the work.

The Main Witness: It runs six different versions of the program written in six different languages (Rust, Go, C, Java, TypeScript, and AWK).
The Result: Five of them passed perfectly. One (Java) was marked "SKIP" because the judge didn't have the right tools (a Java compiler) on their desk to check it. It wasn't a failure; the test just couldn't happen.
The Analogy: Imagine a taste-tester trying six different cakes. Five taste exactly right. The sixth one is in a box they can't open, so they mark it "Not Tested" rather than "Bad."

3. The "DAG" (The Family Tree)

The paper uses a structure called a DAG (Directed Acyclic Graph).

The Concept: Imagine a family tree. You have the "Grandparents" (the source code files), and they all feed into a "Parent" (the verification step).
The Point: This map shows exactly which code file led to which test result. It proves that the test didn't just happen by magic; it was a direct, traceable result of specific code.

4. The "Rewrites" (The Magic Tricks)

The paper also tests if the system can spot when someone tries to "hide" the rule.

The Go Trick: One programmer wrote the "Hello, world!" message in a very complicated, twisted way (like writing a secret code). The paper claims the system can still see the "skeleton" of the code (the function names) even if the "meat" (the literal text) is hidden.
The AWK Trick: Another language (AWK) wasn't on the official list of languages the system usually understands. So, the authors created a special "fallback" checklist just for it.
The Analogy: It's like a detective who can tell that a suspect is wearing a disguise (the twisted code) but can still recognize their height and shoe size (the code structure). For the language the detective doesn't know, they just use a simpler checklist.

5. What This Paper is NOT (The "Non-Claims")

This is the most important part. The authors are very careful to say what they are not doing:

It is not a benchmark: They aren't saying their system is the fastest or the best.
It is not a guarantee for the real world: They are not claiming this system can catch every hacker or fix every bug in a massive bank.
It is not about "Meaning": They aren't proving that two complex programs mean the same thing. They are only proving that for this tiny example, the rules were followed.

The Bottom Line

Think of this paper as a blueprint for a single, perfect brick.

The authors aren't trying to build a skyscraper yet. They are saying: "Look, we built one tiny brick. We have a map of how it was made, a list of the tools used, and a witness that confirms it meets the size requirement. If you have the same tools, you can build the exact same brick and see the same result."

The goal is to show that transparency is possible: you can trace a claim (we followed the rule) all the way back to the specific code and the specific test that proved it.