A Machine May Draft It

Chapter one

What a switching order actually is

A sequence of state changes, each verifiable, executed under a named authority, producing a defined end state that other people's safety depends on.

The four properties

The three roles, and why they are three

Preparation, approval and execution are separate acts by separate people, and the separation is the control. The person who wrote the sequence is not the person who checks it, and neither is necessarily the person standing at the switchgear.

Machine drafting changes exactly one of those three. It changes who prepares. It does not, and must not, change who approves or who executes. Any design in which machine drafting collapses two of the three roles has removed a control, whatever it has added.

What machine drafting is genuinely good at. Completeness against a device list. Consistency of step phrasing. Never omitting the verification step. Never forgetting the restoration sequence. Producing the same quality of order at 03:00 as at 14:00. These are real, and they are the failure modes of tired humans.

What it is not good at. Knowing what is not on the diagram. Knowing what changed on site last week. Knowing that the labelling at this particular substation departs from the convention everywhere else. Chapter 4.

Chapter two

Drafting — and where the machine must stop

The drafter's job is to produce a complete, ordered, fully-specified candidate sequence and hand it to a human with every assumption visible.

What the drafter receives

A drafting request is not a prompt. It is a structured object, and the structure is what makes the output checkable:

A well-formed request carries the site in a canonical identifier rather than free text, the objective, the target equipment as identifiers drawn from the asset register, the specific revision of the one-line diagram the draft is to be prepared against, a reference to the entity's own approved switching practice, and the identity of the requester — resolved from an authenticated session, never supplied as text.

Two of those fields do more work than they look like. The one-line revision makes the draft reproducible and makes it obvious when a draft was prepared against a superseded diagram. The operating practice reference ties the draft to the entity's own approved switching practice — the document the order must conform to — so the approver can check conformance rather than plausibility.

What the drafter produces

Every step must be complete before the order can be submitted, and completeness is specific: an ordered position, a device identified from the asset register rather than invented, the action, the expected state after the action, the method by which the operator confirms that expected state, the provenance of the step, and — where the step was inferred rather than read — the assumption behind it, written out. A step missing any of those is not a terse step. It is an incomplete one, and the register should refuse it.

Provenance is the discipline of EC-WP-1100 applied to a switching order. A step derived from the one-line diagram, a step derived from the entity's approved practice, a step added because the equipment class standardly requires it, and a step the drafter inferred are four different epistemic statuses. An approver reading an order in which all four render identically is checking a document that has concealed the one thing they most need to see.

The design rule. Every inferred step is flagged and carries its assumption in plain language. "Assumed DC combiner fuses present per equipment class; not shown on one-line revision C." The approver can then confirm or delete it — which is a thirty-second decision when the assumption is visible and an undetectable omission when it is not.

The four things the drafter may never write

1. Any identity field. Prepared-by is the requesting operator, resolved server-side from the session, not from anything the drafter produces. Approved-by and executed-by are written only by the approval and execution paths.

2. Any approval state. A draft is created in draft and can reach no other state by drafting.

3. An order number that implies issuance. Numbering is a sequence controlled by the register, allocated at submission — not at drafting. Otherwise abandoned drafts burn numbers out of a sequence that later has to be explained.

4. Its own refusal, as a document. Chapter 6.

Chapter three

Expected state — the field that makes a step verifiable

On the register measured in August 2026, five drafts carried complete step arrays targeting real devices. Expected state was null on every step of every one.

What that means operationally

A step reading "Open the feeder breaker" is an instruction. A step reading "Open the feeder breaker — expected state: OPEN, verify by position indication and voltage absent on the load side" is a control.

The difference is not documentation quality. It is that the second one can fail. An operator who performs the first step and finds an ambiguous indication has no defined criterion for whether the step succeeded. An operator performing the second either gets the expected state or stops.

The last row is where this becomes a compliance question as well as a safety one. An executed switching order with expected states and confirmations is a contemporaneous record of what the plant was doing at each moment of the sequence. Without them it records only what somebody meant to do.

Calculation 1 · Step completeness — refuse at submission

