Conventional tables are the bread and butter of IT. The data in those tables represent both what things are currently like and also what we currently believe those things are like. They represent both what things are like now and what we now believe they are like.

There is a timeline along which persistent objects are located, and a timeline along which we hold various beliefs. Data in conventional tables is “pinned”, along both timelines, to the moving point in time we call “the present” and which, in this book, we designate as Now(). The maintenance of conventional data is an ongoing effort to keep up with the changes that follow in the trail of that moving point.

But as well as the present, there are the past and the future. So if we “unpin” data along both these timelines, we end up with nine possible ways that data and time may be related.

In this section, we will use the terminology of beliefs even though, as we said previously, the nine different terms we listed there are equivalent, as far as our discussions in this book are concerned. This chapter is about assertions, and so we initially tried to write this section using that terminology. But it seems to us that the argument is easier to follow using the language of beliefs. Nonetheless, we are speaking about assertions, albeit in the more colloquial language of beliefs. Not all assertions, of course; and not all beliefs. Rather, as we said earlier, assertions that statements made by rows in database tables are true statements, and beliefs that those statements are true statements.

Using the terminology of beliefs, we may say that the rows in tables in relational databases may relate data to time in any of nine ways. So where “thing” means, more precisely, “persistent object”, we can organize these nine relationships of rows to time as shown in Figure 12.1.

In Asserted Versioning, beliefs are what we assert by means of rows in our tables, and facts are what those rows describe about the objects they represent. Columns, in Figure 12.1, from left to right, represent past, present and future beliefs. Rows, in that same illustration, from top to bottom, represent past, present and future facts. Temporalized beliefs are represented by rows with assertion time periods. Temporalized facts are represented by rows with effective time periods, i.e. by versions. ²

But temporal transactions cannot insert, update or delete all nine types of rows. Specifically, temporal transactions cannot insert, update or delete rows making statements about what we used to believe, statements of type (i), (ii) or (iii).

It's important to understand why this is so. Temporal transactions create new rows in temporal tables. But these rows represent beliefs, and we can't now make a statement about what we used to believe. On the other hand we can, of course, now make a statement about what used to be true. To understand what the two temporal dimensions of bi-temporal data really mean, we need to understand why distinctions like these ones are valid—why, in this case, we can make statements about how things used to be, but cannot make statements about what we used to think about them.

So why can't we? Surely we make statements about what we used to believe all the time. For example, we can now state that we used to believe that Bernie Madoff was an honest man. If we can make such statements in ordinary conversation, why can't we make them as transactions that will update a database?

The reason is that in a database, as we said, a belief is expressed by the presence of a row in a table. No row, no belief. So if we write a transaction today that creates a row stating that we believed something yesterday, we are creating a row that states that we believed something at a time when there was no row to represent that belief. Given that the beliefs we are talking about are beliefs that certain statements about persistent objects are true, and given that those statements are the statements made by rows in tables, it would be a logical contradiction to state that we had such a belief at a point or period in time during which there was no row to represent that belief. ³

This leaves us six combinations of beliefs and what they are about that we can, without logical contradiction, modify by means of a temporal transaction. Asserted Versioning recognizes all six combinations. But the standard temporal model does not permit data to be located in future belief time, and so it does not recognize combinations (vii), (viii) or (ix) as meaningful. It does not attempt to develop a data management framework within which we can make statements about what we may in the future believe.

Future beliefs, and their representation in temporal tables as not yet asserted rows, are precisely what make the difference between the assertion time dimension of Asserted Versioning and the transaction time dimension of the standard temporal model. Without it, the two temporal dimensions of Asserted Versioning are semantically equivalent to the two temporal dimensions of the standard temporal model. Without it, assertion time is equivalent to transaction time.

But is it valid to locate data in future belief time? After all, as we noted in a footnote a short while ago, we can be certain about what we once believed and about what we currently believe, but we cannot be certain about what we will believe. On the other hand, a lack of certainty is not the same thing as a logical contradiction. There is nothing logically invalid about making statements about what we think was, is or may come to be true. By the same token, there is nothing logically invalid about making statements about what we currently believe or may come to believe was, is or may turn out to be true. The only logical contradition is the one already noted, that because of the temporalized extension of the CWA, it is a logical contradiction to create a row representing a statement about what, prior to the time the row was created, we then believed/asserted to be true.

