Part 038 — Change Orders, Supplemental Orders, Cancellation, and In-Flight Modification

Positioning

Order yang sudah submitted atau sedang diproses tidak boleh diperlakukan seperti draft biasa.

Setelah fulfillment dimulai:

• supplier order mungkin sudah dibuat;
• capacity sudah di-reserve;
• perangkat sudah dikirim;
• service sudah diaktifkan;
• Inventory sudah berubah;
• Billing sudah berjalan;
• dan customer promise sudah diberikan.

Perubahan terhadap Order harus memilih model yang tepat:

• amendment;
• supplement;
• cancellation;
• replacement;
• corrective order;
• atau product change baru.

Core thesis: in-flight Order harus immutable secara historis tetapi changeable melalui first-class change objects. Setiap perubahan harus memiliki source intent, delta, scope, authority, dependency impact, fulfillment impact, commercial impact, dan explicit lineage ke original Order.

1. Why In-Flight Change Is Hard

Satu perubahan sederhana seperti:

requestedDate = newDate

dapat memengaruhi:

• appointment;
• supplier;
• capacity;
• critical path;
• SLA;
• customer communication;
• price;
• Agreement;
• dan Billing.

2. Draft Edit versus Order Change

Draft Edit

Mengubah Order sebelum submission/commit.

Order Change

Mengubah committed or executing intent melalui governed lifecycle.

3. Historical Immutability

Original submitted Order harus tetap dapat direkonstruksi.

4. Effective Mutability

Current intended outcome dapat berubah melalui:

• Amendment;
• Supplemental Order;
• Cancellation;
• Replacement Order;
• atau new Product Order.

5. Change Object

First-class Change object menyimpan:

• identity;
• source Order;
• requested delta;
• reason;
• authority;
• impact;
• lifecycle;
• dan outcome.

6. Change Identity

Contoh:

Order Change ID: OCH-2026-000123
Original Order: PO-123

7. Change Version

Gunakan optimistic concurrency.

8. Change Type

Possible:

• AMENDMENT;
• SUPPLEMENT;
• CANCELLATION;
• REPLACEMENT;
• CORRECTION;
• EXPEDITE;
• RESCHEDULE;
• SCOPE_REDUCTION;
• SCOPE_EXPANSION.

9. Amendment

Mengubah existing in-flight Order intent.

10. Supplement

Menambahkan related scope tanpa mengubah original history.

11. Cancellation

Menghentikan seluruh atau sebagian remaining work.

12. Replacement

Mengganti original Order dengan new Order/change set.

13. Correction

Memperbaiki recording/technical defect, bukan negotiated business change.

14. Expedite

Mengubah priority/schedule dengan possible operational/commercial impact.

15. Reschedule

Mengubah dates/windows tanpa selalu mengubah product scope.

16. Scope Reduction

Menghapus atau menurunkan remaining scope.

17. Scope Expansion

Menambah products/sites/features.

Sering lebih aman sebagai supplement/new Order.

18. Change Request versus Change Order

Change Request

Permintaan perubahan yang belum disetujui/applied.

Change Order

Approved/committed executable change.

19. Change Lifecycle

Possible states:

• DRAFT;
• SUBMITTED;
• VALIDATING;
• IMPACT_ASSESSMENT;
• PENDING_APPROVAL;
• APPROVED;
• PLANNING;
• APPLIED;
• PARTIALLY_APPLIED;
• REJECTED;
• CANCELLED;
• FAILED;
• SUPERSEDED.

20. DRAFT

Change dapat diedit.

21. SUBMITTED

Requester commits the change request for assessment.

22. IMPACT_ASSESSMENT

System/domain owners calculate effects.

23. PENDING_APPROVAL

Commercial/operational authority required.

24. APPROVED

Change is authorized but not necessarily applied.

25. PLANNING

New/dependent fulfillment plan is created.

26. APPLIED

Target change has been incorporated into Order/Plan state.

27. PARTIALLY_APPLIED

Some scope changed, residual scope remains.

28. REJECTED

Change cannot or will not be accepted.

29. FAILED

Approved change failed during application.

Original Order truth remains.

