Contract-Coding: Executable Contract Engineering

• Contract-Coding is defined as embedding formal contracts—preconditions, postconditions, and invariants—into code to enforce operational correctness and robustness.
• It is applied in LLM-based contract-aware code generation and repository-scale synthesis, where contracts guide negative testing and architectural decisions.
• Empirical studies show that augmenting code prompts with contract-violating tests and language contracts improves test precision and maintains structural integrity.

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 (Lim et al., 14 Oct 2025). 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 (Lin et al., 10 Apr 2026). 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 (Rubinger et al., 2010).

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 (Rubinger et al., 2010). 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 (Estler et al., 2012).

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 (Lim et al., 14 Oct 2025). 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 (Lin et al., 10 Apr 2026).

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

$\{\,P\,\}\;C\;\{\,Q\,\}$0

A contract-violating test case $\{\,P\,\}\;C\;\{\,Q\,\}$1 is an input for which

$\{\,P\,\}\;C\;\{\,Q\,\}$2

while all non-violated predicates remain true (Lim et al., 14 Oct 2025).

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 (Rubinger et al., 2010). 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

$\{\,P\,\}\;C\;\{\,Q\,\}$3

where $\{\,P\,\}\;C\;\{\,Q\,\}$4 is a symbol alphabet of API signatures and type names, $\{\,P\,\}\;C\;\{\,Q\,\}$5 is a naming map from functional module names to file paths, and $\{\,P\,\}\;C\;\{\,Q\,\}$6 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 $\{\,P\,\}\;C\;\{\,Q\,\}$7 and repository implementation $\{\,P\,\}\;C\;\{\,Q\,\}$8 (Lin et al., 10 Apr 2026). 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 (Lim et al., 14 Oct 2025). 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 $\{\,P\,\}\;C\;\{\,Q\,\}$9, and then asking an SMT solver such as Z3 for satisfying models that violate exactly selected non-empty subsets $f$0. 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 $f$1 contracts, the framework can in principle produce up to $f$2 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

$f$3

and Target Specificity (TS) is the average Jaccard alignment between intended violations $f$4 and actual violated assertions $f$5. For code generation, with true contracts $f$6, generated assertions $f$7, and semantic-equivalence relation $f$8, 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 (Lin et al., 10 Apr 2026). 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 $f$9, 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

$A=\{a_1,\dots,a_n\}$0

and argues that this induces sequential error propagation and context exhaustion.

The proposed remedy is a symbolic mediator. A Language Contract $A=\{a_1,\dots,a_n\}$1 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:

$A=\{a_1,\dots,a_n\}$2

from which it derives decoupled execution and architectural parallelism. In a sequential chain, topological depth is $A=\{a_1,\dots,a_n\}$3; in the contract-driven DAG, depth is the longest path $A=\{a_1,\dots,a_n\}$4, with maximum parallelism $A=\{a_1,\dots,a_n\}$5.

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 $A=\{a_1,\dots,a_n\}$6 and Structural Integrity $A=\{a_1,\dots,a_n\}$7, while the best baseline (Gemini) reports $A=\{a_1,\dots,a_n\}$8 overall success and $A=\{a_1,\dots,a_n\}$9 structural integrity; the reported two-tailed $x$0 test gives $x$1. 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 $x$2 FSM $x$3 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 (Yu et al., 12 Sep 2025). FSM-SCG instead abstracts requirements into a finite state machine $x$4, 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 (Luo et al., 13 May 2025).

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 $x$5 on-chain transactions against both original and generated contracts, matching transaction status, return values, event logs, and post-state storage (Ye et al., 28 Sep 2025). 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 (Falcão et al., 2021). 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 (Roche et al., 2021). The survey on computable contracts presents the CNL/DSL $x$6 intermediate language $x$7 bytecode methodology and treats the contract text as the single source for legal prose, formal semantics, and executable code (Clack, 2021). Related model-driven approaches include EROP, which compiles Events, Rights, Obligations, and Prohibitions into Drools rules (Delchev et al., 2023), 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 (Liu et al., 28 May 2025).

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 (Giesen et al., 2022). 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 (Amilon et al., 19 May 2026). 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 (Lim et al., 14 Oct 2025, Ye et al., 28 Sep 2025). 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 (Estler et al., 2012). 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 (Rubinger et al., 2010). 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 (Lim et al., 14 Oct 2025, Luo et al., 13 May 2025, Ye et al., 28 Sep 2025).

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.