Sovereign AI Architecture for a Grid Control Room in Saudi Arabia

A Daily Question Goes Unanswered in the Systems That Hold the Data

The operation holds every fact the question needs and no system answers it.

The abstract promised a sovereign AI architecture that turns data an operation already holds into answers a named person can act on. This chapter states the question that system exists to answer, what answering it costs today, and the operation that will live with it.

1.1  The Question, the Data It Requires and the Regimes It Must Satisfy

Every shift in a transmission control room asks one question in a hundred forms: what just happened on the grid, what does it affect, and what must be done next within the rules. At its sharpest, when one 380 kilovolt line trips at summer peak, the question becomes a list with a clock on it: which protection operated and in what order, which busbars and connected operators now sit de-energized, what maintenance is already in progress on the affected apparatus, which procedure governs the switching that follows, and who must approve each step. The data that answers it all exists: alarms, events and telemetry from the SCADA and energy management systems, topology from the network model, outage windows from the outage management system, load behind busbars from meter data, asset condition, relay settings, the procedure library in Arabic and English, weather forecasts tied to the lines, the shift log, and the contracted sensitivity of every connected operator. The regimes it must satisfy are just as fixed: the operator's own rule that the operational network stays separated from everything else, national cybersecurity and communications controls that grade that network into segmentation zones, the grid code that governs outage planning, and a clear direction of international regulatory travel, from safety and security guidance for AI in critical infrastructure (DHS 2024) to an initial risk assessment of AI in energy infrastructure (Energy 2024) and a regulatory inquiry into utility AI use that begins by inventorying use cases and internal controls (NY 2026).

1.2  The Documented Cost of the Problem

Today the list is assembled by hand, and the industry has documented what that costs. An independent review of AI use in electricity networks, published by the UK government, was commissioned precisely because networks were adopting AI in fragments, without a joined view of risk and benefit across their operational systems (Service 2026). Researchers at a major energy company go further and argue that introducing AI into major accident hazard operations without a systemic safety risk assessment creates new accident risk rather than reducing it, because knowledge that lives in separate systems cannot be reasoned over safely (DOI 2025). At the console the cost is concrete rather than abstract: minutes spent finding what a joined query would return in seconds, adjacent work discovered by phone after switching has begun, and a connected operator's interruption sensitivity learned only when that operator calls.

1.3  The Operation as a Scenario

The scenario is a national grid operator in Saudi Arabia that runs the electricity transmission grid: the substations, busbars, lines, transformers and breakers that carry bulk power across the Kingdom, operated from control rooms at regional and national level. The first phase covers one regional control center for one summer, the season when peak load and peak heat coincide and the proving event, one 380 kilovolt line tripping at summer peak, is a realistic day rather than a worst case. Four roles are in the loop by name: the control engineer who confirms alarm triage, the shift supervisor who approves switching drafts, the incoming supervisor who approves the handover, and the protection engineer who receives the event analysis. The physical environment is the control center itself, a conditioned room watching remote substations and corridors, and the regulatory ground is national cybersecurity and communications controls together with the grid code. The design names ten source systems, three adapter families, sixteen ontology objects, eight services, four surfaces, two models and four drafting agents, arranged in three phases carrying eighteen items, every figure traceable to its source or marked as an assumption.

Every System Sees One Slice of the Operation

Each system of record sees its own part of the answer and none sees the whole.

Chapter 1 named the question and every piece of data it requires. This chapter shows where that data lives today and why no system of record can assemble the answer alone.

2.1  What Each System Sees

The SCADA and energy management systems are the backbone: they see every alarm, every event, the telemetry stream and the network model that describes how substations, busbars, lines and breakers connect, and they miss everything written down elsewhere, from procedure text and outage plans to asset history and operator contracts. The outage management system sees planned outage windows, the apparatus involved and the requesting parties, and misses the live state of the grid those windows sit inside. The meter data management system sees load behind busbars and what connected operators actually drew, and misses the topology that would explain it, along with alarms, procedures and outage plans. The asset and maintenance system sees the condition of every substation, line, transformer and breaker, and the maintenance already in progress nearby, and misses the grid as it stands right now. The protection settings databases see relay models, settings revisions and the elements each relay protects, and miss the operational context that would make a settings change meaningful. The procedure library sees the operating procedures and switching instructions, in Arabic and English with their revisions, and misses the state of the equipment they govern. Weather services see forecasts of temperature, wind and dust tied to lines and load at summer peak, and miss anything operational at all.