We should now have a clear idea of what deferred transactions and deferred assertions are. They are the data in categories (vii), (viii) and (ix) of Figure 12.1. We understand that neither the standard temporal model nor, for that matter, any more recent computer science work on bi-temporality that we are aware of, recognizes data which represents what we are not yet willing to assert is true about what things were like, are like or may turn out to be like.

Before discussing deferred transactions and deferred assertions, we want to explain how they are one subtype of a more generalized concept, of something we call pipeline datasets. Once we have done that, the remainder of this chapter will focus on deferred transactions and deferred assertions, and the business value of internalizing them. Then, in the next chapter, we will look at several other kinds of pipeline datasets, and the business value of internalizing them as well.

We begin with an open episode of policy P861. As shown in Figure 12.2, the current version in this episode—P861(r4)—has an [Aug 2012 – 12/31/9999] effective time period. ⁴ It also has an [Aug 2012 – 12/31/9999] assertion time period. From this, we know that there is no representation of this object anywhere else in the production table, in either temporal dimension, from August 2012 until further notice.

By now we should know how to read an asserted version table like this. The episode extends from an effective begin date of November 2011 to an effective end date of 12/31/9999. Every version in this episode is currently asserted.

We will now submit a deferred temporal update. Again, we assume that it is now January 2013. That transaction looks like this:

The three temporal parameters following the bracketed data are the effective begin date, effective end date and assertion begin date. All temporal updates discussed so far have accepted the default value for the assertion begin date, that value being Now(). Here, with our first deferred transaction, we override that default with a future date.

There are several things to note about this transaction. First of all, the object specified in this transaction is policy P861, and the transaction's effective timespan is May 2012 to July 2012, i.e. the two months of May and June 2012. The assertion begin date is January 2090, a date which is several decades in the future.

The first thing the AVF does is to split one or more rows in the Policy table into multiple rows such that one or a contiguous set of those rows has the oid and the effective timespan specified on the transaction. When a set of one or more contiguous asserted version rows, and a temporal transaction, have the same oid and also the same effective time period, we will say that they match.

Since the transaction specifies an effective timespan of [May 2012 – July 2012], the AVF modifies the current assertions for P861 so that one version matches the transaction. That is P861(r6), as shown in Figure 12.3.

This results in a set of rows that are semantically equivalent to the original row, those rows being P861(r5, r6 & r7). They cover the same effective time period as the original row; and they contain the same business data as the original row. Note that, in Figure 12.3, we have not yet created the deferred assertion. We have just realigned version boundaries, within current assertion time, as a preliminary step to carrying out the update. Prior to this realignment, the effective timespan of the transaction was located [during] the effective time period of P861(r3). Now the effective timespan of the transaction [equals] the effective time period of P861(r6), and so the transaction matches that asserted version.

The result of this alignment is shown in Figure 12.3. P861(r3) has been withdrawn into past assertion time, into an assertion time period that ends on January 2013. P861(r5, r6 & r7) have replaced it in current assertion time, in assertion time periods that begin on January 2013 (and not, let it be noted, on January 2090). Again, we use angle brackets on row numbers to indicate rows that are part of an atomic and isolated unit of work, a series of physical modifications to the database that must together all succeed or all fail, and a set of rows that are not visible in the database until the unit of work completes.

Note that P861(r5, r6 & r7) have the same episode begin date and the same business data as row 3. In addition, their three effective time periods cover exactly the same clock ticks as the withdrawn P861(r3). These three rows, together, are semantically equivalent to P861(r3). They represent the same object in exactly the same effective time clock ticks; and in every such clock tick, they attribute the same business data to that object.

Nor has the assertion time in the table been altered, either. Prior to this transaction, the statement made by P861(r3) was asserted from April 2012 to 12/31/9999. Midway into the transaction, at the point shown in Figure 12.3, the table still asserts that from April 2012 to 12/31/9999, P861 was owned by client C882, was an HMO policy, and had a copay of $30. It asserts this because the statement made by the logical conjunction of P861(r6, r7 & r8) is truth-functionally equivalent to the statement made by P861(r6), and the assertion times of [Apr 2012 – Jan 2013] and [January 2013 – 12/31/9999] both [meet] and, together, [equal] the original assertion time of P861(r3), before it was withdrawn. At this point in the transaction, we have performed syntactic surgery on the target table, but have in no way altered its semantic content.

