Migrate engineering decisions between repositories by inventorying affected records, preserving their original IDs and provenance, mapping dependencies, and reviewing their scope in the destination. Do not copy every accepted decision as automatically accepted: the new repository must explicitly adopt, supersede or reject each one.
Start from the code boundary
A repository split or extraction changes ownership and sometimes changes assumptions. Identify decisions governing the code, interfaces, data and operational responsibilities being moved. Include relevant negative decisions and supersession links, not only records whose titles name the component.
Preserve provenance
Keep the original stable ID or an explicit source-ID mapping, the source repository and commit, original status and decision date. Provenance lets future readers distinguish an inherited decision from one created locally and inspect the context that produced it.
- Source repository, path and commit.
- Original ID, lifecycle state and relationships.
- Destination owner and reviewed adoption status.
- Links to interfaces or decisions that remain elsewhere.
Re-evaluate scope and authority
A decision accepted in a monolith may become irrelevant or too broad in a service repository. Review each imported record as adopted, adapted, superseded, historical-only or rejected. Record the new decision when assumptions change instead of editing the inherited rationale to appear timeless.
Rebuild retrieval and checks
Validate links, discovery terms and lifecycle relationships in the destination. Update CI scopes and verify that every claimed enforcement check still covers the relevant files. Finally, run representative agent queries in both repositories to ensure each returns the authority it actually owns.