2.2  What None of Them Sees Together

The trip question crosses every one of these systems at once: the alarm and its sequence of events come from SCADA and EMS, the affected apparatus and its maintenance state from the asset system, the relay behavior from the protection databases, the restoration steps from the procedure library, the outage window from the outage plan, the load at risk from meter data, the thermal context from weather, and the sensitivity of who sits behind the busbar from the connection records. Figure 2 sets these views side by side and shows them converging on a question none can answer alone. In practice the control engineer is the join, working from memory, phone calls and window switching while an alarm flood is still arriving at summer peak; the handover is only as good as what the outgoing shift can recall; and the event analysis waits until the protection engineer can gather the pieces by hand. The cost is the minutes between the trip and the first correct action, and the adjacent work found too late.

Four Constraints Shape Everything Downstream

The goals, the scoping decisions and the exclusions were fixed before any component was chosen.

Chapter 2 showed that the join failure, not any single system, is the problem. This chapter fixes the goals and exclusions that every component choice in Part II had to satisfy, and records what was weighed and set aside.

3.1  Inference Stays Sovereign

The first goal is that every token of reasoning runs on the operator's own hardware, in the operator's own data center in the Kingdom, on open weights the operator can hold. This is hard in this industry because the easy path is a managed service, and a managed service puts grid data and grid reasoning outside the boundary the operator is required to keep. The design therefore places all inference centrally: no edge compute, no field site serving, one frontier class model, GLM 5.3 at 753 billion parameters, served at FP8 precision where its weights occupy 753 gigabytes, held on a single node of eight GPUs of the 141 gigabyte class with the remainder left for the key value cache and activations.

3.2  The Boundary Is One Way and Read Only

The second goal is that the platform never sends a control command and never writes into a system of record. SCADA and EMS networks are safety segregated, and the operational technology segmentation zones, OTCC 2 to 4, together with the operator's own rule that the operational network stays separated, make any direct platform path into the control network a compliance breach rather than a shortcut. The design reads through a replicated historian or demilitarized zone feed into a separate AI platform zone, and a hardware-enforced data diode remains the committed fallback where the segmentation review demands demonstrably one-way flow, with forward error correction sized to the link because nothing can be resent.

3.3  Every Decision Has a Named Owner

The third goal is that agents draft and people decide, always by name. The alarm triage agent's ranking is confirmed by the control engineer, the switching draft by the shift supervisor, the handover by the incoming supervisor, and the event analysis is prepared for the protection engineer. This is hard in a control room because the temptation under pressure is to trust whichever answer arrives first, so the design makes the approval a first-class object with its own status vocabulary, and keeps an immutable record of every confirmed decision, which is also what regulators inventorying use cases and internal controls expect to find (NY 2026).

3.4  The System Improves Without Training

The fourth goal is that memory improves every shift without training a model. Nothing is fine tuned, trained or distilled into weights: agents improve through memory loops over confirmed decisions and event analyzes, each run reading what was decided before it acts. This is hard because fine tuning is the industry's reflex answer to improvement, but a moving model would invalidate the frozen baselines the summer trial is gated on, and the license terms that let the operator hold its weights carry conditions that a training pipeline would put under new scrutiny.

3.5  Scoping Decisions

The scope was fixed before any component was chosen, and each decision bought something at a known cost. Table 1 records the three decisions that bound the first phase: where the trial runs, which sources feed it and in what order, and how much compute the sovereign answer is sized on.

3.6  What the Design Chose Against

Each of the goals above had credible alternatives, and Table 2 records what was picked, what it was picked instead of, and why. The final row marks the boundary of the work itself: the design is a read-only projection over the systems of record on the operator's own hardware, and everything beyond that projection is out of scope.