There is now one and only one row in the target table that matches the transaction. It is P861(r6). The AVF next withdraws P861(r6), moving it into closed assertion time, i.e. giving it an assertion time period with a non-12/31/9999 assertion end date. It does so by giving P861(r6) an assertion end date that matches the assertion begin date on the transaction, thus preserving the assertion time continuity of this effective time history of P861.

The next thing the AVF does is to make a copy of P861(r6), apply the copay update to that copy, and give it an assertion time period of [Jan 2090 – 12/31/9999]. This becomes P861(r8), the row that supercedes row 6. This row is the deferred assertion.

The result is shown in Figure 12.4.

Note that this closed assertion is still current. It is currently January 2013, and so Now() still falls between the assertion begin and end dates of P861(r6), and will continue to do so until January 2090. So a closed assertion time period is one with a non-12/31/9999 end date. Some closed assertion time periods are past; they are no longer asserted. But others are current, like this one. And yet others may be assertion time periods that lie entirely in the future.

Note that this process is almost identical to the familiar process of withdrawing a version into past assertion time and superceding it with a row in current assertion time. The only difference is that the withdrawn assertion is moved into closed but still current assertion time, and the superceding assertion is placed into future assertion time.

At this point, both P861(r3 & r6) are locked. The AVF will never modify P861(r3) because it is already located in past assertion time. But P861(r6) is also locked, even though it is still currently asserted. The AVF treats any row with a non-12/31/9999 assertion end date as locked. The reason all such rows are locked, including those whose assertion time periods are not yet past, is that the database contains a later assertion which otherwise matches the locked assertion.

In this case, P861(r6) is locked because the Policy table now contains a later assertion that was created from it. That later assertion was supposedly written and submitted based on then-current knowledge of the contents of the database, specifically of what the database then asserted about what P861 was like in May and June of 2012. If that description is allowed to change before the later assertion became current, then all bets are off.

Another way to think about the locking associated with deferred transactions and deferred assertions is that it serializes those transactions. If a process about to update a row in a database does not first lock that row from other updates, then another update process could read the row before the first process is complete. Then, whichever process physically updates that row on the database first, its changes will be lost, overwritten by the changes made by the process which updates the database last. This could happen with deferred assertions if they were not serialized.

The mechanics of deferred assertion locking are simple. Every temporal transaction has an assertion begin date, either the default date of Now() or an explicitly supplied future date. Temporal updates and temporal deletes begin their work by withdrawing the one or more versions which represent an object in any clock ticks included in the transaction's effective timespan. The versions they withdraw are those versions located in the most recent period of assertion time. That may be current assertion time, and usually is. But when a deferred transaction has been applied to versions in current assertion time, it closes their assertion periods with the same date that begins the assertion period of the deferred assertion it creates, just as the deferred update we are discussing closed P861(r6) and superceded it with P861(r8). And it creates a version that exists in future assertion time. Deferred transactions may then be applied to that deferred assertion, and we will explain how to do that in the next section.

Note what is not locked. The episode itself is not locked. Out of the entire currently asserted effective time period from November 2011 to 12/31/9999, for P861, only two months have been locked. Inserts, updates and deletes can continue to take place against any of the other clock ticks in the episode occupied by P861—or, for that matter, against any clock ticks not occupied by P861.

We have now completed the deferred transaction. As directed by the transaction, the AVF has created a version of P861, for the effective time months of May and June 2012, that will not be asserted until January 2090. If nothing happens between now and January 2090, then at that time, the database will stop asserting that P861 had a copay amount of $30 in May and June of 2012, and begin asserting, instead, that it had a copay amount of $55 during those two long-ago months.

Now we have a deferred assertion. Next, let's consider an update which will apply to that deferred assertion. This transaction takes place on February 2013.

Apparently, sometime in the month after the first deferred update, we decided that the copay update should have been increased to $50, not to $55, for the month of May 2012. To process this second deferred update, the AVF begins its work by looking for versions already in the target table, with the same oid, whose effective time periods [intersect] the effective timespan specified on the transaction. It ignores past assertions, because database modifications neither affect past assertions nor are affected by them.

The effective timespan for P861 that the AVF is looking for is [May 2012 – Jun 2012]. The AVF finds two rows—P861(r6 & r8) (as shown in Figure 12.4)—whose effective time includes that of the timespan on the transaction. Both rows have the same oid as the transaction, and both include the effective-time clock tick of May 2012.

