Every experienced BSS/OSS architect knows the basic rule: an order is completed only after the network has confirmed fulfilment and the product inventory has been updated. In a design review, nobody argues with that.
The difficult questions start where that rule stops helping:
- What does „completed“ still tell you a month later, after a field engineer, a migration or a failed rollback has changed the network?
- What state does a product have while a second order is already in flight against it?
- An order with five items ends as
partial. What should the inventory say? - Care sees the order completed, the service degraded and the product active. Which of the three is „the“ status?
These are not happy-path questions. They are questions about who owns which state, across layers and over time. TM Forum Open APIs define a well-structured state model for each resource, but they don’t say who writes those states or how they relate across APIs. That is an architecture decision, and it is where mature landscapes still accumulate their most expensive incidents.
This article gives a pragmatic answer: four rules, a reference flow, an approach to concurrent orders, and a reconciliation model for TMF622, TMF641, TMF637 and TMF638.
Key takeaways
- Orders own the state of a request. Inventory owns the state of a result. The network owns operational reality. These are different things and must not share one status field or one writer.
- Every state has exactly one writer. Channels never write state. They submit intent and read.
- State flows up, intent flows down. Fulfilment results move upward (network → service → product), while orders push intent downward (product → service → network).
- Completion is a statement about the past. After the order closes, inventory and network can still drift. Plan for it.
- Disagreement between order, inventory and network is a signal. Handle it through an explicit reconciliation process, not through silent patches.
The landscape in this article
To keep the discussion simple, I use only the components that matter for state:
- Customer Order Management (COM): receives product orders (TMF622), decomposes them, and owns the product inventory (TMF637).
- Service Order Management (SOM): receives service orders (TMF641), performs design, reservation and service activation as part of its fulfilment logic, and owns the service inventory (TMF638).
- Network: the systems that actually carry the service.
Channels (mobile, web, BFF, agents) sit in front of COM and only submit intent and read state.
1. Three kinds of state that get mixed up
| Order state | Inventory state | Operational state | |
|---|---|---|---|
| Question it answers | What is happening with this request? | What do we believe is sold and deployed? | What is actually running right now? |
| Nature | Process, temporary | Result, long-lived | Observation, volatile |
| Typical owner | COM (product level), SOM (service level) | Product inventory (COM), service inventory (SOM) | Network and monitoring |
| TMF APIs | TMF622, TMF641 | TMF637, TMF638 | Reflected in TMF638 operating status |
| Changes when | The request progresses | A fulfilment outcome is confirmed | Anything happens in the network |
| Ends | When the order closes | When the product or service is terminated | Never (continuous) |
A few concrete examples of each:
- Order state: product orders and their items move through states such as
acknowledged,inProgress,held,completed,failed,partialorcancelled. Service orders (TMF641) use a similar vocabulary. - Inventory state: a product in TMF637 carries a lifecycle status such as active, suspended, pending terminate or terminated. A service in TMF638 carries a lifecycle state such as designed, reserved, inactive, active or terminated.
- Operational state: is the service running, degraded or failed right now? In TMF638 this is typically an operating status that is fed by network and monitoring data, not decided by the order process.
(Exact enumerations differ between API versions and implementations. Check the version you actually use before building rules on top of them.)
The most common root cause I see in practice is simple: one word, „status“, is used for all three, and different teams read it differently.
2. Four rules for state ownership
Rule 1: One writer per state
For every state attribute, name the single component allowed to change it. Everyone else reads, or sends a request to the owner.
| State | Single writer | Everybody else |
|---|---|---|
| Product order and item state | COM | Reads (TMF622), may request cancel or change via the order |
| Service order and item state | SOM | Reads (TMF641) |
| Service inventory state (deployed) | SOM | Reads (TMF638) |
| Product inventory state | COM (as result of order completion) | Reads (TMF637) |
| Operational status | Network monitoring integration | Reads |
| Channels (BFF, mobile, agents) | none | Submit intent, read state |
If your digital channel can PATCH a product in inventory „to fix a status“, you don’t have a state model, you have a shared database with HTTP in front of it.
Rule 2: State flows up, intent flows down
Intent travels downward: COM decomposes a product order into service orders, and SOM turns them into activation in the network. Results travel upward: the network confirms, SOM updates the service inventory and completes the service order, and COM advances the product order and updates the product.
Product state is therefore derived from service state through orchestration, not set independently. A simple example rule: a product becomes active only when its order item is complete and all mandatory services in its decomposition are active. Define such rules explicitly, one per product family, and keep them in COM, not in channels.
Rule 3: Orders advance on fulfilment results, nothing else
An order moves forward because a fulfilment result arrived (a service order completed, an activation succeeded or failed), not because a UI timer expired and not because someone polled inventory and inferred the answer. Order progress is the record of what the process did. Inventory tells you what resulted. Confusing the two is how teams end up building order tracking on top of inventory queries.
Rule 4: Completion is a promise at a point in time
An order is completed only when the network has confirmed fulfilment and the inventory write has been confirmed. Treat that as a precondition, not a feature, and make it robust (for example with an outbox, so a crash between inventory write and completion event cannot lose the update).
But even then, „completed“ only describes the moment of completion. From that point on, the network and the inventory live their own lives: manual interventions, migrations, failed rollbacks, lost events. Order state is therefore history, not evidence of current state. Anything that needs the current state must read inventory and operational status, and anything that needs to know what happened must read the order.
3. Reference flow: new broadband service
The flow is deliberately short: channel → COM → SOM → network, with the two inventories beside it.
- Intent in. The channel submits a product order (TMF622). COM validates it and acknowledges it. Order and items move from
acknowledgedtoinProgress. - Decomposition. COM decomposes the product order item into service orders and submits them to SOM through TMF641. Service order items move to
inProgress. - Design and reserve. SOM retrieves the service specification (TMF633), reserves resources and records the service in the service inventory (TMF638) as
designedorreserved. - Activation. SOM executes the activation against the network. On success, it updates the service in TMF638 to
activeand completes the service order. - Fulfilment result up. COM receives the result (event or callback) and advances the product order item.
- Inventory update. COM creates or updates the product in TMF637 as active, then marks the order item and the order
completed. - Later, reconciliation. Inventory is checked against what the network reports. Differences go into a controlled drift process (section 6).
How the states line up in the happy path:
| Step | Product order item | Service order item | Service (TMF638) | Product (TMF637) |
|---|---|---|---|---|
| Accepted | acknowledged → inProgress | – | – | – |
| Decomposed | inProgress | acknowledged → inProgress | – | not yet created, or marked pending |
| Reserved | inProgress | inProgress | designed / reserved | pending |
| Activated | inProgress | completed | active | pending |
| Closed | completed | completed | active | active |
Two kinds of return information flow back to COM and the inventories: fulfilment results (which advance order state) and service state for reconciliation (which keeps inventory honest). Keep these as two separate paths in your design.
4. Where it breaks: seven failure patterns
1. Order state used as proof of current state.
Symptom: care or an automated process concludes „the order is completed, so the service is running“, weeks after completion.
Cause: order state describes what the process did, not what exists now.
Fix: use orders for history and progress, and inventory plus operational status for the current state. Show them side by side.
2. Channels write inventory.
Symptom: statuses changed by BFFs, scripts or support tools, with no order behind them.
Fix: remove write access. Corrections go through a controlled path with audit (see section 6).
3. Dual writes.
Symptom: SOM updates the service inventory and also pushes a product status, while COM writes the product status itself. Under failure, the two diverge.
Fix: one writer per state, and one fulfilment result that drives everything downstream of it.
4. Order status inferred from inventory.
Symptom: „where is my order?“ is answered by looking at inventory.
Cause: inventory only shows results, not progress. It can’t distinguish „not started“ from „failed“.
Fix: order tracking reads order state (TMF622, TMF641) and uses inventory only as additional evidence.
5. One status enum for everything.
Symptom: a single status field shows order progress, lifecycle and health, depending on who looks.
Fix: separate order state, lifecycle state and operational status, as in the table in section 1.
6. No handling for partial and failed orders.
Symptom: an order with five items ends as partial; two services are active, three are not, and nobody knows what the product state should be.
Fix: define up front what each outcome means for inventory (roll back, keep partial, compensate) per product family.
7. Out-of-order and duplicate events.
Symptom: a late „in progress“ event overwrites „completed“.
Fix: idempotent consumers keyed by event ID, state-machine guards that reject illegal or stale transitions, and a version or timestamp comparison before applying a change.
5. Concurrent orders: do you put „pending“ in inventory?
This is where architects disagree, and it’s worth deciding consciously.
Option A, realized state only. Inventory holds only what has been fulfilled. Everything in flight lives in orders. To check for conflicts, COM queries open orders for the product. It is clean, but every consumer who needs to know „may I change this product now?“ has to look in two places.
Option B, pending markers in inventory. Inventory also reflects in-flight changes, for example a product being activated or terminated. Consumers get a single place to look, but inventory now mixes result and process, which is exactly the blur Rule 1 tries to avoid.
My pragmatic recommendation is a hybrid:
- Inventory contains realized state plus a minimal, COM-written pending marker (the lifecycle models of products already include pending-type statuses for this purpose).
- COM is the only component that starts an order on a given product, and it serializes orders per product, so there is exactly one open change at a time.
- Channels and agents do not guess. They ask an eligibility question first (TMF679 is a natural fit: may this customer change this product now?), and the answer accounts for open orders.
Be aware that the standard product status model does not cover every real-world need. Concepts such as a lock on a product, or an operational sub-status next to the main status, are usually added as extensions in practice. If you add them, document who sets and clears them, because an orphaned lock is as harmful as a missing one.
6. Reconciliation: treating disagreement as a signal
Even with perfect ownership rules, reality will drift: manual network changes, failed rollbacks, lost events, migrations. You need a reconciliation process, not just good intentions.
Three modes
| Mode | When | Purpose |
|---|---|---|
| Event-driven | Continuously, on every state-change event | Keep state aligned in normal operation |
| Scheduled sweep | Nightly or weekly, per product or service family | Find drift that events missed |
| On demand | Before a modify order, or during care diagnosis | Verify state before acting on it |
Types of drift
- Ghost: exists in inventory, not in the network (billing without service).
- Orphan: exists in the network, not in inventory (service without billing).
- Attribute mismatch: both exist, but configuration differs.
- State mismatch: both exist, but lifecycle or operational state differs.
Ghosts and orphans are not just technical issues. They are revenue assurance issues, because product inventory typically drives billing and rating.
Who wins on mismatch?
Decide per attribute class, in advance:
| Attribute class | Master | On mismatch |
|---|---|---|
| Commercial (offer, price, contract dates) | Product inventory, via COM | Network is irrelevant. Correct the data through an audited correction. |
| Service intent (requested characteristics) | Service inventory, from the service order | Re-provision to match, or raise an incident. |
| Operational status (running, degraded, failed) | Network / monitoring | Update inventory automatically. This is an observation, not a decision. |
| Allocated resource identifiers (ports, addresses) | Network discovery | Validate, then correct inventory. |
Never fix drift silently
Corrections must be visible: a correction order or a controlled administrative path, with who, why, before and after, and a state-change event so downstream systems learn about it. A drift process that patches records quietly will eventually hide the very problems it should expose.
7. A diagnostic matrix for care and operations
When a customer asks „where is my order?“, read order state, service state and product state together, instead of picking one:
| Order | Service (TMF638) | Product (TMF637) | Likely meaning | Action |
|---|---|---|---|---|
| inProgress | active | absent or pending | Fulfilment result not yet processed by COM (lost or delayed event) | Replay or re-read the result; check the event queue |
| inProgress for a long time | designed / reserved | pending | SOM is waiting for a manual task, a resource or the network | Check SOM’s task queue and open manual tasks |
| completed | not active or absent | active | Drift after completion (manual change, rollback, migration), or a defect in the completion logic | Verify against the network; raise a reconciliation case; check whether the completion logic is at fault |
| failed | active | absent | Orphan after failed order | Compensate (decommission or complete); check billing impact |
| completed | degraded | active | Not an order problem; operational issue | Open a trouble ticket instead of an order inquiry |
| completed | active | active, but network shows nothing | Ghost | Raise a reconciliation case; check revenue impact |
This matrix is also what an AI agent or assistant should implement: report all three states, flag the inconsistency, and don’t decide which one is right. That decision belongs to operations or to your reconciliation process.
8. Events and idempotency: the plumbing that makes it work
TMF APIs offer state-change notifications for orders, services and products. For ownership rules to hold in practice:
- Make consumers idempotent. Events get redelivered. Processing the same event twice must have the same effect as once.
- Guard transitions. Reject illegal or stale transitions explicitly, and log them. They tell you about integration bugs.
- Carry correlation. Include the product order, order item and service order references in events so any state can be traced back to its cause.
- Use an outbox for completion. Writing inventory and emitting the completion event should not be two independent operations.
- Plan replay. Have a dead-letter queue and a safe way to replay events, so a lost message is a fixable incident, not a permanent inconsistency.
A simplified service state-change event shows what a consumer needs:
{"eventId": "evt-8f21","eventType": "ServiceStateChangeEvent","eventTime": "2026-10-05T09:14:22Z","correlationId": "po-48213/item-2","event": {"service": {"id": "svc-77310","state": "active","version": 4}}}
The eventId supports idempotency, the correlationId supports tracing, and the version lets the consumer ignore anything older than what it already applied. The exact event schema depends on your implementation. The principles don’t.
9. A pragmatic checklist
Before your next integration or review, check the following:
- Is there a written table of single writers for every state attribute?
- Do channels have read-only access to all state APIs?
- Is the product state derivation rule defined for each product family?
- Does the order complete only after the network result and the inventory write are confirmed?
- Are partial and failed outcomes defined, including what happens to inventory?
- Do you have event idempotency, transition guards and replay?
- Is there a reconciliation process with an explicit master per attribute class?
- Are corrections audited and visible downstream?
- Do care tools and agents show all three states instead of one?
Conclusion
The question „who owns the state?“ doesn’t have one answer, because there is more than one kind of state. Orders own the state of requests. Inventory owns the state of results. The network owns operational reality. And „completed“ is a statement about a moment, not a guarantee about the future. TMF Open APIs give you well-defined resources and state models for each layer, but they are integration contracts, not an ownership policy.
The pragmatic approach is to decide ownership explicitly, keep one writer per state, let results flow up through orchestration, and treat disagreement as a signal for a controlled reconciliation process. That is less glamorous than a new platform, and it prevents more incidents than most platforms do.
Working through order, inventory and reconciliation design in your own BSS/OSS landscape? A short initial conversation is free and non-binding.