One Stack Runs From the Systems of Record to the Surfaces

Systems of record below, one object model in the middle, services and surfaces above.

Chapter 3 fixed the four constraints that shape everything downstream: data and weights stay inside the operator's boundary, no control command is ever sent, every draft is confirmed or approved by a named person, and a first gate can stop the work cheaply. This chapter lays out the stack that satisfies those constraints, stage by stage.

4.1  The Pattern and Why It Fits

The design uses the layered shape that a sovereign AI architecture in critical infrastructure converges on: systems of record below, one object model in the middle, applications and agents above. Below sit the ten read-only sources the control room already trusts, among them SCADA and EMS, the outage management system, the asset and maintenance system, the protection settings databases, the procedures library and weather services. In the middle sits the grid ontology, sixteen objects joined by typed links and seeded by the CIM export from the EMS network model rather than assembled from documents. Above sit the eight services and four surfaces where the agents draft and the control engineers and shift supervisors decide.

The pattern fits because the control room's real problem is a join problem. When one 380 kilovolt line trips at summer peak, the question that matters spans the alarms, the network model, the outage plan, the protection record and the procedures library, and no single system of record holds that join. The pattern also fits the regulatory ground: safety and security guidance for critical infrastructure treats AI risk as something to govern before use (DHS 2024), and an independent review of AI in electricity networks found the binding constraint to be trustworthy data foundations under operator control (Service 2026). Figure 3 shows the layered stack with the count at each layer.

4.2  The Stack Stage by Stage

Table 3 walks the stack from sources to surfaces. Each stage carries one responsibility and named components, and each stage speaks only to its neighbors: sources never address the ontology, the ontology never addresses a surface, and nothing above the adapter tier ever touches a source system directly.

4.3  Where Each Layer's Choice Is Recorded

Every layer's component choice is recorded in Table 7, which the platform prints from the design record in Layer, Component, Choice and Why columns. Two entries are classes rather than products and are settled at design: the time series store for the replicated SCADA and EMS series is chosen against the historian's export format and scan rate, and the ontology or graph store class is fixed by what the sixteen objects and their links demand. The rest are committed by name, from the streaming backbone to the identity service, and the reasoning behind each row sits in the table.

4.4  A Reusable Pattern

The reusable shape is the whole vertical slice: a replicated, read-only boundary out of the operational network; an adapter tier that owns every contract; one governed object model that joins the records; drafting agents that propose and named people who dispose; and weights the operator holds in its own data center. A team carrying a similar brief swaps the source systems, the object set and the model sized to its own budget, and keeps the rest unchanged, because the parts worth keeping are the ones that make a system safe to stand next to a control room: no write path into the systems of record, adapters owning contracts, and every decision tracing to a person.

Sixteen Objects Turn Operational Data Into One Argument

The object model is the join the systems never made.

Chapter 4 showed the stack's layers and what each is responsible for. This chapter opens the middle layer, where the design's whole claim rests: sixteen objects, joined by typed links, that turn the systems' separate records into one argument.

5.1  Sixteen Objects and the Links Between Them

The model holds sixteen objects in five kinds. Sites and assets: the Substation, the Transmission Line, the Busbar, the transformer, the breaker and the relay, each anchored in the network model or the asset system and each carrying the properties its system of record already holds, from thermal rating to settings revision. Events: the Alarm, anchored in SCADA, and the Grid Event, anchored in EMS. Records: the switching program, the Planned Outage and the shift log. Documents: the Operating Procedure, anchored in the procedures library. Measures and people: the weather cell, the Connected Operator, the Control Engineer and the Shift Supervisor.

The typed links are what make this more than a list. When the 380 kilovolt line trips, the triage reasoning starts at the alarm, reaches the line it references, the substations at both ends, the busbars behind them, the operators whose supply runs through those busbars, the relays that protect the line with their settings revisions, the procedures that govern restoring it, and the shift logs where the last comparable event was handled. A document store holds all of those facts as text and cannot walk them; the object model walks them in one traversal, which is the difference between a search result and an argument. Figure 4 shows every object and its typed links, with the alarm at the focal center, and Table 8 records, for every object, the system it is anchored in and the links the plan implies.