-- No order may be submitted with an incomplete step. -- This runs as a constraint, not as a report. SELECT o.order_id, o.site_id, COUNT(s.*) AS steps, COUNT(*) FILTER (WHERE s.expected_state IS NULL) AS missing_expected, COUNT(*) FILTER (WHERE s.verification_method IS NULL) AS missing_verification, COUNT(*) FILTER (WHERE s.device_id NOT IN (SELECT device_id FROM asset_register)) AS unknown_device, COUNT(*) FILTER (WHERE s.source = 'inferred' AND s.assumption IS NULL) AS unexplained_inference FROM switching_order o JOIN switching_step s USING (order_id) GROUP BY o.order_id, o.site_id HAVING COUNT(*) FILTER (WHERE s.expected_state IS NULL) > 0 OR COUNT(*) FILTER (WHERE s.verification_method IS NULL) > 0 OR COUNT(*) FILTER (WHERE s.device_id NOT IN (SELECT device_id FROM asset_register)) > 0 OR COUNT(*) FILTER (WHERE s.source = 'inferred' AND s.assumption IS NULL) > 0;

Every row that query returns is an order that must not be submittable. Enforce it as a check at the submission boundary rather than as a report somebody reads later — a report describes orders that already exist, and by then the incomplete one may have been executed.

Chapter four

The equipment the diagram does not show

A drafter working from a one-line diagram produces an order that is complete with respect to the diagram. Plants are not complete with respect to their diagrams.

The gap

One-line diagrams are abstractions built for a purpose — usually protection coordination or interconnection study — and they legitimately omit equipment that is not relevant to that purpose but is entirely relevant to isolating a circuit safely.

Direct-current combiner fusing on a photovoltaic site is the canonical example. It is frequently absent from the one-line, and it is frequently exactly what has to be addressed to make a section safe to work on.

A drafter that knows only the diagram will produce an order that reads as complete and omits it. That is a more dangerous output than an obviously incomplete order, because the reviewer's attention is drawn to what is present rather than to what is missing — and human review is far better at catching a wrong step than a missing one.

The requirement this creates. The drafter must draw on two sources, not one: the site-specific model (one-line, asset register, tag list) and a class-standard equipment model that knows what equipment types normally accompany a given configuration regardless of whether the diagram shows them.

Every step originating from the second source is flagged standard_equipment with its assumption stated, so the approver confirms presence rather than discovering absence.

The three-source model

Labelling deserves its own caution, and it is the same lesson as the asset-population finding in EC-WP-1105: naming conventions are not reliable across sites. A drafter inferring device function from a tag pattern will be right at most sites and silently wrong at the one where the convention differs. Device function comes from the asset register's own attributes, never from the shape of its name.

Chapter five

Identity — the one thing content guards cannot guard

A set of privileged functions guarded their content well. One demanded a directive reference before writing a schedule of record. One refused an evaluation interval under five minutes. One refused a priority change with no written reason. Not one of them could guard identity.

The finding

Across the assessed platform, the fields naming who did something — set_by, approved_by, changed_by, responded_by — were strings supplied by the caller.

The functions were careful about everything except the one thing that makes an approval an approval. A function that refuses to write a setpoint without a directive reference, and then accepts approved_by = 'anyone' from whoever called it, has secured the content of the record and left its authorship open.

Compounding it: twenty of those functions ran with elevated privilege, and twelve were called by nothing in the application at all — including one that allocates switching order numbers. A function that nothing calls is a function nobody notices being called.

Content guards test whether the record is well-formed. Only the identity path can test whether it is true.

The rule

An identity field is never a parameter.

It is resolved server-side from an authenticated session, checked against the roster, and written by the platform. A function that accepts an actor name as an argument cannot produce an attributable record, however carefully it validates everything else.

For a switching order this is not a hardening preference. Approval is the control. An order approved by a name that the system accepted on the caller's word has not been approved; it has been annotated.

Calculation 2 · Which of your privileged functions accept an identity?

