An interface needs a specific contract

I spent years at ETI Software Solutions working with software that had to fit into an ISP’s operational systems. A new tool needs more than access to an API: it needs the correct identifiers, operations and state transitions for the operator’s workflow.

TM Forum’s Open APIs provide defined contracts for parts of the telecom stack. Alignment can make those connections more consistent, while authentication, optional features, versions and local extensions still affect an integration.

For example, TMF642 covers Alarm Management, TMF639 covers Resource Inventory Management, and TMF621 covers Trouble Ticket Management. TMF622 covers Product Ordering.

Autonomy is assessed in a defined context

TM Forum’s Autonomous Networks model spans six levels, from 0 through 5: manual, assisted, partial, conditional, high and full autonomy.

A level applies to a defined operational context. Automating one diagnostic scenario does not establish that an entire network operates at that level.

Conditional autonomy is a useful design target for a bounded fault-handling scenario: the system handles the cases within its defined scope and escalates exceptions. XSI LodeStone’s shadow and graduated-autonomy approach is designed to make that scope visible to the operator.

Connect a fault to its operational record
Standard API responsibilities connect alarm, resource and ticket records within a defined fault-handling workflow.

Follow one fault through the system

An alarm can be linked to inventory and topology records to identify the affected resources and services. A curated procedure can then establish the diagnostic operations available for that device and fault.

If the evidence is incomplete or the fault falls outside the approved scenario, the workflow escalates with its current findings. If an action is eligible, the execution layer still checks the operator’s policy and any required approval.

The resulting record should connect the alarm, relevant resource identifiers, diagnostic evidence, proposed action and outcome. A trouble ticket can carry that work into the operator’s existing service process.

Verify integration and scope

A deployment needs to test the operations it will use against the actual OSS/BSS and management systems. Matching an API name is not a guarantee that every required operation or data field is implemented.

XSI’s Telecom Skill Library combines those interfaces with equipment-specific procedures and escalation logic. Standards alignment supports integration; it is separate from a formal certification or an observed autonomy-level assessment.

The useful deployment record identifies the API versions, supported scenarios, tested equipment and cases that require human handling. It gives both teams a concrete basis for operating and extending the integration.

Define the integration that will actually run

Select diagram to enlarge
A useful integration record names the interface version, operations, local mappings, authority limits and observed test outcomes.
Rhyan J. Neble
Rhyan J. Neble
Founder & CEO, Extended Systems Intelligence