A Reference Architecture for RAG-Based Digital Grid Operational Decision Support: Integrating Contextual Grid Data and Engineering Evidence

Abstract

Digital Grid operational decision support requires the integration of validated operational observations and analytical results, structured contextual grid data, and engineering knowledge distributed across heterogeneous systems. Conventional document-centric retrieval-augmented generation (RAG) does not inherently provide the operational grounding, relationship-aware retrieval, governance validation, traceability, and human oversight required in mission-critical grid environments. This article presents a conceptual reference architecture for RAG-based Digital Grid operational decision support. The architecture integrates nine functional capabilities spanning governed operational data publication, asset contextualization, query construction, hybrid information retrieval, context fusion, large language model (LLM)-based evidence synthesis and insight generation, governance validation, operator interaction, and human decision oversight. A three-tier context data model organizes operational telemetry context, asset and event context, and grid and external context, while a complementary asset and topology graph represents relevant relationships. Context fusion combines operational observations, validated analytical results, structured contextual records, and structured retrieval results containing retrieved engineering evidence and relevant graph-derived context into a constrained and traceable LLM-ready request package. Generated interpretations and candidate recommendations undergo governance validation before presentation to authorized decision makers for evaluation. The architecture preserves specialist analytical authority and human operational authority while supporting evidence grounding, uncertainty reporting, provenance, and end-to-end traceability.

Index Terms: Digital Grid; retrieval-augmented generation; operational decision support; contextual grid data; hybrid information retrieval; AI governance; human-in-the-loop.

I. Introduction

The transformation toward the Digital Grid is reshaping traditional power systems into complex cyber-physical systems of systems in which sensing, computation, communications, control, and analytics support grid operation under dynamic conditions. Digital Grid environments increasingly comprise operational technology systems, grid-edge devices and distributed energy resources, enterprise asset and maintenance systems, engineering knowledge repositories, communications infrastructure, and data, analytics, and artificial intelligence platforms.

These environments generate operational observations, analytical outputs, asset and maintenance records, contextual grid data, and engineering knowledge across heterogeneous systems. Operational technology systems provide measurements, alarms, events, and equipment states, while specialist grid and asset applications produce validated analytical results. Enterprise systems contain equipment characteristics, condition records, work orders, and maintenance histories, whereas engineering knowledge is captured in manuals, standards, procedures, incident reports, and expert-derived practices. These sources are not always connected within operational decision-support workflows. Effective decision support therefore requires operational observations and validated analytical results to be associated with the relevant asset, event, grid, and external context, related to appropriate engineering evidence, and translated into traceable and operationally relevant decision-support information.

Large language models (LLMs) provide capabilities for evidence synthesis, explanation, candidate-recommendation generation, and natural-language interaction. However, general-purpose LLMs are not inherently grounded in utility-specific asset models, current operational states, protection principles, or operational and engineering constraints. Their probabilistic generation process may produce plausible but unsupported conclusions. Evidence grounding, uncertainty reporting, governance validation, traceability, and human oversight are therefore important architectural requirements for their use in mission-critical Digital Grid environments.

Retrieval-Augmented Generation (RAG) can mitigate some of these limitations by grounding LLM outputs in retrieved external information [1]. Conventional document-centric RAG, however, does not inherently integrate real-time and historical operational information, structured contextual records, graph-derived relationships, specialist analytical results, governance controls, and accountable human decision-making. The proposed architecture addresses this gap through hybrid information retrieval and context fusion. Relevant operational information, validated analytical results, structured contextual records, graph-derived context, and retrieved engineering evidence are assembled into a constrained and traceable LLM-ready request package for evidence synthesis and insight generation.

This article presents a conceptual reference architecture for RAG-based Digital Grid operational decision support. Its main contributions are as follows:

Reference architecture: Nine functional capabilities that transform operational observations, validated analytical results, and contextual grid data into governed decision-support information.
Three-tier context data model: A structured representation comprising Operational Telemetry Context, Asset and Event Context, and Grid and External Context.
Hybrid information retrieval and context fusion: Retrieval and fusion of operational information, structured contextual records, graph-derived relationships, validated analytical results, and engineering evidence for LLM-based evidence synthesis and insight generation.
Governance-oriented AI decision framework: Validation of generated claims and candidate recommendations against supporting evidence, traceability requirements, operational policies, safety constraints, and risk criteria.
Human-in-the-loop decision oversight: Preservation of human authority and accountability, with controlled feedback informing governed improvement activities.

The remainder of this article is organized as follows. Section II reviews related work and identifies the architectural gap addressed by this study. Section III presents the proposed reference architecture and its nine functional capabilities. Section IV introduces the Three-Tier Context Data Model. Section V describes the end-to-end decision-support workflow. Section VI presents an illustrative transformer cooling-system degradation use case. Section VII discusses the architectural design rationale and implications. Section VIII outlines limitations and future research directions. Section IX concludes the article.

II. Related Work and Architectural Gap

Retrieval-Augmented Generation (RAG) has emerged as an important approach for grounding LLM-based applications in retrieved external information [1]. LLMs draw on knowledge encoded in their model parameters during training but may generate responses that are inaccurate, outdated, or unsupported by verifiable external evidence. RAG can mitigate these limitations by retrieving relevant information and incorporating it into the generation process.

Conventional document-centric RAG implementations primarily focus on document ingestion, information retrieval, and text generation for knowledge-search and question-answering applications. Such implementations do not inherently provide the operational grounding, structured contextual data, relationship-aware retrieval, governance validation, and human oversight relevant to mission-critical Digital Grid operational decision support. Hybrid RAG approaches combine vector-based and knowledge-graph-based retrieval to provide complementary textual and relationship-oriented context for answer generation [4]. However, additional architectural capabilities are required to integrate these retrieval mechanisms with operational data, context fusion, governance validation, and human oversight.

Digital Twin technologies have received significant attention in industrial and power-system domains by providing digital representations of physical assets, network infrastructure, and operational conditions [7]. In power systems, Digital Twins can support asset monitoring, network modeling, simulation, predictive maintenance, planning, and operational analysis. Conventional Digital Twin implementations primarily emphasize synchronized system representation, simulation, and analytical modeling. However, their integration into an end-to-end, evidence-governed decision-support workflow that combines operational context, retrieved engineering knowledge, LLM-based evidence synthesis and insight generation, governance validation, and human oversight remains comparatively underexplored in the reviewed Digital Twin literature.

Digital Twins are therefore complementary to the proposed architecture: they can provide structured representations of the physical grid and its operational state, while the proposed architecture integrates retrieval, context fusion, governance validation, and human oversight within an evidence-grounded decision-support workflow. Where Digital Twin implementations expose structured asset, connectivity, and topology information through supported interfaces, APIs, or standards-based exchanges, such information may contribute to the construction, enrichment, or synchronization of the Asset & Topology Graph, subject to the established data-authority and governance rules.

