The Contract Is the Asset

Every engagement produces two deliverables: a working application, and a machine-readable contract a future team could use to understand, verify, and carry that application forward, even if that team replaces us. We hand over both.

This paper is about why the second deliverable may be the more durable asset, and what a buyer of business software should now demand from anyone they pay for it, including us. The contract we mean is not the legal document. It is a set of files: a human-readable specification of everything the system does, a machine-readable twin that validators can check, and a verification record connecting both to the running code. Our clients ratify it at every gate during the build, and it leaves with them when the engagement ends.

For most of the history of enterprise software, that sentence would have been aspirational at best. What changed is worth a CTO’s attention, not because AI wrote the code, but because of what AI did to the economics of everything around the code.

Ask what a buyer actually holds under each of the three ways to get business software, and the honest answer is a spectrum:

The middle column deserves a fair reading, because it is not the result of bad vendors. Legal ownership of code has often provided less operational control than buyers expected (you owned every line and still couldn’t safely change one) because keeping a specification current was pure human discipline pushing against economic gravity. Unenforced discipline decays fast: when Anthropic measured it on its own internal analytics documentation, curation accuracy fell from 95% to 65% within a month, until keeping the documentation current became a mechanical merge gate rather than a habit [Controlled AI, §3]. The industries that kept specs alive anyway, including aviation, medical devices, and the regulated world, prove the point from the other side: they maintained requirements traceability and living specifications for decades by spending what only they could justify. Everyone else, rationally, stopped pretending.

So the interesting question was never “SaaS or custom?” It is: what do I hold when the engagement ends? That question finally has a good answer at mid-market prices, and the rest of this paper is about what the answer looks like.

AI did not invent specifications, traceability, or enforceable documentation. Three economic shifts made them central.

Code stopped being scarce. Generation sharply reduced the cost of producing and re-producing implementation. When the expensive artifact gets cheap, durable value migrates to what stays scarce: ratified intent, and the means to verify code against it.

Generation demands a governing artifact anyway. The research record on ungoverned AI-assisted development shows recurring failures in specification, requirements elicitation, and self-assessment, in our reading precisely the gap a ratified specification exists to fill. We walked that evidence in our previous paper and won’t re-argue it here. What matters for this paper is the form the governing artifact must take: machine-checkable. In the largest study of its kind, natural-language comments beside a formal specification added nothing to generation quality; the formal artifact carried all the signal [Vericoding]. Architecture documents and explicit plans supplied as first-class input measurably improved conformance and correctness [Cervantes, Kazman & Cai]. In other words: to build well with AI at all, you must produce exactly the artifact that ownership always needed. The spec you need for governance is the asset. You get it as a by-product of doing the job right.

Re-running checks became nearly free. What killed spec currency outside regulated industries was the recurring cost of verification: human hours, again and again. The marginal cost of re-running mechanical consistency checks is now near zero: schema validation, type checks, traceability audits, behavioral test suites. Authoring those checks, designing what they should assert, and ratifying the intent behind them is real work; that work is precisely what you’re paying for. But keeping them running costs very little per run, which means the spec can stay structurally current by construction instead of by discipline.

Here is what that looks like concretely, in the pipeline we run. An RFP line becomes a numbered requirement in a requirement inventory. Every task in the build plan carries the requirement IDs it serves. Every contract artifact (endpoint, data model, or workflow) carries the requirement IDs it satisfies. Validators reject the build plan if an active requirement has no task, and reject the contracts if coverage is broken. At the end, a quality review audits requirement coverage against the delivered code and publishes the verdict. Every declared link in that chain is mechanically checked for presence and coverage; the meaning of each link is ratified by humans. None of it survives by anyone’s memory.

Precision matters here, so let us be exact about what each layer establishes:

The fourth row is the one an honest vendor must say out loud: no machine proves that the contract captures your real intent. That is why our clients ratify the contract at gates during the build, while the artifacts are small and the decisions are fresh, rather than discovering intent gaps at acceptance. It is the same conclusion the broader evidence reaches: put human judgment up front on intent, and machines behind on verification [Controlled AI]. No layer asks you to take more on faith than its artifacts demonstrate, and the one property machines can’t prove is placed in your hands, not ours.

