Protection Settings Governance with AI: Versioning, Peer Review, and Change Evidence

Protection settings are not just numbers in a relay file. They are the executable result of a study case, a coordination decision, a peer review, a field implementation, and a record that someone may need to reconstruct after a trip. AI can make that chain easier to search and harder to leave incomplete. It cannot be the engineer who approves the change.

Start with explicit setting states

Use a controlled vocabulary and do not overwrite history. A practical set is:

State	Meaning	Evidence that should remain attached
Pending	Proposed value not yet implemented	Change request, study basis, rationale, affected assets
As-specified	Approved design value	Signed calculation, coordination review, external communications
As-found	Value read from the relay before work	Downloaded file, date/time, relay identity, operator
As-left	Value recorded after implementation	Downloaded file or test report, date/time, restoration check
In-service	Current documented operational baseline	Approval, validation date, source and status
Archived	Historical value no longer current	Prior record retained, never deleted or silently replaced

The U.S. Bureau of Reclamation’s FIST Volume 6-4 is a useful public example of this discipline. It distinguishes pending, as-specified, as-found, as-left, in-service, and archived records and ties settings work to peer review and coordination. A utility’s own procedure governs, but the state model is broadly useful.

Build a change packet before asking AI to review it

Every proposed change should carry the reason for the change, the initiating event or project, the study-case and short-circuit model versions, topology, CT/VT data, relay model and firmware, affected setting groups, coordination curves or tables, loadability checks, protection philosophy, communication-assisted logic, and the planned test cases. Include the current in-service file and the proposed file as separate, identifiable artifacts.

AI can inspect that packet for completeness. It can say that a proposed distance reach has no stated line parameter source, that a transformer differential change lacks vector-group context, or that a new setting group has no test plan. It can produce a structured diff and draft questions for the reviewer. It must not supply a missing assumption from a generic example or silently “correct” the setting file. ProtectionAI’s standards context is a useful place to distinguish implemented calculation, readable file format, and standards reference.

NERC PRC-027-1 provides the coordination context for protection systems during faults and identifies evidence expectations around settings-development processes. The exact applicability and compliance interpretation belongs to the entity and its compliance program. The governance lesson is straightforward: the model, source data, reviewer, and decision must be identifiable after the fact.

Make peer review independent and substantive

Peer review is not a button that changes “draft” to “approved.” The reviewer should be independent of the original calculation where the procedure requires it and should check the study assumptions, fault cases, element margins, selectivity, load encroachment, CT/VT performance, communications, breaker timing, firmware, and coordination with interconnected entities. The review should list questions and resolutions, not just a name and date.

AI can prepare the review queue and highlight differences. It can compare an old and new settings file, search the attached study for the equation or input behind a value, and assemble the test points needed to prove the changed function. ProtectionAI is bounded for this part of the workflow: it handles relay/protection test planning, settings evidence, event evidence, deterministic expected-versus-measured results, and report packaging. The relay-test evidence trail is the right companion for preserving the record. The engineer still owns the setting decision and the physical test procedure.

Prove the implementation, not only the approval

After approval, record the implementation window, work authorization, isolation state, relay identity, firmware, as-found settings, change method, as-left settings, restoration checks, test-set identity and calibration, injected quantities, measured results, binary output observations, and any retest. IEEE C37.233’s system-testing frame and Reclamation’s FIST 3-8 both support treating maintenance and field testing as evidence-producing work performed by qualified staff.

The implementation gate should fail closed when the as-left record is missing or cannot be matched to the approved setting version. A signed approval without proof of what reached the relay is a design record, not an in-service record. Store the prior version as archived and keep the new version’s validation date visible.

Handle event-driven changes as a loop

When a relay event or misoperation arrives, first preserve the event record and identify the active setting group. Compare the event with the in-service baseline, not with a later proposed file. If the event points to a coordination issue or protection misoperation, NERC PRC-004-6 supplies the correction context. The result may be a settings change, a test-only investigation, a device repair, a model update, or “insufficient evidence.”

If the event also raises a transformer condition question, a separate approved reference can be carried to AgenticGrid Pro for diagnostic evidence, condition assessment, and a potential maintenance work package. That handoff does not change the relay baseline and does not create an autonomous path between the products.

Keep AI governance inside the engineering process

Map the workflow to NIST AI RMF: govern who may use the assistant and approve outputs; map the operational context and failure modes; measure completeness, disagreement, and reviewer edits; and manage residual risk with hold points and escalation. NIST SP 800-82 adds the OT requirement to protect safety, reliability, and performance while keeping a review tool separate from the control environment.

The useful metrics are evidence completeness, time to an independent review, number of missing assumptions found before implementation, as-left capture rate, repeat-event traceability, and engineer disagreement with the draft. Do not use model fluency as a reliability metric. Settings governance succeeds when the final record is accurate, attributable, and reproducible.

References

1. North American Electric Reliability Corporation. (n.d.). PRC-027-1: Coordination of protection systems for performance during faults. https://www.nerc.com/standards/reliability-standards/prc/prc-027-1
2. North American Electric Reliability Corporation. (2020). PRC-004-6: Protection system misoperation identification and correction. https://www.nerc.com/standards/reliability-standards/prc/prc-004-6
3. IEEE. (2023). IEEE guide for power system protection testing (IEEE C37.233-2023). https://standards.ieee.org/ieee/C37.233/6676/
4. IEEE Power & Energy Society, Power System Relaying and Control Committee. (2023). Practical applications of artificial intelligence / machine learning in power system protection and control (PSRC Working Group C43 report). https://www.pes-psrc.org/kb/report/117.pdf
5. U.S. Bureau of Reclamation. (2022). Management of protective relay settings (FIST Volume 6-4). https://www.usbr.gov/power/data/fist/FIST_6-4_%281-2022%29.pdf
6. U.S. Bureau of Reclamation. (2021). Operation, maintenance, and field test procedures for protective relays and associated circuits (FIST 3-8). https://www.usbr.gov/power/data/fist/FIST_3-8_%289-2021%29.pdf
7. Tabassi, E. (2023). Artificial intelligence risk management framework (AI RMF 1.0) (NIST AI 100-1). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.AI.100-1
8. Stouffer, K., Pease, M., Tang, C., Zimmerman, T., Pillitteri, V., Lightman, S., Hahn, A., Saravia, S., Sherule, A., & Thompson, M. (2023). Guide to operational technology (OT) security (NIST SP 800-82 Rev. 3). National Institute of Standards and Technology. https://csrc.nist.gov/pubs/sp/800/82/r3/final