Revise a part
The satellite bus's antenna pointing bracket needs a thicker wall and one fewer fastener. In a lot of systems that means editing the live part and hoping nothing in flight notices. Carbon makes you do it deliberately: you open a , edit a hidden draft of the part's method, review exactly what changed, and release when it's ready. Until that moment, every job, plan, and cost calculation still sees the old bracket.
A change notice is the paper trail and the workbench at once. You revise on a draft that no one else can see, and release turns that draft into the new truth.
Start with the parts, not the change
You can start from Items → Change Notices → New, but you'll usually start from the bracket itself. Its part header has a "Create Change Notice" action, its row in the parts table has the same, and the method's version menu — the one with New Version — offers New Change Notice right where you're looking at the recipe. Each of those pre-attaches the bracket as the first affected item. A change can even start from a quality issue, which links the non-conformance to the change notice so the fix traces back to the problem.
However you start, the header form is short: a "Name", a "Category" (your change-notice types, seeded with a starter set like Design Improvement, Cost Reduction, and Obsolescence / End-of-Life), a "Reason for Change" and "Description of Change", an "Owner", "Priority", and dates. If you started from a quality issue, that non-conformance rides along as the linked issue. The affected item is the unit of work, and once you're on the change notice the Add Affected Item picker is deliberately narrow: Parts only. A material, consumable, or service doesn't carry an engineering revision, so it never appears.
Before you touch the bracket, though, its own page already warned you this was coming. A part that's on an open change notice shows a heading right on its detail page — "This part is on 1 open change notice" — with the change notice linked, so nobody revises a design that's already mid-change. The alert informs rather than blocks: a second change notice on the same part is allowed, and Carbon keeps their draft versions from colliding, so a deliberate parallel change is fine.
You pick the parts first, then edit them in place.
Carbon doesn't ask you to describe a change as a list of add-this, delete-that rows. You select the affected part and then edit its actual bill of materials and bill of process inside the change notice. The change is whatever the finished draft says it is.
Draft the change in place
Add the bracket and Carbon quietly snapshots its live into a new Draft version stamped to this change notice. That draft is invisible everywhere else — it won't show in a version switcher, a copy-target list, or anything MRP, jobs, or costing read. You edit it with the same Bill of Material and Bill of Process editors you'd use on the part directly.
Before you edit, pick a change type on the affected item. It's the most consequential choice on the whole change notice, because it decides both what you can touch and what release will create. You can switch it later, but not for free: switching discards the draft and mints a fresh one from the live method, so any edits you'd made are reset. Decide the type first, then edit.
- revises how the same part is made. You edit its BoM and BoP; release publishes a new method version and archives the old one. No new part, nothing superseded.
- Revision mints a new revision of the part (same Part ID, next revision). You edit its attributes, documents, and method; release reveals the new revision and supersedes the old one.
- Replacement Part derives a brand-new part number from this one. Release reveals it and supersedes the old part with it. The 1:1 replacement.
- New Part introduces a genuinely new part with no old part behind it. Release reveals it, but supersedes nothing, because there's no predecessor to phase out.
Only Revision and Replacement Part supersede.
This trips people up. A Version bumps the recipe on the existing bracket, so existing stock and history stay put and nothing is superseded. A Revision and a Replacement Part each derive a new item from the old one, so each auto-writes a supersession at release. A New Part is net-new — there's no old part to phase out, so it supersedes nothing. Pick the wrong type and you either strand stock or fail to phase it over. A purchased part has no method to version, so adding a Buy item lands on Revision automatically.
For the bracket we want the wall change to carry a new drawing revision and phase over cleanly, so this is a Revision. You thicken the wall in the attributes, drop the extra fastener line from the BoM, and attach the updated drawing — all on the draft.
A bought revision releases un-buyable unless you set its supplier up first.
If the revised part were purchased instead of made, its line would carry a Supplier Parts grid. The draft starts with none, because the old revision's suppliers aren't copied over. Leave it empty and the new part releases with nowhere to buy it — no purchase order can reference it. So for a Buy revision you add the supplier, part number, price, and order quantities on the line before you release.
Review the diff
Advance the change notice through its stages: Draft, then "Start", then "Engineering Complete", then "Implementation". It only moves forward, one step at a time, and "Start", "Implementation", and "Done" each notify the assignee and the action-task assignees, so the people working the change hear about every stage it enters. There's no separate approval step to configure — the stages are the workflow, and the change notice is its own gate. If the change doesn't pan out, you're not trapped in the forward march either: a "Cancel" action sits in the header at every open stage. Cancelling locks the change notice but keeps every draft, and "Reopen" takes it back to Draft later with your edits intact, so shelving a change costs nothing.
You don't have to reach Implementation to see what you've done. The overview page carries a Changes card that rolls up every affected item's diff as you edit — the dropped fastener, the thicker wall, any supplier you added — so the review is available the whole time, not just at the gate.
At "Implementation" the "Release" action opens. It doesn't just apply the change: it shows you every affected item's change as a read-only diff first. Materials added and removed, operations and their steps changed, attributes that moved — laid out line by line against the method you snapshotted from.
The diff is real because the draft is real.
There's no shadow copy of your edits to drift out of sync. You edited an actual draft method, so the diff is simply that draft compared against the live one it came from. What you review is exactly what releases.
Release, and let supersession carry it
Confirm the release and Carbon walks the affected items. For the bracket revision it activates the draft method, archives the prior version, reveals the new revision as a live item, and writes a from the old revision to the new one. When every item is done, the change notice flips to "Done" and locks as a read-only record.
You never wrote that supersession by hand. You only chose how it phases over, through the affected item's cutover fields: a (defaulting to Consume First), a discontinuation date, and a successor effectivity date. From there, planning takes over.
Consume First exhausts on-hand of the old bracket before switching; Prefer New redirects new demand immediately. Once the successor is effective, MRP redirects planned demand to the new revision and Get Method substitutes it onto new jobs, recording where the substitution came from.
Release steers the future, not the past.
Existing stock stays on the old bracket, and any job already created keeps the exact material and method version it was built against. The same goes for paperwork: an open purchase order or quote line that names the old revision keeps it, and nothing warns or rewrites it at release. Supersession only touches forward planning — a job cut after the effectivity date picks up the new revision, one cut before it does not. That's what makes releasing safe on a busy floor.
Afterward the new revision carries a "Created by CN-…" back-link to the change notice that made it, and the bracket's page shows its full change history. The trail from "the wall was too thin" to the released revision is one click, and the floor never built a single bracket against a design that wasn't done.