Exercise 2: A Different Kind of Rule — Possible Solution
====================================================================

THE INVARIANT THIS CHAPTER'S RULE ENFORCES
------------------------------
The update rule enforces that if an update's resulting document has status equal to "used", that same resulting document must not contain an expiryDate field at all. In other words: it is never valid, according to the database itself, for a document to simultaneously be marked used and still have an expiry date.

HOW IT DIFFERS FROM CHAPTER 6'S CREATE RULE
------------------------------
Chapter 6's create rule validates the shape of a brand-new document being created for the first time - checking things like whether name is a non-empty string or whether status is one of the two valid values, at the moment a document comes into existence. This chapter's update rule instead validates a transition - the relationship between what the document is changing into as a result of an update, regardless of what it looked like before. Chapter 6 asks "is this new document shaped correctly?"; this chapter asks "is this specific change producing a result that's still internally consistent?"

WHAT THAT "SOMETHING ELSE" IS
------------------------------
Chapter 6's create rule validates creation shape; this chapter's rule validates a data invariant across an update - a rule about what combinations of field values are allowed to coexist in a resulting document, independent of who performed the update or what the document looked like beforehand.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly describes the specific invariant (used status and expiryDate presence can never coexist) the rule enforces, and correctly distinguishes create-time shape validation from update-time transition/invariant validation as two different kinds of things Security Rules can check.