More Information

SID: structure, patterns and the step to an ontology

SID gives you the nouns. This is how they become meaning an agent can use.

SID is the industry's shared dictionary for telecom business, and the telecom ontology for BSS and OSS in Exosphere Agentic is built directly on 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 11 October 2026

A shared dictionary every system can speak

The Information Framework (GB922 SID) describes the business entities a service provider works with, independent of platform, language and protocol. It is a UML model. Open API payloads serialise SID-aligned structures as JSON, but the model itself is UML-native.

Domains group related concerns: Market and Sales, Customer, Product, Service, Resource, Business Partner, Enterprise, and a Common domain shared across them.
Aggregate Business Entities (ABEs) are sub-domains, the chapters of the dictionary. An ABE can contain other ABEs.
Business entities carry the attributes and relationships.

SID says what; eTOM (GB921) says how. The framework overview (GB991) also describes a Patterns domain of abstract ABEs that the business domains specialise.

SID layering and patterns

flowchart TB
    DOM["Domain<br/>e.g. Product, Service, Resource"]
    ABE["Aggregate Business Entity<br/>a sub-domain"]
    BE["Business Entity<br/>attributes and relationships"]
    PAT["Patterns domain<br/>abstract ABEs"]
    BP["Basic patterns<br/>Spec and Entity · Entity and Role<br/>Composite and Atomic · Characteristic"]
    EP["Pattern ABEs<br/>e.g. Usage, Closed Loop, Intent"]
    DOM --> ABE
    ABE --> BE
    ABE -->|"may contain"| ABE
    PAT --> BP
    PAT --> EP
    EP -.->|"sub-classed into domains"| ABE
    BP -.->|"templates for"| BE
    classDef std stroke:#005F8A,stroke-width:1px
    class DOM,ABE,BE,PAT,BP,EP std

Domains hold ABEs, ABEs hold business entities, and the Patterns domain supplies the templates.

SID's own patterns become the ontology's class templates

The telecom ontology does not invent a new modelling style. It promotes the basic patterns SID already defines (GB922 User's Guide) into entity types and typed relationships.

SID pattern	What it captures	How the ontology uses it
Specification and Entity	The catalogue definition versus the instance	Paired entity types, such as ProductSpecification and Product
Entity and Role	A thing versus the part it plays	Party and PartyRole, with Customer as a specialised role
Composite and Atomic	Trees and graphs of parts, such as one offering inside several bundles	Bundling and decomposition as typed relationships
Characteristic	Attributes that extend at run time	Characteristic values bound as properties, with their specification recorded

Elaborate patterns are subclassed per domain. Usage is the standard example: one Usage pattern, specialised as Product, Service and Resource Usage. The Patterns domain also holds abstract ABEs for Intent, Goal, Policy, Closed Loop and Metric, which is where agentic loops find their footing in SID.

Why a consensus model leaves room for meaning

SID is a consensus model, and it is deliberately highly normalised: rich in entities and associations, lighter on attributes, because agreement comes most readily at the level of entities (GB979D). Its user guide presents it as a reference model rather than a schema to implement as-is. That is exactly what makes SID a durable shared vocabulary, and it shapes what an agent needs on top.

Meaning lives in instances. Which resource carries which service for which customer only exists once real records are linked.
Associations are declared; the graph comes next. TM Forum already models associations with direction, navigability and multiplicity in its entity catalogue APIs (TMF662, TMF703). The next step is a shared instance graph that rules can check and agents can traverse.
SID and the APIs travel together. Open API data models take SID input where appropriate and are mapped back to it (RN310), so every entity type can name both its ABE and its API.

Where TM Forum is heading

Formal ontology is already part of TM Forum's toolkit. The TM Forum Intent Ontology (TIO, IG1358) validates the intents exchanged through TMF921 Intent Management. It is built on RDF and RDFS, uses OWL-Time, and is written in Turtle or JSON-LD.

Exploratory guidance on agentic architecture (IG1486) suggests SID could be formalised as an OWL/RDF ontology, a shared world model for agents. Read it as direction of travel.
TM Forum's AI-Native ODA roadmap prioritises BSS and OSS ontologies built on SID and eTOM.

Exos builds in the same direction now: SID-aligned entity types, typed relationships and checkable conformance rules, ready to sit alongside the formal ontology work as it matures.

From SID to agent-ready meaning: the Exos method

Five steps take SID from a shared dictionary to meaning an agent can act on. They are the Exos method, not a TM Forum process.

Resolve each ABE to an entity type with a stable key and a declared subtype hierarchy, so customer-facing and resource-facing services are subtypes of Service rather than a category string.
Promote the references inside Open API payloads, an id and an href, to typed, directional relationships with cardinality.
Bind each entity type to the system of record or stream that holds it, with a refresh policy suited to its cadence.
Constrain the graph with conformance rules an engine checks, such as a product order not completing before its service orders resolve.
Cite the provenance of every assertion, back to the retrieved passage and its source document.

Binding, constraints and citation are where the ontology meets your own estate. Exos delivers them per engagement, starting with one domain mapped properly. See SID to entity types, entity by entity.

From SID to agent-ready meaning

flowchart TB
    S1["GB922 SID<br/>UML information model"]
    S2["Open API schemas<br/>SID-aligned payloads"]
    subgraph M["EXOS METHOD"]
        S3["Resolve<br/>entity types and subtypes"]
        S4["Promote<br/>typed directional links"]
        S5["Bind<br/>systems of record and streams"]
        S6["Constrain<br/>conformance rules"]
        S7["Cite<br/>provenance per answer"]
    end
    S8["Agents act via MCP<br/>governed and audited"]
    S1 --> S2 --> S3 --> S4 --> S5 --> S6 --> S7 --> S8
    classDef exos stroke:#0077B6,stroke-width:2px
    classDef std stroke:#005F8A,stroke-width:1px
    class S3,S4,S5,S6,S7 exos
    class S1,S2 std

The first two steps are TM Forum's; Resolve to Cite is the Exos method.

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.