Asset management, condition assessment, and diagnostic approaches combine operational measurements, historical records, maintenance information, and specialized analytical methods. Power transformer applications provide a representative example [8]. These capabilities provide relevant asset-level observations and validated analytical results to support operational decision-making. However, integrating these outputs with retrieved engineering knowledge, explicit context fusion, graph-derived relationships, LLM-based evidence synthesis, governance validation, and human oversight requires additional architectural mechanisms.

Although AI-governance frameworks define relevant risk-management principles [9], their integration with operational grounding, contextualization, heterogeneous retrieval, LLM-based evidence synthesis, and human oversight must be explicitly addressed when designing an end-to-end Digital Grid decision-support architecture. The proposed architecture addresses this integration requirement through a dedicated AI governance and decision-validation capability.

Collectively, the reviewed bodies of work suggest an architectural integration gap in connecting validated operational observations and analytical results; structured contextual data; graph-derived relationship context; retrieved engineering evidence; LLM-based evidence synthesis and insight generation; governance validation; and human oversight for Digital Grid operational decision support.

III. Proposed Reference Architecture for RAG-Based Digital Grid Decision Support

The proposed reference architecture extends document-centric RAG to support operationally grounded and governed Digital Grid decision support. It integrates validated operational observations and analytical results, structured contextual data, graph-derived relationships, and retrieved engineering evidence into a constrained and traceable LLM-ready request package. The LLM-Based Evidence Synthesis and Insight Generation capability processes this package and returns a structured insight package, which subsequently undergoes governance validation before operator presentation.

The architecture maintains a clear boundary between specialist engineering analysis and LLM-based synthesis. Validated analytical results remain authoritative, while LLM-based synthesis interprets and explains the supplied information without reproducing or overriding the underlying calculations.

Validated outputs from applications such as state estimation, forecasting, contingency analysis, optimization, and asset analytics enter through the operational data-acquisition and contextualization capabilities. Graph-based representations provide explicit asset, topology, event, and maintenance relationships that support asset contextualization, query construction, graph-based retrieval, context fusion, and traceability.

The architecture comprises nine functional capabilities, denoted P1–P9: P1 Industrial Data Ingestion and Unified Namespace Publication, P2 Asset Contextualization, P3 Query Construction, P4 Hybrid Information Retrieval, P5 Context Fusion and Prompt Assembly, P6 LLM-Based Evidence Synthesis and Insight Generation, P7 AI Governance and Decision Validation, P8 Decision Support Operator Interface, and P9 Human-in-the-Loop Decision Oversight.

Fig. 1 organizes the nine capabilities across data acquisition and contextualization, unified context and knowledge access, query construction and hybrid information retrieval, context fusion and prompt assembly, LLM-based evidence synthesis and insight generation, governance validation, operator interaction, and human oversight. The unified access layer supports integrated, virtualized, or hybrid access to the Three-Tier Context Data Model, the Asset & Topology Graph, and engineering knowledge sources. P3 constructs structured retrieval specifications, and P4 executes the operational, relational, time-series, graph-based, sparse, dense/vector, or combined retrieval operations required by each specification before transferring the structured and traceable retrieval results package to P5.

Fig. 1. Proposed reference architecture for RAG-based Digital Grid operational decision support.

A. P1: Industrial Data Ingestion and Unified Namespace Publication

P1 represents the entry point for operational observations and validated analytical results within the reference architecture. It acquires real-time and historical telemetry, alarms, events, and other operational observations from grid assets, operational technology systems, operational applications, and relevant external information sources; validates and normalizes the resulting data streams; and makes them available through a governed Unified Namespace. To support interoperability across heterogeneous Digital Grid environments, P1 provides connectivity adapters for industrial and utility communication protocols and information models, such as IEC 61850 [5], OPC UA, MQTT, DNP3, IEC 60870-5-104, and Modbus.

P1 performs protocol connectivity, buffering, timestamp validation and alignment, data validation and normalization, data-quality assessment, and source-identifier handling before publishing operational observations and validated analytical results through a governed, asset-oriented Unified Namespace. Data may enter P1 as native source tags or through publishers already conforming to the namespace structure. Where authoritative enterprise or Common Information Model (CIM)-aligned asset identifiers [6] are available, P1 may include them in the Unified Namespace. When incoming observations or analytical results lack authoritative asset associations, P1 preserves their source identifiers for subsequent asset resolution by P2. P1 also preserves the distinct identities of sensors, devices, and source observations, together with their timestamps, quality indicators, and source provenance.

P1 may additionally ingest validated outputs from operational and analytical applications, including state estimation, forecasting, contingency analysis, condition monitoring, predictive maintenance, and asset analytics.

P1 outputs may be incorporated into the decision-support workflow through streaming, integrated, virtualized, or hybrid integration patterns without requiring replication into a single repository. Operational and historical data may remain within authoritative source systems or designated repositories according to governance and retention requirements.

The outputs of P1 primarily form the Operational Telemetry Context tier of the Three-Tier Context Data Model described in Section IV. Depending on their operational scope and meaning, P1 outputs may also contribute to the Asset and Event Context and Grid and External Context tiers. P1 standardizes and publishes operational observations and validated analytical results, whereas P2 resolves cross-system asset identities where required and performs contextual enrichment.

B. P2: Asset Contextualization

P2 transforms operational observations and validated analytical results into asset-aware context. It uses governed asset associations available through the Unified Namespace. When these associations are missing, ambiguous, or inconsistent across systems, P2 resolves the preserved source identifiers to authoritative enterprise or CIM-aligned asset identities. P2 enriches the observations and analytical results by linking the identified assets to relevant records from maintenance systems, geographic information systems, Asset Performance Management platforms, asset registries, and other structured asset-information sources.

A telemetry-to-asset mapping registry preserves the associations among source tags, CIM and enterprise asset identifiers, measurements, events, work orders, condition records, and analytical results. P2 also retains relevant timestamps, quality and uncertainty information, and source provenance.

The resulting asset-aware information contributes primarily to the Asset and Event Context tier of the Three-Tier Context Data Model described in Section IV and establishes the relationships required to associate Operational Telemetry Context with relevant Grid and External Context.

P2 populates and maintains relationships among assets, topology elements, locations, operational events, maintenance records, and other contextual entities within the Asset & Topology Graph. These relationships support subsequent query construction, graph-based retrieval, context fusion, and traceability across the decision-support workflow.

Accordingly, P2 resolves or verifies authoritative asset identities and constructs the structured contextual representation required for downstream processing.

C. P3: Query Construction

P3 defines structured retrieval specifications that determine the scope, targets, and constraints of downstream retrieval operations. It supports three primary scenarios: event-driven retrieval triggered by observed operational conditions, operator-initiated requests, and operator follow-up queries, which request clarification, additional evidence, or further assessment of a preceding governed output arising from either scenario. In all scenarios, P3 uses the contextual representation maintained by P2 to determine the information required for subsequent decision-support activities.