30. SUPERSEDED

A newer Change replaces it.

31. Change Subject

Can target:

• Order;
• Order Item;
• item group;
• site;
• delivery wave;
• fulfillment unit;
• requested date;
• party/contact;
• atau priority.

32. Change Scope

Must identify exact source identities and versions.

33. Source Order Snapshot

Change references:

• Order ID/version;
• item versions;
• active Plan version;
• execution states;
• and relevant downstream references.

34. Delta

A Delta describes requested difference.

35. Delta versus Target State

Delta

What changed.

Target State

What final state should become.

Use both where possible.

36. Field-Level Delta

Examples:

• date change;
• contact change;
• priority change.

37. Structural Delta

Examples:

• add item;
• remove item;
• replace Product;
• change dependency.

38. Commercial Delta

Examples:

• quantity;
• price;
• term;
• cancellation fee;
• and committed date.

39. Operational Delta

Examples:

• supplier;
• route;
• appointment;
• resource plan.

Operational delta should not change accepted Product outcome silently.

40. Change Provenance

Store:

• requestedBy;
• reason;
• customer request evidence;
• source Quote/Agreement if applicable;
• and channel.

41. Customer-Initiated Change

May require:

• new Quote;
• approval;
• acceptance;
• Agreement amendment;
• and Product Order change.

42. Provider-Initiated Change

May be caused by:

• capacity;
• supplier;
• incident;
• product retirement;
• or correction.

Customer consent may be required.

43. System-Initiated Change

Examples:

• automatic replan;
• expired reservation;
• retry path.

Should remain within pre-approved operational boundary.

44. Commercial versus Operational Change

Commercial Change

Alters customer commitment.

Operational Change

Changes internal realization while preserving commitment.

45. Commercial Materiality

A change is material if it affects:

• product;
• quantity;
• price;
• term;
• legal obligation;
• accepted date promise;
• or customer risk.

46. Non-Material Operational Change

Examples:

• alternate internal resource;
• different technician;
• route change with same committed outcome.

47. Materiality Policy

Versioned policy determines required governance.

48. Requote Trigger

Examples:

• product scope changes;
• price changes;
• term changes;
• customer chooses alternative;
• and compensation changes commitment.

49. Reapproval Trigger

Examples:

• additional cost;
• expedite fee waiver;
• committed-date risk;
• supplier substitution;
• and margin impact.

50. Customer Reacceptance Trigger

Required when accepted commercial commitment changes materially.

51. Agreement Amendment Trigger

Required when governing contractual terms or commitments change.

52. Change Assessment

Assessment should answer:

• Can change be applied?
• Which completed/in-flight work is affected?
• What is reversible?
• What must be cancelled/compensated?
• Does it change customer promise?
• What are price/cost/date impacts?
• Which approval/consent is required?

53. Impact Dimensions

• Product;
• fulfillment;
• dependency graph;
• schedule;
• capacity;
• supplier;
• Inventory;
• Billing;
• Agreement;
• price/cost;
• customer;
• and regulatory.

54. Impact Assessment Identity

Store immutable assessment version.

55. Assessment Input Version

Pin:

• Order;
• item;
• Plan;
• Inventory;
• Agreement;
• and pricing snapshots.

56. Assessment Staleness

If execution progresses, assessment may become stale.

57. Apply-Time Revalidation

Before applying approved change, recheck actual state.

58. Change Window

A change may be valid only within a period.

59. Change Deadline

After certain milestone, change is prohibited or more expensive.

60. Point of No Return

Examples:

• custom hardware manufacturing starts;
• service cutover completes;
• regulatory order submitted;
• billing cycle closes.

61. Reversibility

Classify affected work as:

• not started;
• cancellable;
• compensatable;
• irreversible;
• or unknown.

62. In-Flight State Matrix

63. Unknown Outcome Guard

Do not apply conflicting Change while affected operation outcome is unknown.

64. Completed Scope

Completed work remains historical fact.

65. Pending Scope

Can often be directly amended or superseded.

66. In-Progress Scope

Requires participant capability analysis.

67. Irreversible Scope

Must remain and may create residual product/cost.

68. Change Capability

