Part 039 — Product Inventory, Installed Base, Reconciliation, and Lifecycle Lineage

Positioning

Quote, Product Order, Fulfillment Plan, Product Inventory, dan Billing tidak menyimpan jenis kebenaran yang sama.

Satu customer product dapat memiliki beberapa view:

• as-quoted — apa yang ditawarkan dan diterima;
• as-ordered — action dan target state yang diminta;
• as-designed — bagaimana provider merencanakan realization;
• as-built — apa yang benar-benar terpasang atau aktif;
• as-billed — apa yang benar-benar dikenakan charge;
• as-observed — apa yang terdeteksi oleh monitoring atau discovery;
• as-contracted — apa yang dijamin oleh Agreement;
• as-entitled — hak customer yang berasal dari Agreement atau subscription.

Kesalahan arsitektur umum adalah memaksa semua view menjadi satu object raksasa yang terus ditimpa.

Akibatnya:

• accepted Quote kehilangan history;
• Product Order sulit direkonstruksi;
• Inventory Product tidak merepresentasikan actual installed state;
• Billing tidak dapat direkonsiliasi;
• dan support tidak tahu view mana yang authoritative.

Core thesis: setiap view harus memiliki semantic authority, identity, version, effective time, dan lineage sendiri. Synchronization bukan berarti semua field harus sama; synchronization berarti perbedaan dapat dijelaskan, ditelusuri, dan direkonsiliasi.

1. Product Inventory

Product Inventory adalah system of record untuk customer-facing Product instances yang telah atau sedang direalisasikan.

Typical responsibilities:

• Product identity;
• lifecycle state;
• current configuration;
• related parties/accounts/sites;
• effective period;
• Product relationships;
• source Order lineage;
• and references to Services/Resources.

2. Installed Base

Installed Base adalah kumpulan Product instances yang dimiliki, digunakan, atau dilayani untuk customer/account/site.

Installed Base dapat mencakup:

• active products;
• suspended products;
• pending activation;
• pending termination;
• historical products;
• and externally managed products.

3. Product Instance

Product Instance adalah occurrence nyata dari Product Offering/Specification untuk customer tertentu.

4. Product Offering versus Product Instance

Product Offering

Commercially sellable definition.

Product Instance

Customer-specific realized occurrence.

5. Product Specification versus Product Instance

Specification defines allowed structure/characteristics.

Instance contains actual effective values.

6. Product Inventory versus Asset Inventory

Product Inventory

Customer-facing commercial Product.

Asset Inventory

Physical or financial asset.

One Product may use several assets.

7. Product Inventory versus Service Inventory

Product Inventory

Commercial/customer-facing abstraction.

Service Inventory

Technical service realization.

8. Product Inventory versus Resource Inventory

Product Inventory

What customer owns/subscribes to.

Resource Inventory

Infrastructure/resources realizing Services.

9. Product Inventory versus CMDB

CMDB may track configuration items for operational management.

Do not assume CMDB CI equals customer Product.

10. Product Inventory Authority

The authoritative system for installed Product should be explicit.

Possible authority models:

• centralized Product Inventory;
• domain-specific product stores with federation;
• Inventory projection from fulfillment;
• or hybrid master/projections.

11. Product Identity

Use stable Product ID.

Example:

Product ID: PROD-01J...
External Product Number: CUST-SVC-00042

12. Business Number

Human/customer-facing identifier.

Do not use as sole technical identity.

13. Product Version

Use optimistic concurrency/versioned state.

14. Product Revision

If historical commercial snapshots are needed, revision may differ from technical version.

15. Effective-Dated Product State

Current state alone is insufficient.

Store or reconstruct:

• validFrom;
• validUntil;
• recordedAt;
• and source action.

16. Bitemporal Consideration

Two time axes may matter:

• effective time — when Product state was true in business reality;
• recorded time — when system learned/recorded it.

17. Product Lifecycle State

Possible states:

• PLANNED;
• PENDING;
• ACTIVE;
• SUSPENDED;
• PENDING_TERMINATION;
• TERMINATED;
• CANCELLED;
• FAILED_ACTIVATION;
• and UNKNOWN.

Exact vocabulary must be verified internally.

18. Planned Product

A future Product identity may be allocated before fulfillment completes.

19. Pending Product

Fulfillment started but Product not yet active.

20. Active Product

Expected customer-facing outcome is available.

21. Suspended Product

Temporarily restricted without termination.

22. Pending Termination

Termination action accepted/started but not complete.

23. Terminated Product

Product no longer active for customer.

History remains.

24. Failed Activation

Planned Product failed to become active.

Do not silently delete it if it has commercial/operational lineage.

25. Unknown State

Used only when source systems disagree or observation is insufficient.

Must trigger reconciliation.

26. Product Status versus Operational Health

Lifecycle state differs from:

• service health;
• alarm state;
• performance degradation;
• and incident state.

27. Product State versus Billing State

An active Product can be:

• billing pending;
• billing active;
• billing failed;
• or non-billable.

