---
title: 'Contract-Coding: Executable Contract Engineering'
url: https://www.emergentmind.com/topics/contract-coding
type: topic
---

# Contract-Coding: Executable Contract Engineering

Searching arXiv for the cited paper and closely related work to ground the article in current literature.
Contract-Coding denotes a family of contract-centric programming and code-generation practices in which executable artifacts are required to satisfy not only a functional objective but also an explicit contract. In the recent LLM literature, this term is used most directly for **contract-aware code generation**: training or prompting models so that generated code enforces preconditions, postconditions, and invariants, and rejects ill-formed inputs correctly [2510.12047]. In a second recent usage, Contract-Coding refers to a **structured symbolic paradigm** for repository-scale generation, where ambiguous natural-language intent is projected into a formal “Language Contract” that serves as a Single Source of Truth (SSOT) for parallel implementation [2604.13100]. More broadly, the topic sits within the longer design-by-contract lineage of executable specifications embedded in code, API wrappers, smart-contract DSLs, protocol compilers, and module-level verification systems [1009.3715].

## 1. Terminological scope and historical lineage

In design-by-contract, every software component specifies precisely what it expects and what it guarantees in return. The standard clauses are **preconditions**, **postconditions**, and **object invariants**; in Hoare-style notation, a command \(C\) is characterized by \(\{\,P\,\}\;C\;\{\,Q\,\}\), while invariants constrain every visible object state around public method calls [1009.3715]. Empirical work across Eiffel, C# Code Contracts, and JML projects describes contracts as “lightweight formal specification embedded in the program text,” with routine-level and class-level clauses remaining comparatively stable over time relative to implementation changes [1211.4775].

The contemporary LLM-oriented formulation sharpens this tradition. In PACT, a function contract is the set of validity constraints that govern what inputs must be accepted or rejected and what properties results must satisfy under edge cases. The paper explicitly contrasts this with prevailing evaluation protocols such as pass@k on well-formed inputs, arguing that these benchmarks ignore a crucial aspect of real-world software: ill-formed-input handling and rejection behavior [2510.12047]. By contrast, the repository-scale Contract-Coding paper treats the contract not as a per-function assertion set but as a symbolic mediator between intent and implementation: a formal object that organizes APIs, file naming, and task dependencies before code is emitted [2604.13100].

A common misconception is that “contract” has a single meaning across this literature. The data instead shows several technically distinct usages: software contracts in the design-by-contract sense, smart contracts on blockchain platforms, protocol contracts governing endpoint order, legal or computable contracts tied to controlled language, and interface-specification contracts for embedded C modules. These are not interchangeable, even when they share formal methods vocabulary.

## 2. Formal contract models

PACT defines a contract for a function \(f\) as a set \(A=\{a_1,\dots,a_n\}\) of predicates partitioned into preconditions, postconditions, and invariants. A correct implementation must satisfy two obligations: for every well-formed input \(x\) such that \(\land_i a_i(x)\) holds, \(f(x)\) does not raise an error and produces a valid output; for every \(x\) that violates at least one \(a_i\), \(f(x)\) must raise an assertion or error corresponding exactly to the violated predicate(s). Each assertion is written as
$$
\texttt{assert }a_i(x)\,,\quad i\in\{1,\dots,n\}\,.
$$
A contract-violating test case \(t\) is an input for which
$$
F_t \;=\;\{\,a_i\mid a_i \text{ fails on }t\}\;\neq\;\emptyset
$$
while all non-violated predicates remain true [2510.12047].

Classical design-by-contract formalizes similar obligations with method-entry, method-exit, and object-state properties. In the .NET Code Contracts realization, `Contract.Requires(P)` encodes a precondition, `Contract.Ensures(Q)` a postcondition, and `Contract.Invariant(I)` an invariant written inside `ObjectInvariant`; runtime checking compiles these into ordinary if-throw sequences, while static analysis via Clousot attempts to prove them at call sites and exits [1009.3715]. This suggests a continuity between older contract systems and newer contract-aware code generation: both treat contracts as executable specifications, but the newer work additionally treats them as promptable and measurable targets for synthesis.

