[Paper] A Minimal Executable Proof for Multi-Language Contract Traceability

Source: arXiv - 2605.28546v1

Overview

Werner Kasselman’s paper presents a tiny, fully‑executable proof‑of‑concept that demonstrates end‑to‑end traceability for a simple “Hello, world!” contract across six programming languages (Rust, Go, C, Java, TypeScript, and AWK). By wiring each implementation to a single observable contract, a dependency graph, a traceability file, a readiness gate, and an evidence matrix, the work shows how automated checks can verify that every artifact truly satisfies the contract—without claiming to be a production‑grade assurance system.

Key Contributions

• Minimal multi‑language artifact: Six distinct “Hello, world!” programs linked to a single contract.
• Executable contract definition: The contract is a concrete observable (exact UTF‑8 output Hello, world!\n, no stderr, exit code 0).
• Implementation DAG & traceability file: A directed‑acyclic graph (DAG) captures the relationships among source files, build steps, and the contract.
• Readiness gate & evidence matrix: Automated checks that gate promotion of the artifact based on test outcomes and generate a machine‑readable evidence report.
• Side‑car witnesses: Two additional validators illustrate how source‑analysis tools (e.g., sqry) can still locate the greeting literal even after code transformations.
• Open, falsifiable artifact: The entire setup can be cloned, run, and broken (e.g., by changing the output), making it a reproducible demonstration rather than a benchmark.

Methodology

1. Define a concrete contract – expressed as a witness harness that runs a program, captures its stdout, stderr, and exit code, and checks them against the expected values.
2. Create implementations – six tiny programs, each in a different language, emit the exact contract output.
3. Build an implementation DAG – nodes represent source files or build steps; edges encode “depends‑on” relationships (e.g., go build depends on main.go).
4. Generate a traceability file – a JSON/YAML manifest maps each node in the DAG to the contract it satisfies.
5. Run the readiness gate – an automated script iterates over the DAG, executes each implementation, and records PASS/SKIP/FAIL outcomes.
6. Produce an evidence matrix – the gate emits a concise table (the “evidence matrix”) that can be consumed by downstream CI/CD or audit tools.
7. Add side‑car witnesses – two extra checks use static‑analysis queries (sqry) to verify that the greeting literal is still discoverable even after code refactoring (Go) or when the language is unsupported by the validator (AWK).

All steps are scripted with standard tooling (shell, make, language‑specific compilers/interpreters) and can be executed on a typical developer workstation.

Results & Findings

Side‑car witnesses confirmed that:

• The Go version, despite a “convoluted rewrite” that hides the literal in the source text, still exposed the greeting at the AST level, allowing the query to succeed.
• The AWK version, though not part of the validator’s language whitelist, could be linked to a declared source profile, showing that traceability can be extended via metadata.

These results prove that a compact, reproducible artifact can enforce a contract across heterogeneous codebases, and that the traceability chain remains intact even when source transformations occur.

Practical Implications

• Cross‑language compliance checks – Teams maintaining polyglot services can adopt a similar lightweight contract + DAG approach to guarantee that every language implementation adheres to a shared API or output contract.
• CI/CD gate integration – The readiness gate can be plugged into existing pipelines (GitHub Actions, Jenkins, GitLab CI) to automatically block merges when any implementation fails the contract.
• Audit‑ready evidence – The generated evidence matrix provides a machine‑readable proof that can satisfy regulatory or internal compliance audits without manual sign‑offs.
• Rapid prototyping of traceability frameworks – Because the artifact is minimal, developers can experiment with different graph representations, metadata formats, or static‑analysis back‑ends before scaling to larger codebases.
• Educational tool – New hires or students can clone the repo, break the contract (e.g., change the output string), and see the gate fail, gaining hands‑on experience with reproducible software assurance concepts.

Limitations & Future Work

• Scope limited to a trivial contract – The proof uses a single static string; real‑world contracts often involve complex schemas, network interactions, or nondeterministic behavior.
• Environment dependencies – The Java implementation was skipped due to missing tooling on the runner; a production setup would need robust environment provisioning (Docker images, toolchains).
• Validator language coverage – The static‑analysis side‑car only supports a subset of languages; extending sqry or similar tools to cover more ecosystems is an open challenge.
• Scalability – The current DAG and traceability file are handcrafted; future work could explore automated generation from build systems (Bazel, Gradle) and handling of large dependency graphs.
• Security & sandboxing – Running arbitrary implementations as part of a gate raises security concerns; integrating sandboxed execution (e.g., Firecracker, gVisor) would be necessary for broader adoption.

Addressing these points could evolve the minimal executable proof into a robust, language‑agnostic framework for contract‑driven development and continuous assurance.

Authors

• Werner Kasselman

Paper Information

• arXiv ID: 2605.28546v1
• Categories: cs.SE
• Published: May 27, 2026
• PDF: Download PDF