5.2  The Human Loop and the Hosting Posture

The human loop lives in the status vocabularies and the links to people. An alarm moves from Raised to Acknowledged only under the control engineer's confirmation; a switching program moves from Drafted to Approved only under the shift supervisor; a shift log is approved by the incoming supervisor, not the outgoing one. Regulators are moving toward exactly this discipline, inventorying utility AI use cases and their internal controls (NY 2026), and sector guidance on ethical AI treats named human accountability as a condition of use, not a courtesy (OFGEM 2026).

The hosting posture follows the same line. Everything runs in the operator's own data center in the Kingdom: the ontology, the memory, the weights and the surfaces. Identity is issued inside the boundary, so no decision is attributable to an account the operator does not control. The one external input, weather services, enters through the integration adapter as data on a schedule, never as a live call the model makes on its own. The single write path anywhere in the design is the recorded confirmation or approval, written into the object model and the memory service, and never into any system of record.

5.3  One Object in Its Recorded Form

The substation record below shows the id, label, kind, properties and status vocabulary the platform prints for every object; the breaker, which carries the trip in the simulated event, is recorded the same way.

{ "id": "substation", "label": "Substation", "kind": "site", "anchored_in": "The network (CIM export)", "properties": [ "Voltage level", "Bays", "Air insulated or gas insulated", "Region", "Single line diagram reference" ], "status_vocabulary": [], "links": [ { "to": "busbar", "label": "contains" } ] }

Every Source Enters Through an Adapter, Never Directly

Nothing reaches the object model except through an adapter that owns its contract.

Chapter 5 described what the object model holds. This chapter describes how data gets into it: through three adapter families and an event backbone, and by no other route.

6.1  Every Source and Its Provenance Class

Ten sources feed the platform, all read-only, all of operator provenance, meaning every fact they contribute carries the name of the system it came from. SCADA and EMS is the backbone: alarms, events, telemetry and the network model that seeds the ontology's topology, read through the replicated boundary and never commanded. The outage management system supplies the planned outage requests that trigger the switching program agent and the live outage plan its adjacent work checks read. Meter data management contextualises load behind busbars and connected operators, and joins during the summer under the phasing the intake set. The asset and maintenance system gives every substation, line, transformer and breaker its asset context, including the maintenance already in progress nearby that a switching draft must respect. Protection settings databases supply the relay context the event analysis agent reasons from. The procedures library is the corpus every answer and every switching draft must cite, in Arabic and English. Weather services tie forecast cells to lines and load at summer peak. The remaining sources enter on the same contracts as the phasing allows. Figure 5 shows each named system, its provenance class and its adapter path into the object model.

6.2  What the Adapter Tier Guarantees

Three adapter families own every contract. The telemetry adapter carries the replicated SCADA and EMS series into the time series store. The integration adapter carries documents and records: outage plans, protection settings, procedures, weather. The ERP adapter carries asset, maintenance and meter data from the operator's enterprise systems. Together the tier guarantees four things. Schema and unit checking, so alert logic lands on curated, unit-checked series rather than raw tags. One-way flow, so no path exists from the platform back into the operational network. Provenance stamped on every fact at the moment it lands, so any answer can be traced to its source system. Citation resolution and freshness checks on every answer, so a draft that cites a superseded procedure or a stale feed is caught before a person reads it. This discipline is the operational answer to the risk picture the US Department of Energy drew in its initial assessment of AI in critical energy infrastructure (Energy 2024): the guardrail is architectural, not procedural.

6.3  The Event Backbone

