Add Your Heading Text Here
Add Your Heading Text Here
A trillion-dollar buildout runs on requirements. Keep every one provable.
The largest grid expansion in a generation is colliding with the heaviest compliance regime in industry. Modern Requirements gives utility engineering, OT, and compliance teams one governed requirements thread inside Azure DevOps — from interconnection obligation to commissioned asset, from CIP control to audit-ready evidence, provable at any point in time.
Modern Requirements4DevOps · Copilot4DevOps · Agents4DevOps — deployed inside your boundary, including Azure DevOps Server for OT-segmented and air-gapped environments.
✓ Obligation → requirement → settings → test → evidence: one thread, energization to audit.
Coverage computed from live link data — the energization answer, before the walkdown.
The challenge
Record buildout. Record compliance burden. The same engineering teams.
Utilities are being asked to execute the largest capital program in their history while the compliance regime tightens underneath them — and the requirements record that both depend on is, at most utilities, a set of design-basis documents in Word, settings in vendor tools, and evidence in whoever-ran-the-test's inbox.
Utility capex, 2026–2030 — a record
Data-center-driven demand has utilities underwriting the largest buildout in a generation. Every dollar of it lands as engineering requirements someone must trace.
NERC CIP penalty ceiling — per violation, per day
Compliance is mandatory, audits are routine, and the evidence burden is heavy. Three major CIP updates reshape 2026 alone.
of giga-scale data center load arriving 2026–27
Sixteen giga-scale projects are landing on interconnection queues FERC has ordered reformed — compressing engineering timelines that were already breaking.
of rework cost traces to requirements errors
On a capital project, the most expensive defects were written into the design basis months before procurement — and surface at commissioning.
More projects than the engineering bench has ever carried
Substations, transmission lines, generation interconnections, grid-modernization programs — all running in parallel, all flowing requirements to EPCs and vendors as PDF packages, all returning evidence as email attachments. The program grows; the method doesn't scale. The projects that slip are rarely short of money — they're short of a record everyone can trust.
CIP evidence assembled by fire drill
CIP-003-9 enforcement live since April. CIP-012-2 since July. Internal network security monitoring phasing in through 2030, and eleven updated standards for virtualization landing by 2028. Every one of them is an evidence obligation — and at most utilities, audit prep still means weeks of reconstructing what the record should have known all along.
A settings change is never just a settings change
On energized equipment, a relay setting, a logic change, or a firmware update carries reliability, safety, and CIP consequences simultaneously. When the trace lives in spreadsheets and vendor tools, the management-of-change review works from a hand-built impact estimate — and the deviations that slip through are the ones the auditor, or the event report, finds.
Projects end. Assets live for forty years.
The design basis, the as-built configuration, the test evidence — assembled at enormous cost during the project, then handed to operations as a document dump that starts aging the day the asset energizes. Twenty years later, someone modifying that substation is reverse-engineering intent from drawings. The thread that survives the handover is the one that was never a document to begin with.
Everything on this page runs on three Modern Requirements products
All native to Azure DevOps — cloud or Azure DevOps Server inside your OT boundary. Start with the foundation; add the layers as your program needs them.
Exigences modernes4DevOps
The governed requirements record: design-basis Smart Docs, live traceability, as-built baselines, MOC-ready change control, review management with e-signatures.
See the foundation → The AI layerCopilot4DevOps
Governed AI on that record: decompose interconnection obligations, score requirement quality, assess change impact — with BYO-LLM and on-prem AI for OT-segmented environments.
See the AI layer → The agents layerAgents4DevOps
Agents that run the routine work — CIP evidence patrols, coverage checks before energization, audit package assembly — under policy controls, with human sign-off.
See the agents layer →Next: the asset lifecycle, the safety loop, and the compliance clock running on both.
Next: The lifecycle →The lifecycle
Assets live for forty years. The record has to live longer.
Two lifecycles govern a utility's engineering: the functional-safety loop that never closes, and the asset lifecycle that outlives everyone who worked on the project. Both keep asking the same question — what was this required to do, what changed, and where's the evidence — and both get their answer from the same governed record.
Functional safety
lifecycle
Hazard & risk assessment
Safety functions allocated (SIL)
Design & engineering
Install, commission & validate
Operate, maintain & proof-test
Modify or decommission
The safety loop is only as strong as its trace
IEC 61511 calls it the safety lifecycle for a reason — every stage depends on the one before it, and a modification re-enters the loop at stage one. A safety function whose SIL rationale, design basis, and proof-test evidence live in three different systems isn't a lifecycle. It's a liability with paperwork.
In Modern Requirements, every station is a governed work item: the hazard traced to the safety function that mitigates it, the SIL carried through design, and the validation and proof-test evidence linked at execution depth. When a modification reopens the loop, it reopens with its full history — analysis, decisions, signatures — on one thread.
One requirements thread, across the asset lifecycle
From the interconnection application to the decommissioning plan, the asset keeps asking questions of the record — long after the project team has dispersed. Baselines at every stage keep the answers immutable; the thread keeps them current in between.
Plan & permit
Obligations from interconnection agreements, standards, and permits captured as traceable items
Design & engineer
Design basis decomposed, allocated to disciplines and vendor packages
Procure & build
Vendor and EPC requirements flowed down with evidence return paths
Commission & energize
FAT/SAT at step depth; as-built baseline locked at handover
Operate & maintain
MOC changes impact-assessed against the living as-built record
Repower or decommission
Forty-year-old design intent answered from the record, not the archive
Why utilities invest here now: a record $1.3 trillion capital program is landing on interconnection queues FERC has ordered reformed, while the CIP evidence burden grows every year — up to $1M per violation per day at the ceiling. The utilities that scale through this decade are the ones whose requirements, changes, and evidence live on one queryable thread — because the buildout and the audit are drawing from the same record.
Next: the five governed workflows that run utility engineering day to day.
Next: Workflows →Governed workflows
Five workflows that run utility engineering
Each workflow is enforced inside Azure DevOps. Every state has an owner, every transition has a rule, and every approval is logged with an immutable audit trail. They ship as the energy & utilities configuration of Modern Requirements4DevOps.
Capital project requirements & allocation
From interconnection obligation to vendor package with nothing lost in translation. Obligations from agreements, standards, and permits are captured as structured items, decomposed into the design basis with trace intact, and allocated to disciplines, EPCs, and vendors — each allocation carrying its verification method from birth.
Obligation captured
Interconnection, standard, and permit clauses as items
Design basis derived
Requirements quality-scored before approval
Allocated
Electrical, P&C, civil, OT — interfaces defined
Flowed down
Packages with rationale, V&V method, evidence return path
Validated
Right requirement, right level — e-signed
Baselined
Design basis immutable; flowdown status computed live
Management of change
Change on energized equipment, with the impact analysis done before the review convenes. Suspect links flag every requirement, safety function, CIP control, and test a proposed change touches — so the MOC board decides on computed impact, and the configuration baseline explains every state the asset has ever been in.
Change proposed
Linked to the items it proposes to modify
Impact computed
Suspect links across safety, CIP, and test items
Impact assessed
Reliability, safety, and compliance consequence recorded
Approved
E-signed with rationale — identity, timestamp, meaning
Implemented
Flagged tests re-run; evidence attached
Baseline updated
As-built current; difference report auto-generated
Safety instrumented systems V&V
The functional-safety loop as a governed thread: hazards assessed, safety functions allocated with SIL, and every function carried through design, validation, and the proof-test schedule — with evidence rigor matched to the integrity level and the safety case assembling from live links.
Hazard assessed
HAZOP/LOPA findings logged with context
SIL allocated
Safety function derived, integrity level assigned
Designed
SIS design items linked at the assigned level
Validated
Site validation at step depth; evidence attached
Proof-tested
Recurring tests tracked against the schedule
Safety case current
Claim-argument-evidence from live links
NERC CIP compliance evidence
The workflow that keeps the audit from being a fire drill. BES Cyber Systems categorized, CIP controls living as traced requirements with implementation and verification evidence attached, configuration baselines monitored for deviation — and the RSAW answered from a filtered view of live data.
Assets categorized
CIP-002 impact rating mapped to systems
Controls derived
CIP requirements as first-class work items
Implemented
Config changes linked with IDs under MOC
Evidence verified
Test results and config snapshots attached
Monitored
Baseline deviations flagged; self-reports governed
Audit-ready
RSAW responses generated from live links
Commissioning & handover
The workflow that decides whether operations inherits a living record or a document dump. Factory and site acceptance tests execute at step depth against the requirements they verify, punch items track to closure as work items, and energization locks an as-built baseline that operations keeps current through MOC — the same thread, four decades forward.
FAT executed
Factory tests linked to requirements at step depth
SAT executed
Site verification with evidence attached
Punch list closed
Deficiencies tracked as work items to closure
Energization review
Coverage computed; readiness e-signed
As-built baselined
The record operations actually inherits
Living handover
MOC keeps the same thread current for the asset's life
Next: every framework a utility answers to, mapped to capability.
Next: Compliance →Compliance
Every framework a utility answers to, mapped to capability
From grid reliability to functional safety to OT cybersecurity, Modern Requirements maps the artifacts in your Azure DevOps environment to the frameworks below — obligation by obligation.
| Framework | What it governs | How it's covered inside Azure DevOps |
|---|---|---|
| NERC CIP (002–015) | Cybersecurity and physical security of the Bulk Electric System — mandatory, audited, penalties to $1M/day per violation | CIP controls as traced requirements with implementation and verification evidence — RSAW responses from live links, baseline deviations flagged under MOC |
| IEC 61508 | Functional safety of E/E/PE systems — SIL-rated safety functions | Safety functions as traceable items with SIL attributes and verified evidence per lifecycle phase |
| IEC 61511 | Safety instrumented systems for the process sector — the safety lifecycle | Hazard-to-proof-test trace: HAZOP findings to safety functions to validation and recurring proof-test evidence |
| IEC 62443 | Industrial automation and control system security — zones, conduits, security levels | OT security requirements traced alongside functional requirements, through the same MOC and evidence rails |
| IEC 61850 | Substation communication and automation | Protection and automation requirements traced to settings, logic, and SAT evidence per bay and device |
| ISO 55001 | Asset management — value from assets across their life | The requirements thread as the engineering backbone of the asset record — design intent queryable for the asset's life |
| 10 CFR 50 App. B | Nuclear quality assurance — design control, document control, audits | Design control evidence generated from live work-item history: reviews, approvals, changes, and verification per criterion |
| ISO/IEC/IEEE 15288 · 29148 | System life cycle processes and requirements engineering | Requirement items carry 29148-aligned attributes, quality-scored against INCOSE characteristics before review |
| EIA-649 | Configuration management — identification, control, status accounting, audit | Immutable baselines, difference reports, as-built control — status accounting as a query over live data |
| FERC orders & interconnection | Interconnection agreements, reliability directives, reform orders | Obligations captured as traceable items at project start — every clause lands somewhere, and the somewhere is provable |
Every mapping is bidirectional. Pick an obligation, see which artifacts satisfy it. Pick an artifact, see which obligations it serves. When the regional entity auditor, the safety assessor, or the interconnection counterparty asks "show me," the answer is a filtered view of live data — not a binder someone maintains.
Next: the foundation, the AI layer, and the agents layer.
Next: The platform →The foundation · Modern Requirements4DevOps
One thread, from obligation to as-built evidence
Modern Requirements4DevOps makes every artifact below a real Azure DevOps work item or a Modern Requirements virtual work item. The links are live. Nothing is exported, synced, or reconstructed — the document is a view of the data, not a copy of it.
Design-basis documents built from work items
Author the documents a utility runs on — design-basis memoranda, protection philosophies, functional specs, vendor requisition packages — as structured documents where every clause is a traceable, versioned work item. Word and Excel imports bring legacy design bases in with hierarchy intact.
Configuration control that matches how assets live
Freeze any work-item set into an immutable baseline at every stage — design freeze, energization, each MOC — and compare any two with a difference report. Variant management keeps fleet configurations side by side, each substation or unit with its own traceable set.
Traceability into test execution, not just test plans
Horizontal and vertical matrices generated on demand from live link data — obligation down to the SAT step that verifies it. Virtual work items extend the trace into execution depth: Test Point, Test Run, Test Result, Test Step Run. Energization coverage is computed, not claimed.
MOC and energization reviews where the work lives
Formal review cycles with item-by-item navigation, threaded findings, and e-signatures bound to work-item versions — who approved what, at which revision, with complete history. Smart Report turns the same live data into design, trace, and compliance reports in minutes.
Built inside Azure DevOps. Deployable inside your OT boundary.
Many requirements tools connect to Azure DevOps. Connection means synchronization — and synchronization is where threads break, baselines fork, and audit findings are born.
External RM tool, synced to Azure DevOps
- Two systems of record; sync jobs decide which one is true today
- The thread crosses a tool boundary — matrices exported and rebuilt per audit
- A new SaaS surface to clear through OT security review — often a non-starter
- Engineering works in one tool, requirements live in another — drift is structural
- Evidence assembled per audit: weeks of reassembly, every time
Modern Requirements, native in Azure DevOps
- One system of record — requirements are work items, links are link data
- The thread spans obligation → design → configuration → test execution in one graph
- Lives inside your boundary — cloud or Azure DevOps Server, inheriting your identity and network segmentation
- Engineers never leave their environment — the thread maintains itself as work happens
- Evidence is continuous: audit and energization packages generate from live state in minutes
The AI layer · Copilot4DevOps
AI that clears your OT security review, not just your demo
Critical infrastructure doesn't get to use AI that ships operational data to an uncontrolled endpoint. Copilot4DevOps puts AI-assisted requirements work inside Azure DevOps — with deployment options built for segmented and air-gapped environments — so every generated artifact lands in the managed lifecycle with authorship, review, and trace links intact.
Decompose
Turn an interconnection clause or design-basis statement into complete, well-formed requirements — structured, linked to their parent, ready to allocate, in a single click. The engineer reviews and accepts; the decomposition arrives with its trace already built.
Analyze quality
Every requirement scored against INCOSE requirement-quality characteristics — ambiguities flagged with concrete rewrites before review. An ambiguous design-basis statement caught at authoring costs minutes; caught at commissioning, it costs the outage window.
Change impact
Real-time impact assessment over your actual link graph — the full ripple of an MOC across safety functions, CIP controls, and tests before the board convenes. The review meets with the analysis done, not to commission it.
Diagrammation
Generate flow and logic diagrams directly from requirements to validate shared understanding fast — linked to live work items and always current, from protection schemes to interlock logic.
The agents layer · Agents4DevOps
The routine work of the thread, executed by agents. Engineers approve.
Agents4DevOps runs the repetitive, high-volume work a utility generates — CIP evidence patrols, coverage checks before energization, audit package assembly — under policy controls you define, with an engineer's decision at every consequential step.
CIP evidence patrols
Agents patrol the compliance thread continuously: controls drifting from their evidence, configuration baselines with unapproved deviations, proof-tests aging past schedule, self-report items awaiting action — surfaced and packaged weeks before the audit notice, not after it.
Energization & audit package assembly
One prompt assembles the energization readiness package, the RSAW evidence set, or the safety-case update — design basis, trace matrices, coverage reports, baselines, and signed approvals pulled from live data, validated, and staged for human review.
Flowdown & coverage patrols
Vendor packages without returned evidence, requirements without verification methods, safety functions without current proof-tests, broken traces after an MOC — flagged and drafted into tracking items long before the gap becomes a finding.
Plain-English commands that act
Tell it "show every CIP-010 baseline deviation without an approved change record, and draft the remediation items" — and the agent queries the live thread, creates the items, and stages the output for engineering review.
A capacity multiplier for your best engineers, not a replacement for them. Agents execute under policy controls you define; engineers review, decide, and sign. Every agent action runs through governed accounts and the same audit trail as everything else in the system.
Next: six roles working inside one asset thread.
Next: Who it's for →Who it's for
One asset thread. Six roles working inside it.
Every workflow on this page has named owners because that's how a utility actually runs — engineering owns the design basis, the MOC board owns the baseline, compliance owns the RSAW. Here's what each role does inside the same system, instead of in six disconnected tools.
Owns the design basis, not the spreadsheet
Engineers own the design basis, allocations, and interfaces. Requirements are authored as traceable items with parent links from birth, Copilot drafts the tedious parts, and "where does this interconnection clause land?" is answered by the trace tree, not a matrix rebuild.
Status accounting as a query
Program managers own the milestones, the baselines, and the answer to "where are we, really?" across a portfolio of parallel projects. Readiness packages assemble from live data, difference reports write the change story, and vendor flowdown status is computed from links — not compiled from emails.
Change on a live grid, with the record intact
OT engineers own the settings, logic, and firmware that keep the grid stable. Every change rides MOC with computed impact, configuration baselines stay current by construction, and the CIP consequences of a change are visible before it's made — not discovered at audit.
An RSAW answered from live data
Compliance owns the categorization, the controls, and the audit. Every CIP control traces to its requirement, implementation, and evidence; baseline deviations surface as they happen; and the self-report decision is made over a queryable record instead of a reconstruction.
The safety case that stays current
Safety engineers own the HAZOP findings, the SIL allocations, and the proof-test schedule. Integrity levels flow through decomposition automatically, evidence rigor tracks the level, and a modification reopens the loop with its full history — analysis, decisions, signatures — attached.
Energization on computed coverage
Commissioning owns FAT, SAT, and the punch list. Tests execute at step depth against the requirements they verify, deficiencies track to closure as work items, and the energization review runs on coverage that's computed — then locks the as-built baseline operations will live with.
Next: guides and a blog to go deeper.
Next: Resources →Resources
Go deeper on energy & utility compliance.
Guides and a blog on functional safety and OT cybersecurity for energy & utility teams in Azure DevOps — IEC 61508, NERC CIP, IEC 62443 and NIS2.
Next: the 90-day rollout and the questions strong buyers ask.
Next: Getting started →Implementation
A use-case-driven rollout, not a platform project
We don't turn on the full platform on day one. The rollout starts with one requirement thread on one project, traced end to end, so the team experiences a real win in the first sprint — and by day 90, holds an audit-ready evidence package.
One thread, end to end
- Deployed into your Azure DevOps — cloud or Server, inside your boundary
- One obligation traced to verified test evidence
- Smart Doc structure mirrored from your design-basis documents
- First trace matrix in the chief engineer's hands
Requirement set moved in
- Active design basis imported from Word/Excel as structured items
- Legacy IDs preserved as attributes
- MOC and review workflows live with e-signatures
- First Copilot4DevOps quality scores on the backlog
Role-based training, four tracks
- Engineering — Smart Docs, decomposition, allocation
- OT & compliance — MOC, baselines, control trace
- Safety — SIL flow, proof-test tracking
- Commissioning & PM — FAT/SAT depth, status views
First evidence package
- Audit- or energization-style package assembled by Agents4DevOps
- Coverage dashboard live at the current baseline
- Internal mock review run against the package
- Package exported for your next real audit or gate
What "audit-ready" means, measurably
Full bidirectional trace on at least one requirement family · the active design basis migrated with MOC workflow live · and an evidence package generated from live data that passes an internal mock review.
The questions strong buyers ask
What a decision maker will want answered before talking to anyone
The questions chief engineers, OT leads, and compliance managers actually ask when they evaluate a system that will hold their asset thread. Straight answers, including where the honest answer is "that stays in your EAM or GRC."
Our OT networks are segmented / air-gapped. Can this run inside our boundary?
The architecture is designed for it: Modern Requirements runs inside your Azure DevOps environment — including Azure DevOps Server for on-premises and disconnected deployments — inheriting your identity model, permissions, and network segmentation rather than adding a new SaaS surface to clear through OT security review. For the AI layer, Copilot4DevOps supports bring-your-own-data, bring-your-own-LLM, and on-prem AI configurations, so AI assistance doesn't mean operational data leaving your boundary. [CONFIRM with product: supported Azure DevOps Server versions and current on-prem AI deployment options]
Does this make us NERC CIP compliant?
No tool makes you compliant, and you should distrust any that claims to. What Modern Requirements does: it makes your compliance demonstrable — every CIP control traced to the requirement it satisfies, the implementation that delivers it under MOC, and the verification evidence behind it. Your compliance program, categorizations, and regional-entity relationships stay yours; the requirements thread is where the engineering evidence behind them lives. With three standards changing in 2026 alone and eleven more by 2028, a queryable record is also your hedge: new obligations become a gap query and staged requirements, not a program restart.
Does this replace our EAM (Maximo / SAP)?
No — and the boundary matters. Your EAM owns the physical asset register, work orders, and maintenance execution. Modern Requirements owns the engineering requirements thread: what the asset was required to do, why, how the design satisfies it, and the verification evidence that it does — living where the engineering work happens. The two meet at the asset: the as-built baseline and its evidence are the engineering record behind the asset your EAM manages. Utilities that try to run requirement-level traceability inside an EAM are usually the ones reverse-engineering design intent from work-order history.
We work through EPCs and vendors. How do external parties fit the thread?
Flowdown with a return path. Vendor and EPC packages generate from the live thread — each requirement with rationale, verification method, and acceptance criteria — and returned evidence links back to the exact items it verifies, whether the vendor works inside your Azure DevOps under scoped permissions or delivers documents that are attached and traced. The difference from the status quo: vendor evidence lands on the thread it answers, not in a project inbox — so energization coverage includes the supply chain, not just your own scope.
We have nuclear assets. Does this hold up under 10 CFR 50 Appendix B?
The mechanics map directly to the criteria: design control through governed requirements and reviews, document control through versioned Smart Docs, control of design changes through the MOC workflow with e-signatures, and audit support through generated evidence packages — all with the immutable history Appendix B programs expect. Your QA program defines the procedures; the thread executes and evidences them. [CONFIRM with product: existing nuclear customer references and any NQA-1 positioning]
We're on DOORS / legacy RM. What does moving look like?
Staged by project, not big-bang. Word and Excel imports bring structured requirement sets into Smart Docs with hierarchy intact, and existing IDs are preserved as attributes so references in agreements and past submissions stay resolvable. Most utilities start with an active capital project and keep legacy programs read-only until retirement. Coexistence is normal for a season; two live systems of record for the same asset is the thing to avoid. [CONFIRM with product: ReqIF import support and current DOORS migration tooling]
What do auditors actually receive?
Documents — because audits still run on documents. Smart Report produces design-basis reports, horizontal and vertical trace matrices, coverage and gap reports, baseline difference reports, and approval histories with signature records, formatted for your reviewer — including RSAW-structured evidence sets for CIP audits. The difference from the status quo isn't the format the auditor sees — it's that the document is a report of the thread's state, so it never disagrees with the system it came from.
Ready? Scope an energy & utilities working session with our team.
Book a working session →Talk to us
See it on an asset shaped like yours
A working session with our energy & utilities team — in a demo environment preloaded with a design basis, MOC workflow, CIP control trace, and FAT/SAT evidence. Your standards, your vocabulary, your boundary constraints.
- Walk one thread end to end: obligation → design basis → vendor evidence → as-built baseline
- Run a live MOC impact assessment and watch the suspect links land across safety and CIP items
- Watch an audit evidence package assemble from live work-item data
Prefer to look before you talk? Watch the five-minute technical demo — Smart Docs authoring, live traceability into test execution, and e-signature review workflows, screen-recorded in the live product. Watch the demo — no form →
Book an energy & utilities working session
Tell us about your program. We'll come prepared with your standards, not a generic tour.