Across these scenarios, P3 selects the relevant information sources and retrieval mechanisms, identifies the assets, contextual records, graph relationships, and knowledge domains relevant to the request or observed condition, and generates the necessary metadata constraints (e.g., asset type, voltage level, manufacturer, equipment family, candidate failure mode, and document type) and temporal constraints, including applicable analysis windows. Depending on the information required, P3 may formulate structured database queries, historian queries, graph-traversal queries, engineering-knowledge retrieval specifications, or combinations thereof. The resulting source selections, retrieval-method choices, query scopes, metadata constraints, and temporal constraints are intended to limit retrieval to information relevant to the observed condition or operator request.

For event-driven scenarios, P3 interprets observed operational conditions and associated analytical results using deterministic engineering rules. It may identify candidate failure modes, determine severity classifications, and establish the contextual scope of the retrieval task. The resulting specification is configured for the relevant asset, operational event, operating condition, and graph relationships. P3 may apply predefined deterministic engineering-rule templates to identify candidate failure modes and severity classifications. It then uses these outputs, together with failure-mode mappings, asset metadata, validated model outputs, and contextual parameters, to construct the retrieval specification. P3 treats upstream analytical results as validated inputs and does not reproduce or override their underlying calculations.

For operator-initiated and follow-up requests, P3 interprets the request in conjunction with the contextual representation maintained by P2. It determines the information required to address the request and formulates the corresponding query or combination of queries. Interactive requests may therefore span operational data sources, contextual data repositories, graph representations, and engineering knowledge sources.

The output of P3 is a structured retrieval specification that defines the retrieval scope, requirements, metadata constraints, source-selection requirements, and queries. Graph queries may identify electrically connected assets, including upstream and downstream equipment connected to the affected asset, related switching states, associated work orders, related alarms, and topology-dependent constraints. P4 executes the specification, while P5 subsequently assembles the LLM-ready request package.

D. P4: Hybrid Information Retrieval

P4 executes the structured retrieval specifications produced by P3 across event-driven, operator-initiated, and operator follow-up scenarios. Depending on the specification, P4 retrieves information through integrated, virtualized, or hybrid access patterns spanning the governed UNS and associated operational data services, relational databases, historians and time-series stores, the asset & topology graph, engineering knowledge sources, or combinations thereof. P4 applies the specified queries, source selections, metadata constraints, time windows, and graph-traversal requirements without reinterpreting the underlying operational condition or reproducing upstream analytical calculations.

Real-time operational retrieval obtains current measurements, alarms, equipment states, and other operational observations through the governed UNS and associated operational data services. Relational and structured-data retrieval obtains asset, event, maintenance, condition, location, and other contextual records. Historian and time-series retrieval obtains historical measurements, alarms, states, and trends over the time windows defined by P3. The retrieved results retain relevant timestamps, identifiers, quality indicators, uncertainty information, and source provenance.

Graph-based retrieval obtains relationship-oriented context from the Asset & Topology Graph, including asset connectivity, topology, location, operational-event, maintenance, and CIM-aligned asset relationships (e.g., equipment containment within substations, voltage levels, bays, lines, or feeders). Graph traversals may identify electrically connected assets, upstream and downstream equipment connected to the affected asset, related switching states, associated work orders, related alarms, and topology-dependent constraints.

Engineering-knowledge retrieval applies sparse and dense/vector methods to relevant technical sources. Sparse retrieval techniques such as BM25 support term-sensitive retrieval of technical terminology, identifiers, equipment codes, and procedure names [2]. Dense retrieval uses embeddings and vector representations to identify semantically related engineering knowledge [3]. Metadata constraints may limit candidate evidence according to asset type, voltage level, manufacturer, equipment family, failure category, document type, and graph-derived contextual constraints specified by P3. Approaches combining knowledge-graph-based and vector retrieval can improve contextual relevance in complex information environments [4].

When specified by P3, P4 performs combined multi-source retrieval across real-time operational, relational, time-series, graph-based, and engineering-knowledge sources. P4 coordinates the required retrieval operations and associates their results using shared asset identifiers, timestamps, operational events, analysis windows, and contextual relationships. Filtering, ranking, and reranking are applied according to the characteristics of each retrieval method. Candidate engineering evidence may be reranked against the retrieval specification (e.g., prioritizing an applicable OEM procedure for the affected transformer model and candidate failure mode over a generally similar document), whereas structured, time-series, and graph results are selected and ordered according to their query constraints and contextual relevance. Cross-source association and temporal alignment preserve the relationships among retrieved operational data, contextual records, graph-derived context, and engineering evidence.

P4 produces a structured and traceable retrieval-results package containing retrieved records, time-series results, graph-derived relational context, engineering evidence, applicable relevance information, and source provenance. The retrieval-results package is transferred to P5, which performs context fusion and assembles the LLM-ready request package.

E. P5: Context Fusion and Prompt Assembly

P5 performs context fusion and assembles the LLM-ready request package transferred to P6. Its inputs comprise the relevant operational observations and validated analytical results available through the maintained information environment, the contextual representation maintained by P2, the structured retrieval specification defined by P3, and the structured and traceable retrieval-results package produced by P4. The P4 package may contain query-selected real-time operational data, structured records, historian and time-series results, graph-derived relational context, engineering evidence, relevance information, and source provenance. P5 uses the P3 specification to preserve the scope and intent of the retrieval task; it neither formulates queries nor executes retrieval operations.

P5 performs final temporal, identifier, and entity alignment across the complete set of inputs used for context fusion (e.g., verifying that an operational event, its analytical results, and the P4 retrieval-results package correspond to the same asset and analysis window). It associates information from different sources using asset identities, operational events, analysis windows, and contextual relationships; removes duplicate information; checks cross-source consistency; normalizes representations; associates retrieved evidence with the corresponding operational and contextual information; and selects the content relevant to the request. Throughout these operations, P5 preserves timestamps, quality and uncertainty information, lineage, provenance, and traceability. Validated analytical results, including classifications, forecasts, calculated values, detected violations, risk scores, model versions, and uncertainty measures, are retained as authoritative analytical evidence. P5 does not modify, override, or recompute validated analytical results.

For event-driven scenarios, P5 fuses the observed operational condition, validated analytical results, relevant contextual representation, retrieval specification, and corresponding retrieval results. For operator-initiated requests, P5 incorporates the operator request received through P8 only after P3 has performed context-aware query construction and P4 has executed the required retrieval operations. For follow-up requests, P5 retains the relevant prior interaction and decision-support context from the preceding interaction and combines it with the updated retrieval specification and retrieval results produced by P3 and P4. Operator requests are therefore not submitted to P6 as unconstrained standalone prompts.

