Date: 2026-02-12
Accepted
Two patterns frequently appear in BN/mod data:
- legacy IDs that were renamed over time (migrations);
- layered overrides that inherit from the same visible ID (self-copy).
Without explicit architectural handling, these patterns can cause broken inheritance, recursion issues, and misleading provenance.
Item lookups and parent traversal follow migration mappings so legacy IDs resolve to the current canonical object identity.
When an override inherits from its own ID, the parent is interpreted as the previous layer in load order, not the same node again. This preserves incremental extension behavior across multiple mods.
Provenance collapses repeated self-copy steps that keep the same identity, so lineage highlights meaningful identity changes instead of noisy intermediate hops.
Public provenance queries currently expect canonical/current identifiers at entry. Migration mapping is guaranteed inside object lookup and parent traversal logic.
- stronger backward compatibility for renamed items;
- reliable behavior for common mod layering patterns;
- cleaner provenance narratives for heavily overridden objects.
- more complex identity and parent resolution rules;
- migration quality must stay aligned with upstream data evolution.