Data vault 2.0 hub end date

I'm creating a data vault that tracks a business key where it's possible that an instance can be present in one load, removed from another load, then reappear in a third load down the line. From what I can tell from existing DV (especially DV 2.0) documentation is that this scenario isn't accommodated in the architecture - I've sometimes seen hubs where keys have end dates but not where they can be repeated at a later point.

I can imagine that capturing the timeline of a key that behaves like this may be considered an anti-pattern - in order to create a unique hash we would need to include the load date in the hashing algorithm, which would be difficult to return for satellite and link rows that weren't included in the same load as the hub row.

My question is, what would be the best approach to capturing this information?

1. Load as described above, doing some sort of lookup to retrieve the correct load date from the hub for satellite and links in order to create the hash
2. Not put end dates on the hub, but rely on the end dates of a given 'primary' satellite to determine whether the hub key is still current (i.e. all satellite rows have an end date, so hub is not current, downstream consumers would need to know to join on this satellite)
3. Do nothing, just allow the key to persist in perpetuity for reporting purposes
4. Something else...?

what you're looking for is already defined in the DV 2.0, this is the "Status tracking satellite".

Basically, it keep track where a BK was create, update and deleted.

Please watch https://www.scalefree.com/knowledge/webinars/data-vault-friday/cdc-status-tracking-satellite-and-delta-lake/ for more information.