Lifecycle & release
The five change-notice stages, the Implementation lock and Reopen, the impact panel, the diff review, and exactly what release does when a change notice reaches Done.
A change notice advances forward one stage at a time. There's no approval toggle — the stages are the workflow, and the change notice is its own release gate. There are two ways back: Reopen at "Implementation" sends it one stage back to "Engineering Complete", and "Cancel" — available from every open stage — closes it, after which Reopen returns it to "Draft".
The stages
The "Start", "Implementation", and "Done" transitions each notify the people on the change notice: the assignee, plus everyone assigned an action task. Whoever made the transition isn't notified of their own action, and a change notice with no assignee and no assigned tasks advances silently. "Engineering Complete" is silent for everyone. Once a change notice reaches "Done" it is locked — every editor is read-only. "Cancelled" is locked too, but not lost: cancelling keeps every affected item's draft, and "Reopen" takes the change notice back to "Draft" to pick up where it left off. Only "Done" is permanent. Deleting a change notice is the destructive path — that discards each affected item's draft and any new items the change notice minted, so nothing is orphaned.
Implementation freezes the engineering content
Advancing to "Implementation" means "we are now rolling this out." From that moment the engineering content is read-only, so what's being implemented can't shift underneath the people implementing it. The workflow content stays editable, because coordinating the rollout is exactly the work that happens at this stage.
| Locked at Implementation (engineering) | Still editable at Implementation (workflow) |
|---|---|
| Adding or removing affected items | Action tasks — add, complete, skip, reorder, delete |
| Changing an affected item's change type | Assignee |
| The staged Bill of Material and Bill of Process drafts | Due date |
| The cutover config (supersession mode, discontinuation date, successor effectivity date) | Priority |
| Reason for Change and Description of Change | Category |
The lock is enforced on the server, not just greyed out in the UI. If a stale tab tries to write a frozen field you get "This change notice is being implemented, so its changes are locked. Reopen it to make changes."
Reviewing still works while frozen.
Freezing only blocks writes. The Changes rollup, each affected item's diff, and the impact panel all stay visible at Implementation — you can read the whole change, you just can't edit it.
Reopen
If review at Implementation turns up something that has to change, use Reopen in the ⋮ menu next to the change notice id. It sends the notice back one stage to "Engineering Complete", which unfreezes the affected items, the drafts, the cutover config, and the narrative fields. Nothing you've already done is discarded — the drafts, diffs, and action tasks are exactly as you left them. Edit, then advance to Implementation again. (The same Reopen action appears on a "Cancelled" notice, where it returns it to "Draft" instead.)
Done is terminal — there is no reopen from Done.
Reopen exists only at "Implementation" (before release) and at "Cancelled" (nothing was released). Releasing to "Done" has already activated the new method versions, revealed the new items, and written the supersessions that downstream MRP and Get Method are now acting on. Un-doing that would mean retracting live planning decisions, so Carbon doesn't offer it. To change the same parts again, raise a new change notice — the released methods and items are its starting point.
The impact panel
Alongside the affected items, a change notice shows an Impact panel: a where-used tree for each affected item across jobs, job materials, method materials, purchase orders, receipts, quotes, issues, maintenance, and assembly instructions.
Impact is informational — it never blocks release.
The panel is there so you can see what a change touches before you commit, not to gate you. Nothing in it stops a release; the copy says as much: "Where the affected items are used across the system. Informational — nothing here blocks releasing."
Review the changes, then release
You don't have to wait for release to see what a change notice does. The overview page carries a Changes card, between the description and the action tasks, that rolls up every affected item's diff as you author it — each item labeled with its change type, its diff rendered read-only. It's the same view the release dialog shows, available the whole time so you can check your work before you commit. An item with nothing edited yet reads "No changes yet."
Release itself lives on the change notice at "Implementation". The "Release change notice" dialog lays out that same per-item diff one more time before you commit — "Review each item's changes, then confirm — releasing can't be undone."
Each item's diff compares its edited draft against the method it was snapshotted from, across four sections:
- Bill of Materials — added, removed, and modified BoM lines, field by field.
- Bill of Process — added, removed, and modified operations and their steps, parameters, and tools.
- Properties — changed item fields (name, description, unit of measure, tracking type, replenishment system, and the rest), one row per changed column.
- Supplier Parts — for a purchased Revision, Replacement Part, or New Part, the suppliers you set up on the line, each listed as an addition with its part number, unit price, min order qty, order multiple, conversion factor, and purchasing unit. A draft starts with none, so every supplier you add shows here.
The diff is exact 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.
What release does
On confirm, Carbon walks the affected items and, per change type:
- Activates the draft method — it becomes the new Active version and the prior Active version is Archived (kept as history, never deleted).
- Reveals the new item — for a Revision, Replacement Part, or New Part, the newly created item is switched live and stamped with the change notice id. A Version has no new item.
- Writes the supersession — for a Revision or Replacement Part only, from the old item to the new one, using that affected item's cutover settings. A New Part has no predecessor, so it supersedes nothing. See Supersession & cutover.
New Part items are released first, so a parent assembly whose draft BoM references a consolidated new part finds it already active. When every affected item is processed, the change notice flips to "Done".
Release is idempotent, not one big transaction.
Each affected item is marked done the moment its draft's change-notice id is cleared, so a re-run skips items already released and resumes at the first unreleased one. The final flip to "Done" is a compare-and-swap on the "Implementation" status, so two people releasing at once can't double-apply.
Parallel change notices on the same part
Two change notices can revise the same part at once. Each drafts its own method version, and Carbon steps around version collisions so they don't clobber each other. Whichever releases second activates on top of the first, and the earlier version is archived as history rather than overwritten — so no work is lost. There's no merge-conflict step to resolve.