Precision is not optional
Unlike the interpretation of substantive obligations, where courts can weigh commercial common sense, conditions precedent are read strictly on their plain language. Ambiguity will not be resolved in your favour. So the drafting standard for triggers is higher than for ordinary clauses: each one has to be precise enough to be applied mechanically.
What follows are the elements that make a trigger work, drawn from how the recent cases have failed parties who got them wrong.
Define the triggering event objectively, and specify notice
The event must be capable of objective verification. "Payment of Milestone 3 becomes due upon satisfactory completion of the prototype phase" is bad - satisfactory to whom? A workable version ties the milestone to delivery meeting a named specification, passing a defined test protocol with stated pass criteria, and a project manager issuing an acceptance certificate in a set form. If you cannot prove the event happened on a specific date, you do not have an objective trigger.
Specify notice precisely. "Contractor shall promptly notify the Client of any delay" is unenforceable as a condition. State when the clock starts, how long the party has, what counts as a day, and how notice is given and deemed received.
State the consequence, and address prevention
Do not leave the consequence of non-compliance to implication. If failing to satisfy a condition forfeits the right, say so explicitly: that the contractor shall have no entitlement to time or money for the relevant event if it fails to give complying notice in the window, regardless of the underlying merits.
And address prevention directly. After King Crude, if you want protection against a party relying on a non-fulfilment it caused, include an express clause deeming the condition met where the other side's material breach was the sole cause, with the sum claimable as a debt. Without it, you are left to damages.
Build in deemed satisfaction, and separate condition from procedure
Where a condition depends on the other party acting - approving, accepting, responding - protect yourself with a deemed-satisfaction provision. For example, give the client a fixed window to issue an acceptance certificate or a detailed rejection notice, failing which the deliverable is deemed accepted and payment becomes due. That stops a party avoiding payment simply by ignoring deliverables.
And distinguish conditions precedent from procedural requirements in the drafting itself. Make true conditions read as conditions ("the right is conditional upon..."), and make process steps that should not forfeit the right say so ("failure to use the specified form shall not invalidate an otherwise valid claim").
Make the timeline survivable, then run the checklist
Conditions precedent fail in the chaos of a troubled project, so design a notice regime that a real team can actually follow. If you require notice within 24 hours of a delay event, ask whether anyone will even know within 24 hours. Consider a tiered approach: a short initial notice that an event has occurred, then fuller particulars within a longer window - and make clear which tier is the condition precedent.
Then run the pre-signature checklist: can we objectively prove when the trigger occurred; who controls whether it happens; are the deadlines achievable; what happens if we breach versus if they do (watch for asymmetry that protects only the other side); and have we actually built compliance into our project processes? In TCS v DBS, sophisticated parties with top advisers still missed conditions precedent - having them in the contract is not the same as meeting them.
Use at the desk
Practical checklist
- Define each triggering event objectively - a specification, a defined test with pass criteria, a dated certificate.
- State notice timing precisely: when the clock starts, how long, what a day means, and how notice is given and deemed received.
- State the consequence of non-compliance explicitly, including forfeiture where intended.
- Add an express prevention clause (post-King Crude) and deemed-acceptance windows where the other party controls the trigger.
- Distinguish true conditions precedent from procedural steps in the wording itself.
- Design achievable, tiered timelines, and run the five-question pre-signature checklist before you sign.
This guide is informational only and is not legal advice. It does not replace advice from licensed counsel on the facts of a specific transaction.
Product demo
Use the guide for context. Use Veqtor for the Word documents.
Watch Claude compare negotiation drafts and create a separate Word document with proposed tracked changes.
See Veqtor work with Word redlines