Change notices
How Carbon drafts an engineering change against real methods, reviews it as a diff, and releases it so downstream planning supersedes the versions it replaces.
A change notice groups the parts whose designs are changing, revises each one on a hidden draft, and releases them together. It answers "what changed, who owns it, and what does the new version supersede?" without touching a live method until you release.
The model is deliberately top-down. You pick the affected items first, then edit each item's real
(its bill of materials and bill of process) inside the change notice. Nothing
about the part moves for planning, jobs, or costing until release. Change notices live under Items → Change
Notices, and every action is gated by the parts permission.
The affected item is the unit of work
A change notice is a header plus a list of affected items. The picker accepts Parts only — materials, consumables, services, and tools have no path in the change-notice UI, so they're excluded. Each affected item carries its own , its own edits, and its own cutover configuration.
Adding an affected item snapshots the item's live Active method into a new Draft method stamped with the change notice's id. That draft is hidden from every version switcher, copy-target picker, and MRP, job, or cost read until release. You edit it with the same Bill of Material, Bill of Process, and Part Properties editors you use anywhere else.
The draft is a real method, not a staged copy.
Carbon does not mirror your edits into shadow tables. An affected item's edits live on an actual make method whose change-notice id is set, which is why the diff is exact and release is just an activation. The draft is invisible everywhere else precisely because that id is set — clearing it at release is what makes the draft live.
Find one in the list
Items → Change Notices lists every change notice. Because the affected item is the unit of work, each row expands to reveal the parts it changes — one line per affected item, with its change type badge and, for a Revision or Replacement Part, the old item number arrowed to the new one (P000123 → P000124). A New Part shows a single id — it's net-new, with no predecessor to arrow from. You see what a change notice touches without opening it.
To find the change notices that touch a specific part, use the Item filter. Pick one or more items and the list narrows to change notices that affect them. The Items column that backs the filter is hidden by default; turn it on from the column toggle if you want it in view or in a CSV export.
How the pieces fit
Every entry point — the standalone form, a part or tool header, the parts table, the method version menu, and a quality issue — plus how change notices surface back on a part.
Version, Revision, Replacement Part, and New Part: what each lets you edit and what release creates.
The five stages, the Implementation lock and Reopen, the diff review, the impact panel, and what release actually does.
How a released revision phases over, and how MRP and Get Method honor it downstream.
The change-notice category lookup, the reusable action-task templates, and linking a task to Linear.