Each downstream domain should expose supported changes.

69. Capability Examples

• cancel pending;
• reschedule appointment;
• modify quantity;
• replace supplier item;
• change target date;
• no change after dispatch.

70. Capability Version

Retain version/effective period.

71. Capability Query

Assessment can query participants.

72. Capability Timeout

Unknown capability is not approval.

Route to manual review or conservative block.

73. Amendment Identity

An Amendment should reference:

• Original Order;
• source items;
• requested delta;
• effective date;
• and resulting Plan/Order versions.

74. Amendment Number

Business-readable sequence may be useful.

75. Amendment Line

Each changed item/field can be a line.

76. Line State

Possible:

• PROPOSED;
• VALID;
• APPROVED;
• APPLIED;
• REJECTED;
• FAILED;
• and SUPERSEDED.

77. Amendment Atomicity

May be:

• all lines together;
• grouped;
• or independent.

78. All-or-Nothing Amendment

If any required line cannot apply, none apply.

79. Partial Amendment

Only explicitly independent lines may apply separately.

80. Amendment Effective Time

May differ from request/approval/application time.

81. Future-Dated Amendment

Plan now, apply later.

82. Retroactive Amendment

High-risk and requires explicit authority.

83. Amendment of Draft Order

May collapse into ordinary draft edit.

84. Amendment of Submitted Order

Creates governed change lifecycle.

85. Amendment of Completed Order

Usually a new Product Order/action, Agreement amendment, or correction.

Do not rewrite completed Order.

86. Amendment versus New Order

Choose Amendment when:

• same committed execution remains active;
• change is supported in-flight;
• and lineage benefits from one process.

Choose new Order when:

• new Product lifecycle action;
• original completed;
• or participant cannot mutate in-flight work.

87. Supplemental Order

A Supplemental Order adds related scope.

88. Supplemental Identity

New Product Order ID plus link to original Order.

89. Supplement Relationship

Possible:

• supplements;
• extends;
• dependsOn;
• remediates;
• or completesResidualScope.

90. Supplement Use Cases

• add extra sites;
• add optional component;
• remedial work;
• additional installation;
• and post-acceptance operational data-driven work.

91. Supplement Is Not Amendment

Original Order remains unchanged.

92. Supplement Commercial Basis

May require:

• same accepted Quote;
• new Quote/Acceptance;
• Agreement entitlement;
• or internal no-charge authorization.

93. Supplemental Pricing

Do not assume original price applies.

94. Supplemental Dependencies

Supplement may depend on original Order milestones.

95. Supplemental Completion

Original and supplement have separate lifecycle.

96. Residual-Scope Supplement

Creates executable work for accepted scope not converted earlier.

97. Remediation Order

A new Order repairs or completes outcome after fallout.

98. Corrective Order

Fixes wrong Product state.

99. Replacement Order

Supersedes remaining intent of original Order.

100. Replacement Relationship

Store:

• original;
• replacement;
• scope;
• effective time;
• and reason.

101. Replacement Preconditions

• original state known;
• remaining work isolated;
• duplicate effects prevented;
• and customer/commercial basis valid.

102. Original Order State after Replacement

Possible:

• partially completed;
• cancelled remaining scope;
• superseded;
• or failed.

103. Cancellation

Cancellation requests stopping all or part of remaining Order intent.

104. Cancellation Identity

First-class Cancellation record.

105. Cancellation Scope

Possible:

• full Order;
• Order Item;
• item group;
• site;
• wave;
• fulfillment branch;
• or future recurring action.

106. Cancellation Reason

Examples:

• customer request;
• duplicate;
• provider inability;
• Agreement issue;
• compliance;
• and replacement.

107. Cancellation Requested versus Effective

A request can be accepted, rejected, or partially completed.

108. Cancellation Lifecycle

Possible:

• REQUESTED;
• ASSESSING;
• ACCEPTED;
• IN_PROGRESS;
• PARTIALLY_CANCELLED;
• COMPLETED;
• REJECTED;
• FAILED;
• and SUPERSEDED.

109. Cancellation Guard

Check:

• state;
• authority;
• completed work;
• point of no return;
• Agreement;
• cancellation fees;
• and downstream capabilities.

110. Cancellation before Dispatch

Often straightforward.

111. Cancellation after Dispatch

May require supplier cancellation and possible cost.

112. Cancellation during Installation

May require safe-stop procedure.

113. Cancellation after Activation

Use DELETE/termination Product Order, not cancellation of historical completed Order.

114. Partial Cancellation

Unaffected items continue.

115. Cancellation Dependency Impact

Dependent items may:

• cancel;
• block;
• replan;
• or continue degraded.

116. Cancellation Propagation

Send explicit cancel commands to downstream units.

117. Cancellation Acknowledgement

Remote receipt is not cancellation completion.

118. Unknown Cancellation Outcome

Reconcile before issuing another cancellation or replacement work.

119. Cancellation Compensation

Completed effects may require:

• deprovision;
• resource release;
• device return;
• credit;
• or penalty.

120. Cancellation Fee

May be:

• quoted;
• Agreement-defined;
• dynamically assessed;
• or waived by approval.

121. Refund/Credit

Separate financial process with lineage to cancelled scope.

122. Cancellation Date

Could be:

• requested;
• accepted;
• effective;
• or completed.

Keep distinct.

123. Cancellation of Future-Dated Work

May avoid operational effects but still have commercial implications.

124. Customer Notification

Communicate:

• accepted/rejected cancellation;
• completed scope;
• residual charges;
• and next steps.

125. Cancellation Completion Evidence

Examples:

• supplier cancelled;
• reservation released;
• service not activated;
• Inventory outcome;
• Billing adjustment.

126. Change Dependency Graph

A Change can generate delta graph against active Plan.

127. Delta Graph

Contains:

• nodes to add;
• nodes to cancel;
• nodes to modify;
• dependencies to replace;
• and compensations.

128. Graph Overlay

Apply change as overlay rather than editing published graph.

129. New Plan Version

Approved change produces new immutable Plan version.

130. Handover

Define:

• completed nodes retained;
• in-flight nodes adopted;
• cancelled nodes;
• replacement nodes;
• and effective cutover.

131. Re-Orchestration

Orchestrator transitions from old to new Plan.

132. Active Attempt Handling

For each active attempt:

• continue;
• cancel;
• wait;
• reconcile;
• or supersede after safe outcome.

133. Timer Migration

Move/cancel/recreate timers under new Plan version.

134. Reservation Migration

Transfer, release, or create reservations.

135. Appointment Migration

Cancel/reschedule using explicit appointment lifecycle.

136. Supplier Order Change

Supplier may support:

• modify;
• cancel/recreate;
• supplement;
• or no change.

137. Service Order Change

May create Service Order amendment or new Service Order.

138. Resource Order Change

May change reservation/allocation if supported.

139. Billing Change

Must preserve:

• accepted price;
• effective dates;
• credits;
• cancellations;
• and amendment lineage.

140. Inventory Change

Inventory should reflect actual as-built state, not only new target.

141. As-Ordered View

Current intended outcome after applied changes.

142. As-Built View

Actual realized state after partial/full execution.

143. Change Lineage

Trace:

Original Order
-> Change Request
-> Approval/Acceptance
-> New Plan
-> Downstream amendments
-> Inventory/Billing outcome

144. Commercial Delta

A structured delta should include:

• old/new product;
• old/new quantity;
• old/new price;
• old/new term;
• old/new date;
• and financial impact.

145. Execution Delta

Include:

• work completed;
• work cancelled;
• new work;
• changed dependencies;
• supplier/reservation changes;
• and residual work.

146. Customer Promise Delta

Include:

• old committed date;
• new committed date;
• scope;
• service level;
• and remedy.

147. Cost Delta

Internal cost impact may require approval.

148. Revenue Delta

Changes to charge timing or amount.

149. Margin Delta

May trigger commercial reapproval.

150. Tax Delta

Effective-date/product/site change can affect tax.

151. Agreement Delta

May require amendment.

152. Price Lock

Determine whether original price remains valid for changed scope.

153. Grandfathering

Policy may preserve original terms for unchanged scope.

154. Repricing Boundary