P861(r6), however, is locked because there is a later assertion about the same object that includes all its effective time clock ticks. It is P861(r8) that is the latest assertion which has an effective time period that [intersects] that of the transaction. ⁵ That row's time period, to be more precise, [starts^-1] the effective time period on the transaction.

So the target of the deferred update must be P861(r8). It is the latest, i.e. future-most, assertion about the month of May 2012, in the life of P861.

Next, because P861(r8) includes June as well as May, the first thing the AVF does is to split that row to create a semantically equivalent pair of rows, one of which matches the transaction. This is shown in Figure 12.5. P861(r8) has been withdrawn. In its place, the AVF has created the two rows P861(r9 & r10).

P861(r8) has been withdrawn into closed assertion time, but that assertion time is neither past nor present assertion time. It is empty assertion time, because the time period [Jan 2090 – Jan 2090] includes no clock ticks, not a single one.

In all our dealings with temporal transactions, the assertion date specified on the transaction (or accepted as a default) is used both as the assertion end date of the withdrawn row and also as the assertion begin date of the row or rows that replace and/or supercede it. In this way, our transactions build an unbroken succession of assertions about what the object in question is like during the unbroken extent of the episode's effective time.

P861(r8) cannot be withdrawn into past assertion time because it hasn't been asserted yet. But it also can't be allowed to remain in future assertion time because if P861(r9 and/or r10) are ever updated, they and P861(r8) would make different statements about what P861 was like at the same point in time, i.e. in either May or June 2012. In other words, P861(r8) can't be allowed to remain in future assertion time because it would then be a TEI conflict waiting to happen.

This is why the AVF moved it into empty assertion time. This is the semantically correct thing to do. With P861(r9 & r10) now in the database, which together match P861(r8), and with both being in yet-to-come assertion time, one of them had to go. Creating P861(r9 & r10) is a preparatory move made by the AVF, to isolate a single deferred assertion that will match the update transaction. So P861(r8) was the correct one to go. Having nowhere in past assertion time to go, and obviously not belonging in current assertion time, it went to the only place it could go—into non-asserted time, i.e. into empty assertion time.

A row in empty assertion time, however, is a row that never was asserted and never will be asserted. So there is an argument for simply physically deleting the row rather than moving it into empty assertion time. For one thing, Asserted Versioning cannot keep track of when it was moved into empty assertion time. The only physical date on an asserted version table is the row creation date, and the movement of a row into empty assertion time is a physical update, for which there is no corresponding date.

For another thing, since a row in empty assertion time never was asserted, and never will be asserted, what information does it contain that would justify retaining it in the database? Well, in fact, a row in empty assertion time is informative. The information it contains is information about an intention. At one point in time, we apparently intended that the business data on that row would one day be asserted. Perhaps we intended to deceive someone with that business data. In that case, that row is a record of an intent to deceive. By retaining the row, we retain a record of that intent.

Non-deferred transactions are always against currently asserted versions which have a 12/31/9999 assertion end date. They withdraw those target versions by ending their assertions on the same clock tick that their replacement and/or superceding versions begin to be asserted. The result is to withdraw those target versions into past assertion time, but leave no assertion time gap between them and the results of the transaction.

Deferred transactions against those same currently asserted versions do the same thing. They withdraw them by ending their assertions on the same clock tick that their replacement and/or superceding versions will begin to be asserted. But being deferred, those replacement and/or superceding versions begin on some future date. Using that future date as the assertion end date of the target versions, those target versions are withdrawn, but into current assertion time. This current assertion time, however, has a definite, non-12/31/9999, end date, and so we say that their assertion periods are current but closed. If nothing happens in the meantime, then when that date comes to pass, the current closed assertions will fall into past assertion time, and the deferred assertions which replaced and/or superceded them will fall into current assertion time. The mechanics of withdrawal supports these different semantics correctly, just as it supported the semantics of non-deferrals correctly.

Deferred update and delete transactions may also have deferred assertions as their target. However, for any oid and any effective-time clock tick, the target of a deferred update or delete transaction must be the latest assertion of that effective-time clock tick for that object because, if it were not, it would violate the serialization property of deferred assertions (as described earlier, in the section A Deferred Update to a Current Episode). And the AVF guarantees that this will be so because any but the latest assertion will be locked; it will be on a row with a non-12/31/9999 assertion end date.

The mechanics of the AVF does its job, as in the first two cases, by ending the withdrawn assertions on the same clock tick that their replacement and/or superceding versions begin to be asserted.