Keep dimensions separate.

28. Product State versus Agreement State

Product may remain active while Agreement renewal is pending.

29. As-Quoted View

Represents accepted commercial promise.

Contains:

• selected offering;
• configured characteristics;
• quantity;
• site/account;
• price and terms;
• and accepted validity/evidence.

30. Authority of As-Quoted

Quote/Acceptance domain owns the accepted snapshot.

It should be immutable.

31. As-Ordered View

Represents Product Order target intent.

Contains:

• action;
• existing Product reference;
• target Product snapshot;
• requested dates;
• Order relationships;
• and accepted commercial lineage.

32. Authority of As-Ordered

Product Order domain owns submitted Order intent.

33. As-Designed View

Represents fulfillment design or planned realization.

Contains:

• service decomposition;
• resource requirements;
• supplier choices;
• topology;
• dependencies;
• and scheduling assumptions.

34. Authority of As-Designed

Fulfillment planning/design domains own the Plan.

35. As-Built View

Represents actual realized Product and supporting implementation.

Contains:

• actual Product characteristics;
• Service/Resource references;
• actual activation dates;
• realized relationships;
• supplier identifiers;
• and variances.

36. Authority of As-Built

Product Inventory owns customer Product actual state.

Service/Resource inventories own their own technical facts.

37. As-Billed View

Represents actual Billing charges and invoicing state.

Contains:

• charge identities;
• billing start/stop dates;
• rates;
• discounts;
• usage;
• tax;
• invoice status;
• and adjustments.

38. Authority of As-Billed

Billing system owns actual billable charge state and invoice results.

39. As-Observed View

Represents monitoring/discovery observations.

Examples:

• discovered device;
• measured bandwidth;
• telemetry service status;
• network topology.

40. Authority of As-Observed

Monitoring/discovery owns observations, not necessarily commercial Product truth.

41. As-Contracted View

Represents Agreement commitments:

• product entitlement;
• price commitment;
• term;
• SLA;
• renewal;
• and obligations.

42. Authority of As-Contracted

Agreement/Contract system owns contractual commitments.

43. View Comparison

44. Synchronization Does Not Mean Equality

Differences may be valid.

Example:

• Quote says routerModel = managed-standard;
• as-designed selects vendor model A;
• as-built uses vendor model B;
• customer-facing Product still satisfies accepted specification.

45. Semantic Equivalence

Two views can differ structurally while preserving equivalent Product outcome.

46. Realization Variance

A variance is a difference between expected and actual view.

47. Variance Categories

• representational;
• derived;
• permitted substitution;
• operational;
• commercial;
• defect;
• and unknown.

48. Representational Variance

Different field/value representation with same semantics.

Example:

1 Gbps
versus
1000 Mbps

49. Derived Variance

As-built includes technical characteristics not present in Quote.

50. Permitted Substitution

Actual implementation differs but is allowed by Product/Agreement policy.

51. Operational Variance

Actual dates/resources differ while customer commitment remains satisfied.

52. Commercial Variance

Actual Product or charge differs from accepted commitment.

Requires escalation.

53. Defect Variance

Actual realization violates expected target.

54. Unknown Variance

Difference cannot yet be classified.

55. Variance Identity

Store:

• variance ID;
• compared views;
• scope;
• type;
• severity;
• and resolution.

56. Variance Evidence

Include:

• source versions;
• observed values;
• expected values;
• mapping/rule version;
• and timestamps.

57. Allowed Variance Policy

Defines substitutions or tolerances allowed without commercial change.

58. Policy Version

Retain policy version used to classify variance.

59. Variance Resolution

Possible:

• ACCEPTED_AS_EQUIVALENT;
• INVENTORY_CORRECTED;
• FULFILLMENT_REMEDIATED;
• BILLING_CORRECTED;
• ORDER_AMENDED;
• AGREEMENT_AMENDED;
• CUSTOMER_REMEDY;
• MANUAL_REVIEW.

60. Product Inventory Creation

When should Product Inventory entry be created?

Possible models:

1. at Order submission;
2. at fulfillment start;
3. at activation;
4. at successful completion;
5. staged planned Product followed by activation.

61. Model 1 — Create at Order Submission

Benefits:

• early identity;
• easy lineage.

Risks:

• many never-activated Products;
• lifecycle ambiguity.

62. Model 2 — Create at Fulfillment Start

Benefits:

• only actionable scope.

Risks:

• identity may be late for planning.

63. Model 3 — Create at Activation

Benefits:

• Inventory contains actual Products only.

Risks:

• weak planned-product correlation.

64. Model 4 — Planned Product then Activate

Benefits:

• stable identity early;
• explicit lifecycle;
• easier correlation.

Costs:

• more states and cleanup.

65. Product Creation Trigger

Possible trigger:

• Product Order acknowledged;
• Plan published;
• fulfillment unit started;
• activation succeeded;
• or Inventory command.

66. Product Creation Command

Example:

CreatePlannedProductFromOrderItem

67. Product Activation Command

Example:

ActivateProduct

68. Product Creation Idempotency

Use stable business key such as:

Product Order Item + target Product generation

69. Duplicate Product Prevention

Enforce domain uniqueness where one Product outcome is intended.

70. Product Correlation Key

Connect:

• Quote Item;
• Order Item;
• planned Product;
• and active Product.

71. Product Inventory Update

A non-ADD action may update existing Product.

72. MODIFY Update

Inventory should capture:

• prior state/version;
• target state;
• effective date;
• and source Order Item.

73. DELETE Update

Inventory transitions to termination state, then terminated.

Do not delete record.

74. SUSPEND Update

Record suspension reason/effective period.

75. RESUME Update

Restore active state through explicit Order action.

76. REPLACE Update

Link:

• replaced Product;
• replacement Product;
• effective cutover;
• and source Order.

77. RENEW Update

May update:

• commercial term;
• Agreement;
• price commitment;
• and lifecycle validity

without technical Product replacement.

78. Product Change History

Every effective change should be reconstructable.

79. Product Snapshot

An immutable state snapshot at key transitions can support audit.

80. Event-Sourced Product History

Possible but requires careful event/version evolution.

81. Temporal Table

Another option for historical states.

82. Hybrid History

Current Product row plus immutable change log/snapshots.

83. Product Characteristic

Each characteristic may have:

• identity;
• value;
• unit;
• source;
• effective period;
• and visibility.

84. Customer-Visible Characteristic

Part of Product promise or display.

85. Technical Characteristic

Supports realization but may not be customer-facing.

86. Derived Characteristic

Computed from Services/Resources or policy.

87. Characteristic Authority

Different fields can have different authorities.

88. Field-Level Source

Store source/provenance where needed.

89. Characteristic Effective Dating

Changes can take effect at different times.

90. Characteristic Correction

Recording correction differs from Product modification.

91. Product Relationships

Examples:

• contains;
• dependsOn;
• bundledWith;
• replaces;
• uses;
• parentOf;
• and associatedWith.

92. Relationship Identity

First-class identity supports change and history.

93. Relationship Effective Period

Relationships can begin/end separately.

94. Bundle Inventory

Options:

• parent Product plus child Products;
• composite Product snapshot;
• or graph.

95. Shared Product

One supporting Product may relate to several customer Products.

96. Product Hierarchy versus Service Topology

Product hierarchy is commercial.

Service topology is technical.

97. Installed Base Query

Examples:

• all active Products for customer;
• Products at site;
• Products governed by Agreement;
• Products eligible for upgrade;
• Products pending termination;
• and Products with Billing mismatch.

98. Query by Effective Date

Support historical view:

What Product state was effective on date X?

99. Current-State Query

Should not accidentally return future-dated or terminated state.

100. Eligibility Baseline

CPQ may use Product Inventory as baseline for:

• upgrade;
• modify;
• renew;
• suspend;
• and terminate.

101. Modify Baseline

A Modify Quote must bind to:

• exact Product ID;
• current version;
• state;
• configuration;
• Agreement;
• and account/site context.

102. Baseline Snapshot

Capture current Product snapshot when configuration session starts.

103. Baseline Version

Use for optimistic conflict detection.

104. Baseline Drift

Product changes while Quote is being prepared.

105. Baseline Conflict

At Order readiness/submission:

• revalidate;
• merge;
• reconfigure;
• or reject.

106. Product Version in Quote

Quote should reference expected Inventory version for change actions.

107. In-Flight Order

Inventory should expose active/pending changes to prevent conflicting Orders.

108. Pending Action

Possible projection:

• pending upgrade;
• pending termination;
• pending suspension;
• pending move.

109. Order Reservation on Product

Can reserve Product for exclusive change.

110. Product Change Lock

Avoid long database locks.

Use domain reservation/expected version.

111. Conflicting Order Matrix

Examples:

112. Product Reservation Identity

Store:

• Product;
• action;
• Order;
• scope;
• expiry;
• and version.

113. Reservation Release

Release on:

• Order cancellation;
• failure;
• supersession;
• or completion.

114. Reservation Reconciliation

Detect leaked/stale reservations.

115. As-Designed to As-Built

Fulfillment Plan predicts realization.

Actual execution may differ.

116. Design Identity

Reference exact Plan version.

117. Build Evidence

Examples:

• Service IDs;
• Resource IDs;
• supplier completion;
• activation timestamp;
• test result.

118. Build Mapping

Map planned units to actual realized entities.

119. Build Completeness

Every required planned outcome should have actual outcome or residual.

120. Build Variance

Examples:

• alternate resource;
• different supplier;
• changed topology;
• delayed activation;
• partial site delivery.

121. Permitted Build Variance

Must be classified by Product equivalence/policy.

122. Unpermitted Build Variance

Triggers remediation or commercial process.

123. As-Built Update Timing

Possible:

• incrementally per fulfillment unit;
• at Product activation;
• at Order Item completion;
• or after reconciliation barrier.

124. Incremental Inventory Update

Benefits:

• real-time visibility.

Risks:

• partial state;
• rollback complexity.

125. Completion-Boundary Update

Benefits:

• simpler Product truth.

Risks:

• delayed visibility.

126. Hybrid Inventory Update

Create planned Product early, update actual details incrementally, activate only after required evidence.

127. Inventory Update Transaction

Local Inventory state/event should be atomic.

128. Distributed Outcome

Service/Resource systems update independently.

Product Inventory composes references and Product state.

129. Inventory Event

Representative events:

• PlannedProductCreated;
• ProductActivated;
• ProductModified;
• ProductSuspended;
• ProductResumed;
• ProductTerminated;
• ProductReplaced;
• ProductInventoryCorrectionApplied.

130. Event Payload

Include:

• Product;
• version;
• source Order Item;
• effective time;
• and changed fields.

Avoid full sensitive snapshots broadly.

131. Inventory Command

Examples:

• CreatePlannedProduct;
• ActivateProduct;
• ApplyProductModification;
• SuspendProduct;
• ResumeProduct;
• TerminateProduct;
• ReplaceProduct;
• CorrectProductRecord.

132. Generic Upsert Risk

Generic upsert can overwrite:

• history;
• source Order;
• and expected version.

133. Inventory Idempotency

Every Order Item outcome should apply once.

134. Outcome Key

Possible:

Order Item + fulfillment outcome generation

135. Duplicate Activation

Should return existing Product/outcome.

136. Late Callback

Old fulfillment attempt must not overwrite newer Product version.

137. Fencing/Expected Version

Protect against stale updater.

138. Out-of-Order Events

Use Product version and source generation.

139. Inventory Projection

Search/read models may lag.

Commands must use authoritative Inventory store.

140. Inventory Synchronization

Synchronization patterns:

• command-driven;
• event-driven;
• API polling;
• CDC;
• periodic reconciliation;
• or hybrid.

141. Command-Driven Sync

Fulfillment explicitly commands Inventory change.

142. Event-Driven Sync

Inventory consumes completion events.

143. Polling Sync

Inventory queries source systems.

Useful for reconciliation, less ideal as sole real-time mechanism.

144. CDC

Can propagate row changes but may lack domain meaning.

145. Periodic Reconciliation

Essential even with events.

146. Hybrid Sync

Commands/events for primary flow; reconciliation for repair.

147. Synchronization Authority

Inventory must not accept conflicting updates from arbitrary sources.

148. Source Precedence

Define which source may update which field.

149. Field Ownership Matrix

Example:

150. Last-Write-Wins Risk

Different authorities can overwrite correct state.

151. Merge Policy

Field-level semantic merge, not generic timestamp merge.

152. Eventual Consistency Window

Document expected propagation time.

153. Stale Inventory

CPQ or Order may read Product state before latest fulfillment update.

154. Read-Your-Write

After Order completion, caller may need direct outcome reference instead of relying on lagging search projection.

155. Consistency Token

Can identify minimum Product version expected.

156. Inventory Cache

Must be tenant- and version-aware.

157. Cache Invalidation

Trigger on Product state/version events.

158. Negative Cache

Risky for newly created Products.

Use short TTL or version-aware behavior.

159. Product Reconciliation

Compare expected and actual Product state.

160. Reconciliation Sources

• accepted Quote;
• Product Order;
• Fulfillment Plan;
• Service Inventory;
• Resource Inventory;
• Product Inventory;
• Billing;
• and Agreement.

161. Reconciliation Direction

Do not assume Inventory always wrong.

Determine authority per fact.

162. Reconciliation Key

Use stable lineage identities.

163. Reconciliation Window

Allow expected event propagation.

164. Reconciliation Result

Possible:

• MATCH;
• REPRESENTATION_VARIANCE;
• PERMITTED_VARIANCE;
• INVENTORY_MISSING;
• INVENTORY_EXTRA;
• CONFIGURATION_MISMATCH;
• STATE_MISMATCH;
• RELATIONSHIP_MISMATCH;
• BILLING_MISMATCH;
• UNKNOWN.

165. Missing Inventory Product

Fulfillment says active but Product Inventory absent.

166. Extra Inventory Product

Product exists without valid source or active entitlement.

167. Configuration Mismatch

Actual Product characteristics differ.

168. State Mismatch

Product active in one system, terminated in another.

169. Relationship Mismatch

Bundle child/link missing or wrong.

170. Billing Mismatch

Active Product has no charge, or terminated Product still billed.

171. Reconciliation Case

Material mismatch opens managed case/fallout.

172. Auto-Repair

Safe examples:

• rebuild search projection;
• link unique Service reference;
• republish missing event.

173. Unsafe Auto-Repair

Examples:

• create active Product solely from Billing record;
• terminate Product based on one stale observation;
• overwrite accepted characteristics.

174. Reconciliation Frequency