Only changed/new scope may be repriced under policy.

155. Proration

Cancellation/amendment may require partial-period charge/credit.

Part 020 provides pricing foundation; downstream Billing remains authoritative.

156. Change Approval

Possible authority domains:

• customer;
• commercial;
• finance;
• legal;
• operations;
• supplier;
• and risk.

157. Customer Consent

Store exact changed commitment and evidence.

158. Internal Operational Approval

May be required for risky replan.

159. Cancellation Approval

Needed for:

• high-value work;
• fee waiver;
• regulatory scope;
• or irreversible operations.

160. Approval Binding

Bind to exact Change version and impact assessment.

161. Assessment Change

If execution advances, approval may become stale.

162. Reapproval

Required when impact materially changes.

163. Change Idempotency

Repeated same Change application must not duplicate:

• amendments;
• supplemental Orders;
• cancel commands;
• reservations;
• credits;
• or notifications.

164. Change Business Key

Examples:

• source Order + customer change request ID;
• cancellation request ID;
• amendment number;
• residual scope ID.

165. Concurrent Changes

Two Changes may target same Order scope.

166. Conflict Detection

Examples:

• reschedule and cancel same item;
• two different target products;
• scope expansion while replacement pending;
• and price change during cancellation.

167. Change Lock/Reservation

Reserve affected scope for assessment/application.

168. Scope Version

Each item/group can have current change version.

169. Change Queue

Possible policy:

• serialize overlapping Changes;
• allow independent scopes;
• or merge compatible Changes.

170. Change Merge

Domain-aware only.

171. Change Supersession

A newer request may supersede older unapplied Change.

172. Applied Change Immutability

Do not modify applied Change.

Create correction/new Change.

173. Change versus Fallout

Fallout describes exception.

Change describes new intended action.

Fallout may initiate Change.

174. Change versus Replan

Replan changes operational realization.

Change may alter Product Order intent.

175. Change versus Correction

Correction repairs incorrect record/effect.

Amendment changes intended business outcome.

176. API Commands

Examples:

• CreateOrderChange;
• SubmitOrderAmendment;
• AssessOrderChange;
• ApproveOrderChange;
• ApplyOrderChange;
• CreateSupplementalOrder;
• RequestOrderCancellation;
• CancelOrderItem;
• ReplaceOrder;
• SupersedeOrderChange.

177. Change Request Contract

Should include:

sourceOrder
sourceVersion
scope
changeType
requestedDelta
reason
requestedEffectiveTime
customerEvidence
idempotencyKey

178. Impact Assessment API

Returns:

• feasibility;
• completed/in-flight impact;
• new/cancelled work;
• schedule;
• commercial delta;
• approvals;
• and risks.

179. Apply API

Requires exact approved Change and fresh assessment.

180. Dry Run

Preview:

• Plan overlay;
• downstream changes;
• cancellation effects;
• price/date impact;
• and residual outcomes.

181. Generic PATCH Risk

Patch hides:

• history;
• impact;
• approvals;
• and downstream synchronization.

182. Change Events

Representative events:

• OrderChangeRequested;
• OrderChangeAssessed;
• OrderChangeApproved;
• OrderAmendmentApplied;
• SupplementalOrderCreated;
• OrderCancellationRequested;
• OrderCancellationCompleted;
• OrderChangeRejected;
• OrderChangeFailed.

183. Event Payload

Include:

• Change ID;
• original Order;
• scope;
• type;
• state;
• and resulting Order/Plan references.

184. Outbox/Inbox

Change and cancellation flows require idempotent messaging.

185. Audit

Record:

• original state;
• requested target;
• assessment;
• approvals;
• application;
• and actual outcome.

186. Audit Diff

Keep semantic old/new values.

187. Customer-Facing History

May expose:

• change request;
• status;
• dates;
• and confirmed outcome.

Hide internal cost/risk.

188. Internal History

Includes:

• Plan diff;
• supplier effects;
• compensation;
• and approval reasoning.

189. Change Metrics

• requests per Order;
• approval rate;
• rejection rate;
• and application success.

190. In-Flight Change Rate

