Revise a part
The robot's arm 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 order 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 Orders → New, but you'll usually start from the bracket itself. Its part header has a "Create Change Order" action, its row in the parts table has the same, and the method's version menu — the one with New Version — offers New Change Order 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 order so the fix traces back to the problem.
However you start, the header form is short: a "Name", a "Category" (your change-order types, seeded with Design improvement, Obsolescence, and Cost reduction), a "Reason for Change" and "Description of Change", an "Owner", "Priority", dates, and an optional "Linked NCR". The affected item is the unit of work, and the picker is deliberately narrow: Parts and Tools only. A raw material or a 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 order shows a heading right on its detail page — "This part is on 1 open change order" — with the change order linked, so nobody revises a design that's already mid-change.
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 order. 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 order. 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 order, because it decides both what you can touch and what release will create.
- 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 letter). You edit its attributes, documents, and method; release reveals the new revision.
- New Part derives a brand-new part number from this one. Release reveals it and points the old part at it.
Only Revision and New Part create a new item.
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 or a New Part creates a new item alongside the old one, which is why each of those auto-writes a supersession at release. 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 order 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 team. There's no separate approval step to configure — the stages are the workflow, and the change order is its own gate.
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 order 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. 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 order 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.