• immediate after Order completion;
• near-real-time event checks;
• nightly installed-base sweep;
• invoice-cycle checks;
• and incident-triggered scans.

175. Reconciliation at Completion

Before Order Item completes, verify required Inventory outcome.

176. Post-Completion Reconciliation

Detect later drift.

177. Administrative Correction

Used when Inventory record is wrong but real-world Product is known.

178. Correction versus Product Change

Correction

Fixes recorded truth.

Product Change

Changes actual Product through Order lifecycle.

179. Correction Command

Example:

CorrectProductRecord

180. Correction Preconditions

• authoritative evidence;
• actor authority;
• expected version;
• no conflicting in-flight action;
• and reason.

181. Correction Scope

Possible:

• identifier;
• characteristic;
• relationship;
• effective date;
• lineage reference;
• or state metadata.

182. Correction Cannot Invent Fulfillment

Do not mark Product active without real-world evidence.

183. Backdated Correction

Requires effective and recorded time separation.

184. Correction Audit

Capture:

• before;
• after;
• reason;
• evidence;
• actor;
• and impact.

185. Correction Event

Emit specific correction event, not pretend normal fulfillment occurred.

186. Mass Correction

Needed after systemic defects.

187. Mass Correction Safety

Use:

• impact analysis;
• dry run;
• canary;
• per-Product idempotency;
• and post-reconciliation.

188. Product Merge

Duplicate Product records may need merge.

189. Product Split

One incorrect Product may need split into several actual instances.

190. Merge/Split Governance

High risk for:

• Billing;
• Agreement;
• Inventory;
• support;
• and customer portal.

191. Product Identity Preservation

Avoid reusing Product ID for a different logical Product.

192. Replacement Lineage

Old and new Product IDs remain related.

193. External Product Identity

Multiple external systems may have their own IDs.

194. External Reference Registry

Store typed references:

• source system;
• type;
• value;
• validity;
• and status.

195. Duplicate External Reference

Detect and reconcile.

196. Identity Resolution

Do not match Products only by display name/address.

197. Customer Moves

Product move may change site while preserving or replacing Product identity.

198. Move Semantics

Could be:

• MODIFY;
• REPLACE;
• DELETE + ADD;
• or specialized MOVE action.

199. Product Transfer

Transfer between accounts/customers requires governed semantics.

200. Ownership Transfer

May require Agreement, Billing, privacy, and legal changes.

201. Product Renewal

Renewal may update commercial validity without changing as-built state.

202. Product Suspension

As-built may remain physically present while service state changes.

203. Product Termination

As-built resources may remain temporarily during cleanup.

204. Decommissioning Lag

Terminated commercial Product and technical resource removal can differ in time.

205. Residual Resource

Track orphaned or pending-decommission resources.

206. Product Inventory and Billing

Inventory state influences Billing but should not be sole uncontrolled trigger.

207. Charge Activation Reference

Billing activation should reference Product/Order/accepted charge identity.

208. Billing Start Date

May be:

• activation date;
• service-ready date;
• customer acceptance date;
• Agreement date;
• or scheduled date.

Authority must be explicit.

209. Product Termination and Billing Stop

Stop date may differ from technical decommission date.

210. Billing Reconciliation

Compare:

• active Products with expected recurring charges;
• terminated Products with stopped charges;
• usage-enabled Products with rating setup;
• and discounts with validity.

211. Revenue Leakage

Inventory/Billing mismatch can cause:

• active unbilled Product;
• underbilling;
• missing one-time fee;
• or expired discount still applied.

212. Overbilling

Examples:

• terminated Product still billed;
• duplicate Product charge;
• wrong quantity;
• duplicate activation.

213. Product Inventory and Customer Portal

Portal should display customer-appropriate Product view.

214. Portal Projection

May combine:

• Inventory Product;
• Agreement;
• Billing summary;
• and operational status.

Do not make portal projection authoritative.

215. Customer-Visible Product Name

May come from accepted offering snapshot, not current catalog name.

216. Historical Product Display

Retain source labels for old Products.

217. Product Inventory and CPQ

CPQ queries Inventory for:

• installed base;
• eligibility;
• modify baseline;
• renewals;
• upsell;
• and cross-sell.

218. Inventory Query Contract

Should include:

• tenant;
• customer/account;
• site;
• Product state;
• effective time;
• and consistency/version needs.

219. Snapshot for Configuration Session

Freeze or record baseline version.

220. Product Discovery

Discovery may find unknown resources/services.

221. Discovery-to-Product Mapping

Requires governed matching and Product semantics.

222. Discovered Does Not Equal Sold Product

A discovered router is not automatically a customer Product.

223. Orphan Detection

Types:

• Product without Order;
• Service without Product;
• Resource without Service;
• Billing charge without Product;
• and active Order without Inventory outcome.

224. Orphan Resolution

Possible:

• link;
• create correction;
• terminate;
• classify external/legacy;
• or manual review.

225. Legacy Product

Migrated Product may lack complete Quote/Order lineage.