Apache Kafka carries everything between the adapters and the platform. Ordering is per partition, keyed by point or asset, so any one telemetry point's series arrives in order even when the flood is wide. Delivery is at least once with idempotent writes into the time series store, so a replayed record cannot double count an alarm or an event. Buffering absorbs alarm floods, which arrive in bursts, and lets the platform drain at its own pace rather than at the SCADA scan rate. Replication runs inside the platform zone, so the loss of a broker node costs availability, not data. The retained log is also the replay mechanism: the pre-summer phase validates the triage agent on the operators' own recorded floods by feeding them back through the same backbone. Time is held by linuxptp with chrony, disciplined by a GNSS PTP grandmaster with holdover, so alarms, events and telemetry from different systems can be placed in one sequence of events, which is the evidence the event analysis agent drafts from and the protection engineer reviews.

Inference Belongs Where the Data Is

Each tier runs what its data and its link can carry.

Chapter 6 followed every source through its adapter into the event backbone inside the AI platform zone. This chapter decides where the models that read that backbone run, what each tier must hold in memory, and what the placement owes the control room when the link, the power or the update path fails.

7.1  Two Central Tiers and a Deliberately Empty Edge

The design has two inference tiers and both are central: a frontier tier that carries GLM 5.3 for all four drafting agents, the command center surface and ontology maintenance, and an embedding tier that carries BGE-M3 for retrieval over procedures, records and past event analyzes. Both run in the operator's own data center in the Kingdom, on the operator's own hardware. The absent edge tier is a decision rather than an omission: the platform consumes replicated data instead of serving models at field sites, and fast protection and dispatch decisions stay in the relays and remote terminal units where they have always lived.

The memory arithmetic fixes the frontier tier. GLM 5.3 is filed at 753 billion parameters, and at FP8 precision one byte per parameter gives 753 GB of weights; multiplying by the 1.2 planning factor for KV cache and activations gives 904 GB the GPUs must hold. One node of eight GPUs of the 141 GB class gives 1,128 GB, which carries the weights with 375 GB left beside them, well above the 151 GB the planning factor reserves. That spare capacity is the KV cache ceiling, the memory that holds each in-flight request's context, and it is what buys concurrent served requests during an alarm flood. The embedding tier is small by comparison: BGE-M3 at FP16 is about 1.1 GB of weights, running on the platform zone's dual-socket x86 rack server class beside the ontology, streaming and retrieval services. Figure 6 sets the two tiers side by side, with what runs on each and what crosses into them.

7.2  The Latency Budget

The budget is built on the control room's own rhythm rather than a single number, because the human terms dominate it. In order, the terms are replication lag across the one-way boundary, then retrieval, then generation, then the named person's confirmation. Replication lag bounds the alarm triage agent, which must rank a flood while the flood is still unfolding, and the embedding tier's small footprint keeps the retrieval term short. Generation is the longest machine term, and the design spends it where the work tolerates it: an event analysis draft for the protection engineer can take the time a careful engineer would take, and a handover draft is bounded by the end of shift window rather than by seconds. Stated as an ordering, nothing the machine does may outrun the freshness of the replicated stream, and nothing the machine does substitutes for the confirmation that closes the loop.

7.3  What Crosses the Boundary, and What Happens When It Fails

Everything that crosses the network boundary crosses in one direction: replicated SCADA telemetry and alarms, EMS events and the network model, outage plans, asset and protection records, the procedure library, meter data and weather forecasts flow into the AI platform zone, and nothing flows back. No agent sends a control command, no agent issues a switching instruction without a named approval, and the platform holds no write path of any kind into SCADA or EMS. The advisory placement is also the safety argument: guidance for critical infrastructure owners treats an AI system that can act on physical plant as a materially different risk from one that advises a named person (DHS 2024), and work on major accident risk argues that AI placed inside safety-critical loops demands systemic assessment the advisory placement avoids (DOI 2025).

Failure is designed for rather than hoped away. If the link fails, platform heartbeat and data freshness signals mark every surface stale, and the control room keeps operating on SCADA and EMS directly because the platform was never in the control path; the degraded-mode procedure is written down and rehearsed before summer go-live. If power fails, the conditioned data center room restarts the services and the event backbone replays what was buffered, so the platform resynchronizes rather than loses the record. If the update path fails, models and artifacts move through the Harbor registry as staged, signed images, and the platform keeps serving the last verified version until the path returns. A named owner watches these signals, because the US Department of Energy's initial risk assessment on AI in critical energy infrastructure stresses governance and accountability from the start rather than after an incident (Energy 2024).