-- Any function taking an actor-shaped argument is an attribution risk. SELECT p.proname, pg_get_function_arguments(p.oid) AS arguments, p.prosecdef AS runs_elevated, has_function_privilege('anon', p.oid, 'EXECUTE') AS callable_anonymously FROM pg_proc p JOIN pg_namespace n ON n.oid = p.pronamespace WHERE n.nspname = 'public' AND pg_get_function_arguments(p.oid) ~* '(approved_by|set_by|changed_by|responded_by|executed_by|operator|actor|user_id)' ORDER BY p.prosecdef DESC, callable_anonymously DESC;

Read the result in three passes. Functions that are both elevated and anonymously callable are the immediate exposure. Functions accepting an identity argument at all are the design problem. And functions that appear in that list but are called by nothing in the application should be revoked rather than left available — an unused privileged entry point is pure liability.

The three-role separation, enforced

The self-approval refusal in row two is the cheapest control in this document and the one most often absent. Preparer and approver being the same person defeats the separation entirely, and it is a single equality test.

Chapter six

The lifecycle, and what an empty register tells you

Measured on 24 August 2026, one switching order register held twenty rows: thirteen cancelled, seven draft, and zero that had ever reached submitted, approved or executed.

What the register contained

Read rows five and six together, because that combination is the interesting one. Six of seven drafts were titled as tests — and five carried complete step sequences addressing real switchgear at real sites. Test-titled records containing real device operations occupy an ambiguous position that a register should never permit: not clearly exercise, not clearly operational, and indistinguishable from either by anyone reading the table later.

The refusal persisted as a document

One cancelled record contained, as its order body, a language model's refusal to produce the order.

The model behaved correctly. It declined. The defect is entirely in the calling code: a refusal was treated as a successful response and written into the record where an order belongs.

This is the same shape as every failure in this series. A failure that looked like a result. An empty list read as "nothing to do." A timeout read as an answer. A declined generation read as a document.

The rule: a drafting call has three outcomes — an order, a refusal, or an error — and they are three different types with three different destinations. A refusal is surfaced to the requester with its reason and creates no record. Only a validated order is persisted, and validation means passing the completeness check in Chapter 3.

What an empty register means

A register in which nothing reaches a terminal state is telling you one of three things, and it is worth determining which:

1. The capability is not in use. Switching is happening on paper and the register is decorative.

2. The lifecycle cannot be completed. A required transition is blocked or unimplemented, so orders accumulate in draft.

3. It is genuinely new and has not yet carried real work.

All three are legitimate answers. Only the third is safe to leave alone. The first is the most dangerous, because a visible-but-unused safety register creates an impression of control that the organisation does not have — and it will be found by somebody asking for switching records, at which point the answer is that the real records are elsewhere and this system's presence in the navigation was misleading.

The judgement from the assessment, unchanged. Build it properly or remove it from the navigation. A safety register that reads empty is worse than an absent one. There is no acceptable middle position, and the middle position is where these features tend to sit for years.

Calculation 3 · Lifecycle health

SELECT state, COUNT(*) AS n, ROUND(100.0*COUNT(*)/SUM(COUNT(*)) OVER (),1) AS pct, MIN(created_at) AS oldest, MAX(created_at) AS newest FROM switching_order GROUP BY state ORDER BY n DESC; -- The diagnostic that matters: has anything EVER completed? SELECT COUNT(*) FILTER (WHERE state = 'executed') AS ever_executed, COUNT(*) FILTER (WHERE state = 'approved') AS ever_approved, COUNT(*) FILTER (WHERE title ~* '(test|sample|demo)' AND EXISTS (SELECT 1 FROM switching_step s WHERE s.order_id = o.order_id AND s.device_id IN (SELECT device_id FROM asset_register))) AS test_titled_real_devices FROM switching_order o;

Chapter seven

The registers that must exist alongside

A switching order produces an isolated state. Something has to record who is relying on that state, and nothing else in the system did.

What was missing

The second row is the instructive one. An empty table can be filled. A table whose schema cannot express the question cannot — no amount of data entry makes a site access register that lacks arrival and departure columns capable of telling you who is on site.