226. Legacy Provenance

Mark source:

• migration;
• external;
• unknown;
• or reconstructed.

227. Lineage Completeness Level

Possible:

• FULL;
• PARTIAL;
• LEGACY;
• UNKNOWN.

228. Migration Baseline

Capture as-of date and source system.

229. Migration Reconciliation

Compare counts, states, relationships, and charges.

230. Product Inventory API

Possible resources:

• Products;
• Product relationships;
• Product history;
• pending actions;
• reconciliation results;
• and external references.

231. Command API

Examples:

• CreatePlannedProduct;
• ActivateProduct;
• ModifyProduct;
• SuspendProduct;
• ResumeProduct;
• TerminateProduct;
• ReplaceProduct;
• CorrectProductRecord;
• LinkExternalReference.

232. Query API

Examples:

• GetProduct;
• SearchInstalledBase;
• GetProductAtTime;
• GetPendingActions;
• CompareProductViews;
• GetLineage.

233. ETag/Expected Version

Use for Product modifications/corrections.

234. Partial Update Risk

Generic PATCH can violate state/history/source semantics.

235. Event Contract

Product events should include:

• Product ID;
• version;
• lifecycle transition;
• effective time;
• source Order;
• and changed scope.

236. Event Ordering

Partition/key by Product ID.

237. Duplicate Event

Consumers must be idempotent.

238. Event Replay

Historical event version/schema compatibility required.

239. Outbox

Persist Inventory state and event intent atomically.

240. Inbox

Deduplicate incoming fulfillment outcomes.

241. Security

Product Inventory contains sensitive:

• customer;
• location;
• topology;
• product;
• and operational references.

242. Tenant Isolation

Apply to:

• primary store;
• search;
• cache;
• event;
• and reconciliation jobs.

243. Field-Level Access

Some roles can see commercial Product but not technical resources.

244. Data Residency

May constrain Inventory placement.

245. Audit Access

Historical Product changes may be sensitive.

246. Retention

Terminated Product history may need long retention.

247. Metrics

Useful metrics:

• Products by lifecycle state;
• create/modify/terminate volume;
• and pending action count.

248. Lineage Metrics

• Products without source Order;
• Order Items without Product outcome;
• missing Agreement;
• missing Billing charge;
• and missing Service reference.

249. Variance Metrics

• as-ordered versus as-built mismatch;
• permitted substitution rate;
• and unclassified variance.

250. Reconciliation Metrics

• mismatch count;
• age;
• auto-repair;
• and manual backlog.

251. Data Quality Metrics

• duplicate Products;
• invalid relationships;
• stale external references;
• and impossible state transitions.

252. Inventory Freshness

Measure event/update lag.

253. Product Inventory SLI

Examples:

• all completed ADD items create exactly one Product outcome;
• all MODIFY outcomes reference expected prior Product;
• all active Products have complete lineage level required by policy;
• and all critical mismatches reconcile within target.

Internal targets must be verified.

254. Stuck Product

Examples:

• planned indefinitely;
• pending termination beyond SLA;
• unknown state;
• reservation without active Order;
• and Product pending Billing activation.

255. Reconciliation Backlog

Track by:

• severity;
• customer;
• Product type;
• system;
• and age.

256. Recovery Commands

Examples:

• ReconcileProductOutcome;
• LinkExistingProduct;
• CorrectProductRecord;
• RebuildProductProjection;
• ReleaseStaleProductReservation;
• RepairProductRelationship;
• ReconcileBillingLink.

257. Inventory Incident

Examples:

• duplicate Product;
• wrong customer Product;
• terminated Product reactivated by stale event;
• active Product missing charge;
• and current Inventory used to rewrite accepted Quote history.

258. Incident Containment

Possible:

• freeze Product mutation;
• block new change Orders;
• pause Billing activation;
• preserve source evidence;
• identify impacted Products;
• and execute canary correction.

259. View Smells

• one object named Product used everywhere;
• current catalog data used for history;
• and view differences treated as data errors automatically.

260. Inventory Smells

• Product created by generic upsert;
• no effective time;
• no source Order Item;
• and physical delete on termination.

261. Synchronization Smells

• last-write-wins across authorities;
• event-only with no reconciliation;
• and polling by display name.

262. Baseline Smells

• Modify Quote uses customer/product text instead of Product ID;
• no Inventory version;
• and in-flight Orders ignored.

263. Correction Smells

• support changes state directly;
• no before/after;
• and correction event indistinguishable from fulfillment.

264. Billing Smells

• active Product always means bill now;
• Billing status stored as Product lifecycle;
• and no charge identity lineage.

265. Anti-Patterns

Giant Canonical Product

Different domains overwrite each other.

As-Built Overwrites As-Quoted

Commercial evidence disappears.

Inventory Equals Monitoring

Observed resources become Products automatically.

Current Catalog Defines Existing Product

Historical meaning changes.

Termination Deletes Product

History and Billing lineage disappear.