For example, P861(r8) has an assertion begin date of January 2090. If a deferred update transaction targeting P861(r8) specified any assertion date later than that, then it would leave P861(r8) to become currently asserted on January 2090, and to remain currently asserted until whatever assertion end date the transaction assigned to it. That's an ordinary enough case, and perhaps we should not be surprised that the machinery of deferral works correctly for it. But in fact, the deferred update we are discussing here specifies an assertion date of January 2090, the same date as the begin date on the target deferred assertion. And this is not so ordinary a case.

But in this case, too, what the mechanics achieves is precisely what the semantics demands. In this case, P861(r8)'s assertion end date is set to January 2090, with the result that its assertion time period is [Jan 2090 – Jan 2090]. With a closed-open convention for representing periods of time, this is an empty time period, one including not a single clock tick. It makes it as though P861(r8) had never been. It makes that row one which never was asserted and never will be asserted. For such rows, we will say, the transaction overrides them. So, to override a row is to withdraw it into empty assertion time prior to its ever being asserted in the first place.

What the semantics demands is a replacement row and a superceding row to cover the months of May and June 2012 in the life of P861, and for both those rows to begin to be asserted on January 2090. With P861(r9 & r10), that's exactly what it gets. There is now a target row which exactly matches the update transaction, and the transaction can now proceed on to completion.

The remaining analysis is straightforward. P861(r9) matches the deferred update transaction. P861(r10) is of no interest to the transaction because its effective time period does not share even a single clock tick with the effective timespan of the transaction.

Having created a target row which matches the transaction, the AVF now updates that row with the new copay amount. Note that it does not withdraw P861(r9) and supercede it with a new row. It could do that, but there is no need to do so because we are still in the midst of an atomic and isolated unit of work. At this point, the change to the copay amount is recorded. At this point, the update is complete. The result is shown in Figure 12.6.

As directed by the transaction, the AVF has created a version of P861, for the effective time period of May 2012, that will not be asserted until January 2090. The first deferred update changed the copay amount for P861, for the month of May 2012, from $30 to $55. This second deferred update corrected the copay amount which the first one set to $55. It changed it to $50.

Once again, we retain the angle brackets in the illustration to make it easy to identify the rows involved in the transaction. But the transaction, at this point, is complete. All DBMS locks are released, and all the rows in Figure 12.6 are now visible in the database. P861(r9 & r10) are not locked. P861(r8) has been overridden by those next two rows, and moved into empty assertion time. But note that P861(r6) is still both currently asserted and locked.

Does the business really intend to leave the database in this state? Does it really intend to continue saying until 2090 that in May and June 2012, P861 has a copay of $30, even though it apparently knows that the correct amount is $50 in May and $55 in June? Well, it certainly doesn't seem very likely.

When a deferred transaction is applied to the database, it locks all prior but not yet past assertions for that object and that effective time period by setting the assertion end date to a non-12/31/9999 date. It withdraws matching current assertions, and either withdraws matching deferred assertions, or overrides them, or withdraws an earlier portion of them and overrides the remaining portion. The deferred transaction then creates a deferred assertion for the specified object in the specified effective time period, whose assertion begin date is set to the assertion begin date specified on the transaction.

For example, the first of the deferred transactions we looked at locked the effective time months of May and June 2012 for policy P861, and then created a deferred assertion for that policy in those two months. The second deferred transaction focused in on the month of May 2012, isolating it by splitting the deferred assertion P861(r8) into the two semantically equivalent deferred assertions P861(r9 & r10), and overriding P861(r8) with those two deferred assertions. Next, with P861(r9) representing the policy during May 2012, the deferred transaction applied the new copay amount to that row, completing the transaction and the atomic unit of work, ending the isolation of those rows and making them visible in the database, accessible to queries that specify assertions deferred until 2090.

As shown in Figure 12.6, the Policy table now contains only three deferred assertions that have not been overridden. One is P861(r6), whose withdrawal has been deferred until January 2090. The other two are P861(r9 & r10). They constitute a single deferred assertion group, that group being defined by the future assertion date that they share.

A deferred assertion group is another managed object introduced by Asserted Versioning but not supported by relational theory, relational technology, other temporal models, or ongoing research in the field. It is a designated collection of one or more rows which consist of assertions in the same future assertion period of time, and, transitively, any earlier non-past assertions that are locked because of them. These deferred assertion groups can contain assertions for different episodes of the same object, and for different objects in the same or in different tables.

