title: Prevent DELETES from bypassing versioning in Amazon QLDB
body: <p>Amazon QLDB allows querying the version history of a specific object by its ID. However, it also allows deleting objects. It seems like this can be used to bypass versioning by deleting and creating a new object instead of updating the object.</p>
  <p>For example, let's say we need to track vehicle registrations by VIN.</p>
  <pre><code>INSERT INTO VehicleRegistration
  &lt;&lt; {
      'VIN' : '1N4AL11D75C109151',
      'LicensePlateNumber' : 'LEWISR261LL'
  } &gt;&gt;
  </code></pre>
  <p>Then our application can get a history of all LicensePlateNumber assignments for a VIN by querying:</p>
  <pre><code>SELECT * FROM _ql_committed_VehicleRegistration AS r
  WHERE r.data.VIN = '1N4AL11D75C109151';
  </code></pre>
  <p>This will return all non-deleted document revisions, giving us an unforgeable history. The <code>history</code> function can be used similarly if you remember the document ID from the insert. However, if I wanted to maliciously bypass the history, I would simply delete the object and reinsert it:</p>
  <pre><code>DELETE FROM VehicleRegistration AS r WHERE VIN = '1N4AL11D75C109151';
  INSERT INTO VehicleRegistration
  &lt;&lt; {
      'VIN' : '1N4AL11D75C109151',
      'LicensePlateNumber' : 'ABC123'
  } &gt;&gt;
  </code></pre>
  <p>Now there is no record that I have modified this vehicle registration, defeating the whole purpose of QLDB. The document ID of the new record will be different from the old, but QLDB won't be able to tell us that it has changed. We could use a separate system to track document IDs, but now that other system would be the authoritative one instead of QLDB. We're supposed to use QLDB to build these types of authoritative records, but the other system would have the exact same problem!</p>
  <p>How can QLDB be used to reliably detect modifications to data?</p>