P5 constructs the task instruction by selecting, configuring, and combining governed task-instruction modules according to the scenario, operational condition or operator request, asset and event context, candidate failure mode, validated analytical results, retrieval specification, retrieved information, applicable constraints, and required output schema. The assembled instruction specifies the task, reasoning and evidence-use constraints, uncertainty-reporting requirements, output structure, and traceability requirements, thereby constraining P6 to base its synthesis, explanations, and candidate recommendations on the supplied information.

The resulting LLM-ready request package contains the assembled task instruction, relevant operational condition or operator request, validated analytical results, structured context, retrieved operational and historical information, graph-derived relational context, engineering evidence, and traceability metadata. P5 transfers the package to P6 for evidence synthesis and insight generation. After receiving the structured insight package from P6, P5 associates it with the retained provenance and trace information and forwards the resulting package to P7 for governance validation and auditability.

F. P6: LLM-Based Evidence Synthesis and Insight Generation

P6 performs LLM-based evidence synthesis and insight generation, including explanation generation, using the LLM-ready request package assembled by P5 as its sole governed input. Its processing is governed by the task instruction, supplied context, validated analytical results, retrieved information, reasoning constraints, evidence-use restrictions, uncertainty-reporting requirements, output schema, and traceability requirements contained in the package.

P6 synthesizes the supplied operational, contextual, analytical, and retrieved information to generate context-aware interpretations and explanations. It associates supporting evidence with the relevant operational conditions and analytical findings, identifies evidence-supported relationships and possible causes, and formulates candidate recommendations when required by the task instruction. P6 also identifies relevant uncertainty, conflicting or missing information, evidence limitations, and cases in which the supplied information is insufficient to support a conclusion or recommendation.

For event-driven scenarios, P6 explains the observed condition and validated analytical findings and may generate evidence-supported interpretations and candidate recommendations. For operator-initiated requests, P6 responds to the operator’s question using the contextualized and retrieved information supplied by P5. For follow-up requests, P6 uses the relevant prior interaction and updated decision-support context included in the new LLM-ready request package. In all scenarios, P6 operates only on the LLM-ready request package provided by P5 and does not perform query construction, information retrieval, or independent contextualization.

P6 treats validated analytical results as authoritative inputs. It does not independently calculate, reproduce, modify, override, or validate numerical, statistical, physics-based, optimization, graph-analytic, or specialized machine-learning results produced by upstream applications. P6 may synthesize and explain graph-derived context but does not independently execute graph computations or infer relationships unsupported by the supplied graph results. P6 must conform to the constraints and output schema specified in the LLM-ready request package.

P6 produces a structured insight package that may include interpretations, explanations, supporting evidence references, candidate recommendations, uncertainty and limitation statements, and other schema-required fields. Natural-language explanations may accompany the structured content where required by the task instruction. P6 returns the structured insight package to P5 for association with the retained provenance and trace information and subsequent transfer to P7.

G. P7: AI Governance and Decision Validation

P7 performs governance and decision validation on the package forwarded by P5, comprising the structured insight package produced by P6 and its associated provenance and trace information. The assessment covers candidate recommendations, interpretations, explanations, evidence references, uncertainty statements, and limitations.

Risks addressed across the upstream decision-support workflow include incomplete or inconsistent context, incorrect asset associations, deficient retrieval results, unsupported LLM-generated content, inadequate uncertainty reporting, traceability deficiencies, and noncompliance with applicable operational policies, safety constraints, and established risk evaluation criteria. The structured insight package is evaluated for manifestations of these risks without repeating upstream acquisition, contextualization, retrieval, or analytical processes.

The validation process assesses structural completeness, claim-to-evidence consistency, uncertainty reporting, traceability, and compliance with applicable operational policies, safety constraints, and risk criteria. Claims and candidate recommendations are checked against the referenced operational information, contextual records, graph-derived relationships, validated analytical results, and engineering evidence. The process identifies unsupported claims, missing or conflicting evidence, traceability gaps, policy violations, and recommendations outside the scope permitted by applicable operational policies, procedures, safety constraints, and authorization rules. Reported uncertainty is assessed against applicable acceptance thresholds and risk criteria. P7 does not recalculate, modify, override, or independently validate specialist analytical results. It verifies their declared provenance and quality and assesses whether they are used consistently and appropriately within the structured insight package.

The same governance framework applies to event-driven, operator-initiated, and operator follow-up scenarios. Validation criteria may be adapted to the task, operational context, applicable policies, risk level, and intended form of presentation.

Possible validation outcomes are approved, approved with conditions, escalated, or rejected. An approved outcome indicates that the package satisfies the applicable validation criteria for operator presentation. An approved-with-conditions outcome permits presentation through P8, provided that the specified qualifications, restrictions, and required actions are displayed with the governed recommendation. Escalation indicates that additional evidence, specialist review, or higher-level assessment is required. Rejection indicates that the package does not satisfy the applicable validation criteria.

Approved and approved-with-conditions outcomes authorize presentation through P8 for human evaluation but do not constitute operational authorization. Final operational authority remains with the authorized decision-maker represented through P9.

P7 produces a governed decision-support package containing the governance outcome, recorded rationale, uncertainty and limitation statements, supporting evidence references, and traceability information. Approved packages include the validated response or governed recommendation. Approved-with-conditions packages additionally include the applicable qualifications, restrictions, or required actions. Escalated packages specify unresolved deficiencies and requirements for further evidence or assessment, whereas rejected packages exclude the candidate recommendation from actionable presentation but communicate the rejection outcome, rationale, identified deficiencies, and any requirements for additional evidence or further assessment. P7 transfers the package to P8 for presentation, notification, or interaction according to the governance outcome.

H. P8: Decision Support Operator Interface

P8 presents the governed decision-support package through concise natural-language explanations and visualizations that support operational judgment, evidence inspection, traceability, and operator interaction.

P8 presents the information needed to understand and evaluate the governed outcome, reflecting the task, operational context, initiating scenario, and governance status. Depending on that outcome, the presentation may include the asset condition, relevant telemetry trends and validated analytical results, supporting contextual and engineering evidence, uncertainty and limitations, traceability information, and either a governed recommendation, applicable conditions, escalation requirements, or rejection rationale.

P8 adapts the presentation to the P7 governance outcome: approved responses or governed recommendations are displayed with their supporting information; applicable conditions accompany approved-with-conditions outcomes; and escalated or rejected outcomes communicate the relevant rationale, deficiencies, and requirements for further evidence or assessment without presenting an unapproved candidate recommendation as actionable guidance.

P8 captures operator-initiated natural-language requests and follow-up queries and routes them to P3 for context-aware query construction. Such requests proceed through retrieval by P4, context fusion and request-package assembly by P5, evidence synthesis by P6, and governance validation by P7 before a governed response is returned through P8. Operator requests therefore do not bypass the governed workflow or reach P6 as unconstrained standalone prompts.