Eventual Consistency without Reconciliation

Permanent mismatches remain invisible.

Modify by Fuzzy Match

Wrong installed Product changes.

266. Product Inventory Template

## Product Identity and Version

## Lifecycle / Effective Period

## Customer / Account / Site / Parties

## Offering / Specification Snapshot

## Product Characteristics

## Product Relationships

## Agreement / Entitlement References

## Source Quote / Acceptance / Order Item

## Pending Actions / Reservations

## Service / Resource / Supplier References

## Billing References

## External References

## Lineage Completeness

## History / Audit

267. Product View Comparison Template

## Scope and Product Identity

## As-Quoted

## As-Ordered

## As-Designed

## As-Built

## As-Billed

## As-Observed

## As-Contracted

## Variances

## Authority per Fact

## Resolution / Reconciliation

268. Variance Template

Variance ID:
Product/scope:
Compared views:
Expected:
Observed:
Category:
Allowed policy/version:
Severity:
Customer/commercial impact:
Evidence:
Resolution:

269. Product Change Record Template

Change ID:
Product:
Source Order Item:
Action:
Prior version/state:
Target version/state:
Effective time:
Recorded time:
Characteristic changes:
Relationship changes:
Inventory outcome:

270. Product Reservation Template

Reservation ID:
Product:
Requested action:
Order/item:
Expected Product version:
Scope:
Created at:
Expires at:
State:
Release reason:

271. Reconciliation Template

Reconciliation ID:
Product/business key:
Expected source view:
Observed target view:
Authority matrix:
Consistency window:
Differences:
Classification:
Repair:
Evidence:

272. Administrative Correction Template

Correction ID:
Product/version:
Field/scope:
Before:
After:
Effective time:
Reason:
Authority:
Evidence:
Downstream impact:
Audit:

273. Lineage Template

Quote Item:
Accepted Revision:
Product Order Item:
Fulfillment Plan/Unit:
Service Order/Service:
Resource Order/Resource:
Inventory Product:
Agreement Item:
Billing Charge:
External Supplier/Asset:

274. Inventory Invariants

Representative invariants:

• one intended ADD outcome creates at most one logical Product;
• non-ADD actions reference exact Product identity/version;
• Product history remains reconstructable;
• termination does not erase Product identity;
• as-built changes do not overwrite as-quoted evidence;
• every active Product has required source lineage or explicit legacy classification;
• stale events cannot overwrite newer Product state;
• and critical view mismatches open reconciliation/fallout.

275. Worked Example: New Product ADD

Quote accepts:

• managed connectivity at Site A.

Order requests:

• ADD with target characteristics.

Plan realizes:

• access, router, monitoring.

Inventory:

• planned Product created early;
• activated after required evidence;
• links actual Services/Resources;
• retains Quote/Order lineage.

276. Worked Example: Permitted Router Substitution

As-designed uses router model X.

Supplier delivers model Y.

Policy confirms Y is equivalent for customer-facing Product.

Variance is classified as permitted substitution.

277. Worked Example: Unpermitted Bandwidth Variance

Order target is 1 Gbps.

As-built activation is 500 Mbps.

Inventory cannot mark target Product fully active.

Fallout/remediation begins.

278. Worked Example: Modify Baseline Drift

Quote starts from Product version 7.

Another Order changes Product to version 8.

Original MODIFY Order readiness detects baseline conflict.

279. Worked Example: Replacement

Old Product P1 is replaced by P2.

Inventory records:

• P1 termination;
• P2 activation;
• replacement relationship;
• cutover time;
• source Order.

280. Worked Example: Suspension

Service is physically present but customer Product is suspended.

Product lifecycle, Service technical state, and Billing policy remain separate dimensions.

281. Worked Example: Active but Unbilled

Product active.

No recurring Billing charge exists.

Reconciliation opens critical revenue-leakage case.

282. Worked Example: Terminated but Billed

Product terminated effective June 30.

Billing continues in July.

Inventory/Billing reconciliation triggers correction/credit process.

283. Worked Example: Duplicate Inventory Product

Duplicate completion event creates a second candidate Product.

Unique source outcome prevents commit or reconciliation merges/corrects safely.

284. Worked Example: Legacy Product

Migrated Product has:

• no Quote;
• partial Order lineage;
• known Billing account.

Inventory marks lineageCompleteness = LEGACY and retains migration source.

285. Worked Example: Discovery Mismatch

Monitoring discovers an unknown router.

System does not auto-create commercial Product.

It opens discovery/reconciliation workflow.

286. Worked Example: Backdated Activation

Activation occurred July 1 but callback arrived July 3.

Inventory stores:

• effectiveAt = July 1;
• recordedAt = July 3.

Billing handoff applies explicit start-date policy.

287. Worked Example: Mass Correction

A mapping defect assigned wrong site reference to 400 Products.

Correction process:

• identifies version/blast radius;
• dry-runs;
• canaries;
• applies idempotently;
• reconciles Billing and portal projections.

