The temporal setting on a fact type offers a fixed ladder of options rather than a free combination of the three things it actually covers: the period over which the fact is administered, the history of registrations, and the moment a decision was taken.

Because of that, an organisation that has to register when a decision was taken, in addition to registering the fact itself, can only do so by also declaring an effective period it does not need. That produces period columns nobody asked for in every generated artifact. This is a normal requirement in strongly governed environments such as the military, regulated industries and audit heavy organisations.

The naming is part of the problem. The current options are phrased in temporal database terms, where valid time reads as if it were about correctness and transaction time reads as a database or business transaction. In business terms these are the effective period, the registration history, and the decision moment.

Expected: the three can be chosen independently, including the combination of registration history plus decision moment without an effective period; and they are named in terms a modeller recognises. Existing models must keep working unchanged.