You won the second site. Same skid, different plot plan, new customer tag convention. Engineering copies last year's submittal folder (sensible) and renames the top-level project number. By Friday the P&IDs say WTP-2. About half the datasheets still say WTP-1. The line list has a hybrid that made sense to whoever was in it at eleven at night.

This isn't a rookie error. It's the default outcome when a base design forks and nobody runs a rename pass that treats the set as one linked thing.

Why tag renames are worse than they look

A tag isn't a string in one drawing. Pump P-101A shows up on the P&ID, the pump datasheet, the motor spec, the I/O list, the cause-and-effect matrix, the 3D model tree, the procurement description, and three cells of the heat and mass balance. Your CAD tool will propagate a tag inside its own model all day. It has no idea the Word spec is open on a process engineer's screen in the next building.

• The P&ID gets fixed in AutoCAD; the Excel line list gets a filter-and-replace, except the two tabs nobody ever opens.
• The customer format needs a new prefix; the narrative specs still call things by the internal tag in the middle of a sentence.
• A piece of equipment got deleted on the fork, but its tag still haunts the relief study and the shutdown narrative.
• Vendor submittals show up tagged for the base project, and the as-built package never gets reconciled back.

The site that shipped with the wrong prefix

On one modular water job the fork got rushed for a bid date. The instrument tags on the P&IDs were updated. The hook-up drawings weren't. Field techs wired to I-201 through I-208 off paper that didn't match the panel schedule, and commissioning lost the better part of a week to it. The root cause wasn't bad drafting. Nobody cross-checked the set after the fork.

Copying the folder is instant. Getting the copy to still agree with itself is the part that takes real work.

How Kord finishes the rename

• The fork copies the base set as a tracked branch, so the new site is a controlled change against WTP-1 rather than an orphan copy no tool understands.
• Kord's AI reads across the package and calls out the tags that didn't follow: the datasheets still on WTP-1, the line-list tabs nobody opened, the hook-up drawing still wired to I-201 through I-208.
• Every format the tag lives in gets a native diff (P&ID, Excel line list, Word spec, datasheet) so a prefix that changed in the drawing but not the prose reads as a real difference.
• Vendor and customer documents you sync into the fork are in scope for the same check, so references still tagged for the base project get caught instead of shipping as-is.
• The fork releases as an audit-grade snapshot, so WTP-2 is a set someone verified, not WTP-1 with a new cover sheet.

If you run several deployments off one standard design, this shows up every quarter. PLM won't save you, because the parts barely changed. Storage won't either, because it holds copies, not relationships. What helps is treating the fork as a change event: diff the new site against the base, review the diffs as a set, release with a trail. It's unglamorous work, and on a multi-site program it's the whole ballgame. Either WTP-2 is its own verified set, or it's WTP-1 wearing a new cover sheet until someone finds out otherwise.