SDK Quick Start — Energy & Utilities

Getting started: Energy & Utilities

This guide takes you from install to your first attributed governance record in energy & utilities. 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 energy and utilities is deployed across: autonomous grid state estimation and topology optimisation (IEC CIM 61970 integration via EMS APIs), AI-driven demand response orchestration replacing manual DR programme management (OpenADR 2.0b), DER aggregation and virtual power plant (VPP) dispatch agents (FERC Order 2222 compliance), predictive maintenance for generation and transmission assets (reducing forced outage rates), AI-powered energy trading and settlement optimisation (FERC/ENTSO-E market rules), NERC CIP compliance monitoring agents automating evidence collection and gap detection, renewable energy forecasting and curtailment optimisation, pipeline integrity management AI (inline inspection data analysis, anomaly detection), water and wastewater process optimisation agents, and emissions monitoring and ETS compliance automation. The EU AI Act does not explicitly list energy grid management as Annex III high-risk AI, but the EU NIS2 Directive (2022/2555) classifies energy as an essential sector — grid management AI systems are subject to NIS2 security and incident reporting obligations. NERC CIP v7 directly constrains AI system deployment on Bulk Electric System (BES) Cyber Systems — AI agents operating on or near BES assets must meet CIP-005 electronic security perimeter and CIP-007 system security requirements. NERC CIP v7 creates direct regulatory exposure for AI systems connected to or interacting with BES Cyber Systems (BCS). A BCS is any programmable device that, if compromised, could adversely impact the reliable operation of the Bulk Electric System. AI agents performing autonomous topology changes, protection relay configuration, or EMS setpoint modifications on high or medium impact BCS assets require documented change management (CIP-010) and vendor supply chain risk management (CIP-013). FERC Order 3052 (2024) creates cybersecurity investment incentives tied to NERC CIP compliance — AI security monitoring systems are eligible for incentive rate treatment. EU ETS Phase 4 (2021-2030) requires continuous emissions monitoring with verified data — AI-driven CEMS (Continuous Emissions Monitoring Systems) must maintain EPA 40 CFR Part 75 / EU MRR data quality standards or face allowance invalidation.

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 Energy & Utilities 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 { GridAssetOperationalStatus, GridAssetOperationalStatusMeta, SwitchingEquipmentState, SwitchingEquipmentStateMeta } from '@veriproof/sdk-core/verticals/energy-utilities';

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

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

const session = client
  .startSession('energy.utilities.review')
  .withSessionMetadata(SessionMetadata.forTransaction('txn-001').withEnvironment('production'))
  .addStep('evaluate', { output: { status: 'completed' } })
  .withMetadata(GridAssetOperationalStatusMeta.otelAttribute, GridAssetOperationalStatus.in_service)
  .withMetadata(SwitchingEquipmentStateMeta.otelAttribute, SwitchingEquipmentState.closed)

await session.complete();

Python example

import os
from opentelemetry import trace
from veriproof_sdk import VeriproofClientOptions, configure_veriproof
from veriproof_sdk.verticals import energy_utilities as eu

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

tracer = trace.get_tracer(__name__)

# Instrument a governed workflow
with tracer.start_as_current_span("energy_utilities.review") as span:
    span.set_attribute(eu.GridAssetOperationalStatus.__otel_attribute__, eu.GridAssetOperationalStatus.in_service.value)
    span.set_attribute(eu.SwitchingEquipmentState.__otel_attribute__, eu.SwitchingEquipmentState.closed.value)
    span.set_attribute(eu.OutageLifecycleState.__otel_attribute__, eu.OutageLifecycleState.reported.value)
    ...

.NET example

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

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

// Instrument a governed workflow step
using var activity = ActivitySource.StartActivity("evaluate");
    activity?.SetTag(GridAssetOperationalStatus.Metadata.OtelAttribute, GridAssetOperationalStatus.in_service);
    activity?.SetTag(SwitchingEquipmentState.Metadata.OtelAttribute, SwitchingEquipmentState.closed);
    activity?.SetTag(OutageLifecycleState.Metadata.OtelAttribute, OutageLifecycleState.reported);

How teams use this in production

• Grid Asset & Outage Management (IEC CIM): Grid Asset Operational Status. AI energy management agent monitors all BES asset statuses via CIM. 'Forced_outage' on a high-impact asset triggers automatic NERC EOP-004 assessment, initiates restoration workflow, and escalates to grid operations HITL. AI agent may not autonomously re-energise a 'de_energized' asset — crew clearance confirmation required. (Nerc Eop 004: NERC EOP-004 — Disturbance reporting: 'forced_outage' on BES elements meeting reporting thresholds must be reported to NERC and regional entity)
• Grid Asset & Outage Management (IEC CIM): Switching Equipment State. AI distribution management agent executes fault isolation switching sequences. Each switching step is logged with the pre- and post-state. OPA policy blocks AI from closing a 'grounded' switch — crew clearance confirmation from safety system is required first. (Nerc Cip 010: NERC CIP-010 — Configuration change management: autonomous AI switching on BES Cyber Systems requires approved change documentation)
• Grid Asset & Outage Management (IEC CIM): Outage Lifecycle State. AI outage management agent receives outage reports from AMI (Advanced Metering Infrastructure), customer calls, and SCADA alarms. Agent correlates reports, confirms outage boundary, and dispatches crew. OPA policy enforces that 'fully_restored' state requires meter-verified restoration confirmation — not just switch state change.
• Grid Asset & Outage Management (IEC CIM): Protection Relay Operation Status. AI grid monitoring agent detects relay operation from SCADA and classifies status. 'Reclose_failed_lockout' triggers immediate crew dispatch. 'Protection_inhibited_ai_action' is a critical flag indicating an AI agent has interfered with protection — requires immediate HITL escalation and is a NERC compliance event. (Nerc Prc 023: NERC PRC-023 — Transmission relay loadability: relay settings affected by AI optimisation must comply with NERC PRC-023 loadability criteria)

Next steps

• Open the full Energy & Utilities governance reference for all 23 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.