P8 supports operator understanding, evaluation, and interaction but does not make or execute operational decisions. P9 represents the human-authority boundary and records the accountable decision, outcome, and associated feedback.

I. P9: Human-in-the-Loop Decision Oversight

P9 establishes the human-authority and accountability boundary of the reference architecture. Authorized decision-makers, such as operators, engineers, and supervisors, review the governed decision-support information presented through P8. and exercise accountable judgment according to applicable operating procedures [10]. P8 supports information presentation and interaction, whereas P9 captures the resulting human decision, rationale, outcome, and feedback.

Human decision handling depends on the governance outcome assigned by P7. Approved recommendations remain advisory until accepted, rejected, deferred, or escalated by an authorized decision-maker. Any modification is recorded and handled according to applicable operating and governance procedures. Recommendations approved with conditions are evaluated and acted upon subject to the specified qualifications, restrictions, and required actions. Escalated outcomes require the identified additional evidence, specialist review, or higher-level assessment. Rejected candidate recommendations cannot be accepted or executed as governed recommendations. P9 records the authorized human decision, while any resulting operational action is executed through established procedures and authorized control systems.

The decision record identifies the authorized human decision, its rationale, the accountable role, the decision timestamp, any applicable conditions, and any follow-up actions initiated through established procedures. The record may be supplemented with subsequent operational outcomes when available. It is linked to the corresponding governed recommendation, governance outcome, supporting evidence, operational context, and traceability information.

Reviewed human feedback and operational outcomes may support controlled improvements to knowledge sources, retrieval logic, telemetry-to-asset mappings, graph relationships, context-fusion processes, task-instruction modules, and governance rules and thresholds. Subject to a distinct governance and approval process, reviewed feedback and operational outcomes may also inform model evaluation, domain adaptation, or fine-tuning. Feedback does not automatically establish ground truth or modify production models, rules, graph relationships, task-instruction modules, or knowledge sources. Any resulting change is evaluated and implemented through separate governed processes that preserve provenance, traceability, and accountability.

P9 closes the decision-support workflow by linking governed system outputs to accountable human judgment, recorded decisions, operational outcomes, and controlled feedback.

IV. Three-Tier Context Data Model

The reference architecture includes a Three-Tier Context Data Model comprising Operational Telemetry Context, Asset and Event Context, and Grid and External Context. The model provides a logical organization for structured Digital Grid information and supports event-driven, operator-initiated, and follow-up decision-support scenarios through context-aware query construction, hybrid information retrieval, context fusion, evidence synthesis and insight generation, governance validation, and operator interaction. Figure 2 presents an illustrative conceptual entity-relationship representation of the model. The specific entities, attributes, relationships, and cardinalities may vary according to utility-specific use cases, information requirements, domain semantics, and governance policies.

Fig. 2. Illustrative conceptual entity-relationship representation of the Three-Tier Context Data Model. Dashed boundaries distinguish the Operational Telemetry Context, Asset and Event Context, and Grid and External Context tiers. The representation associates operational telemetry and validated analytical results with relevant physical assets and relates those assets to event, maintenance, condition, location, topology, system, market and dispatch, and weather and ambient context. The specific entities, attributes, relationships, and cardinalities may vary according to utility-specific use cases, information requirements, domain semantics, and governance policies.

Operational Telemetry Context represents current and historical operational observations associated with grid assets and systems. It includes telemetry tags and streams, archived measurements, alarms, operational events, equipment states, timestamps, quality indicators, uncertainty information, and relevant validated analytical results. P1 provides the principal acquisition, validation, normalization, and publication path for this information. Within this tier, alarms and event signals represent operational observations received from SCADA or other operational systems. Their asset associations and broader event context are represented in Asset and Event Context.

Asset and Event Context provides the asset-centered information required to interpret operational observations. It includes authoritative asset identities, equipment classes, stations and locations, operational-event associations, work orders, maintenance records, condition records, and other structured asset information. P2 uses governed asset associations available through the UNS and resolves source identifiers when those associations are missing, ambiguous, or inconsistent. It then relates operational observations and analytical results to the corresponding assets and contextual records. Operational-event observations from Operational Telemetry Context thereby become associated with the assets, event records, maintenance activities, and condition information required for interpretation.

Asset and Event Context serves as the principal contextual anchor between the other two tiers. Operational telemetry and validated analytical results are linked to relevant assets, while alarm or status signals are associated with asset event context. Broader grid and external information is related through asset, location, topology, and system context, including market and dispatch and weather and ambient information. This organization enables information from different sources to be interpreted within a common asset-centered operational context.

Grid and External Context represents system-level, environmental, dispatch, and market information that may influence the interpretation of asset and operational conditions. It includes grid topology, switching configurations, loading conditions, system states, weather and ambient conditions, dispatch information, market signals, and other relevant external factors. P1 may acquire and publish information that contributes to this tier, while P2 establishes the contextual relationships that associate it with the applicable entities in Asset and Event Context. Dynamic grid and external data become usable context after their asset, location, event, system-scope, and analysis-window relevance has been established.

The telemetry-to-asset mapping registry supports cross-tier association by maintaining relationships among source tags, enterprise and CIM asset identifiers, measurements, operational events, analytical results, work orders, and condition records. These associations preserve the identifiers, timestamps, event and analysis windows, quality and uncertainty information, lineage, and provenance required for downstream retrieval and traceability.

The three-tier logical model does not require contextual information to be consolidated into a single repository. Structured and time-series records may remain distributed across their source systems and be accessed through integrated, virtualized, or hybrid patterns while preserving consistent associations among entities across the three tiers, together with their provenance and traceability.

The Asset & Topology Graph provides a complementary relationship-oriented representation derived from or synchronized with relevant entities and associations in the three-tier context data model. It maintains asset, topology, location, operational-event, maintenance, and CIM-aligned relationships. These relationships support context-aware query construction by P3, graph-based retrieval by P4, and cross-source association and context fusion by P5.

Engineering knowledge lies outside the three-tier context data model. OEM manuals, standards, procedures, troubleshooting guides, engineering reports, and historical case studies are retrieved separately by P4. P5 fuses the relevant engineering evidence with structured contextual records, graph-derived context, operational observations, and validated analytical results to assemble the LLM-ready request package.

V. End-to-End Decision-Support Workflow

The end-to-end workflow is illustrated in Fig. 3. All initiation scenarios use the operational and contextual information continuously maintained through P1 and P2; therefore, the workflow does not necessarily begin with the arrival of new telemetry. The workflow supports three initiation scenarios: an event-driven workflow initiated by an observed operational condition, an operator-initiated workflow requested through P8, and a follow-up workflow arising from an ongoing operator interaction. In each scenario, the contextual representation maintained by P2 provides the structured operational, asset, event, grid, and external context required by downstream functions.