High rate may indicate poor initial data or unstable customer demand.

191. Cancellation Metrics

• full/partial;
• lifecycle stage;
• reason;
• fee;
• and success.

192. Assessment Latency

Time from request to decision-ready impact.

193. Application Latency

Time from approval to effective application.

194. Replan Rate

How often Change requires new Plan.

195. Commercial Delta Metrics

• additional revenue;
• credit/refund;
• margin impact;
• and approval impact.

196. Change Fallout Rate

Changes causing operational fallout.

197. Change SLI

Examples:

• zero applied Change without source/version/approval;
• all cancelled scopes have explicit downstream outcomes;
• no completed history overwritten;
• and all customer-material changes linked to consent.

Internal targets must be verified.

198. Reconciliation

Detect:

• Change marked applied but Plan unchanged;
• cancellation complete while supplier work active;
• supplemental Order missing lineage;
• Billing delta missing;
• and Inventory state inconsistent with changed target.

199. Stuck Change

Examples:

• assessment stale;
• approval pending;
• cancellation unknown;
• replan not published;
• and downstream amendment unacknowledged.

200. Recovery Commands

Examples:

• RefreshOrderChangeAssessment;
• ReconcileCancellationOutcome;
• ResumeChangeApplication;
• LinkSupplementalOrder;
• RepairChangeLineage;
• CloseChangeAsPartial;
• SupersedeStaleChange.

201. Change Incident

Examples:

• completed Order overwritten;
• cancellation creates duplicate termination;
• original and replacement both execute;
• customer date changed without notification;
• and price delta lost.

202. Incident Containment

Possible:

• pause old/new orchestration;
• freeze affected scope;
• reconcile active attempts;
• block Billing/Inventory mutation;
• and require corrective Change.

203. Amendment Smells

• mutable original Order;
• no Change ID;
• no impact assessment;
• and no apply-time revalidation.

204. Supplement Smells

• duplicate unrelated Order;
• no original linkage;
• original price copied blindly;
• and dependencies undocumented.

205. Cancellation Smells

• status set to CANCELLED immediately;
• downstream work ignored;
• completed scope deleted;
• and no fee/credit handling.

206. In-Flight Change Smells

• patch request sent to every downstream;
• unknown attempts ignored;
• and Plan edited in place.

207. Commercial Smells

• operational replan changes product outcome;
• customer promise changed silently;
• and Agreement/approval not revisited.

208. Anti-Patterns

Edit Submitted Order

Historical intent disappears.

Cancellation Equals Delete

Completed and irreversible effects vanish.

Supplement Equals Unrelated New Order

Lineage and dependency disappear.

Change without Impact Assessment

Unsafe downstream effects.

Apply Using Stale Assessment

Execution may have advanced.

Replan Equals Amendment

Operational and commercial boundaries collapse.

Replace before Reconciling Old Work

Duplicate fulfillment occurs.

209. Order Change Template

## Change Identity and Version

## Type

## Original Order / Item / Plan Versions

## Requester / Source / Reason

## Requested Delta and Target State

## Requested Effective Time

## Impact Assessment

## Commercial / Agreement / Approval Impact

## Fulfillment / Dependency / Schedule Impact

## Completed / In-Flight / Pending Scope

## Customer Consent

## Application Plan

## Resulting Order / Plan / Supplement

## Residual Outcome

## Audit

210. Amendment Line Template

Line ID:
Source Order Item:
Change type:
Old value/state:
Requested target:
Effective date:
Materiality:
Approval:
Application result:

211. Impact Assessment Template

Assessment ID/version:
Source versions:
Affected scope:
Completed work:
In-flight work:
Pending work:
Reversibility:
Capability results:
New/cancelled work:
Dependency changes:
Schedule delta:
Commercial delta:
Risks:
Required approvals/consent:
Valid until:

212. Supplemental Order Template

Supplemental Order:
Original Order:
Relationship type:
Commercial basis:
Added scope:
Dependencies:
Price/Agreement basis:
Requested dates:
Completion relationship:

213. Cancellation Template