Besides its own currently asserted production data, a production table may contain any number of deferred assertion groups. These deferred assertion groups are the internalization of inflow pipeline datasets. They are the internalization of collections of transactions which are not currently production data.

Usually, these collections are called batch transaction datasets. Typically, there may be any number of batch transaction datasets in which pending transactions are accumulated as they are acquired or created. One by one, on a scheduled or as-needed basis, these batch datasets are processed against their target databases, and production tables are updated. But with asserted version tables as the target production tables, these batch datasets aren't necessary. Transactions scheduled to be processed on a later date can be submitted immediately, with that later date as the assertion begin date.

Let us assume that the business has now reviewed the deferred assertion group and approved the assertions in it to become current as soon as possible. It is now March 2013, and so the next opportunity to update the database is April 2013.

The AVF moves deferred assertions backwards in time with a special temporal update transaction. This transaction takes deferred assertions in the far future and moves them into the near future.

But before we move P861(r9 & r10) backwards in assertion time, consider P861(r6). P861(r9 & r10) were created as assertion-time contiguous with P861(r8), which itself was created as assertion-time contiguous with P861(r6). The idea was that, on January 2090, when P861(r6) ceased being asserted, it would hand-off to P861(r8) on precisely that clock tick. But then a second deferred update was applied, which overrode P861(r8) with P861(r9 & r10), and then updated P861(r9).

When we originally created P861(r9 & r10), that future clock tick was January 2090. We are now about to change the assertion begin date on those two assertions to April 2013.

But if we do so, and do nothing about P861(r6), we will create a TEI violation. If we do nothing about P861(r6), then from January 2013 to January 2090, P861(r6) will assert that P861's copay amount in May 2012 was $30, but P861(r9) will assert that it was $50. So even though P861(r6) exists in a closed period of assertion time, it can, and indeed in this case must, be overridden. So rather than thinking of the approval transaction as changing the assertion begin date on one or more deferred assertions, we should think of it as changing the hand-over clock tick between locked assertions and the deferred assertions that are being moved backwards in assertion time.

The approval transaction looks like this: ⁶

This transaction is unlike the standard temporal update transaction in that its temporal parameters are both assertion dates. As indicated by the commas, there are no effective time dates on this transaction. And although a standard transaction can have one assertion date, this transaction has two assertion dates.

The first assertion date on the approval transaction is the assertion group date. The second is the assertion approval date.

The transaction proceeds as an atomic (all-or-nothing, and isolated) unit of work. For all assertions whose assertion begin date matches the assertion group date, it changes their assertion begin dates to the approval date. This is shown in Figure 12.7. P861(r9 & r10) have been moved from far future (2090) into near future (2013) assertion time. As soon as April 2013 occurs, those two rows will fall into currency.

The approval transaction is almost complete, but it has one thing left to do. As shown in Figure 12.6, P861(r6) has a January 2090 assertion end date prior to the approval transaction. If nothing is done, then in less than a month after the approval transaction is applied, P861(r9 &r10) will be in TEI conflict with P861(r6), and will remain so for several decades.

This is because the override work of the approval transaction is incomplete. P861(r9 & r10) match P861(r6), which exists in current but closed assertion time. But in order to make room in near future assertion time, the AVF must withdraw any earlier assertions that would conflict with the assertions being moved backwards in time by the approval transaction. So, using the same withdraw/override mechanics it has always used, the AVF sets the assertion end date on P861(r6) to the assertion begin date of the two rows it has moved into near future assertion time, that date being April 2013.

The approval transaction is now complete. The deferred assertions have been moved into near future time, and are waiting to fall into currency. The database is in the state shown in Figure 12.7.

And, once again, we find that our mechanics, applied to a situation never anticipated for it, produces results that accurately express the correct semantics. For with its approval transaction, the business told us that we could update the copay amount for P861 in May of 2012 as soon as possible. As soon as possible is April 2013. So our database now shows the incorrect claim about P861 in May of 2012 continuing until that as soon as possible correction, and that correction, as the two rows P861(r9 & r10), taking over on that same clock tick.

In this way, multiple deferred assertions can be managed as a single group. For example, if we are adding 1000 clients to our database, then if all 1000 clients are assigned the same future assertion date, a single approval transaction can be used to assert all of them at once.