The contract is the control
By the time someone writes the first line of code, most of the decisions that will determine whether a public system serves people have already been made — in the contract.
It's tempting to treat procurement as paperwork: a scope, a price, a timeline, some boilerplate to get past on the way to the real work. But for public-interest technology, the contract is the real work. It is the one moment when an agency has maximum leverage and the vendor has to write down what it will actually be held to. Everything after that is either enforcing those terms or wishing you'd written better ones.
The decisions hide in the paperwork
Who owns the data the system collects? Can the agency inspect and audit how it works, or only see the output? What happens when it fails — who is notified, how fast, and who pays to fix it? Can the vendor swap the underlying model or change a threshold without telling anyone? Is the agency free to leave, with its data, or quietly locked in?
None of these are engineering details to be discovered later. They are choices, and they are made — explicitly or by omission — the moment the contract is signed. A protection that isn't in the agreement is a protection you're hoping for, not one you have.
What a public-interest contract asks for
The specifics vary, but the spine is consistent. A contract written to serve the public should secure, at minimum:
- Data ownership and portability — the public body owns its data and can take it and leave.
- A right to inspect and test — access to audit logs and the ability to evaluate the system, not just trust the demo.
- Scope limits on permissions and data use — the vendor gets only what the task requires, and no license to repurpose it.
- Incident notification timelines — defined obligations for what gets reported, to whom, and how quickly.
- Change transparency — no silent swaps of the model or logic behind a consequential decision.
- Exit rights — a clean, affordable way out, so a bad system can be replaced rather than endured.
Buy the guarantees, not the promises
A demo proves a system can work once, under conditions the vendor chose. A contract is what holds when conditions are not ideal — when the system is wrong, when the vendor is acquired, when the person who understood the deal has moved on. That is why the protections belong in enforceable terms, not in the aspirational prose of a statement of work that no one can hold anyone to.
A promise you can't enforce is a decision you've handed to someone else.
We help public agencies write procurement that encodes the public interest before the build begins — because the cheapest, most durable place to fix a public system is the contract, long before it ever reaches a courtroom or a headline.