Stating Warranties Relating to “Future Facts”

I’d like to revisit something discussed in MSCD—how one states warranties relating to, for example, goods yet to be delivered.

Consider the following:

Acme warrants that the Units will be free from defects when shipped from Acme’s plant.

That’s standard warranty language, with Acme stating “future facts,” to use warranties-doctrine lingo.

Well, in terms of semantics, I’m not keen on the notion of “future facts,” because what’s being stated isn’t a fact at all. Instead, it’s a commitment on the part of Acme to deliver conforming goods. So I recommend instead saying exactly that:

Acme shall sell to the Buyer Units that comply with the Specifications.

If you want also to specify remedies, then do so:

If a Unit fails to comply with the Specifications, then …

Now, as a matter of idiom, it’s standard for people to speak in terms of future facts: I promise that the cake will be ready! I guarantee that you’ll be happy.

But just because use of future facts is idiomatic doesn’t mean that they’re suited to contracts. Language of obligation is a clearer alternative to stating “future facts.” And it’s not a good idea to use future facts just for the heck of it—contracts aren’t the place for elegant variation.

Of course, getting rid of future facts means that you can also get rid of the verb warrants, at least in this context. That ties into my broader analysis of represents and warrants. You’ll have to wait a few months for that. I’m sure you’re heartbroken!

About the author

Ken Adams is the leading authority on how to say clearly whatever you want to say in a contract. He’s author of A Manual of Style for Contract Drafting, and he offers online and in-person training around the world. He’s also chief content officer of LegalSifter, Inc., a company that combines artificial intelligence and expertise to assist with review of contracts.

11 thoughts on “Stating Warranties Relating to “Future Facts””

  1. Read literally and without the benefit of the remedy provision, I think your proposed covenant would be satisfied if Acme sold more than one Unit that complies with the Specifications. It does not clearly require that all Units sold by Acme comply with the Specifications. Perhaps “Acme shall not sell to Buyer any Units that do not meet the Specifications” would work, as might “Acme shall sell to Buyer only Units that meet the Specifications”. There’s also “Acme shall ensure that all Units its sells to Buyer comply with the Specifications”. The intent is made clear by the remedy provision (“If any Units fail…”). As an aside, I would suggest “If any Unit fails…”

    You’re also taking out the timing of the determination of when the warranty must be satisfied (i.e., at the time of delivery vs. throughout some period of time). The recommendation in 13.741 of MSCD is a good one in that it contains the obligation, the remedy, and the time limitation.

    Reply
    • Good point regarding how the obligation is stated, but I suggest that if you include the remedy provision, that would eliminate any possible confusion.

      Also, “Acme shall sell to the Buyer only Units that meet the Specifications” could be read as meaning that Acme is prohibited from selling to the Buyer items other than Units.

      Regarding timing, the ellipses were my way of saying “and there’s other stuff involved.” But I love your citing MSCD at me! I often have to remind myself what I said about various topics.

      Reply
  2. Warranties are really just conditional covenants. Contracts would be cleaner if phrased that way. But business people (and old-fashioned lawyers) often look for the term “warranty.”

    I sometimes draft contracts that include a subheading along the lines of “Limited Warranty and Remedies,” in which the text following the subheading doesn’t use the term warrant, but only conditional covenants.

    Reply
  3. Ken:

    I prefer Mr. Poindexter’s “Acme shall ensure that all Units its sells to Buyer comply with the Specifications.” The reason is that the obligation to sell units should probably be in the first section. Then price in the second. Then “warranties” in the third. Your version seems to combine the obligation to sell with the obligation to meet specifications.

    Chris

    Reply
  4. Couple of peripheral notes:

    1/ Covenant. Ken, you dislike the word ‘covenant’, but it fills the need for a short way to describe *a contractual provision that creates a duty*, or *a contractual instance of language of obligation*.

    2/ Aren’t all instances of language of declaration (acknowledgments, representations, and warranties) ultimately conditional covenants? If so, then doesn’t the rule of concision require recasting statements of fact, whether or not preceded by a declarant and a declaring verb, into conditional covenants? Why not cut to the chase and say, as you recommend, ‘If a Unit fails to comply with the Specifications, then [remedy]’? Why not reject the two-step process of saying (1) declarant states X; and (2) If X was/is/becomes untrue, then [remedy]’?

    Reply
    • > Aren’t all instances of language of declaration (acknowledgments, representations, and warranties) ultimately conditional covenants? ….

      I pound that concept into my students.

      > Why not cut to the chase ….

      That would be great. Drafters and others, though, are accustomed to using the terms of art such as representations, warranties, etc., as shorthand expressions.

      (In the software world, such terms of art are known as “syntactic sugar”; see https://en.wikipedia.org/wiki/Syntactic_sugar)

      The problem is that sometimes we get something akin to genetic drift: The meanings of those shorthand expressions can vary with the jurisdiction.

      I strongly suspect that many contracts would be more clear if drafters stuck to simple IF-THEN-ELSE statements, as AWrightBurke suggests.

      Either that or we need to agree on standard meanings for acknowledge, represent, warrant, etc.

      Reply
    • Why can’t you just refer to something as an obligation?

      As for your second point, sure, you can short-circuit things as you suggest. But in a contract of any complexity, you’ll have remedies geared to statements of fact collectively, and conditions to closing geared to facts collectively, so you what propose wouldn’t work.

      Reply
      • > Why can’t you just refer to something as an obligation?

        Because you should be unwilling to sow confusion by using the word ‘obligation’ mean both ‘duty’ and ‘a statement that expresses a duty’ or even worse, ‘an instance of language of obligation’. ‘Covenant’ is conciser by far.

        Your resistance is surprising, since you insist on a similar distinction between ‘drafting convention’ and ‘provision specifying drafting convention’ and between ‘fact’ and ‘statement of fact’. Where has that sense of nuance gone?

        > in a contract of any complexity, you’ll have remedies geared to statements of fact collectively, and conditions to closing geared to facts collectively, so you what propose wouldn’t work.

        Sure it would work:

        A condition consists, a little bird called MSCD told me, of a conditional clause with a subordinator (like ‘if’ or ‘unless’) and a ‘matrix clause’. (In my day they were ‘protasis’ and ‘apodosis’.)

        For a statement of many facts, such as conditions to closing, simply state all the facts that share a remedy or other consequence, then make a conditional sentence cover the facts collectively:

        ‘If any of the following facts is or becomes inaccurate by [date and time], then Acme will have no obligation to close and [other consequences]’.

        Reply
        • Regarding the distinction between an obligation and language imposing an obligation, I feel a blog post coming on, one that looks at this dichotomy more generally. Happy now? ;-)

          The whole let’s-not-say-who’s-stating-the-facts mishegoss ain’t gonna fly, for reasons that I’ll convey to you sometime over a beer or three.

          Reply

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.