Recent repository-scale Contract-Coding adopts a different formal object. Its Language Contract is
$$
\mathcal{C} = (\Sigma, \mathcal{N}, \Delta)
$$
where \(\Sigma\) is a symbol alphabet of API signatures and type names, \(\mathcal{N}\) is a naming map from functional module names to file paths, and \(\Delta\) is a directed acyclic graph whose nodes are tasks and whose edges encode “must-precede” relations. Validity is tied to kernel extraction and acyclicity, and the contract is intended to mediate between high-level intent \(\mathcal{I}\) and repository implementation \(\mathcal{R}\) [2604.13100]. Here the contract is not merely a set of assertions over data values; it is an architectural object.

## 3. PACT and contract-adherent code generation

PACT introduces a two-phase framework for evaluating and improving contract adherence in LLM-generated code [2510.12047]. The first module generates **Contract-Violating Tests (CVTs)** by translating natural-language contracts into a small ADT schema, emitting SMT-LIB definitions for each predicate \(a_i\), and then asking an SMT solver such as Z3 for satisfying models that violate exactly selected non-empty subsets \(S\subseteq A\). The second module evaluates code generation under two prompting strategies: **Contract Specification (CS)**, which injects natural-language contract statements into the prompt, and **Example-Augmented Specification (EAS)**, which appends one or more CVTs as concrete invalid-input examples.

The resulting corpus extends HumanEval+ and MBPP+. Starting from 164 HumanEval+ tasks and 131 MBPP+ tasks, PACT reports a total of 295 tasks and approximately 1,150 CVTs, with an average of 3.9 CVTs per task. For each task with \(n\) contracts, the framework can in principle produce up to \(2^n-1\) distinct CVTs, although the final suites are compact and average 3–4 CVTs per task.

PACT also introduces explicit metrics for both test generation and code generation.

| Metric | Role | Definition |
|---|---|---|
| AVC | Test/code | Fraction of ground-truth contracts covered by at least one violating test |
| TS | Test | Average Jaccard alignment between intended and actual violations |
| AAR | Code | Fraction of true contracts implemented |
| AAP | Code | Fraction of generated assertions matching a true contract |

For test generation, **Assert Violation Coverage (AVC)** is
$$
AVC \;=\;\frac{\bigl|\{\,a_i\mid\exists t\in T_{neg}:a_i\in F_t\}\bigr|}{n}\,,
$$
and **Target Specificity (TS)** is the average Jaccard alignment between intended violations \(V_t\) and actual violated assertions \(F_t\). For code generation, with true contracts \(A=\{a_1,\dots,a_n\}\), generated assertions \(\hat A=\{\hat a_1,\dots,\hat a_m\}\), and semantic-equivalence relation \(M\subseteq A\times \hat A\), **Assertion Alignment Recall (AAR)** measures the fraction of true contracts implemented and **Assertion Alignment Precision (AAP)** measures the fraction of generated assertions that match a true contract. AVC is also reused dynamically to measure how many generated assertions actually fail the CVTs.

The experimental setup uses HumanEval+ and MBPP+, evaluates Phi-4-reasoning-plus, Gemma-3, DeepSeek, and Qwen-3, and reports pass@1 on valid tests together with dynamic AVC and static AAR/AAP. In CVT generation, the SMT step substantially improves targeted-violation precision: for HumanEval+, TS rises from 75.6% to 85.8%, and for MBPP+ from 69.1% to 84.5%, while AVC remains high. In code generation, EAS compared with CS yields on average **+33.7 pt AVC, +11.3 pt AAR, +9.4 pt AAP, and +12.8 pt aggregate “AVG” score**, with a mild **pass@1** drop of **−1.5 to −5 pt** due to added complexity. Qualitatively, prompts without CVTs often omit type checks or numeric-range assertions, whereas EAS more often elicits assertions such as `assert isinstance(x,int)` or `assert len(s)>0`, though sometimes with over-specialization and minor logical errors. The central result is therefore not that contracts are free, but that explicit invalid-input exemplars materially change what models implement.

## 4. Contract-Coding at repository scale

The 2026 paper titled “Contract-Coding” extends the contract idea from snippet-level input validation to repository-scale synthesis [2604.13100]. Its starting point is the **Context-Fidelity Trade-off** in intent-driven or “vibe” software engineering: if a system insists on high fidelity to an under-specified natural-language intent \(\mathcal{I}\), ambiguity remains intractable; if it expands context by eagerly generating concrete code, prompt windows fill with semantically noisy implementation details. The paper formalizes direct repository synthesis as
$$
P(\mathcal{R}\mid \mathcal{I}) = \prod_n P(f_n \mid f_{<n}, \mathcal{I}),
$$
and argues that this induces sequential error propagation and context exhaustion.

