Pages
More Information
SID to entity types, entity by entity
An illustrative mapping: ABE, entity type, typed relationship, Open API and plane
This is the working table behind the telecom ontology for BSS and OSS in Exosphere Agentic: each SID entity a loop touches, with its entity type, typed relationships and the Open API that reads or writes it. Exosphere Agentic runs on Azure and integrates with the Microsoft AI platform, deployed into the customer's own tenant — so context, data and governance stay where they belong.
Updated
Three contributions, each in its lane
- TM Forum supplies the nouns: SID ABEs, and the Open APIs that expose them.
- Microsoft supplies the platform: ontology and graph primitives in Microsoft Fabric, Fabric IQ for shared context, and Copilot Studio and Microsoft Foundry for the agents.
- Exos supplies the telecom mapping: ABE to entity type, typed relationships, bindings and refresh policy, conformance rules, and the governed action path through Exosphere, the judgment layer inside Exosphere Agentic.
Fabric gives agents context to reason with. Change takes a different route: the agent proposes, Exosphere applies policy, and the call reaches the owning system through TM Forum Open APIs.
SID to the telecom ontology: who does what
flowchart TB
subgraph TMF["TM FORUM · STANDARDS"]
direction TB
T1["SID ABEs<br/>Party · Product · Service<br/>Resource · Agreement"]
T2["Open APIs<br/>TMF620 · 622 · 637 · 638<br/>639 · 656 · 657 · 678"]
end
subgraph EX["EXOS · THE MAPPING WORK"]
direction TB
X1["ABE to entity type<br/>keys and subtypes"]
X2["Typed relationships<br/>and cardinality"]
X5["Conformance rules"]
X3["Bindings<br/>and refresh policy"]
X4["Exosphere<br/>governed action"]
end
subgraph MS["MICROSOFT AI PLATFORM"]
direction TB
M1["Fabric IQ ontology<br/>shared context"]
M2["Graph in<br/>Microsoft Fabric"]
M3["Copilot Studio and<br/>Microsoft Foundry agents"]
end
OP["Operator systems of record<br/>and event streams"]
T1 --> X1
X1 --> X2
X2 --> X5
X5 --> M1
OP --> X3
X3 -->|"bind and refresh"| M1
M1 --> M2
M2 -->|"context · read"| M3
M3 -->|"proposed action"| X4
X4 -->|"policy and audit"| T2
T2 -->|"governed write"| OP
classDef ms stroke:#4A5F7A,stroke-width:2px
classDef exos stroke:#0077B6,stroke-width:2px
classDef std stroke:#005F8A,stroke-width:1px
classDef sor stroke:#7A8DA5,stroke-width:1px
class M1,M2,M3 ms
class X1,X2,X3,X4,X5 exos
class T1,T2 std
class OP sorHow to read the table
The SID column names the ABE. The entity type is what the ontology declares. Relationships are typed and directional. The Open API is the contract that reads or writes the entity, and the plane says how the entity is bound.
| Plane | Binds to | Cadence |
|---|---|---|
| Spine | Catalogue, inventory, party and agreement records | Business cadence, on a scheduled refresh |
| Stream | Usage, alarms and problem events | Continuous, kept in the real-time event store and joined at query time |
| Act | Loops, goals and policy | Every governed action, recorded in the audit lineage |
Semantics stay out of the real-time path, and authorisation and audit attach exactly at the hop where an agent acts. More in Three planes, two clocks, and usage to bill.
The mapping, entity by entity
Illustrative mapping. Properties, state sets and binding notes are covered in the ontology briefing; cardinalities follow TM Forum-derived design intent.
| SID ABE | Entity type | Typed relationships | TM Forum Open API | Plane |
|---|---|---|---|---|
| Party; Customer | Party (Individual, Organization); PartyRole; Customer as a specialised PartyRole; BillingAccount | Party playsRole Customer; Customer holds BillingAccount; Customer places ProductOrder | TMF632 Party; TMF669 Party Role; TMF629 Customer; TMF666 Account | Spine |
| Product Offering; Product Specification | ProductOffering; ProductSpecification; ProductOfferingPrice | ProductOffering specifiedBy ProductSpecification; bundles ProductOffering; pricedBy ProductOfferingPrice; ProductSpecification requires ServiceSpecification and ResourceSpecification | TMF620 Product Catalog; TMF633 Service Catalog; TMF634 Resource Catalog | Spine |
| Customer Order (product order) | ProductOrder; ProductOrderItem | ProductOrder contains ProductOrderItem; item references ProductOffering and yields Product; ProductOrder decomposesTo ServiceOrder (orchestration, TMFC003) | TMF622 Product Ordering (Customer domain); TMF641 Service Ordering downstream | Spine |
| Product (inventory) | Product, the installed instance | Product instanceOf ProductOffering; heldBy Customer; realisedBy CustomerFacingService; realisedBy Resource | TMF637 Product Inventory | Spine |
| Service: customer-facing | CustomerFacingService, a subtype of Service | CFS supportedBy RFS (0..n); measuredBy ServiceLevelObjective; affectedBy ServiceProblem | TMF638 Service Inventory; changed via TMF641 | Spine |
| Service: resource-facing | ResourceFacingService, a subtype of Service | RFS supports CFS; realisedBy Resource | TMF638 Service Inventory; ordered via TMF641 | Spine |
| Resource (logical and physical) | Resource (LogicalResource, PhysicalResource); ResourceSpecification | Resource specifiedBy ResourceSpecification; hostedOn Resource, with topology proximity as an attribute; raises Alarm | TMF639 Resource Inventory; TMF634 Resource Catalog; changed via TMF652 | Spine |
| Usage (Product, Service and Resource Usage) | ProductUsage; ServiceUsage; ResourceUsage | ProductUsage attributedTo Product; ratedAs AppliedBillingRate | TMF635 Product Usage; TMF727 Service Usage; TMF771 Resource Usage; TMF767 usage catalogue; TMF688 for events | Stream |
| Customer Bill | CustomerBill; AppliedBillingRate | CustomerBill onAccount BillingAccount; AppliedBillingRate appearsOn CustomerBill and derivesFrom ProductUsage or Product | TMF678 Customer Bill, the read and notification surface; credits are raised in billing and visible here | Spine |
| Trouble Ticket (Patterns domain) | TroubleTicket; Incident | TroubleTicket informs ServiceProblem, with a confidence attribute; Incident spans Resource, Service and Product | TMF621 Trouble Ticket for resource repair; TMF724 Incident for the ITIL view | Stream |
| Service Problem; alarms | ServiceProblem; Alarm | Alarm underlies ServiceProblem; ServiceProblem affects CFS, affectedResource Resource, affectedLocation Place, breaches ServiceLevelObjective | TMF642 Alarm; TMF656 Service Problem | Stream |
| Agreement; service levels | Agreement; ServiceLevelAgreement, a kind of Agreement; ServiceLevelSpecification; ServiceLevelObjective | Agreement betweenParties Party; SLA commitsVia ServiceLevelSpecification, which groups ServiceLevelObjective; SLO measuredOn CFS | TMF651 Agreement; TMF657 Service Quality; SLA reference on TMF620 | Spine |
| Closed Loop (Patterns domain) | ClosedLoop; ClosedLoopSpecification; ClosedLoopGoal; Policy | ClosedLoop specifiedBy ClosedLoopSpecification; pursues ClosedLoopGoal; ownedBy PartyRole; governedBy Policy | Governed action through Exosphere over the APIs above; TMF921 Intent where a loop is intent-driven | Act |
Modelling decisions the table encodes
- Subtypes, not strings. CFS and RFS are declared subtypes of Service, Customer is a specialised PartyRole, and LogicalResource and PhysicalResource are subtypes of Resource.
- Orchestration is labelled as orchestration. Order decomposition is recorded as ODA orchestration practice, never presented as a SID association.
- Conformance as checks. Rules such as "a product order cannot complete before its service orders resolve" are written in a form an engine checks, not left in specification prose.
- Enrichment carries the standard. GB922 definitions go into entity descriptions, TM Forum names into synonyms and the source API into metadata, so an agent can cite the standard behind a term.
- One identity across APIs. Each entity type has a stable key that every Open API reference resolves to.
- Versioned as code. The ontology pack is Git-versioned, so a second loop or a second operator starts from it, and it can be contributed upstream as TM Forum's ontology work matures.
How Exos delivers the mapping
The mapping is a bounded build, delivered per engagement and starting where your first loop needs it.
- Map one domain properly. The entities your first loop touches, bound to your systems of record, with the conformance rules that matter to that outcome.
- Cross the boundary. Extend from BSS into service and resource, so assurance signals reach the customer and the bill.
- Make it a reference asset. A versioned ontology pack and a governance runbook that the next loop reuses.
Ask for the ontology briefing to see the full table with properties, state sets and binding notes.
Take the next step
Start with one loop. There are many more. Exos Systems will walk you through the mapping for the outcome you most need to improve.