Data Center Operations AI Tools
Data Center Operations uses AI-assisted workflows through product APIs, Advisor-backed diagnosis, Predictive Maintenance handoff, and AI Engine health or remaining-life calls. The goal is to help operators review risk, prepare maintenance actions, and keep evidence traceable.
Use this page when an implementation team needs to understand which DCOps surfaces can be called by the application, which outputs require review, and how to combine DCOps with DFS, Inspector, and Predictive Maintenance.
Tool layers
| Layer | Primary users | Access boundary | Output type |
|---|---|---|---|
/api/v1/dcops/* product APIs | Data center operations UI and approved backend workflows | dcops.view, dcops.predict.view, dcops.diagnosis.run, dcops.workorder.link, and dcops.feedback.write | Dashboards, asset health, predictions, diagnosis, dispatch, BMS mapping, planning, and operations snapshots |
| Advisor diagnosis | Diagnosis workflow and review assistants | Product service authentication and diagnosis permission | Diagnosis summary, confidence, evidence source, and trace ID |
| Predictive Maintenance | Reliability and maintenance owners | pdm:read, pdm:write, and related product permissions | Equipment health, anomaly review, remaining-life estimates, advisories, and work-order feedback |
| AI Engine | Product services and controlled backend jobs | Service authentication and project configuration | Health score, remaining-life estimation, diagnosis support, and engine-mode metadata |
| DFS | Data owners and integration teams | DFS permissions for connectors, mappings, datasets, and quality review | Prepared BMS, alert, meter, equipment, work-order, and signal-history datasets |
When an external Agent needs DCOps context, use approved backend workflows and shared /mcp/base/ context for assets, documents, work orders, and evidence. Runtime tool availability should be discovered in the target environment before exposing a workflow.
Recommended AI-assisted flow
Data preparation
AI-assisted Data Center Operations depends on a source package that can be reviewed:
| Data | Why it matters |
|---|---|
| Equipment identity | Connects dashboards, BMS points, predictions, alerts, work orders, and feedback to the same operating object. |
| BMS mapping | Shows which source points drive target fields and whether mapping coverage is acceptable. |
| Alert history | Provides severity, timing, recurrence, and affected equipment context for diagnosis. |
| Work-order history | Provides recent actions, open backlog, SLA state, and feedback for closed-loop review. |
| Health and prediction snapshots | Provides score, risk level, probability, remaining-life range, model version, and engine mode. |
| Meter and energy readings | Supports PUE/WUE and energy review when definitions, units, and time windows are validated. |
Use DFS mappings, Data Quality in DFS Lite, and Prepare Predictive Maintenance Signal History before exposing automated review.
Health and prediction endpoints
Use these endpoints when an asset needs equipment-level health or risk review:
| Endpoint | Purpose | Review checks |
|---|---|---|
POST /api/v1/dcops/assets/{assetId}/health | Calculate and persist a health snapshot for one asset. | Confirm asset identity, recent alert count, work-order context, source freshness, and engine mode. |
GET /api/v1/dcops/assets/{assetId}/health/trend | Read health-score trend for a selected time window. | Check time range, missing history, and risk-level changes. |
GET /api/v1/dcops/health/summary | Review aggregate health distribution across equipment. | Confirm site scope and which assets have current snapshots. |
POST /api/v1/dcops/assets/{assetId}/predictions | Generate failure probability and remaining-life output. | Review model version, probability windows, remaining-life range, and source assumptions. |
GET /api/v1/dcops/assets/{assetId}/predictions/history | Read prediction history for one asset. | Compare recent predictions with work orders and field findings. |
GET /api/v1/dcops/predictions/high-risk | List equipment above the selected risk threshold. | Validate threshold, time window, and review owner before dispatch. |
Use Predictive Maintenance docs when the workflow requires richer model management, anomaly review, equipment templates, or advisory inbox behavior.
Diagnosis and closed-loop endpoints
Diagnosis endpoints help teams move from alert context to reviewed action:
| Endpoint | Purpose | Review checks |
|---|---|---|
POST /api/v1/dcops/diagnosis/from-alert/{alertId} | Create a diagnosis record for an alert. | Confirm the alert has linked equipment and source timestamps. |
GET /api/v1/dcops/alerts/{alertId}/diagnosis | Read diagnosis history for an alert. | Review diagnosis text, confidence, trace ID, created time, and source. |
GET /api/v1/dcops/alerts/{alertId}/closed-loop | Read alert, diagnosis, work-order, and feedback evidence together. | Confirm diagnosis, action, and feedback are all present before closing review. |
GET /api/v1/dcops/work-orders/{workOrderId}/closed-loop | Read closed-loop evidence for a work order. | Check diagnosis linkage and feedback state. |
POST /api/v1/dcops/work-orders/{workOrderId}/feedback | Record actual root cause, action taken, resolved state, and score. | Keep feedback tied to the responsible reviewer and work-order closeout. |
Diagnosis output should be treated as a reviewed operating record. The recommended action becomes operational only after the responsible owner approves it.
Planning and dispatch endpoints
Use planning and dispatch endpoints to convert reviewed risk into scheduled work:
| Endpoint | Purpose | Review checks |
|---|---|---|
GET /api/v1/dcops/planning/recommendations | Read maintenance candidates for a selected window. | Confirm risk score, estimated duration, priority, and asset scope. |
POST /api/v1/dcops/planning/generate | Generate a draft plan. | Review generated items and conflict count before assignment. |
GET /api/v1/dcops/planning/{planId}/conflicts | Inspect plan conflicts. | Check resource or time-window conflicts with shift owners. |
POST /api/v1/dcops/planning/{planId}/resolve | Resolve planning conflicts. | Record strategy and remaining conflicts. |
GET /api/v1/dcops/dispatch/pending | List open alerts with no open work order. | Confirm diagnosis state and action owner. |
POST /api/v1/dcops/dispatch/batch-approve | Approve selected dispatch candidates. | Use after selected alerts and diagnosis evidence have been reviewed. |
Operations analytics
Operations analytics endpoints support shift review and handover:
| Endpoint | Purpose |
|---|---|
/dashboard/operations | Combined operational queue and throughput dashboard data. |
/dashboard/operations/kpi-delta | Recent KPI movement versus the previous period. |
/dashboard/operations/queue-aging | Open queue aging buckets. |
/dashboard/operations/predictive-queue | Predictive risk buckets for 7, 30, and 90 day windows. |
/dashboard/operations/sla-rates | Response and completion SLA rate metrics. |
/dashboard/operations/sla-breaches | Open breached work orders sorted for action review. |
/dashboard/operations/diagnosis-reuse | Diagnosis reuse rate for dispatches. |
/dashboard/operations/dispatch-funnel | Conversion funnel from alert to closed-loop outcome. |
/dashboard/operations/snapshot | Exportable operations snapshot for dashboard and handover. |
/dashboard/operations/snapshot.csv | CSV export for spreadsheet review. |
/dashboard/operations/events | Server-sent event stream for alerts, work orders, and risk snapshot changes. |
Use snapshot exports for operating meetings, shift handover, and post-incident review. Keep the export with the review notes that explain scope and assumptions.
BMS mapping and model operations
| Endpoint | Purpose | Review checks |
|---|---|---|
GET /api/v1/dcops/integrations/bms/mappings | Read latest published or draft BMS mapping metadata. | Check source, version, status, and updated time. |
POST /api/v1/dcops/integrations/bms/mappings/validate | Validate mapping rule shape before publish. | Check source point, target field, coverage, errors, and warnings. |
POST /api/v1/dcops/integrations/bms/mappings/publish | Publish a mapping version and create audit evidence. | Publish after source owner approval. |
GET /api/v1/dcops/model-ops/status | Read active engine mode and status metadata. | Record engine mode, degraded state, latency, and update time. |
POST /api/v1/dcops/model-ops/engine-mode | Switch standard or NVIDIA mode when authorized. | Use project-approved mode, audit the change, and confirm fallback behavior. |
Model-ops status is an operational control surface. Treat mode changes as governed configuration changes.
Suggested Agent answer structure
When an AI assistant summarizes DCOps risk, use a stable format:
| Section | Content |
|---|---|
| Scope | Tenant, site, data center, data hall, time window, and selected assets. |
| Current state | Dashboard KPIs, open alerts, queue aging, SLA risk, health distribution, and predictive queue. |
| Evidence | Source records, health snapshots, prediction history, diagnosis records, BMS mapping version, work orders, and feedback. |
| Recommended review | Ranked actions for the responsible owner, with evidence links and missing data notes. |
| Handoff | Work-order draft, escalation note, planning draft, or request for field verification. |
Validation checklist
- The workflow runs under the correct tenant and DCOps module scope.
- The caller has the required
dcops.*permission for the read, diagnosis, work-order, feedback, or configuration action. - Asset identity, BMS points, alerts, work orders, and meter readings resolve to the same site context.
- AI-assisted output includes source, confidence, trace ID, model or engine mode when available, and review owner.
- Work-order actions remain tied to approved dispatch or planning evidence.
- Feedback is recorded after field execution so future diagnosis and planning can learn from the outcome.