Fig. 3. Illustrative end-to-end RAG-based Digital Grid decision-support workflow. The figure shows the principal process and information flows for event-driven and operator-initiated scenarios, including the operator-request or follow-up-query return path, governed decision-support presentation, human-in-the-loop decision oversight, and reviewed feedback for separately governed improvement activities.

In an event-driven scenario, relevant operational observations or validated analytical results indicate an operational condition that initiates the workflow. Structured contextual information is then associated with the triggering condition to support downstream processing. In an operator-initiated scenario, P8 routes the operator request to P3. A follow-up request follows the same entry path but may also draw upon the relevant prior interaction and updated operational and contextual information. These initiation paths differ in their triggers and initial information needs but converge on the same governed downstream workflow.

P3 defines a structured retrieval specification appropriate to the initiating condition or request. P4 executes that specification and returns a structured and traceable retrieval-results package. P5 fuses the structured retrieval specification and retrieval-results package with the applicable operational observations, validated analytical results, and contextual representation. P5 then configures governed task-instruction modules and assembles the constrained and traceable LLM-ready request package.

P5 submits the LLM-ready request package to P6. P6 performs evidence synthesis, interpretation, explanation, and candidate-recommendation generation and returns a structured insight package to P5. P5 associates the returned package with the retained provenance and trace information and forwards the combined package to P7 for governance and decision validation.

P7 assigns one of four governance outcomes: approved, approved with conditions, escalated, or rejected. An approved or approved-with-conditions outcome may include a governed recommendation for presentation through P8. An escalated outcome identifies unresolved deficiencies and the additional assessment required, while a rejected outcome excludes the candidate recommendation from actionable presentation. P8 presents, notifies, or supports further interaction according to the governance outcome. Any operator follow-up request is routed from P8 to P3 and proceeds through the same P3–P7 path before a governed response is presented.

P9 establishes the human-authority boundary for the workflow. Authorized decision-makers evaluate governed information and record the resulting decision, rationale, applicable conditions, actions initiated, and subsequent operational outcomes when available. Presentation through P8 does not constitute final operational authorization. Any resulting grid action is executed through established operational procedures and authorized control systems rather than directly through the decision-support workflow.

End-to-end traceability links governed outputs to the operational observations, validated analytical results, contextual associations, retrieval specifications, retrieved information and engineering evidence, generated insights, governance outcomes, and accountable human decisions that informed them. Provenance and trace information are preserved across process handovers. Reviewed feedback and recorded operational outcomes may support improvements through separate governed processes rather than automatically modifying production components.

VI. Illustrative Use Case: Transformer Cooling-System Degradation

This illustrative use case considers transformer TX-220-T1, a 220/132 kV transformer exhibiting a thermal condition potentially associated with cooling-system degradation. All measurements, analytical outputs, and records are synthetic and are used solely to demonstrate the application of the reference architecture.

The 24-hour observation window contains six representative observations selected from an assumed higher-frequency operational data stream. Loading increases from 88% to 104%, winding hotspot temperature rises from 78 °C to 100 °C, and top-oil temperature rises from 70 °C to 92 °C. During the latest observations, the cooling fans become unavailable while the cooling pump remains operational and the cooling alarm becomes active. The winding hotspot temperature increases from 97 °C to 100 °C during the final one-hour interval, corresponding to a recent rate of 3 °C/h rather than an average rate over the complete observation window.

Operational Telemetry Context contains the time-aligned loading, temperature, cooling-status, alarm, and ambient-condition observations, together with validated analytical outputs. Asset and Event Context identifies TX-220-T1 and relates these observations to its ratings, cooling arrangement, location, event associations, maintenance records, work orders, and condition records. Grid and External Context contributes relevant ambient, network-loading, switching, and system-state information.

Using the supplied operational observations, validated analytical outputs, and contextual representation, P3 applies deterministic engineering rule TR-THERM-001. For this illustrative condition, the rule assigns a critical severity classification and identifies cooling-system degradation as the candidate failure mode. This classification is specific to the supplied rule and context and does not establish universal critical thresholds for the individual measurements.

Using the operational and structured contextual information already maintained through P1 and P2, P3 defines an engineering-knowledge retrieval specification for the observed condition. P4 executes the specification and returns a structured and traceable retrieval-results package containing relevant OEM cooling documentation, thermal-behavior guidance, alarm-response procedures, provenance, and relevance information.

P5 fuses the operational observations, validated analytical outputs, contextual records, and retrieved engineering evidence. It applies the relevant task-instruction modules, constraints, output schema, and traceability requirements to assemble the LLM-ready request package. P6 returns a structured insight package containing an evidence-supported candidate interpretation, candidate mitigation actions, confidence assessment, evidence references, and identified limitations.

The available information supports cooling-system degradation as the leading candidate explanation. Supporting evidence includes cooling-fan unavailability, an active cooling alarm, increasing loading and temperatures, the deterministic rule output, and retrieved engineering guidance relating cooling availability to transformer thermal performance. The available evidence does not establish the underlying cause of fan unavailability.

Color-coded indicators are accompanied by textual labels so that their meaning does not depend on color alone. Figure 4 represents the workflow state after P6 has generated the structured insight package but before that package has undergone P7 governance validation. Accordingly, the displayed interpretations and mitigation actions remain candidates and do not constitute governed recommendations or operational authorization. Figure 4 presents these outputs in a compact dashboard format, including the representative observation window, current indicators, evidence-supported assessment, candidate mitigation actions, evidence trace, and confidence assessment.

Fig. 4. Illustrative rendering of the P6 structured insight package for transformer cooling-system degradation. The dashboard summarizes six representative synthetic observations, the rule-based severity classification, candidate failure mechanism and mitigation actions, supporting evidence, confidence, and limitations. The displayed content remains pending P7 governance validation.

After P6 returns the structured insight package illustrated in Fig. 4, P5 associates it with retained provenance and trace information before forwarding the resulting package to P7. Governance validation may approve the package, approve it with conditions, escalate it for additional evidence or specialist assessment, or reject it. Only approved or approved-with-conditions outcomes may produce a governed recommendation for presentation through P8.

Authorized personnel subsequently exercise accountable judgment through P9. Any inspection, load adjustment, escalation, or other operational action proceeds through established operating procedures and authorized control systems. The recorded decision and subsequent operational outcome remain traceable to the operational observations, validated analytical outputs, contextual records, retrieval specification, and engineering evidence supporting the assessment.

VII. Discussion

The proposed reference architecture extends document-centric RAG by integrating operational observations and validated analytical outputs with structured contextual grid information, graph-derived relationships, and retrieved engineering evidence. This integration addresses a central requirement of Digital Grid decision support: operational conditions must be interpreted in relation to the affected assets, associated events, system state, external conditions, and applicable engineering knowledge. Explicit governance, traceability, operator interaction, and human oversight further distinguish the architecture from conventional retrieval-and-generation pipelines.