The proposed remedy is a symbolic mediator. A Language Contract \(\mathcal{C}=(\Sigma,\mathcal{N},\Delta)\) is formed by **Constraint Projection** from natural language and **Kernel Extraction** into strict API signatures and a task dependency graph. Grounding proceeds by discrete symbolic evolution: a GeneratorAgent proposes `Add` or `Update` mutations, an acyclicity and type-safety check rejects illegal mutations, and an Auditor plus DiscriminatorAgent performs rectification if needed. The paper states a theorem of **Implementation Independence**:
$$
P(f_i \mid \mathcal{R}_{\neq i}, \mathcal{C}) = P(f_i \mid \mathcal{C}),
$$
from which it derives decoupled execution and architectural parallelism. In a sequential chain, topological depth is \(N\); in the contract-driven DAG, depth is the longest path \(D\ll N\), with maximum parallelism \(N/D\).

Empirically, the work evaluates on Greenfield-5, a benchmark of five open-ended game-engine tasks ranging from 4–6 files to 15–25 files. On Roguelike, Contract-Coding reports **Overall Success \(0.47 \pm 0.15\)** and **Structural Integrity \(1.00 \pm 0.00\)**, while the best baseline (Gemini) reports **\(0.63 \pm 0.12\)** overall success and **\(0.80 \pm 0.18\)** structural integrity; the reported two-tailed \(\chi^2\) test gives **\(p\approx 0.07\)**. The failure analysis is also distinctive: legacy agents exhibit “Hollow Skeleton,” “Reflection–Action Gap,” “Aggregator Collapse,” and “Probabilistic Drift,” whereas Contract-Coding failures are described primarily as local logic bugs with perfect architecture. A plausible implication is that, at repository scale, contracts may improve structural integrity even when end-to-end functional success remains lower than the strongest baseline.

## 5. Adjacent contract-centric paradigms

The broader literature contains several adjacent systems in which contracts or contract-like structures guide generation, enforcement, or verification.

| System | Domain | Salient mechanism |
|---|---|---|
| SmartCoder-R1 | Solidity generation | Security-aware RL with compilation, security, and format rewards |
| SolContractEval | Solidity evaluation | Contract-level benchmark with historical transaction replay |
| FSM-SCG | Solidity generation | Requirement \(\rightarrow\) FSM \(\rightarrow\) code with compilation and Slither feedback |
| SmartScribble | Plutus generation | Protocol language compiled to a state-machine-enforced contract |
| Ergo | Smart legal contracts | Strongly typed DSL with a Coq-based compiler |
| HCC | Smart-contract hardening | Source-to-source compiler over a code property graph |

For Solidity generation, SmartCoder-R1 combines continual pre-training on 286,397 Solidity files, long chain-of-thought supervised fine-tuning on 7,998 expert-validated reasoning-and-code samples, and Security-Aware Group Relative Policy Optimization with weighted rewards for compilation success, security compliance, and format correctness. On 756 real-world functions, it reports **ComPass 87.70%**, **VulRate 8.60%**, **SafeAval 80.16%**, **FuncRate 53.84%**, and **FullRate 50.53%**, with the latter described as a **45.79% relative improvement** over DeepSeek-R1 [2509.09942]. FSM-SCG instead abstracts requirements into a finite state machine \(M=(Q,\Sigma,\delta,q_0,F)\), validates reachability and no-self-loop properties, generates Solidity from the FSM, and iteratively repairs it using Py-solc-x and Slither feedback; on Llama3.1-8B it reports **CPR 95.1%** and **VRS 2.36**, compared with **47.5%** and **6.36** for the best prior baseline [2505.08542].

For evaluation, SolContractEval argues that function-level, synthetic-input testing is insufficient for real-world Solidity development. It builds 124 tasks from real verified contracts, supplies complete context dependencies and skeletons with blank function bodies, and defines correctness by replaying the first \(m=1{,}000\) on-chain transactions against both original and generated contracts, matching transaction status, return values, event logs, and post-state storage [2509.23824]. This benchmark reports **Compile@1 85.5** and **Pass@1 40.7** for Claude-3.7-sonnet, and shows that models do relatively well on standard ERC20 patterns but degrade on ERC721 complexity, DeFi syntax fragility, and inter-contract dependencies.