288. Worked Example: Customer Portal

Portal combines:

• Product Inventory name/state;
• Agreement term;
• Billing summary;
• operational health.

Projection is convenient but not authoritative for commands.

289. Senior Engineer Operating Model

Define every view and authority

As-quoted, ordered, designed, built, billed, observed, contracted.

Preserve identity and effective time

Current state alone is insufficient.

Model variance, not forced equality

Differences can be allowed, operational, or defective.

Make Inventory outcomes idempotent

One Order Item generation, one logical Product outcome.

Bind Modify to exact baseline

Product ID, version, state, and pending actions.

Use commands plus reconciliation

Events alone are insufficient.

Keep correction separate from Product change

Recording truth versus changing reality.

Reconcile Product, fulfillment, Agreement, and Billing

Lineage is an operational control.

Govern legacy and discovered Products

Do not fabricate commercial history.

290. Internal Verification Checklist

Authority and lifecycle

• Sistem mana yang authoritative untuk installed Product?
• What Product lifecycle states exist?
• Are effective time and recorded time separate?
• Are Product, Service, Resource, Asset, and CMDB identities distinct?

Inventory creation/update

• Kapan Inventory Product dibuat atau diubah?
• Is planned Product identity created before activation?
• What exact evidence activates a Product?
• How are MODIFY, DELETE, SUSPEND, RESUME, REPLACE, and RENEW reflected?

View model

• Are as-quoted, as-ordered, as-designed, as-built, as-billed, and as-observed distinct?
• Which system owns each fact?
• Are structural differences treated as semantic variance?
• Can all views be compared by stable lineage?

Variance

• Bagaimana fulfillment variance dicatat?
• Which substitutions are permitted?
• What constitutes commercial versus operational variance?
• What remediation/customer process follows unpermitted variance?

Modify baseline

• Bagaimana modify order menentukan current Inventory baseline?
• Are exact Product ID/version and pending actions captured?
• How is baseline drift detected?
• Can conflicting in-flight Orders reserve Product scope?

Synchronization and idempotency

• Which commands/events update Inventory?
• What business key prevents duplicate Product creation?
• How are stale/out-of-order events rejected?
• What consistency window and reconciliation jobs exist?

Correction and migration

• Are administrative corrections explicit and audited?
• Can support avoid direct database edits?
• How are duplicate/legacy/discovered Products handled?
• Is lineage completeness classified?

Billing and operations

• Are active/unbilled and terminated/still-billed Products detected?
• Are Inventory-to-Billing links first-class?
• What reconciliation metrics/backlogs exist?
• What incidents expose missing authority or lineage?

291. Practical Exercises

Exercise 1 — Authority matrix

Map every Product field/view to authoritative bounded context.

Exercise 2 — View comparison

Compare one Product across as-quoted, ordered, designed, built, billed, and observed states.

Exercise 3 — Inventory lifecycle

Model ADD, MODIFY, REPLACE, SUSPEND, RESUME, and DELETE with effective dates.

Exercise 4 — Baseline conflict

Design Modify behavior when installed Product changes during quoting.

Exercise 5 — Reconciliation

Detect and resolve active-unbilled, terminated-billed, and missing Inventory outcomes.

Exercise 6 — Mass correction

Design safe canary correction after a systemic mapping defect.

292. Part Completion Checklist

You are done if you can:

• distinguish Product Inventory from Service/Resource/Asset/CMDB;
• define as-quoted, as-ordered, as-designed, as-built, as-billed, and as-observed views;
• assign authority for every fact;
• preserve Product identity, history, and effective time;
• create/update Inventory idempotently from Order outcomes;
• classify realization variance;
• bind Product changes to exact Inventory baseline;
• reconcile Inventory with fulfillment, Agreement, and Billing;
• separate correction from Product change;
• and create an internal Product Inventory verification backlog.

293. Key Takeaways

1. Different Product views are not one mutable object.
2. Synchronization means explainable consistency, not identical schemas.
3. Product Inventory owns installed customer Product state.
4. As-quoted evidence must never be overwritten by as-built state.
5. Realization variance needs classification and policy.
6. Modify actions need exact Product ID and version.
7. Inventory updates require idempotency and stale-event protection.
8. Administrative correction differs from Product change.
9. Reconciliation detects revenue leakage and customer harm.
10. Internal CSG Product Inventory authority and synchronization must be verified.

294. References

Conceptual baseline:

• General enterprise and telecom Product Inventory, installed-base, Service Inventory, Resource Inventory, and asset-management practices.
• Bitemporal/effective-dated state, immutable history, semantic variance, and reconciliation patterns.
• Domain-Driven Design bounded contexts, entity identity, aggregate commands, field authority, and lineage.
• Distributed systems idempotency, outbox/inbox, stale-event protection, eventual consistency, and repair.
• TM Forum Product, Product Inventory, Product Order, Service, Resource, and Agreement vocabulary.

These references do not define internal CSG Product Inventory, installed-base, or synchronization implementation.