Picture a service agreement, invented for this example, between a mid-sized company and an IT provider. It runs for two years and renews automatically unless notice is given three months before the end date. The provider must deliver a quarterly service report. Any change to the scope above a certain value requires written approval from the customer’s finance director.
The agreement is negotiated carefully, reviewed by legal and signed. The PDF is stored in the contract repository. Twenty-two months later, the renewal deadline passes without anyone noticing, two quarterly reports were never requested, and a scope change was agreed by email with the delivery manager. None of this happened because the contract was unclear. It happened because, once signed, the contract stopped being anyone’s daily concern.
Where the lifecycle breaks
Contract work is often described as a sequence: drafting, collaboration between the parties, signing, execution and oversight. The first three stages usually receive the most attention and the best tools. Drafting has templates and clause libraries; collaboration has redlining and version control; signing has electronic signatures and audit trails.
The handover from signing to execution is different. The people who negotiated the agreement are rarely the people who have to act on it. Legal moves on to the next contract, procurement to the next supplier, sales to the next customer. Obligations that were clear on paper now sit inside a document that the people responsible for them may never open. Oversight, in turn, depends on someone knowing which obligations exist, who owns them and whether they were met.
Examining one obligation
A practical way to find the gaps is to take a single obligation and follow it through. Take the renewal clause in the example.
What must happen? A decision on whether to renew, renegotiate or terminate, and, if the answer is not to renew, written notice to the provider before the deadline.
Who owns it? Not “the business”, but a named role, for instance the budget holder for IT services, with a deputy if that person is unavailable.
What triggers action? A date: perhaps five months before the end of the term, to leave time for evaluation, followed by a reminder closer to the notice deadline.
What approval is needed? The organisation’s own rules may require the finance director to approve a renewal above a certain value, or procurement to be involved before renegotiating.
What evidence shows completion? A recorded decision, and, where relevant, a copy of the notice sent and confirmation that it was received.
How are exceptions handled? If the owner has left, the deadline is missed or the parties disagree about the notice period, there needs to be a defined escalation route, which often leads back to legal.
Answering these six questions for one obligation usually reveals more than a general review of contract management. It shows where responsibility is assumed rather than assigned, and where the organisation relies on memory rather than a process.
What contract-as-code can and cannot mean
The idea of contract-as-code is to represent selected obligations as executable workflow rules: the renewal clause becomes a dated task with an owner, an approval step and a record of completion; the reporting obligation becomes a recurring check that a report has been received. The aim is to connect what the contract says with the work that has to follow.
It is important to be precise about the limits. Not every clause can, or should, be translated mechanically. Many contract terms depend on interpretation, context or negotiation, and software does not determine their legal meaning. The sensible scope is obligations that are concrete and recurring, with clear triggers and observable outcomes. Deciding which obligations those are, and how they should be read, remains a matter for the people responsible for the contract, including legal.
Where CrossContracts fits
CrossContracts, a venture being developed at Xablu Venture Studio, explores how contract documentation can be connected to operational workflows so that obligations remain visible and owned after signing. The current work concerns validating the market problem and defining the first application that would be valuable enough to build. Connections to existing contract, procurement, finance or workflow systems are intended, and remain subject to that validation.
Is there a recurring obligation in your organisation that loses ownership once the contract is signed? Identify one, and we would be glad to examine with you what follow-through it needs.
Discuss an obligation →