A portability promise is only as strong as its inventory, so here is ours:

Stated honestly: the bundle specifies behavior, boundaries, and verification, not every implementation tradeoff in a developer’s head. That is why the claim is “continue or reimplement from it,” and why the claim is scoped to the bundle.

Rather than ask you to take any of this on faith, here is what the artifacts actually look like, using fragments from a real build: a multi-location fitness-studio management platform (48 data shapes, 30 endpoints, 18 invariants in the full contract). It is one of our validation builds, which we ran ourselves to exercise and prove the pipeline end to end. That is exactly why it can be the example: it is ours to publish in full, down to the last finding, which we could never do with a client’s system. First, one entity from the human-readable contract:

Second, two lines from the same build’s verification record, showing adversarial findings and their dispositions:

And because this paper’s signature claim is the chain itself, here is one requirement’s complete journey through it, from the same build:

Notice two things. First, what the record admits: the adversarial review found real defects (the trace above contains one), and the record shows them, with their fixes, permanently. A verification record with nothing to disposition would be a verification record that wasn’t looking. Second, what the trace demonstrates: this chain is not bookkeeping. The requirement was contracted, including its edge case through a documented assumption; the first implementation left that no-show rule unreachable; the chain caught it before delivery; and the repair is part of the permanent record. That is traceability working as a control system. The full example bundle (contract, inventory, reports, and tools) is available on request.

All of this compresses into one question you can ask every software vendor you pay, whether SaaS or services, in any renewal or procurement conversation:

There are three honest answers today. A SaaS vendor’s answer: your data, in export formats of varying kindness, plus the configuration and integration knowledge your team has accumulated; the operating dependency is well understood even though the code never was. A traditional custom shop’s answer: the code, plus whatever documentation survived contact with the schedule. A contract-governed answer: the full source code and the running system it builds, the ratified specification, and the verification record showing exactly what was checked against it.

Every one of these is a legitimate trade at the right price. The point is not that two of the answers are shameful; the point is knowing which trade you are making before you are five years in.

Our own answer, for the record: our clients hold the bundle, including the contract, code, verification record, and change history, unencumbered by any claim of ours. (The code’s open-source dependencies keep their own licenses, as everywhere.) The methodology that produced it stays with us; the factory doesn’t ship, the product and its blueprint do. The boundary is simple to state: tools required to verify ship with the bundle; tools required to generate do not. That is the trade, in the open. We think retention should be earned by the next engagement being obviously worth it, not by the cost of the door, and a market where buyers ask this question is a market where good vendors win. Which is exactly why we are teaching you to ask it.

None of this is an argument against SaaS. Rent-versus-own is a portfolio decision, and renting is often right: payroll, email, and CRM at standard fit, meaning workflows you share with every other company, belong with vendors who amortize them across thousands of customers.

What changed is the own side of the menu. The workflows that are actually your business, such as the approval process you’ve bent a SaaS product around for years or the operations logic living in spreadsheets because custom software was never economical at your scale, can now be owned outright, spec and all, at a cost that puts the comparison on the table for mid-market companies, not just for banks and airlines. The full economics deserve their own treatment; here it is enough to say the door now exists.

Rent the workflows you share with everyone; own the ones that make you you. When you own, own the spec.

Our firm’s tagline is “Contract-Governed AI: built to be changed,” and we mean the second half as a description of files, not a feeling. A ratified, structurally current, machine-checked description of your system, one that belongs to you, that any competent team can carry forward, and whose claims each name what stands behind them, including the one that rests on your judgment rather than ours, is what “built to be changed” physically looks like. The contract governance is what keeps it true after every change.

Start with the question. Ask it of the next vendor who wants your renewal and the next firm that bids on your build. Ask it of us: if we parted ways tomorrow, what exactly would I hold? The vendors worth keeping will love answering it.