Structured context is essential because natural-language requests and retrieved documents alone do not establish the current operational state, asset identity, temporal relevance, or system relationships needed for operational interpretation. The three-tier context model provides a consistent contextual foundation, while the telemetry-to-asset mapping registry preserves associations between operational observations and authoritative asset identities. Quality indicators, uncertainty information, analysis windows, lineage, and provenance enable downstream outputs to remain connected to the information on which they depend.

Hybrid Information Retrieval addresses the heterogeneous information requirements of Digital Grid decision support. Operational values and historical trends may be obtained through real-time and time-series retrieval, structured-data retrieval from relational data sources may provide relevant asset, maintenance, and condition records, and graph-based retrieval may expose topology and other relationship-oriented context. Engineering knowledge retrieval combines term-sensitive sparse methods with dense/vector methods to identify both lexically precise and semantically related evidence. The structured retrieval specification determines the appropriate combination of retrieval methods for each information need; consequently, individual scenarios do not necessarily invoke every method.

The Asset & Topology Graph complements relational and time-series representations by maintaining relationship-oriented context across assets, topology, locations, events, and maintenance information. This representation supports relationship traversal without replacing the structured records from which relevant entities and associations may be derived or synchronized. Engineering knowledge lies outside the three-tier context model and is distinct from the Asset & Topology Graph. P3 uses the structured contextual representation and relevant graph relationships to define the engineering-knowledge query, metadata constraints, graph-traversal requirements, and applicable retrieval methods. P4 executes these requirements using graph-based, sparse, dense/vector, or combined retrieval methods.

Retrieval-based grounding enables current operational information, contextual records, and updated engineering sources to be incorporated at inference time without requiring retraining of the LLM for each source update. This approach can reduce dependence on model-internal knowledge but cannot eliminate unsupported generation or guarantee correctness. Model evaluation, domain adaptation, and fine-tuning may remain useful for separately governed objectives, but they do not replace current evidence retrieval, provenance, governance validation, or human oversight.

The separation between specialist analytical authority and LLM-based synthesis is particularly important in safety-relevant settings. Numerical, statistical, physics-based, optimization, and specialized machine-learning results remain authoritative outputs of their originating applications. The LLM interprets and explains these results in relation to the supplied context and evidence, communicates uncertainty and limitations, and formulates candidate recommendations. This boundary reduces the risk that LLM-generated interpretations could be treated as replacements for, or overrides of, validated engineering calculations.

Governance consequently evaluates the complete evidence-supported output, including its supporting context, analytical results, retrieved evidence, generated claims, uncertainty, and traceability. Relevant risks may originate from incomplete context, deficient retrieval, conflicting evidence, unsupported synthesis, inadequate uncertainty reporting, traceability gaps, or noncompliance with operational policies and safety constraints. Governance validation assesses these risks without reproducing the underlying specialist analyses and does not, by itself, establish the correctness or safety of the resulting output. Its outcome determines whether a candidate response may be presented as a governed recommendation, requires conditions or escalation, or must be rejected.

The distinction between operator interaction and human authority is significant. The operator interface presents governed information and supports initial and follow-up requests, while accountable personnel retain authority over operational decisions. Subsequent actions proceed through established operational procedures and authorized control systems. Recorded decisions and outcomes may support controlled lifecycle improvement, but they do not automatically modify production knowledge sources, retrieval logic, graph relationships, task-instruction modules, governance criteria, or models.

The architecture remains implementation-neutral because its functional boundaries and artifact handovers do not prescribe a single technology stack or deployment topology. Relational, time-series, graph, integrated, virtualized, and hybrid implementation patterns may be adopted while preserving consistent identifiers, provenance, and traceability. The transformer cooling-system illustrative use case illustrates the separation of functions and associated information flows within the architecture using synthetic data; it does not provide empirical evidence of diagnostic accuracy, operational effectiveness, or field readiness.

VIII. Limitations and Future Work

The proposed reference architecture is conceptual and has not yet been evaluated through implementation or empirical studies. The illustrative transformer use case uses representative synthetic information to explain the application of the reference architecture; it does not provide empirical evidence of diagnostic accuracy, safety, reliability, latency, usability, or operational effectiveness. Generalizability across utilities, asset classes, grid domains, operating practices, and regulatory environments therefore remains untested.

The architecture depends on the quality and consistency of information distributed across operational and enterprise sources. Inaccurate telemetry-to-asset mappings, incomplete or stale contextual records, inconsistent identifiers and schemas, timestamp misalignment, incompatible analysis windows, and missing quality, uncertainty, lineage, or provenance information may compromise the reliability downstream results. Differences in CIM adoption and semantic conventions may further complicate interoperability. Similarly, incomplete or outdated Asset & Topology Graph relationships may produce incorrect contextual associations or graph-traversal results. Further evaluation is required to assess graph synchronization with source systems, the traceability and authority of graph relationships, and query performance at operational scale.

Hybrid Information Retrieval introduces method-specific limitations. Operational, relational, historian, graph-based, sparse, and dense/vector retrieval can produce different types of errors and should therefore be evaluated using criteria appropriate to each retrieval method. Retrieval quality may be affected by query construction, indexing, embedding quality, semantic drift, metadata completeness, filtering, graph-path relevance, ranking, reranking, temporal alignment, and cross-source association. Incomplete, irrelevant, or incorrectly associated results may propagate into context fusion and evidence synthesis. Retrieval latency and scalability may also constrain time-sensitive applications.

Context fusion must reconcile information with different timestamps, schemas, authorities, granularities, and uncertainty characteristics. Conflicting evidence, incorrect source association, context-window constraints and loss of relevant detail during normalization, selection or concise representation may affect the LLM-ready request package. The configuration and governance of task-instruction modules, package schemas, and evolving interfaces also require systematic testing.

Evidence grounding reduces but does not eliminate the risk of unsupported synthesis. LLM outputs may remain sensitive to context ordering, ambiguity, conflicting evidence, instruction construction, and model-version changes. Uncertainty may also be communicated inadequately or inconsistently. Evaluation must therefore distinguish source correctness and claim support from linguistic quality and apparent plausibility.

Governance validation cannot guarantee correctness, safety, or operational suitability. Translating utility policies, safety constraints, risk criteria, and escalation requirements into machine-verifiable controls remains difficult and organization-specific. Incomplete rules or inappropriate thresholds may produce false approval, rejection, or escalation outcomes. Governance effectiveness must therefore be evaluated across representative conditions, including incomplete evidence, conflicting information, traceability deficiencies, and different risk levels.

Implementation would also require integration with legacy operational and enterprise systems while preserving cybersecurity, privacy, identity and access management, auditability, resilience, and data sovereignty. Availability of distributed sources, end-to-end latency, failure handling, lifecycle maintenance, organizational change management, and resource and cost implications remain to be evaluated. Human-factors concerns include operator workload, appropriate trust calibration, the risk of overreliance on automated recommendations, alarm fatigue, explanation usability, and accountability. Operator feedback may be incomplete or inconsistent and must not automatically be treated as ground truth.

