SDK Quick Start — Telecommunications & IT Operations

Getting started: Telecommunications & IT Operations

This guide takes you from install to your first attributed governance record in telecommunications & it operations. You will install the SDK, configure a provider, instrument a workflow step with the real OTel attribute vocabulary from this vertical, and have a reviewable evidence record in your portal within an afternoon. There is no scaffolding project — just your API key and the three steps below.

Why this matters right now. As of March 2026, agentic AI in telecommunications and IT operations is deployed across: autonomous network operations (Level 3–4 on TM Forum AN scale) with AI-driven fault detection and self-healing, AIOps platforms automating root cause analysis and runbook execution across cloud and on-premises infrastructure, AI-powered trouble ticket triage and resolution (TMF621 API integration), autonomous product order orchestration replacing manual provisioning workflows (TMF622), 5G network slice lifecycle management with AI-driven SLA assurance, security operations centre (SOC) automation for threat detection and incident response, ITIL 4 change management with AI-generated standard change proposals, and customer-facing conversational agents for fault reporting and service updates. The TM Forum Autonomous Networks Level 4 (intent-driven, cross-domain automation with human oversight) represents the target maturity for tier-1 operators. ETSI ZSM zero-touch networks and 3GPP SON (Self-Organising Networks) provide the standards foundation. EU NIS2 (in force October 2024) directly applies to telecoms as essential entities, mandating incident reporting within 24h (early warning) and 72h (detailed notification). FCC Part 4 outage reporting applies to US operators. EU NIS2 Directive (2022/2555) entered force October 18, 2024, applying to telecommunications operators as 'essential entities'. NIS2 Article 21 mandates security measures including AI system governance; Article 23 requires 24-hour early warning and 72-hour detailed incident notification to national CSIRTs. NERC CIP v7 applies to telecom networks overlapping with energy sector critical infrastructure. FCC Part 4 requires US carriers to notify NORS within 120 minutes of discovering an outage meeting threshold criteria. The TM Forum Autonomous Networks framework defines five autonomy levels (AL0–AL4) that map directly to the EU AI Act Article 14 human oversight requirements for AI systems — AL3+ systems (cross-domain autonomous) require documented human oversight mechanisms to remain compliant.

How the layering works

You are not adopting a separate product surface for this vertical. You are adding a market-specific vocabulary layer on top of the same core session model used everywhere in VeriProof.

If you need the cross-industry baseline first, open the core SDK reference, Python core, or .NET core before continuing here.

Step 1 — Install

TypeScript / Node.js

npm install @veriproof/sdk-core

Python

pip install veriproof-sdk

.NET

dotnet add package Veriproof.Sdk

Step 2 — Configure

Call the configuration helper once, before any AI framework initialises. After that call, every OTel span in the process — whether emitted by your code or by a framework adapter — is exported automatically to VeriProof.

Your API key comes from the VeriProof portal. Try a live demo to see the portal before you register, or start a free Builder account and use the environment variable pattern above directly.

Need a production credential path rather than sandbox exploration? Get API access for a Builder account, or contact the team if you need an architecture or compliance review alongside implementation.

Step 3 — Instrument your workflow

The governance vocabulary for this vertical lives in the Telecommunications & IT Operations reference. Use the OTel attribute names below — they are the same names the portal uses in evidence records and the same names your policy engine will evaluate. Consistency here is the point.

TypeScript example

import { configureVeriproof, VeriproofClient, VeriproofSdkOptions, SessionMetadata } from '@veriproof/sdk-core';
import { TroubleTicketStatus, TroubleTicketStatusMeta, TroubleTicketSeverity, TroubleTicketSeverityMeta } from '@veriproof/sdk-core/verticals/telecom-it-operations';

// Call once at application startup
configureVeriproof(
  VeriproofSdkOptions.createProduction({
    apiKey: process.env.VERIPROOF_API_KEY!,
    applicationId: 'telecom-it-operations-app',
  }),
  { serviceName: 'telecom-it-operations-app', setGlobal: true },
);

// Instrument a governed workflow
const client = new VeriproofClient(
  VeriproofSdkOptions.createProduction({ apiKey: process.env.VERIPROOF_API_KEY! }),
);