The License Decides What the Operator Can Own

Every model was chosen against its license before its accuracy.

Chapter 7 fixed where inference runs and what each tier holds in memory. This chapter fixes which models run there, and on what terms the operator can hold them, because the license decides the ownership before the benchmark decides the accuracy. Figure 7 opens the chapter: the model stack, with the frontier reasoning model above and the multilingual embedding model beneath it, each carrying its specification, its placement and its job.

8.1  GLM 5.3 on Terms That Let the Operator Hold Its Weights

GLM 5.3 is the register's frontier model, filed at 753 billion parameters, with about 756 GB of weights at FP8 as published and roughly 1.5 TB at BF16; the design serves it at FP8 on one node of eight 141 GB class GPUs in the operator's own Kingdom data center. Its role spans the agentic work surface, ontology maintenance and all four drafting agents: alarm triage on a flood, the switching draft on a planned outage request, the handover draft at end of shift and the event analysis draft on a protection trip. Its license is the GLM-5.3 bespoke license: commercial use, fine tuning and redistribution are allowed, with an attribution notice to carry and a trigger that applies only where a group's revenue rises above 10 billion US dollars from managed access services. Internal control-room use does not reach that trigger, and procurement reads the license and confirms the group position in writing before contract. The model was chosen first because it is the one frontier-class model in the register, and second because its license lets the operator hold the weights itself; the design trains nothing into weights, so the fine-tuning right matters as ownership rather than as a training plan. That ownership is what regulators are beginning to ask about: one state commission has opened an inquiry into how utilities use AI, starting from an inventory of use cases and internal controls (NY 2026), and the British energy regulator's guidance on ethical AI in the sector asks operators to account for the systems that shape their decisions (OFGEM 2026). A stack whose weights, memory and decision record sit inside the operator's boundary answers those questions in one place.

8.2  BGE-M3 Under MIT for Arabic and English Retrieval

BGE-M3 is the register's embedding model, a multilingual retrieval model that indexes the procedure library, switching instructions, records and past event analyzes in Arabic and English. Its footprint is about 2.27 GB at float32, about 1.1 GB at FP16 and about 0.6 GB at 8 bit; the design serves it at FP16 on the platform zone's rack server class, where its retrieval latency sits inside the fast path of the budget Chapter 7 set out. Its MIT license lets the operator hold, run and redistribute it without obligation, which is why it was chosen against the license before its accuracy was weighed. Its accuracy is still proven before trust: retrieval recall over the operator's own Arabic procedures is evaluated as part of the frozen evaluation set before summer go-live, because a cited answer that misses the right procedure is worse than no answer at all.

8.3  The Model and Equipment Register

Table 4 gathers what Chapter 7 and this chapter have fixed into one register: each model, the hardware classes and sizing rules that place it, the sensing the platform watches, the patterns the design stands on, and the ground everything runs on. Each row is a decision already argued in the body; the table exists so an engineer ordering hardware or clearing licenses can read the whole position at once.

Shadow Mode Comes Before Any Flag Is Trusted

The rollout earns each phase at a gate the operator can read.

Chapter 8 fixed the model register and the license terms under which the operator holds its own weights. This chapter sets out how the build earns each stage of the rollout: three phases closed by gates the operator can read, with every measurement named and frozen before the summer starts.

9.1  Phases, Workstreams and Exit Gates

The rollout carries 18 items across three phases, and requirement coverage stands at one requirement covered in full, with nothing partial and nothing open. Figure 8 shows the phases, their item counts, their workstreams and the gates between them. Phase one, the pre-summer build and replay, carries 15 items across six workstreams: the grid ontology, boundary and integration, memory and retrieval, the agents that draft, governance and approvals, and the sovereign platform. Its items include the ontology built from the systems of record, the one-way boundary from the operational network, and telemetry ingestion on curated series. Its exit gate is the switching program drafting agent, the workflow that chains a planned outage request through topology, procedure citation, adjacent-work checks and supervisor approval end to end on replayed records, before anything runs live. Phase two, summer live at one regional control center, carries 2 items across boundary and integration and the summer trial: the phased integration of the remaining source systems during the season, and live operation at one regional control center through one summer. Phase three, extension to every control center, carries a single item, the extension gates that decide whether the design spreads beyond the first center. No phase carries a duration; each closes on evidence, not on a calendar.

