This article is general information, not legal or regulatory advice. Rules, deadlines and program terms change, so confirm current requirements with the relevant regulator or administering agency.
If you ask three systems how many customers were affected by yesterday’s outage, you’ll probably get three different answers. For example, the OMS dashboard says 4,210, the CIS/billing report says 3,876, and the GIS-fed report says 5,102. Nobody is wrong. Each system is answering a different definition of “customer” (an energized service point, a billed account, a mapped location, for example). If one word means three things, you don’t have a data problem; you have a definition problem.
That definition problem used to cost utilities time, but now it creates friction everywhere data has to move. Systems exchange the same concepts using different structures, integrations repeatedly translate between them, regulators want traceable numbers, boards want one version of the truth, and AI agents are only as reliable as the definitions underneath them. The question for most utilities in 2026 isn’t simply whether their data is ready for AI. It’s whether they have a common, governed representation of the utility that systems, people, and agents can consistently understand.
In this article, we’ll walk through the challenges a Common Information Model (CIM) is built to solve, what a CIM actually is, how Keyrus implements one natively on Snowflake, what it can answer today, how it fits with the regulatory picture in the US and Canada, and realistic steps to get started.
The Challenges a CIM Solves
Most utilities don’t have bad systems. The OMS, CIS, GIS, MDMS, SCADA, asset management, and (for water utilities) LIMS each do their job well. The friction lives in the spaces between them.
The Challenge | How a CIM Helps |
The same term means different things in different systems (“customer,” “outage,” “asset”) | One governed definition, shared by every report, dashboard, and agent |
Data lives in separate systems, so cross-domain questions turn into custom projects | Assets, customers, outages, measurements and network connectivity are modeled together and queryable in one place |
Every system and integration represents utility entities and relationships differently | Systems map to a common utility model, reducing repeated point-to-point interpretation and creating a reusable foundation for interoperability |
Regulatory and board reports are assembled by hand from several sources | Reports draw from the same model operations uses, with lineage back to source tables |
Operations, Finance and the board each see a different ranking or KPI | Scoring logic lives once in the semantic layer, so everyone sees the same result |
Spatial analysis needs a separate GIS analytics stack | Native GEOGRAPHY types handle spatial questions inside the same model |
New analytics and pipelines queue behind a backlog | An agent can extend the model inside existing governance, with humans reviewing each change |
AI answers arrive without a way to check them | Every answer is cited back to governed tables and runs inside existing access controls |
Data gaps stay hidden until someone goes looking | Validation rules reject bad records with reason codes, so gaps are visible and auditable |
TL;DR: the problem usually isn’t any single system. It’s that nothing sits across them and provides a shared definition of what utility entities mean, how they relate, and how that meaning can be consistently reused by other systems, applications, reports, and agents.
What Is a Common Information Model?
The CIM is the utility industry’s shared vocabulary, standardized as IEC 61968 and IEC 61970. It describes the things a utility runs on (assets, network connectivity, customers, outages, measurements) and, just as important, how they relate. A transformer feeds a service point. A service point belongs to a customer. A meter reports intervals against that service point.
Think of it as a dictionary and a floor plan in one. The dictionary defines the words. The floor plan shows how every room connects. Once both exist in one place, “customer” stops meaning three things, and every report, dashboard, and agent draws from the same definition. In our example, the same outage question returns a single answer: 4,210, cited and traceable to its source tables.
The bigger value is interoperability. A CIM gives utilities a common language between systems, not just a better structure for analytics.
Upstream, operational systems such as GIS, OMS, ADMS, CIS, MDMS, AMI and asset management platforms can map their different representations of the utility into a shared model. Instead of every new integration having to reinterpret what a customer, meter, transformer, feeder or service point means, those relationships are defined once.
Downstream, that same governed model can serve applications, APIs, regulatory reporting, dashboards, analytics, and AI. Each consumer starts from the same definitions, relationships, and lineage rather than creating another interpretation of the utility.
That is where the compounding value comes from: connect systems through a common model, establish a governed representation of the utility, and then reuse that truth everywhere it is needed.
What Keyrus Built on Snowflake
Our utilities CIM is implemented natively on Snowflake. The reference implementation includes:
17 tables and 7 analytical views covering assets, customers, outages, measurements, and network relationships
Native GEOGRAPHY types for spatial analysis, with no separate GIS analytics stack
A 34-edge recursive network graph that lets queries walk the grid from substation to meter
One governed semantic view that tells AI how to read the model
Here’s how the pieces fit together:
The architecture is deliberately two-sided: upstream systems map into a common utility model, while downstream applications and consumers draw from that same governed representation.
The CIM: the interoperability and governed data foundation. Upstream systems map their different structures into shared utility entities and relationships. Downstream applications, reporting, analytics, and AI can then consume those definitions consistently.
The semantic view: the translation layer. It describes the model in business terms so plain-language questions map to the right tables and logic.
Snowflake CoWork (formerly Snowflake Intelligence): the question-asking layer. Anyone can ask in plain language, and every answer comes back cited and inside existing role-based access control (RBAC). No SQL required.
Snowflake CoCo (formerly Cortex Code): the building layer. It’s a data-native coding agent that reads your schemas and roles before it writes anything, then helps extend the model. For more on both, see our Snowflake CoCo and CoWork explainer.
Governance: RBAC and Horizon governance apply to all of it. Inference stays inside the security perimeter, and actions are logged and auditable.
Once that common model exists, the value compounds. The same governed representation used to connect and reconcile utility domains becomes the foundation for operational questions, regulatory reporting, analytics, and AI.
The CIM in Action
Here’s one conversation, from our demo environment, that mirrors how these questions come up in practice.
A transformer fails on a feeder. Someone asks: “Which customers are affected downstream, and what’s the estimated customer-minutes impact?” CoWork traces the network graph from transformer to feeder to service point to customer, identifies three downstream customers, and estimates impact at 930 customer-minutes (median), 1,137 (average), and 2,250 (worst case), based on four historical equipment-failure outages.
The follow-up: what’s the root cause? “Trace upstream from the affected meters. What’s the common upstream device?” Same conversation, and no dashboard was built for it. The model identifies the single transformer serving all three customers, flags a pole on the same path with a condition score of 3.2, and notes that a healthy upstream switch could isolate the section during repairs.
Then: what else should we worry about? “Rank our worst transformers for maintenance.” The ranking blends four signals: condition score (35%), percentage of expected life consumed (30%), inspection staleness (20%), and an over-life penalty (15%). Because that blend lives in the semantic layer, Operations, Finance, and the board all see the same ranking, not three versions of it. It also surfaces a substation where several top-ranked transformers are concentrated, which is the kind of pattern that supports a coordinated maintenance campaign.
And where is the spatial risk? “Which aging assets sit within 500 meters of a failure in the last 24 months?” The native geospatial layer returns 11 assets, ten of them co-located with an outage, grouped by priority. Poles show up next to transformers, a good reminder that asset risk isn’t only about the equipment that gets the attention.
Every answer shows its work. Each figure links back to the governed tables it came from. That’s the difference between an AI answer and an answer you can put in front of a regulator.
The same model also supports reliability indices such as SAIDI and CAIDI (per IEEE 1366) and 15-minute interval load analysis, all inheriting the same access controls and citations.
When the Model Needs to Grow
A model is only useful if it can keep up. In the demo, we asked CoCo to add an AMI interval-data ingestion pipeline into the measurement domain. Before proposing anything, it read the existing schema and RBAC roles. That’s the difference between a generic coding agent, which generates something plausible, and one that can see what’s actually there and generates something that runs.
The plan was the one an experienced data engineer would draft: a landing stage, a validation layer, a conformance step into the existing interval table, a rejected-rows audit table with reason codes, and an extension of the semantic view. In the test run, 13 raw rows landed, 8 passed validation, 5 were rejected with reason codes, and 7 conformed after deduplication.
The agent planned, wrote, ran, and tested; the human reviewed and decided, and most importantly, nothing landed in the model without review. Then the loop closed. Asked to analyze one meter’s September interval data, CoWork answered from the new pipeline using the same semantic view and citations. It also reported plainly that only 2 of 96 expected intervals had made it through, and pointed to the rejected row and its source file. An answer that shows its gaps is an answer you can trust.
Utility and Energy Regulations in the US and Canada
Regulators on both sides of the border are asking utilities for more data, in more standardized forms, with clearer evidence of where it came from. The details differ by jurisdiction, but the common thread is that definitions, lineage, and consistency matter. That’s exactly the ground a CIM covers.
United States
Reliability Reporting: State commissions commonly require annual reliability reports built on IEEE 1366 indices. California’s reports, for example, cover SAIDI, SAIFI, MAIFI and CAIDI, with ten-year trends and a summary list of major event days. Requirements vary by state. Missouri’s rule calls for circuit-level SAIDI values and for circuits to be identified and ranked using SAIFI, while Minnesota asks utilities to report SAIDI and SAIFI by work center and explain how they normalize their reliability data. A long-running Lawrence Berkeley National Laboratory review of state filings found that differences in reporting practices and conventions make comparisons among utilities difficult. When the definition of an outage or a major event day is modeled once, those reports become repeatable instead of reconstructed every year. (Source)
Transmission Planning and Interconnection: FERC Order 1920 on long-term regional transmission planning is still moving through implementation. Compliance filings have been staggered, with some regions filing in late 2025 and interregional coordination filings extending to mid-2027, and regional planners describe new data-sharing and transparency requirements. Planners are also expected to show what data went into a plan and why, which is harder when inputs and assumptions are spread across separate tools and teams. Order 2023 on interconnection raises a similar theme. A commonly cited compliance risk is inconsistent project data or late updates that trigger restudies, added cost, and delay. A shared model of assets, network topology, and projects gives those teams one consistent source. (Source)
Water and Drinking Water Compliance: For water utilities, the Lead and Copper Rule Improvements and the revised Consumer Confidence Report rule put account-level service line inventories and decade-scale tracking at the center of compliance. In the CIM approach, those inventories are modeled at customer-account grain.
Funded Programs: Grid resilience grants, state formula grants, and water loans carry performance and subaward reporting terms. A governed outage, asset, and reliability model is a practical way to meet them. Program rounds and rules change, so confirm current requirements with the administering agency.
Cyber Boundaries: Bulk electric system assets also fall under NERC CIP cybersecurity standards. The CIM approach is designed to sit in the analytics layer, with agents working against governed data in Snowflake rather than reaching into operational control systems.
Canada
Customer Data Access in Ontario: Under Ontario Regulation 633/21, distributors must make customer energy data available in Green Button format. In September 2026, the Ontario Energy Board opened a province-wide survey (EB-2026-0230) covering usage levels, data quality and availability, and platform performance and reliability, in response to a December 2025 Letter of Direction from the Ministry of Energy and Mines. Clean, consistent interval and billing data feeds directly into that experience, and it’s the same measurement domain our AMI pipeline example builds out. (Source)
Reliability Reporting: The OEB has also introduced voluntary feeder-level reliability reporting by distributors, alongside customer-specific reliability information, and noted that 27 distributors already collect feeder-level reliability data. A model that already connects outages to feeders, devices and customers turns that level of reporting into a query instead of a project. The OEB’s compliance reviews also look at reporting obligations under various codes, alongside Green Button implementation. (Source)
Cyber Security: Bill C-8 received royal assent on 15 June 2026 and enacts the Critical Cyber Systems Protection Act, which requires designated operators in the finance, telecommunications, energy and transportation sectors to protect their critical cyber systems. It is being implemented gradually, with provisions coming into force in phases. Designated operators must establish a cyber security program, including management of supply chain and third-party risk, and commentators highlight incident reporting and third-party risk as areas moving into a formal regulatory framework. The Act covers federally regulated operators, and many distribution utilities are provincially regulated, so applicability varies. The direction is still clear: organizations will want to show who and what can access which systems, and what changed. Governed access, logging and auditability on the data platform support that conversation. (Source)
Privacy: Customer data is also subject to federal and provincial privacy law, such as PIPEDA and Quebec’s Law 25. Role-based access and masking at the platform level help keep customer information appropriately scoped, including when an agent is the one asking.
What They Have in Common
Across both countries, the expectations rhyme: consistent definitions, traceable numbers, clear access controls and evidence of what changed. A CIM doesn’t replace a compliance program, and it doesn’t by itself satisfy any specific rule. What it does is give that program a single, governed place to draw from, which is why it tends to make regulatory work easier, not heavier.
Why Agents Need a Model Underneath Them
AI is one of the highest-value consumers of a CIM, but it is not the only reason to build one. Here’s the part most AI programs get backwards: the agent is rarely the bottleneck. What makes or breaks it is the quality of the data underneath and the guardrails that decide what it’s allowed to do. An agent that doesn’t know what “customer” means will confidently give you one of three wrong answers. (For a deeper look at how agents work, see our guide to agentic AI.)
This is how we think about our Human Orchestrated Model™ (HOM). The CIM is the Intelligence Foundation: one governed definition of the utility. Human in Command shows up in the build, where agents propose and people decide, and in the boundary that keeps agents working on governed data rather than on operational systems like the OMS or SCADA. Performance Steering follows because every answer is cited, measurable and consistent, so the organization can see what’s working and improve it.
Good controls aren’t brakes. They’re what let you move faster and stay trusted while you do it. In practice, that means least privilege access, human review of consequential changes, and a complete audit trail of what the agent did. Humans orchestrate. Agents execute.
Limitations and Trade-Offs
We won’t pretend this is effortless, and being upfront about the trade-offs is part of getting the value.
It’s only as good as your source data. A CIM makes gaps visible, which is a feature, but someone still has to fix them. In our demo, the cited answer plainly reported the missing intervals rather than hiding them.
Mapping takes real work. Aligning OMS, CIS, GIS, MDMS and asset data to a common model requires input from the people who know those systems best.
It needs stewardship. Definitions and scoring logic live in the semantic layer, so somebody owns them. That’s governance doing its job, not overhead.
Consumption needs discipline. Snowflake is consumption-based, so teams benefit from sizing warehouses and setting auto-suspend thoughtfully from day one.
It complements operational systems. A CIM doesn’t replace your GIS, OMS, ADMS, CIS, MDMS or SCADA. It provides a common representation across them, making their data interoperable and consistently reusable by downstream applications, reporting, analytics and AI.
Our demo is a demo. The numbers in this article come from a reference environment. Your estate will have its own shape, which is why we map it before we model it.
None of this is a reason to wait. It’s a reason to be deliberate about where you start.
Best Fit: utilities (electric, water, or both) with data spread across several systems, reporting obligations that pull from more than one of them, and an interest in agentic AI that stays governed. Municipals, co-ops and public power districts with small data teams often see the most leverage, because the model and the agents do the heavy lifting while people review.
How to Start: A 5-Step Guide
The good news is that getting this right is a sequence, not a guessing game.
Pick the question, not the technology. Start with a few high-value questions your teams struggle to answer consistently (outage impact, asset priority, a regulatory report). Resist the urge to model everything at once.
Scan the estate. Map your systems (MDMS, CIS, OMS/ADMS, SCADA, LIMS), your governance posture and your Snowflake footprint. You can’t model what you haven’t found.
Build the common foundation. Map the relevant source systems into shared CIM entities and relationships, define the terms once, and land the data in governed tables with validation and lineage. Design it for reuse: the same model should be able to support system interoperability, reporting, analytics, and AI rather than another single-purpose solution.
Set the controls before you scale. Decide who can see what, where a human approves versus monitors, and turn on logging from day one. These aren’t a final step. They’re what let you expand with confidence.
Prove it, then grow. Ask the first questions in plain language, check the answers against what your experts know, and then extend to adjacent domains, with CoCo helping to build and people reviewing.
The Bottom Line
A Common Information Model isn’t a demo trick or simply an AI enabler. It is an interoperability foundation. Model the utility once and govern it once, and upstream systems can map into a common representation while downstream applications, APIs, reports, dashboards, regulatory filings and agents draw from the same definitions and relationships.
That is the compounding value of CIM: interoperability creates the governed truth; reporting, analytics and AI create value from it. That’s what turns three answers into one, and it’s what makes AI something a utility can put in front of a regulator.
The advantage goes to the organizations that treat their data foundation as the starting point instead of the cleanup phase. Start grounded and scoped, and the path to governed, agent-ready operations is well within reach.
How Keyrus Can Help
At Keyrus, we help organizations move from experimental AI to industrialized AI, from isolated agents to orchestrated systems, and from insight to execution. This is the discipline we call being an Architect of Intelligence: designing the Operating System of the intelligent enterprise, where intelligence is embedded into the core of business processes to create sustainable value. We operationalize intelligence.
Powered by our proprietary Human Orchestrated Model™ (HOM), we architect reliable Intelligence Foundations, Human in Command governance, and Performance Steering. With 30+ years of expertise and 2,800 people across 28 countries, and as a Snowflake partner, we work alongside your team from vision to operational value:
Find the use cases: We help you spot the outage, asset, network, and customer questions that pay off first, and steer you away from the ones that aren’t ready.
Build the foundation: The Common Information Model, semantic layer, and data quality your agents depend on.
Put the controls in place: Access, audit trails and human-in-the-loop checkpoints, mapped to the regulations you answer to.
Enable your team: So your people can supervise, extend and trust the systems doing the work.
The usual first step is an Agentic Readiness Assessment: a scan of your data estate, a gap map against the CIM, and a ranked shortlist of use cases with a sequenced plan. Where the priority is already clear (meter-to-cash data quality, regulatory reporting readiness, revenue protection analytics, or a Snowflake utility landing zone), we can go straight to a focused engagement.
Want to see it against your own use cases? Contact us to book a 20-minute live walkthrough of outage, asset, network and customer questions.