I appreciate the comment. Yes, that's where the big savings are at -- in the developer time. Most shops that try to implement any kind of temporality do it (differently) table by table. Not only do they spend a lot of time doing it, but they often get it wrong, or a new programmer comes in and does it differently. So, there are often different approaches spread across an organization.

I lot of the data quality issues we see are often traced back to incorrect temporal management.

By doing this at the DBMS Insert/Update/Delete level, even ad-hoc types of SQL data updates maintain the temporality in the tables the same way, and 100% of the time. It can be used for OLTP and SCDs in dimensional models. Not only for History, but also for future effectively and future assertions.