That distinction is worth carrying generally: before asking whether a register is populated, ask whether its schema can answer the question it exists for. The second failure is invisible in every completeness metric, because a table with no rows and a table with no relevant columns look identical in a row count.

The chain that has to close

Figure 1 · The safety chain, and where it breaks

Switching order — produces a defined isolated state, step by step, verified. → Isolation record — binds that state to a physical control, with who applied it and when. → Clearance — issued to a named person against that isolation, with scope and duration. → Site access — who is on site, under which clearance, arrived when, and whether they have left. → Restoration — clearance surrendered, isolation removed, switching order reversed, end state verified. Every link is a record. A chain with a missing link cannot answer the question the whole chain exists for: is it safe to re-energise? On the assessed system, links two, three and four were absent, so an executed switching order terminated in a state nothing downstream could reference.

Identity, one more time

The switching order identifier was one of six incompatible namespaces addressing the same sites — alongside an internal site key, a forecast slug, a document code, a free-text name and the upstream platform's object identifier.

For a safety register this is not a reporting inconvenience. It means a switching order and the alarms for the same substation may not be joinable, so the question what was alarming while this order was being executed cannot be answered by query. That is precisely the question asked during an event investigation.

Chapter eight

Ten questions for your own switching records

A machine may draft it. A person prepares, a different person approves, a third executes it step by step. The machine's contribution is completeness. Everything that makes it an order rather than a document is human, and must be written by the platform, not by the caller.

Chapter nine

What RenewOps does about this

The reconciliation layer.Reads your monitoring stack. Checks it against ratings, agreements and the documents of record. Declines to publish what it cannot defend.

This chapter is shorter than its counterparts in the rest of the series, and the reason is the finding. Of the five integrity requirements in this reference, two are enforced controls in RenewOps today. Three are requirements RenewOps is being built to. A document arguing for provenance discipline does not get to blur that line.

The controlled procedure library

RenewOps holds 121 controlled documents — operating practices, alarm response guides, switching practices — live and retrievable, filed by document type, with post-load reconciliation reporting nothing missing. Three behaviours in that library matter more than the count.

A company procedure is never returned as the standard it implements. The document type says what the document is; the linkage to a standard family is carried in a separate field. Every field is supplied explicitly on ingest rather than auto-detected, after auto-detection previously misfiled eight documents as standards. An operator searching for the standard and receiving somebody's internal procedure has been handed the wrong authority, and will not necessarily notice.

Supersession runs on ingest. A replacement retires its predecessor. When the library was reloaded, the entire prior load retired. There is no state in which two versions of a controlled document are both live because nobody remembered to withdraw one.

Ingest re-verifies the operator against a roster on every call and writes an audit row per ingest. An unrostered code was rejected rather than accepted and reconciled later.

The audit finding raised against the library itself. 99 of the 121 controlled documents still carry a placeholder document number, and the approver and wet-signature register could not be loaded. Both were raised ahead of the library's effective date rather than after it. A controlled document library whose documents are not properly numbered is a filing system with aspirations.

Order numbering issues from a controlled sequence

An order number is allocated by the register at submission, not typed by a drafter and not minted at drafting. This is the second enforced control, and it is the one that prevents the failure in Chapter four: abandoned drafts burning numbers out of a sequence that somebody later has to explain.

What the register actually contained

Measured 24 August 2026, and stated because the measurement is the argument:

Five of the six test drafts carried complete step arrays targeting real devices. One cancelled record held, as its order body, a model's refusal to write the order. The refusal was correct. Persisting it as an order was not, and it is the failure that motivates the fifth requirement in this reference.

Where the five requirements stand

An integrity control that has never been exercised is a design, not a control. The register is empty of approvals, so this reference claims a design — and says which two of the six are more than that.

Why the honest version is the useful one

A capability claim in this domain is checkable, and it will be checked by somebody with the authority to look. If a reference asserted enforced separation of drafter, approver and executor, the first competent question at a demonstration is show me an order that was approved by somebody other than the person who drafted it. On the register as measured on 24 August 2026, there is no such order to show, because there is no approved order at all.