9.2  What the Rollout Measures

Every baseline is frozen before go-live, and the headline measure is the interval from trip to first correct action, exercised against the design's simulated event: one 380 kilovolt transmission line tripping at summer peak. Around the alarm triage agent the rollout measures alerts surfaced per shift against the alert budget, confirmation time in the triage queue, and how often engineers take the disagreement path rather than confirming a ranking they doubt. Around the drafting agents it measures citation resolution on every answer, retrieval recall over the operator's own Arabic procedures, and adoption as a gate in its own right: the share of drafts confirmed unchanged against the share edited or rejected. Replay validation runs on the operators' own recorded alarm floods before go-live, so the first live flood is not the first test. Platform heartbeat and data freshness signals run throughout. The measurement-first posture follows published guidance for this infrastructure class: safety and security guidelines for owners and operators (DHS 2024), an initial risk assessment on AI in critical energy infrastructure (Energy 2024), and an independent review of AI use in electricity networks that asks for evidence before scale (Service 2026).

9.3  Failure Modes

Table 5 states what fails and what the design does about each failure.

9.4  Lessons

Shadow the flags before anyone trusts them. The triage agent earns its place on replayed alarm floods from the operator's own historians before any live shift sees a ranking, and adoption is measured as a gate in its own right. Work on systemic safety risk argues that new failure paths appear at the joins between human and machine judgement (DOI 2025), and replay is how those joins are inspected before the summer rather than during it.

Ask the license question once, early. The sizing holds at one node of the 141 GB class precisely so the export license determination is asked once, naming this end user, before the order is placed; a two-node answer would ask the same question twice and double the exposure to timelines nobody controls.

Make disagreement faster than agreement. If disputing a doubtful ranking takes longer than confirming it, engineers will confirm, and the summer will measure politeness instead of accuracy; the disagreement path is therefore a first-class control whose usage is counted alongside confirmation time.

9.5  What Is Still Open

Four questions remain open, and settling each changes a parts list or a gate. Which self hosted time series store carries the replicated SCADA and EMS series is chosen at design against the historian's export format and scan rate, and settling it fixes the telemetry tier. Whether the segmentation review demands the hardware diode in place of the replicated feed decides the boundary's components and its forward error correction budget. Whether Arabic retrieval meets the recall bar on the operator's own procedures decides whether the human check stage stays a permanent cost on every switching draft. Whether feeder risk ranking and outage prediction clear the summer evidence decides the shape of the extension gates in phase three.

The Intelligence Should Stay with the Operation That Produced It

What the design builds belongs to the operator.

Chapter 9 showed the gates at which the rollout earns each phase. This chapter states who holds what those gates protect: the model, the record and the boundary.

10.1  What the Operator Owns

The object model is the operator's. Its 16 objects and typed links are a projection over the operator's own systems of record, never a migration or a shadow copy that competes with them, and the vocabulary, property lists and status sets are the operator's people's to extend and govern. The weights are the operator's. GLM 5.3 runs self hosted on one 141 GB class node in the operator's own data center in the Kingdom, under a license that allows commercial use, fine tuning and redistribution; the operator may hold, patch and resynchronize the weights without asking anyone's permission, subject to the attribution notice and the managed-service trigger above 10 billion US dollars of group revenue, which internal control-room use does not touch. No fine-tune exists by design: memory improves every shift without training a model, so there is no forked weight set to reconcile at any future date. The decision record is the operator's. Every confirmed decision, draft and approval traces to its source system and a named person, and the record is kept as memory the next decision reads; it is the operation's own history, not a corpus held elsewhere. The boundary is the operator's. The one-way replicated path from the operational network into the platform zone, with the hardware diode as the committed fallback where the segmentation review demands demonstrable one-way flow, is a control the operator owns and can demonstrate to its regulator. The design sits squarely in the family of sovereign AI reference architectures: intelligence that stays inside the boundary of the operation that produced it.