Future research should begin with prototype development and staged evaluation using offline replay, simulation, controlled test environments, and carefully governed utility pilots. Event-driven, operator-initiated, and follow-up scenarios should be evaluated separately and jointly. Representative, governed, and appropriately anonymized datasets should connect operational observations, contextual records, graph relationships, engineering evidence, governance outcomes, and accountable human decisions.

Technical evaluation should examine each retrieval method according to its intended function. Relevant measures include retrieval relevance and completeness, temporal and relationship correctness, source correctness, latency, and scalability. Research should also evaluate metadata filtering, ranking, reranking, cross-source association, telemetry-to-asset mapping accuracy, context freshness, graph synchronization, the traceability and authority of graph relationships, and graph-path relevance.

Further work is needed to evaluate temporal alignment, evidence association, source-conflict handling, concise representation of relevant context, schema conformance, and the configuration and governance of task-instruction modules. LLM evaluation should address unsupported-claim rates, evidence faithfulness, uncertainty communication, robustness to conflicting evidence, model-version variation, and reproducibility across repeated runs. Reproducibility assessment should distinguish acceptable linguistic variation from material differences in interpretations, evidence attribution, uncertainty statements, and candidate recommendations. Domain adaptation and fine-tuning may be investigated through separately governed processes. However, these techniques do not replace the need for current information retrieval, evidence provenance, and end-to-end traceability.

Governance research should formalize policy, safety, risk, and escalation criteria and evaluate approved, approved-with-conditions, escalated, and rejected outcomes. This evaluation should include false approvals, false rejections, incomplete evidence, and governance-rule coverage. Operator-centered studies should assess cognitive workload, trust calibration, the risk of overreliance on automated recommendations, explanation usefulness, interaction quality, and decision quality. Context-aware and role-based presentation may also be investigated as a future capability that adapts displayed information to the task, operational context, governance outcome, and operator responsibilities.

Finally, lifecycle change-governance mechanisms are required to review, approve, test, deploy, monitor, audit, and, where necessary, roll back updates informed by human decisions and operational outcomes. Deployment research should examine on-premises, edge, cloud, and hybrid patterns together with secure model hosting, access control, resilience, and failure management. These investigations would support progression from the proposed conceptual architecture toward an implemented, empirically evaluated, and appropriately governed realization of the operational decision-support capability.

IX. Conclusion

This article presented a conceptual reference architecture for RAG-based Digital Grid operational decision support. The architecture provides a framework for addressing the fragmentation of operational observations, validated analytical results, structured contextual grid data, graph-derived relationships, and engineering knowledge by integrating them within a governed and traceable decision-support workflow. It extends document-centric RAG to support event-driven, operator-initiated, and operator follow-up scenarios without requiring the LLM to replace specialist engineering applications.

The architectural contribution lies in combining structured contextual grounding, hybrid information retrieval, evidence traceability, uncertainty reporting, and LLM-based evidence synthesis while preserving clear boundaries between specialist analytical authority, AI-assisted synthesis, and human operational authority. Specialist applications remain responsible for validated analytical results, candidate outputs undergo governance validation before presentation through the operator interface, and final operational authority remains with authorized personnel acting through established procedures and control systems.

The synthetic transformer cooling-system scenario illustrates the application of the architecture but does not provide empirical evidence of diagnostic accuracy, safety, operational effectiveness, or deployment readiness. Prototype implementation, staged technical and governance evaluation, security assessment, and human-factors research are therefore required to progress toward an empirically evaluated and appropriately governed realization of the proposed Digital Grid operational decision-support capability.

References

[1] P. Lewis et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks,” in Advances in Neural Information Processing Systems, vol. 33, pp. 9459–9474, 2020.

[2] S. Robertson and H. Zaragoza, “The Probabilistic Relevance Framework: BM25 and Beyond,” Foundations and Trends in Information Retrieval, vol. 3, no. 4, pp. 333–389, 2009, doi: 10.1561/1500000019.

[3] V. Karpukhin et al., “Dense Passage Retrieval for Open-Domain Question Answering,” in Proc. 2020 Conference on Empirical Methods in Natural Language Processing (EMNLP), 2020, pp. 6769–6781, doi: 10.18653/v1/2020.emnlp-main.550.

[4] B. Sarmah, D. Mehta, B. Hall, R. Rao, S. Patel, and S. Pasquali, “HybridRAG: Integrating Knowledge Graphs and Vector Retrieval Augmented Generation for Efficient Information Extraction,” in Proc. 5th ACM Int. Conf. AI Finance (ICAIF ’24), 2024, pp. 608–616, doi: 10.1145/3677052.3698671.

[5] International Electrotechnical Commission, “IEC 61850: Communication Networks and Systems for Power Utility Automation,” IEC standard series.

[6] International Electrotechnical Commission, Energy Management System Application Program Interface (EMS-API)—Part 301: Common Information Model (CIM) Base, IEC 61970-301:2020, 2020.

[7] N. Mchirgui, N. Quadar, H. Kraiem, and A. Lakhssassi, “The Applications and Challenges of Digital Twin Technology in Smart Grids: A Comprehensive Review,” Applied Sciences, vol. 14, no. 23, Art. no. 10933, 2024, doi: 10.3390/app142310933.

[8] G. S. Rêma, B. D. Bonatto, A. C. S. de Lima, and A. T. de Carvalho, “Emerging Trends in Power Transformer Maintenance and Diagnostics: A Scoping Review of Asset Management Methodologies, Condition Assessment Techniques, and Oil Analysis” IEEE Access, vol. 12, pp. 111451–111467, 2024, doi: 10.1109/ACCESS.2024.3441523.

[9] E. Tabassi, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, National Institute of Standards and Technology, 2023, doi: 10.6028/NIST.AI.100-1.

[10] K. Lazaros, A. G. Vrahatis, and S. Kotsiantis, “Human-in-the-Loop Artificial Intelligence: A Systematic Review of Concepts, Methods, and Applications,” Entropy, vol. 28, no. 4, Art. no. 377, 2026, doi: 10.3390/e28040377.

Alaa Mahjoub is an independent digital business advisor based in Abu Dhabi, UAE. He has collaborated with organizations in the utilities, transportation, petroleum, and defense sectors across multiple countries. He has led digital transformation, data management, operational technology and enterprise architecture programs, as well as training initiatives, across the UAE, Kuwait, Egypt, Malaysia, Singapore, the UK, and the US. His work included driving the Digital Grid transformation as part of the restructuring of the water and electricity sectors in the Emirate of Abu Dhabi.

Alaa has published and served as a reviewer for the IEEE, CIGRE, SPE, the Arab Union of Electricity, and the World Utilities Congress. He holds B.Sc.. and M.Sc. degrees in Computer Engineering from the Military Technical College (MTC) and Cairo University.