Effective dating: links that stop being true

Give a relation a validity period, so a link that has ended drops out of lookups, rollups and anything that travels the relationship — without anyone having to remember to unlink it. Turn it on per relation field Dating is a setting on a Relation field, in the field editor. With it on, each link can carry a from and a to — this employee reported to that manager from January to June; this product sat in that category until the range was renamed. Switching it on changes nothing until somebody actually dates something. An undated link is true at every instant, so existing data keeps behaving exactly as it did. Half-open periods A period includes its from and excludes its to. A link running to 1 July and another starting 1 July do not both cover that day — the first has already ended when the second begins. This convention is applied in exactly one place in the product rather than restated at each call site, which is what stops half the comparisons ending up inclusive on both ends. The symptom of getting it wrong is a link that belongs to two periods for a single day, and it is precisely the kind of thing nobody notices until a total is out by one. You choose whether periods are measured by day or by instant when you turn dating on. Overlaps are refused by default Writing a period that overlaps an existing one on the same link is rejected unless you say otherwise. A record quietly having two parents on the same day is the kind of wrong that only ever surfaces when one report disagrees with another. Where overlap is genuinely real — someone who honestly did report to two managers — you can soften the policy on that field to warn (allowed, but flagged) or allow (silent). What this does today Dated links are stored, validated and policed on write, and resolution honours the period: a link whose period has ended is not returned, so lookups, rollups and computed fields that travel that relationship stop counting it automatically. What is not here yet is reporting as of a chosen past date — asking the workspace to show the world as it stood last March. The resolver already takes a date; nothing in the interface asks you for one. Today's behaviour is "as of now", correctly. Tips • Leave the to empty for the current arrangement — an open-ended period is the normal case, not a special one. • Use by day unless you genuinely need sub-day precision; it makes the half-open rule easy to reason about at a glance. • Keep overlap on reject for hierarchies (a record with one parent) and relax it only for genuinely many-to-many history. Good to know • Changing granularity from instant to day on a field that already has instant-precision periods reinterprets where the boundaries fall — check the data before switching. • An overlap policy of allow means a rollup can legitimately count one record under two parents. That may be correct; make sure it is intended. • Dating a relation does not date the RECORDS. A record deleted while its link was in force is still deleted — periods describe the link, not the thing at either end. Who can do what • Turning dating on, and choosing granularity and overlap policy, is part of editing the field — Admin-only. • Setting a period on a link needs the same edit access as making the link.