Cancellation ID/version:
Order/item scope:
Reason:
Requested/effective dates:
Authority:
Completed/irreversible work:
Pending/in-flight work:
Downstream cancel commands:
Compensation:
Fees/credits:
Customer communication:
Outcome:

214. Plan Overlay Template

Original Plan/version:
Change:
Nodes retained:
Nodes cancelled:
Nodes superseded:
Nodes added:
Dependency changes:
Reservations:
Appointments:
Timers:
Handover point:
New Plan/version:

215. Commercial Delta Template

Old product/quantity/price/term/date:
New product/quantity/price/term/date:
Unchanged grandfathered scope:
Repricing scope:
Proration:
Fee/credit:
Tax impact:
Margin impact:
Agreement impact:
Approval/customer consent:

216. Change Invariants

Representative invariants:

• original submitted/completed Order remains reconstructable;
• applied Change references exact source versions;
• overlapping Changes are detected;
• unknown downstream outcomes are reconciled before conflicting Change;
• completed/irreversible effects are preserved;
• customer-material changes require governed consent;
• cancellation has explicit scope and downstream outcome;
• supplemental Orders retain original lineage;
• and applied Change is immutable.

217. Worked Example: Requested-Date Change before Start

No work dispatched.

Assessment shows:

• appointment/reservation updates only;
• no price impact;
• no customer reacceptance.

Amendment applies and publishes new Plan version.

218. Worked Example: Requested-Date Change after Supplier Dispatch

Supplier order already committed.

Assessment finds:

• supplier modify supported with fee;
• customer date impact;
• commercial approval required.

219. Worked Example: Add Five Sites

Original Order is in progress.

New sites require new commercial scope.

A Supplemental Order references original Order and new accepted Quote/Agreement basis.

220. Worked Example: Remove One Pending Site

Partial cancellation targets one site item.

Dependent router/appointment units cancel.

Completed sites continue.

221. Worked Example: Cancel after Activation

Service is active.

Do not cancel historical completed Order.

Create DELETE Product Order and Agreement/Billing termination process.

222. Worked Example: Replace Supplier

Original supplier has not started.

Operational replan selects alternate supplier while preserving Product/date/price.

No customer reacceptance if commitment unchanged.

223. Worked Example: Replace Supplier with Date Slip

Alternate supplier changes committed date.

Customer promise delta triggers notification and possibly consent/amendment.

224. Worked Example: In-Flight Product Upgrade Change

Customer changes target from 1 Gbps to 2 Gbps while capacity reservation exists.

Assessment:

• commercial requote;
• new approval;
• reservation replacement;
• Plan rework;
• old Change superseded.

225. Worked Example: Unknown Cancellation

Supplier cancellation call times out.

State remains cancellation-in-progress/unknown.

Reconciliation determines whether supplier Order still active before replacement begins.

226. Worked Example: Partially Applied Amendment

Contact and appointment date changed successfully.

Supplier quantity change rejected.

Independent lines permit partial application; residual line remains failed and explicit.

227. Worked Example: Completed Hardware Shipment

Customer cancels installation after custom hardware shipped.

Cancellation records:

• shipped asset residual;
• return/restocking process;
• fee/credit;
• and customer disposition.

228. Worked Example: Residual-Scope Supplement

Ten sites from a prior partial conversion become feasible.

A Supplemental Order references residual accepted scope and original Acceptance.

229. Worked Example: Concurrent Changes

One request cancels a site.

Another request reschedules same site.

Scope conflict prevents both applying concurrently.

230. Worked Example: Stale Impact Assessment

Assessment was approved when work was pending.

Before apply, installation completes.

Apply-time guard rejects and requests refreshed assessment/new change model.

231. Senior Engineer Operating Model

Keep original Order immutable

Changes become first-class objects.

Distinguish amendment, supplement, replacement, and cancellation

They solve different problems.

Assess actual execution state

Pending, in-flight, completed, irreversible, and unknown.

Revalidate before apply

Plans evolve while approval waits.

Separate commercial and operational changes

Only commercial changes require customer/Agreement path.

Apply change as graph overlay

Do not mutate published Plan in place.

Preserve residual outcomes

Especially cancellation and partial application.

Serialize overlapping scope

Avoid contradictory Changes.

