I mean, do not divide as you like. for example, if you have a record "a/b/c/d/", then you should not divide it by "a", "b", "c" or "d"
I'd say you can still divide it to a, b, c and d parts, as long as removal of any one of the parts is prevented or noticeable.
For example, a summary record of e (all of the above) on a, b ,c and d means you can no longer delete and c and never know it existed.
Another way would be to reference for example this as being part 2 of 5. This would be similar to page numbers which can also denote wholeness or integrity of a document.
Taking it to the next level would involve test-suite setups, where later sections do not replace the previous one in an identifiable (e.g. part 2 under rev 1 to a different part 2 under revision 2) but take a unique place in an expansive set.
This is the core principle behind the often little understood practice of decadal (groups of ten) increments in manual maintenance of for example requirements documentation. This practice allow additions to the requirements set later on to still follow some imposed logical structure (for a little while). Else it could seem that a requirement has either transformed (replacement damages long-term integrity of directly referencing the requirement without the higher-level document identifier) or having a catch-all 'these all came later' numbered set of additional requirements at the end making reading and execution of protocols more difficult.