retrodiction, when?

Retrodiction, the ability to change our perception of past events, is a key concept in Rolonics. Every living thing has this capability and many applications in the insurance industry, to give an example, require this capability. But this capability was not part of AgileWiki3, nor is it a part of COODBMS--these time machines only allow past state to be navigated.

Now depending on how it is implemented, retrodiction can be very expensive. Normally you simply reprocess all activity since the last valid snapshot. But while this may work for an application with well defined scope, it does not work in the general case unless we have well defined worksets--and even then it can be expensive.

Working with virtual snapshots, as COODBMS does, has a similar problem when it comes to retrodiction--how many snapshots need to be created, i.e. which journal entries need to be revisited? Again, it would work ok for an application with very narrow scoping.

On the other hand, deductive inferencing systems, good ones any way (not AgileWiki3) track the dependencies of each deduction and allow changes. (All X were smaller than i, but now we have a new X which is larger than i.) Ah hah! Here we have the basis for a scalable retrodiction system.

But there's still a trick. Retrodiction is about viewing past state and changes over time. If we implement it as part of the inferencing layer, then we need to support views of deductions in 2-time. So for example, if at time t4 we enter a policy with an effective date of t1 and a claim for time t2 is entered at time t3, then we need to conclude at time t3 that the claim is invalid but revise at conclusion at time t4, for at time t4 we see the retrodicted history of having a policy at time t1 and a claim at t2.

So I am thinking we can have a scalable retrodiction system by implementing it in the inference layer. But our inference engine will need to work in 2-time.

Now let us consider a check register. We want to view the checks in the order they were written, not in the order they were entered. And we want to know the account balance when each check was issued. Now we deduce the balance from the balance after the previous activity completed. But my wife and I have a joint account and I am especially bad at entering the checks I have written. So for a given check, the prior check will change over time. This then changes what the account balance was when the check was written and impacts subsequent checks as well. But this is nothing that a good inverence engine can't handle.

Now here I am talking about using inferencing as a means of implementing a scalable retrictive system. The problem is that inferencing systems don't scale. Fortunately this is one issue which was addressed in AgileWiki3. In the semantic layer (namespaces) we define worksets and use those worksets to restrict the scope of any given inference. Bingo!