A Minimal Executable Proof for Multi-Language Contract Traceability

Abstract: This paper reports a deliberately small executable proof for a DAG-TOML contract: six "Hello, world!" implementations in Rust, Go, C, Java, TypeScript, and AWK are linked to one observable-output contract, one implementation DAG, one traceability file, one readiness gate, and one evidence matrix. The load-bearing contract requires the exact UTF-8 byte sequence Hello, world!\n, zero stderr bytes, and exit code 0. On the runner used for this paper, the witness harness reported five PASS outcomes, one SKIP for Java because javac/java was not on PATH, and zero FAIL outcomes. Two sidecar witnesses exercise narrower source-analysis claims: a convoluted Go rewrite hides the contiguous greeting literal but remains visible to sqry at the declared AST symbol and simple-edge level, while an indirect AWK rewrite uses a declared source profile because AWK is not in the repository's sqry-backed validator language set. The contribution is not a benchmark, a claim of general semantic equivalence, or a production assurance system. It is a compact, falsifiable artifact that shows how a contract, implementation graph, traceability chain, and review gate can be checked against executable witnesses.

• The paper introduces a minimal artifact demonstrating contract traceability across six programming languages with precise artifact mapping.
• It employs DAG-TOML to structure contract declarations, implementation dependencies, and traceability chains to link claims with evidence.
• Validation outcomes report 5 PASS, 1 SKIP, and detailed source-analysis for Go and AWK, underscoring the artifact's auditability.

Minimal Executable Proof for Multi-Language Contract Traceability

Overview

The paper "A Minimal Executable Proof for Multi-Language Contract Traceability" (2605.28546) introduces a concise, falsifiable artifact demonstrating contract-centered traceability and validation across diverse programming languages. The work centers on a deliberately minimal proof pack encapsulating canonical implementations of a simple output contract ("Hello, world!") in Rust, Go, C, Java, TypeScript, and AWK, with additional source-analysis witnesses for Go and AWK. The artifact employs DAG-TOML to structure contract declarations, implementation relationships, traceability chains, readiness gates, and evidence claims, capturing the workflow from specification to executable validation.

Artifact Organization

The artifact ("proof-bundle") is organized to ensure direct mapping between claims and evidence, adhering to research artifact guidelines. Core files include:

• contract_declaration.toml: Enumerates contract claims (C01–C06).
• implementation_dag.toml: Defines the implementation dependency graph, with nine units (six canonical implementations, two rewrites, and a single verification unit).
• traceability.toml: Describes the intent, requirements, implementation, code, test, and output chains.
• review_readiness.toml and evidence_matrix.toml: Provide review gating and explicit claim-to-evidence mapping.

The proof pack supports six canonical language implementations and two rewritten variants for source-analysis testing. The script harnesses (run_all.sh, detect_semantic_rewrite.sh, detect_awk_rewrite.sh) comprise the executable proof witnesses.

Contract Specification and Witnesses

The load-bearing contract (C01) mandates the exact UTF-8 sequence "Hello, world!", zero bytes to stderr, and exit code 0. Dependent contracts reject terminal markup, BOM prefixes, and enforce ASCII-valid output context. Source-analysis contracts focus on literal hiding (Go) and fallback profile checking (AWK) for languages not supported by the symbol validator.

The Go rewrite demonstrates AST-level visibility despite literal removal, confirming traceability via structural edges and symbol declarations. The AWK rewrite operates under profile-based validation due to a lack of parser or AST tools for AWK. These contracts delineate claim boundaries and non-claims, explicitly avoiding general semantic equivalence, obfuscation resistance, or broad language analysis.

Implementation Graph and Validation Outcomes

The implementation DAG is a fan-in structure: six independent sources converging to a verification unit, which enforces the output contract only for entries with available toolchains. Additional witnesses validate source rewrites. All validators and scripts provide categorical outcomes (PASS, SKIP, FAIL), ensuring transparent auditability.

Reported execution outcomes included 5 PASS (Rust, Go, C, TypeScript, AWK), 1 SKIP (Java due to absent toolchain), and 0 FAIL for primary contract checks. Go and AWK rewrite witnesses also passed. The harness correction (for trailing newline handling) underscores the rigor in distinguishing exact byte-level checks from shell command artifacts.

Claims, Evidence, and Counterexample Boundaries

The claim-audit section directly maps each assertion to its supporting evidence, stressing the importance of direct observation (e.g., artifacts, script outcomes) versus inference. Counterexamples are bounded: missing toolchains produce SKIP, source-analysis contracts provide only narrow guarantees, and artifact completeness does not imply production readiness or scalability.

Related Work

The approach is contextualized against program similarity and clone-detection literature, including token-based and AST-based methods like DECKARD [jiang2007deckard], GumTree [falleri2014gumtree], and robustness analyses [cheers2021robustness], emphasizing the need for transparent claim boundaries in source analysis. Artifact organization leverages current best practices from ACM, POPL, and SIGSOFT for artifact review and empirical standards.

Executable specification framing draws from trace specification methodologies [hoffman1988trace] where formal artifacts are leveraged for both consistency checking and rapid prototyping.

Validity Assessment

Threats to validity are precisely addressed:

• Construct validity: The proof is strictly scoped to contract-checking, avoiding extrapolation to large-scale assurance.
• Internal validity: Script correctness and toolchain dependencies are transparently audited.
• External validity: The artifact is illustrative, not scalable; its method is not demonstrated on complex real-world systems or adversarial contexts.
• Conclusion validity: Outcomes are categorical and non-statistical, with no broader claims about semantic equivalence or legal provenance.

Practical and Theoretical Implications

Practically, the paper demonstrates how review gates, traceability chains, and structured contract checks can be composed in an inspectable, reproducible artifact. Toolchain dependency and unsupported language boundaries are explicit and auditable. Theoretically, the contribution underscores the importance of linking claims, contracts, evidence, and witnesses in artifact evaluation, providing a model for traceability workflows in multi-language environments.

The modular, contractual organization could inform future assurance workflows, agent-based specification pipelines, and review automation, although its scalability, resilience to program obfuscation, and coverage for unsupported languages remain out of scope. The distinction between direct evidence and inferred claims in traceability and source analysis is instructive for empirical methodology in software engineering research.

Limitations and Scope

The paper is precise about its limitations. It does not claim:

• General semantic equivalence across implementations.
• Resistance to arbitrary obfuscation.
• Scalable assurance for industrial workflows or legal provenance.
• Performance, scalability, or statistical precision/recall. Artifact completeness is intentionally limited to a toy multi-language context, with unsupported languages clearly bounded.

Conclusion

This work establishes a minimal, executable proof demonstrating contract traceability and artifact review in a multi-language context. Through explicit contracts, DAG relationships, and categorical validation outcomes, it provides a reproducible, inspectable standard for tying claims to evidence and review gates. While its role is illustrative, not generalizable, the artifact exemplifies the structural, procedural rigor required for contract-centered traceability and transparent artifact evaluation in software engineering research.