Reconcile every boundary

Plan, supplier, Inventory, Billing, and customer promise.

232. Internal Verification Checklist

Mutability and change model

• Apakah in-flight order mutable?
• Are submitted/completed Orders immutable historically?
• Which first-class Change types exist?
• How are Order version and Change version distinguished?

Amendment

• What changes can amend an in-flight Order?
• Are delta and target state both retained?
• Is impact assessment versioned?
• Is apply-time revalidation mandatory?

Supplemental Order

• Bagaimana supplemental order dikaitkan ke original order?
• What commercial basis authorizes new scope?
• Are dependencies to original milestones explicit?
• Can supplements complete residual accepted scope?

Cancellation

• Apa batas cancellation setelah fulfillment dimulai?
• Which states/capabilities allow cancellation?
• Are completed, in-flight, pending, irreversible, and unknown scopes treated separately?
• How are fees, credits, compensation, and customer communication handled?

Commercial and execution delta

• Bagaimana delta commercial terms dan downstream execution dihitung?
• Which changes trigger requote, reapproval, reacceptance, or Agreement amendment?
• Are price, term, date, cost, margin, tax, and Billing effects explicit?
• Are grandfathered and repriced scopes separated?

Plan/orchestration

• Is change applied as new Plan version/overlay?
• How are active attempts, timers, reservations, and appointments migrated?
• Can old and new Plans execute concurrently accidentally?
• How is handover audited?

Concurrency and idempotency

• How are overlapping Change scopes detected?
• Is one business key used per Change/cancellation?
• Can duplicate cancel/amend/apply commands create duplicate effects?
• Are unknown outcomes reconciled before replacement?

Operations

• Are stuck Changes and cancellations observable?
• Are applied Changes reconciled against downstream state?
• What explicit recovery commands exist?
• What incidents reveal uncontrolled in-flight mutation?

233. Practical Exercises

Exercise 1 — Change taxonomy

Classify 30 requests as draft edit, amendment, supplement, cancellation, replacement, correction, or new Product Order.

Exercise 2 — Impact assessment

Assess product, commercial, fulfillment, schedule, Inventory, Billing, and Agreement impact.

Exercise 3 — Cancellation matrix

Define behavior for pending, reserved, dispatched, in-progress, completed, and unknown work.

Exercise 4 — Plan overlay

Create retained/cancelled/superseded/added nodes and handover point.

Exercise 5 — Commercial delta

Model changed and grandfathered scope with price, term, and proration impact.

Exercise 6 — Concurrent changes

Design conflict detection and serialization for overlapping scopes.

234. Part Completion Checklist

You are done if you can:

• preserve original Order history;
• distinguish amendment, supplement, cancellation, replacement, and correction;
• create versioned Change objects;
• represent delta and target state;
• assess completed, in-flight, pending, irreversible, and unknown work;
• calculate commercial and execution impact;
• require approval/customer consent where material;
• apply changes through immutable Plan versions;
• model cancellation and residual outcomes;
• detect overlapping concurrent Changes;
• and create an internal Order-change verification backlog.

235. Key Takeaways

1. Submitted and completed Orders should not be edited like drafts.
2. Order changes need first-class identity and lifecycle.
3. Amendment, supplement, cancellation, and replacement differ.
4. Impact assessment must use actual execution state.
5. Unknown outcomes must be reconciled before conflicting change.
6. Completed and irreversible effects remain historical facts.
7. Operational replanning must not silently alter commercial commitment.
8. Customer-material changes require governed consent.
9. Cancellation is a process, not a status flip.
10. Internal CSG in-flight change semantics must be verified.

236. References

Conceptual baseline:

• General enterprise and telecom change-order, supplemental-order, cancellation, amendment, and replacement practices.
• Immutable history, versioned deltas, plan overlays, and in-flight orchestration handover patterns.
• Saga compensation, idempotent cancellation, ambiguous-outcome reconciliation, and explicit recovery commands.
• Product Order, Agreement, Inventory, Billing, Service Order, and Resource Order change-lineage concepts.

These references do not define internal CSG Order amendment, supplement, cancellation, or change implementation.