Kord logoKord

Blog

You forked the folder. The tags didn't follow.

Copying a base design for a new site is fast. Renaming four hundred equipment tags across P&IDs, datasheets, line lists, and calcs is where base-design programs quietly bleed margin.

Kord vs Bluebeam

You won the second site. Same skid, different plot plan, new customer tag convention. Engineering copies last year's submittal folder, which is sensible, and renames the top-level project number. By Friday the P&IDs say WTP-2. Half the datasheets still say WTP-1. The line list uses a hybrid that made sense to whoever edited it at 11 p.m.

This is not a rookie mistake. It is the default outcome when a base design forks without a rename pass that treats the document set as one linked system.

Why tag renames are worse than they look

A tag is not a string in one drawing. Pump P-101A appears on the P&ID, the pump datasheet, the motor spec, the I/O list, the cause-and-effect matrix, the 3D model name, the procurement description, and three cells in the heat and mass balance. CAD tools propagate tags inside a model. They do not propagate across the Word spec your process engineer has open in another building.

  • P&ID updated in AutoCAD; Excel line list filtered and bulk-replaced, except the two tabs nobody opens.
  • Customer tag format requires prefix change; narrative specs still use internal tags in prose.
  • Equipment deleted on the fork; orphan references remain in relief studies and shutdown narratives.
  • Vendor submittals arrive tagged for the base project; as-built package never reconciled.

The site that shipped with the wrong prefix

On one modular water project the fork was rushed for a bid deadline. Instrument tags on the P&IDs were updated. The hook-up diagrams were not. Field techs wired to I-201 through I-208 on paper that did not match the panel schedule. Commissioning lost a week. The root cause was not bad drafting. It was no cross-file check after the fork.

Forking a folder is instant. Forking a consistent document set is a engineering task with a checklist.

How Kord finishes the rename

  • Folder forking copies the base set as a tracked fork, so the new site is a controlled change against WTP-1, not an orphaned copy no tool understands.
  • Kord's AI reads across the package and flags the tags that didn't follow: the datasheets still on WTP-1, the line-list tabs nobody opened, the hook-up diagram still wired to I-201 through I-208.
  • Native diffs cover every format the tag lives in — P&ID, Excel line list, Word spec, datasheet — so a prefix that changed in the drawing but not the prose shows up as a real difference.
  • Vendor and customer documents synced into the fork are in scope for the same check, so references 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 verified set, not WTP-1 with a new cover sheet.

Teams running multiple deployments from one standard design feel this pain every quarter. PLM will not help, because the parts are mostly the same. File storage will not help, because it holds copies, not relationships. What helps is treating the fork as a controlled change event: diff the new site against the base, review the diffs as a set, release with a trail. That is the workflow we built folder forking for in Kord. Not glamour work, but the difference between shipping WTP-2 and shipping WTP-1 with a new cover sheet.

See document-set review on your deliverables

Book a demoor