Industry Vocabulary Reference

Telecommunications & IT Operations

Telecommunications and IT operations fields describe service orders, alarms, incidents, network changes, and service levels. Use them to connect a recorded action with its operational context.

Back to industry coverage library

This page shows selected examples and categories. Download the JSON for the complete vocabulary, including every field, permitted value, and policy pattern in this catalog.

How to use this reference

1. Start with the core file if you need the cross-industry governance baseline.
2. Choose an industry file for its workflow fields and permitted values.
3. Match the OTel attributes to the policy paths your rules use, then verify the recorded fields in a test session.

Catalog context

Begin with a service workflow whose actions and results you can verify. For network changes, record the requested change, approval, execution result, and recovery outcome.

Risk note: Autonomy levels describe operation; they do not establish legal compliance. Confirm reporting thresholds and deadlines for the operator, service, and jurisdiction.

Vocabulary file

• Download filename: 05_vertical_telecom_it_operations.json
• Kind: vertical

OTel namespaces

Referenced standards

These references explain the catalog's context. A listed standard does not establish that a configured application meets its requirements.

• TM Forum Open API v5.0.1, TMF621 Trouble Ticket Management API v5.0.1 (July 2025 patch)
• TM Forum Open API v5.0, TMF622 Product Ordering Management API v5.0.0
• TM Forum Open API v4.0, TMF640 Service Activation & Configuration API
• TM Forum Open API v5.0, TMF641 Service Ordering Management API v5.0.0
• TM Forum Open API v5.0, TMF642 Alarm Management API v5.0.0
• TM Forum Open API v4.1, TMF628 Performance Threshold Management API
• TM Forum Open API v4.0, TMF688 Event Management API
• TM Forum Autonomous Networks level framework
• ITU-T X.733 (1992), Alarm Reporting Function; extended by ITU-T X.736 Security Alarms
• ITU-T M.3400, TMN Network Management Functions
• 3GPP TS 28.541, 5G NR Network Resource Model (NRM) for Network Slice Management
• 3GPP TS 28.530, 5G NRM Concepts and Requirements for Network Slice Management
• 3GPP TS 28.545, Fault Supervision for Network Slices
• ITIL 4, IT Service Management (Axelos, 2019, current edition)
• ITIL 4 Change Enablement Practice Guide (Axelos, 2020)
• ITIL 4 Incident Management Practice Guide (Axelos, 2020)
• NIST Cybersecurity Framework (CSF) 2.0 (February 2024)
• NIST SP 800-61 Rev 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management (April 2025)
• ETSI ENI 007, Terminology for Experiential Networked Intelligence
• ETSI ZSM 002, Zero-touch Network and Service Management Reference Architecture (2019)
• IEEE 802.1Q, VLANs / Bridged Local Area Networks (for network topology context)
• NERC CIP v7, Critical Infrastructure Protection (applicable to telco/CNI overlap)
• EU NIS2 Directive (2022/2555), Network and Information Security for essential entities
• FCC Part 4, Disruptions to Communications (US outage reporting)
• Ofcom Network Reporting Code (UK), Communications provider outage notifications

Source references

• https://www.tmforum.org/open-digital-architecture/open-apis 
• https://www.tmforum.org/resources/specifications/tmf621-trouble-ticket-management-api-user-guide-v5-0-0/ 
• https://www.tmforum.org/open-digital-architecture/open-apis/product-ordering-management-api-TMF622/v5.0 
• https://www.tmforum.org/open-digital-architecture/open-apis/alarm-management-tmf642/ 
• https://www.3gpp.org/ftp/Specs/archive/28_series/28.541/ 
• https://www.3gpp.org/ftp/Specs/archive/28_series/28.530/ 
• https://www.etsi.org/deliver/etsi_gs/ZSM/001_099/002/01.01.01_60/gs_ZSM002v010101p.pdf 
• https://www.nist.gov/cyberframework 
• https://www.itil.com/ 
• https://www.itu.int/rec/T-REC-X.733/en 

Subdomains

Implementation examples

• 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)

Control ideas

These patterns describe possible controls, not active rules. Confirm applicability, implement the control, and test its effect on the application.

Enforce before the action

Pass the request and your business action to this function. The core SDK checks policy before the action runs and again before its result is released. A deny or review decision means the action never runs.

import { Veriproof } from '@veriproof/sdk-core';
import type { GovernedResult, IndustryFact, JsonValue } from '@veriproof/sdk-core';

const veriproof = Veriproof.fromEnv();

export async function runProtectedAction<TInput extends JsonValue, TValue>(
  request: TInput,
  action: (input: TInput, signal: AbortSignal) => Promise<TValue>,
): Promise<GovernedResult<TValue, TInput>> {
  // Catalog values for this vertical. Replace them with facts from the current workflow.
  const industry: IndustryFact[] = [
    { attribute: "telecom.trouble_ticket.status", policyInput: "telecom_trouble_ticket_status", value: "new" },
    { attribute: "telecom.trouble_ticket.severity", policyInput: "telecom_trouble_ticket_severity", value: "critical" },
    { attribute: "telecom.trouble_ticket.type", policyInput: "telecom_trouble_ticket_type", value: "trouble_report" },
  ];

  // Policy runs before action() and again before the result is released.
  // A deny or review decision means action() never runs.
  return veriproof.govern(
    "telecom.it.operations.evaluate",
    request,
    ({ input, signal }) => action(input, signal),
    { industry },
  );
}

• Replace the sample values with facts from the current workflow. Rules read them under input.snapshot.industry.
• Test both permitted and blocked actions. Confirm that a blocked action never reaches your business function.
• Only completed, completed_with_warning, and transformed results carry a released value.

For review decisions, follow the Human Review guide to configure continuation. Observe remains available when you need to record activity without enforcing a decision.

Set up the Telecommunications & IT Operations example. See the API reference for TypeScript, Python, or .NET.

Selected vocabulary categories

This page uses the vocabulary JSON distributed with the documentation. Check its version when comparing it with an installed SDK.

Download the vocabulary JSON for offline review or automated comparisons.

Use the SDK reference for configuration and supported APIs. Keep vocabulary selection separate from the compliance team's assessment of applicable requirements.