The requirements in Chapters three through seven are correct requirements. They are the ones this platform is being built to, and the ones we would test any other platform against. What they are not, yet, is a description of controls in force — and the distinction between a specification and a control is precisely the distinction this reference exists to teach.

Adjacent registers, and a standing judgement

Three related registers were examined and are named here because their emptiness is the finding. A site access register holds no rows and lacks the fields required to answer who is inside the fence. No lockout and tagout register exists. A work order register has no backing store behind it.

The standing judgement on all three: build it properly or remove it from navigation. An empty safety register in a menu is worse than an absent one, because the menu entry is itself a claim that somebody will act on.

Register figures measured 24 August 2026; library figures 26 August 2026, on a live production instance. Machine drafting of switching orders is built and confirmed by the platform owner. Every currency statement above is dated because a register measured today may read differently tomorrow — and the direction of travel on this one is the point.

The firm

About Energy Compliance, Inc.

Energy Compliance, Inc. is an independent regulatory compliance and advisory firm serving the energy sector, with a focus on NERC, FERC, and RTO/ISO compliance and a particular concentration in the ERCOT and Texas PUCT markets. The firm helps registered entities and prospective registrants navigate the full compliance lifecycle — registration, program design, evidence development, RSAW production, mitigation, and audit defense.

The approach is research-analyst-first. Every conclusion is tied to an authoritative source, every narrative is evidence-backed, and every deliverable is built to survive regulator scrutiny. Engagements are led by a single senior practitioner with regulator-side experience. We do not staff for billable hours. We staff for outcomes. Where automation can replace manual work, we build the automation. Where senior judgment is required, the senior is in the room.

That discipline extends to a portfolio of compliance technology, of which RenewOps — the reconciliation layer described throughout this series — is one part.

Rob Smith — Founder & Principal

More than thirty years on every side of the North American Bulk Electric System. Control-room operations as Reliability Coordinator, Transmission Operator and Power System Operator. Senior compliance auditor and subject matter expert for NERC Reliability Standards — auditing grid facilities, evaluating mitigation adequacy, and supporting the development of violation notifications and settlements as part of FERC-directed enforcement actions, from inside the regulator's process. Overseas, a regulatory audit in the Sultanate of Oman conducted against the Sultanate's Sector Law and Grid Code.

MSL, Corporate Compliance — Fordham Law · MS, Energy Management · BAS, Mechanical Engineering (Metallurgy minor), University of Florida · BAS, Energy Management · AAS, Power Plant Technology and Electrical Transmission System Technology, Bismarck State College

Auditing teaches one habit that never leaves: before you believe a number, ask what it would look like if it were wrong.

Where to start

An assessment points our defect battery at your live monitoring stack and hands you the findings — each with a source, a timestamp, and the question that resolves it — whether or not you buy anything afterward. Nobody buys a reconciliation layer before they know they need one, and the only honest way to find out is to look.

Fleet Exposure Read

Your availability constructs reconciled against your executed agreements, returning a per-site computability position — ready, partial, blocked, or undefined — with the specific blocker named for each site that cannot compute.

Monitoring Truth Assessment

The full defect battery against your live monitoring stack. Every finding returns with a source, a timestamp, and the question that resolves it. Where we cannot verify something, it comes back marked deferred with the specific question, not softened into a maybe.

Evidence Provenance Review

Your compliance-relevant signals traced to source and sorted into citable and not, with the seeded, the derived, and the self-referential separated out from the issued.

RenewOps

The reconciliation layer itself, deployed against your fleet: contract terms parsed to structure, signals resolved to roles, every tile carrying its own denominator, its own provenance, and its own age — and refusing to compute, visibly, when it cannot.

Energy Compliance, Inc.

[email protected] · energycomplianceinc.com · 763.438.4427Bloomington, Minnesota

To discuss how any of this applies to a specific fleet, or to request other references from the Energy Compliance library, visit energycomplianceinc.com.

Rigorous Compliance.Defensible Programs.

energycomplianceinc.com