const session = client
  .startSession('telecom.it.operations.review')
  .withSessionMetadata(SessionMetadata.forTransaction('txn-001').withEnvironment('production'))
  .addStep('evaluate', { output: { status: 'completed' } })
  .withMetadata(TroubleTicketStatusMeta.otelAttribute, TroubleTicketStatus.new)
  .withMetadata(TroubleTicketSeverityMeta.otelAttribute, TroubleTicketSeverity.critical)

await session.complete();

Python example

import os
from opentelemetry import trace
from veriproof_sdk import VeriproofClientOptions, configure_veriproof
from veriproof_sdk.verticals import telecom_it_operations as tio

# Call once at application startup
configure_veriproof(
    VeriproofClientOptions(
        api_key=os.environ["VERIPROOF_API_KEY"],
        application_id="telecom-it-operations-app",
    ),
    service_name="telecom-it-operations-app",
    set_global=True,
)

tracer = trace.get_tracer(__name__)

# Instrument a governed workflow
with tracer.start_as_current_span("telecom_it_operations.review") as span:
    span.set_attribute(tio.TroubleTicketStatus.__otel_attribute__, tio.TroubleTicketStatus.new.value)
    span.set_attribute(tio.TroubleTicketSeverity.__otel_attribute__, tio.TroubleTicketSeverity.critical.value)
    span.set_attribute(tio.TroubleTicketType.__otel_attribute__, tio.TroubleTicketType.trouble_report.value)
    ...

.NET example

using Veriproof.Sdk;
using Veriproof.Sdk.Core.OpenTelemetry.Verticals.TelecomItOperations;

// Configure once at application startup
builder.Services.AddVeriproof(options =>
{
    options.ApiKey = builder.Configuration["VERIPROOF_API_KEY"]!;
    options.ApplicationId = "telecom-it-operations-app";
});

// Instrument a governed workflow step
using var activity = ActivitySource.StartActivity("evaluate");
    activity?.SetTag(TroubleTicketStatus.Metadata.OtelAttribute, TroubleTicketStatus.new);
    activity?.SetTag(TroubleTicketSeverity.Metadata.OtelAttribute, TroubleTicketSeverity.critical);
    activity?.SetTag(TroubleTicketType.Metadata.OtelAttribute, TroubleTicketType.trouble_report);

How teams use this in production

• Trouble Ticket & Service Assurance: Trouble Ticket Status. An AI triage agent creates a ticket in 'new' state, acknowledges it moving to 'acknowledged', then routes it to an autonomous remediation agent moving to 'in_progress'. If the automated fix requires a change window, the agent transitions to 'held' until the change is approved. (Eu Nis2 Art23: EU NIS2 Article 23 — Incident reporting obligations require ticket state to be machine-readable for regulatory timeline tracking (24h early warning, 72h notification))
• Trouble Ticket & Service Assurance: Trouble Ticket Severity. AI triage agent assigns severity based on affected service, customer count, and revenue impact. Critical severity tickets trigger automatic NIS2 timeline tracking and human escalation. (Eu Nis2 Art23: Severity 'critical' or 'major' tickets affecting essential service must be assessed for NIS2 Article 23 reportability)
• Trouble Ticket & Service Assurance: Trouble Ticket Type. Security_incident type tickets are routed to the SOC AI agent chain and subject to NIS2/NIST CSF 2.0 incident handling procedures. Problem type tickets engage the problem management AI agent for root cause analysis across related incidents.
• Trouble Ticket & Service Assurance: Incident Priority. AI incident management agent assigns priority on ticket creation. P1/P2 incidents trigger HITL escalation workflow; P3/P4 permit autonomous runbook execution. (Itil4: ITIL 4 Incident Management Practice — priority matrix based on urgency × impact)

Next steps

• Open the full Telecommunications & IT Operations governance reference for all 32 enum categories, policy patterns, and source standards.
• Review TypeScript SDK core for advanced session-builder options, batch export, and Merkle verification.
• Review Python SDK core for decorator-based annotations and framework adapter options.
• Review .NET SDK core for Semantic Kernel, AutoGen, and Activity-based instrumentation.
• Browse all vertical references to understand how the core governance vocabulary layers underneath vertical-specific attribute sets.
• Compare this guide with the public industry pages if you need the commercial and workflow framing behind the same vocabulary.