Lifecycle & release
The five change-notice stages, the Implementation lock and Reopen, the impact panel, the diff review, and what release does at Done.
A change notice advances one stage at a time; its stages are the release workflow. Reopen from Implementation returns it to Engineering Complete. Cancel closes a notice from any open stage, and Reopen from Cancelled 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
At Implementation, engineering content becomes read-only while workflow fields remain editable for rollout coordination.
| 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
To change engineering content during Implementation, select Reopen from the ⋮ menu. The notice returns to Engineering Complete, preserving drafts, diffs, and tasks while unlocking affected items, cutover configuration, and narrative fields. A Cancelled notice uses the same action to return to Draft.
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
The overview's Changes card shows a read-only diff for every affected item during authoring. The release dialog uses the same view. Items without edits display "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 on the line, with their part number, unit price, min order qty, order multiple, conversion factor, and purchasing unit. A Revision starts with its source revision's suppliers, so only the ones you added, changed, or removed show here. A Replacement Part or New Part starts with none, so every supplier you add shows as an addition.
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 confirmation, Carbon processes each affected item according to its 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.