10.2  The Offer Behind the Design

CodeNinja builds this shape as its offer. Adaptive Operations covers the sensing and detection of physical behavior over the replicated telemetry streams and curated series; Decision Systems covers the rankings, attributions and drafts that a named person decides; Hyper Ontology holds the governed object model this design is built on; Hyper Pragma is the command center and the cited Arabic and English conversational interface, the surface where the operator's people build and run their own agents; Hyper Engram keeps the record of decisions and outcomes that each run reads before it acts; Sovereign Infrastructure covers own hardware, open-weight licenses and in-country operation in the operator's own Kingdom data center; and the design itself was produced on Praxis, the platform for designing physical AI systems.

The Pattern Repeats Wherever Systems of Record Do Not Meet

Seen whole, the design is one object model over the systems a national grid operator in Saudi Arabia already runs, with inference placed where the data is and every decision left to a named person.

Running the same shape elsewhere takes the same four things: the named systems, an object model anchored in them, a first gate that can stop the work cheaply, and the license posture that lets the operator own what it learns.

How Praxis Contextualized and Reasoned This Design

Every choice above traces back to something Praxis recorded reading.

Chapter 10 closed the ownership argument by naming the offer behind the design. Every design in this series is produced on Praxis, and this chapter lets a reader trace any choice above back to what justified it (Figure 9).

11.1  Contextualizing the Ask

The ask, as the operator stated it, was a sovereign knowledge system for a national electricity transmission grid control room: one governed ontology over substation, line, transformer, breaker, alarm, event, outage, procedure and shift data, reading SCADA, EMS, outage management, meter data, asset and protection systems and the procedure library, never sending a control command, with four drafting agents confirmed by named people, a cited Arabic and English conversational interface, and reasoning self hosted in the Kingdom. Praxis assigned it the Vertical-Driven Architectures family in the Energy & Utilities industry, with the country stated by the operator's own requirement. What Praxis read: the case study, tooling, hardware, rules, approach and history shelves, together with the pinned energy and utilities brief and the platform's own ontology specification at version 0.9. The two models were verified live on their public pages, GLM 5.3 and BGE-M3, each with its license attached, so no specification in this paper rests on a secondary description.

11.2  The Lenses

Table 6 states what each of the eight lenses could see, what it cited and what it contributed. The rules lens read the regulator guidance now shaping this sector, from ethical AI guidance for energy (OFGEM 2026) to a public service commission's inventory of utility AI use (NY 2026), and fed the auditable decision trail and the named human decision that run through every chapter above.

11.3  Patterns Adopted and Set Aside

Four patterns were adopted. The CIM import from the network model seeds the ontology's topology rather than assembling it from records; the replicated historian feed replaces any direct platform path into the control network; memory loops replace fine tuning, because the ask itself demanded improvement without training; and core sources first, with meter, asset and protection phased in during the season, protects the summer window. Four were set aside with reasons. Two nodes of the 80 GB class were rejected because they add an RDMA fabric to a footprint one 141 GB class node already holds; direct read-only links inside the operational network were rejected as a compliance breach rather than a shortcut; fine tuning GLM 5.3 on event history was rejected against the ask's own words; and edge serving, cameras and tracking were rejected because the requirement's world is control-room work over telemetry and documents.

11.4  Where the Reasoning Lands

The reasoning lands on four equipment classes: the frontier model GPU footprint sizing rule that fixes FP8 weights against usable memory, the 141 GB HBM GPU class, the GLM 5.3 node count by GPU class, and the data diode one-way transfer class held as the committed fallback. Everything shown in this chapter was recorded reading: the ask, the records read, the lenses and the patterns are what Praxis read and filed, and nothing in the design is inferred beyond them.