Do we have good stories about bitemporality solving business problems outside the history/audit domain? I found this example from "A Philosophy of Software Design" by John Ousterhout. In a chapter about finding abstractions to define errors away. And I think this can be implemented elegantly with temporal modelling. > File deletion provides another example of how errors can be defined away. The Windows operating system does not permit a file to be deleted if it is open in a process. This is a continual source of frustration for developers and users. In order to delete a file that is in use, the user must search through the system to find the process that has the file open, and then kill that process. Sometimes users give up and reboot their system, just so they can delete a file. The Unix operating system defines file deletion more elegantly. In Unix, if a file is open when it is deleted, Unix does not delete the file immediately. Instead, it marks the file for deletion, then the delete operation returns successfully. The file name has been removed from its directory, so no other processes can open the old file and a new file with the same name can be created, but the existing file data persists. Processes that already have the file open can continue to read it and write it normally. Once the file has been closed by all of the accessing processes, its data is freed. The Unix approach defines away two different kinds of errors. First, the delete operation no longer returns an error if the file is currently in use; the delete succeeds, and the file will eventually be deleted. Second, deleting a file thatโs in use does not create exceptions for the processes using the file. One possible approach to this problem would have been to delete the file immediately and mark all of the opens of the file to disable them; any attempts by other processes to read or write the deleted file would fail. However, this approach would create new errors for those processes to handle. Instead, Unix allows them to keep accessing the file normally; delaying the file deletion defines errors out of existence. It may seem strange that Unix allows a process to continue to read and write a doomed file, but I have never encountered a situation where this caused significant problems. The Unix definition of file deletion is much simpler to work with, both for developers and users, than the Windows definition.
Interesting quote, TIL. Filesystems are just a poor man's database with dubious isolation/consistency semantics ๐ As to your question - inserting into the future to orchestrate and preview change is valuable too IMO, but ultimately the key value prop is having easy and accurate 'business intelligence' sat immediately next to your transactional logic - human systems need this, and AI agents need this. This means something beyond 'history' (for the sake of it) or the occasional audit - it's about making better decisions based on the best information available.