Protocol- and legal-contract systems further broaden the meaning of contract-centric coding. SmartScribble compiles a protocol description into a Plutus contract backed by a finite-state machine and reports a **75% decrease in the size of the code that developers must write**, with generated contracts rejecting out-of-order endpoint sequences on-chain [2108.02672]. Ergo is a smart legal contract DSL built in the Accord Project stack, with strong typing, functional purity of clauses, bounded iteration, and a Coq-based compiler targeting JavaScript, Java, or WebAssembly [2112.07064]. The survey on computable contracts presents the CNL/DSL \(\rightarrow\) intermediate language \(\rightarrow\) bytecode methodology and treats the contract text as the single source for legal prose, formal semantics, and executable code [2104.03764]. Related model-driven approaches include EROP, which compiles Events, Rights, Obligations, and Prohibitions into Drools rules [2303.01595], and BPMN+DMN transformation via TABS, where a business analyst can generate Solidity contracts from process and decision models, including nested transactions and repair/upgrade support [2505.22612].

Hardening and verification systems operate after generation rather than during it. HCC is a language-independent hardening contract compiler based on a code property graph that inserts source-level guards against reentrancy, integer bugs, suicidal contracts, `tx.origin` misuse, untrusted `delegatecall`, and unchecked low-level calls; on 10,000 real-world Solidity contracts it reports preventing **100%** of replayed real-world integer and reentrancy exploits while preserving **99.99%** success on replayed transactions for top high-value contracts [2203.00364]. For embedded C, interface-specification contracts express allowed entry points, allowed external calls, call ordering, and initialization rules, and are checked by the VerNFR Frama-C plugin alongside ACSL function contracts [2605.21532]. This suggests that contract-based coding now spans the full spectrum from prompt engineering and RL objectives to static analysis, runtime enforcement, and module-level non-functional verification.

## 6. Evaluation criteria, misconceptions, and practical directions

A recurring theme across the literature is that **functional correctness alone is not an adequate proxy for contractual correctness**. PACT explicitly criticizes benchmarks that evaluate only with pass@k on well-formed inputs, while SolContractEval argues that compilation alone misses semantic drift in return values, events, and storage [2510.12047; 2509.23824]. A related misconception is that adding more specification text is sufficient. PACT’s results instead show that **Example-Augmented Specification**, using concrete contract-violating examples, improves contract adherence more than contract description alone, even though pure functional pass@1 may decline slightly.

Another misconception is that contracts are primarily documentation. The empirical design-by-contract literature shows that executable contracts are common enough to persist across large projects, with a median percentage of routines with pre- or postconditions around **40%**, class invariants around **30%**, and code-only changes vastly outnumbering code-plus-contract changes [1211.4775]. The Facebook API case study similarly reports preconditions on **56 out of 66 public methods**, **69%** of parameters contracted, and **eight real bugs** caught during development, including one bug in the contracts themselves [1009.3715]. These findings support a narrower but stronger claim: contract clauses are part of the operational software artifact, not merely commentary.

The open trade-offs are also consistent across papers. Stronger contract enforcement can slightly harm pure functional accuracy in code generation; symbolic mediation can preserve architecture while still leaving local logic bugs; and security-aware or FSM-guided generation can raise compilation success and reduce vulnerability risk without eliminating the need for replay tests, static analyzers, or manual review. The practical guidance repeated in the sources is correspondingly concrete: formalize contracts explicitly, generate targeted negative tests, measure both static and dynamic adherence, verify context dependencies and event behavior, use state-machine or typed-DSL structure when interaction order matters, and integrate contract-aware checks into CI and verification toolchains [2510.12047; 2505.08542; 2509.23824].

Taken together, the literature presents Contract-Coding not as a single technique but as a contract-first orientation to synthesis and verification. In the narrow LLM setting, it means generating code that respects validity constraints and rejects ill-formed inputs. In the repository-scale symbolic setting, it means grounding intent in an auditable SSOT before implementation. In adjacent smart-contract, legal-contract, protocol, and embedded-systems work, it means encoding obligations, permissions, interfaces, or state-machine orderings into artifacts that can be compiled, checked, replayed, or enforced. The unifying principle is that executable systems are made more robust when their admissible behaviors are represented explicitly and evaluated as first-class objects rather than left implicit in prose or latent in examples.

Source: https://www.emergentmind.com/topics/contract-coding