The data from the source table through the load, post-load/pre-perm stage and then perm table in the baseline code is left intact with few or no transformations. Changes to these tables in future releases are limited and require a minimal number of required changes to then readd custom columns to this handful of tables, tf a patch or upgrade disrupts their infrastructure. As a result, add new custom columns to the existing tables as is recommended for the load tables. If the customizations occur after a historic load for a perm table like perm_transaction_history, which only adds new records on an incremental basis, any custom columns added to that table must get populated using a full historic reload or a special one-time script to update the perm table with the missing column data.