Build and deploy / build-and-deploy (push) Failing after 4s
Pouya's rulings of 2026-09-03, in five parts. 1. THE INTAKE FORM IS NOT BROKEN. (ar) was wrong. docs/09 §7.1 verbatim — POST /api/intake with an Origin header — returns 303 to /contact/could-not-send/ with access-control-allow-origin echoed; the same probe without Origin returns 403. A bare POST 403s BY DESIGN and §7.1 says so three lines below the probe it prescribes: "403 means the Origin header did not arrive". The earlier finding read a status code without reading the document that defines it. Second time in two days. CLAUDE.md's instrument list goes eight to nine. D20 findings 12 and 19 fall with it; §7.2 (that both emails arrive) is still owed. The correction is APPENDED as entry (as); (ar) stands unedited. 2. The privacy retention comment was stale, not a defect — superseded by his decision to publish and confirm after launch, reading from 2026-09-04. Reworded; the TODO(pouya) came off with the gate it enforced. The mechanism finding survives: it was a JSX comment, stripped by Astro, so no build or deploy path could see it. A publication gate that lives only in a stripped comment is not a gate. §9 Q60 corrected. 3. The gloss class is fixed — 15 of the 20 D20 findings, 14 distinct edits across 9 files, under the rule "the gloss may say no more than the extract says; no new claims, no new sources". Swept three unpublished insights drafts too, and corrected the wrong CAA attribution at its source in docs/reference/, which is where a fixed page re-seeds. /bio/ changed, so the committed PDF is regenerated (89,549 B, 1 page asserted). Three findings outstanding: 10 needs a ruling, 11 is ruled and owed via Q60, 13 needs him to have said it. R1 is not one of the twenty. 4. X-Robots-Tag cannot be done with S3 object metadata — --metadata writes user metadata, returned as x-amz-meta-x-robots-tag, which no crawler reads. Built as the CloudFront response-headers policy docs/06 has specified all along: configure.mjs section 4. It needs a --apply run, not a deploy. The policy is cloned from whatever is attached at run time and reconciled on every run, because a response-headers policy replaces rather than merges. 5. Headshot deferred as an open non-defect. The master and the srcset ladder are both fine; Astro passes no quality, so AVIF encodes at sharp's default 50 and is served first. Two review rounds, 29 findings, all resolved, none declined; stopped at two per D19. NINE of round 2's fourteen were defects in round 1's own repairs — including a fix that harmonised both /fees/ rows onto wording that was itself unregistered, publishing an unsourced fee term twice where it had been once. Gates, exit status read for each: check 0 (0 errors, 0 warnings, 0 hints), build 0 (23 pages), check:claims 0, check:intake 0, og:proof 0, lint 0, minifier grep exit 1, router.test.mjs 30/30. Lighthouse NOT run. Nothing deployed and nothing applied to the distribution. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Md3GndFqWPzK78xAoebsg5
202 lines
11 KiB
Plaintext
202 lines
11 KiB
Plaintext
---
|
|
title: 'What a System Impact Assessment actually evaluates'
|
|
description: 'What an IESO System Impact Assessment evaluates, who performs it, where the transmitter customer impact assessment sits, and what to look for in one.'
|
|
# publishDate is the drafting date. Set it on approval (D9).
|
|
publishDate: 2026-08-31
|
|
topics: ['technical-explainer']
|
|
practiceAreas: ['energy', 'technology']
|
|
readingTime: 8
|
|
draft: true
|
|
reviewedByPouya: false
|
|
---
|
|
|
|
## An SIA is not an assessment of the project
|
|
|
|
A connection date is a common term in Ontario energy contracts: EPC schedules,
|
|
equipment supply terms, the covenants around a commercial operation date. When
|
|
it moves, the System Impact Assessment is the document the argument turns to,
|
|
and it invites one specific misreading. An SIA does not assess the project; it
|
|
assesses what happens to the grid if the project connects to it.
|
|
|
|
The term is the Independent Electricity System Operator's own, and so is its
|
|
companion. In the IESO's description of the connection process, "New connections
|
|
or modifications to facilities connected to a transmitter's system are subject
|
|
to the IESO's system impact assessment (SIA) and the transmitter's customer
|
|
impact assessment (CIA)." Two documents, two authors. The IESO conducts the SIA.
|
|
The transmitter conducts the CIA. Treating the pair as one exhibit loses the
|
|
distinction most of these disputes turn on. Both sit in the IESO's and
|
|
transmitter's connection assessment and approval process, CAA in the IESO's
|
|
usage, and each application is given a unique CAA ID.
|
|
|
|
## What the assessment is actually of
|
|
|
|
The IESO describes its study step as assessing "the impact of [the] proposed new
|
|
or modified connection on the reliability of the integrated power system". Stage
|
|
one of the same process puts it more broadly: planned connections and
|
|
modifications "must be assessed to identify and mitigate any potential adverse
|
|
effect on the reliability of the electricity grid and its existing customers".
|
|
|
|
The subject of the assessment is the system, not the applicant. The IESO
|
|
describes its own function as coordinator and integrator of Ontario's
|
|
electricity system, balancing supply against provincial demand in real time and
|
|
directing the flow across the transmission lines, and it names five pillars of
|
|
reliability it is responsible for meeting: capacity, energy, transmission,
|
|
operability and ancillary services. An SIA asks whether a new connection
|
|
disturbs those.
|
|
|
|
That is also how to read a condition: the assessment's subject is the system,
|
|
so a condition speaks to how the system behaves with the facility on it. The
|
|
published process does not describe what conditions a report may carry — that
|
|
question is answered in the report. A pleading that reads a condition as an
|
|
admission of defective work is reading the document as though the other side
|
|
had commissioned it.
|
|
|
|
The IESO's connection-process FAQ names the tools: "The IESO uses DSA and PSSE
|
|
tools to conduct SIA studies." Naming the tools is not describing the study, and
|
|
the published process description does not say what a given study assumed,
|
|
modelled or tested. Where the argument is about the study itself, the report and
|
|
the record behind it are what answer it — not this outline of the process that
|
|
produced it.
|
|
|
|
## Where it sits, and how long it takes
|
|
|
|
The IESO runs connection in up to six stages: prepare application; obtain
|
|
conditional approval to connect; design and build; authorize market and program
|
|
participation; register equipment; commission equipment and validate
|
|
performance.
|
|
|
|
The SIA and the CIA both live in stage two, which "typically takes one year" on
|
|
the IESO's figure. Stage four typically takes about a month, stage five at least
|
|
three months, and the whole process "can take anywhere from a few months for
|
|
small modifications to existing facilities, to more than three years for major
|
|
modifications or to connect new facilities". All applicable stages have to be
|
|
completed before final approval to connect and the start of commercial
|
|
operation.
|
|
|
|
Which stages apply depends on what the facility connects to: "New or modified
|
|
connections to a transmitter's system are generally subject to all six stages,
|
|
while new or modified connections to a distributor's system may only be subject
|
|
to the first three."
|
|
|
|
That last point is about parties as much as engineering. Distribution
|
|
connections run through the distributor's own assessment process, and the IESO
|
|
records that a distributor may itself need to participate in the IESO's and the
|
|
transmitter's processes on the applicant's behalf. The entity handling the
|
|
assessment correspondence is not always the entity whose contract is in dispute.
|
|
|
|
## Two documents, two authors, two agreements
|
|
|
|
The sequence is where the SIA and the CIA come apart.
|
|
|
|
On the IESO's account of stage two, a pre-application meeting comes first. The
|
|
IESO then determines whether the application qualifies for a system impact
|
|
assessment or an expedited system impact assessment (ESIA). Once the application
|
|
and its deposit are in, it prepares an SIA agreement, "in accordance with
|
|
section 6.1.15.3 of chapter 0.4 of the Market Rules", for execution by the
|
|
applicant's authorized representative. Once all required information has been
|
|
provided, it carries out the studies and issues a draft SIA report to the
|
|
applicant and the transmitter for review and comments. After addressing the
|
|
comments on the draft or on a revised draft, it sends the final report to both,
|
|
with either a "Notification of conditional approval (NoCA)" or a "Notification
|
|
of disapproval with reasons (NoDR)".
|
|
|
|
The CIA runs on a different clock. The transmitter "generally initiates the
|
|
customer impact assessment (CIA) after the draft SIA report from the IESO", and
|
|
the CIA has its own agreement, between the applicant and the transmitter.
|
|
|
|
Three consequences follow. The assessments are generally sequenced rather than
|
|
parallel, so a slipped draft SIA ordinarily pushes the CIA start behind it.
|
|
There are two contracts before there are two reports, and the obligations
|
|
parties argue about, which information was owed and by when, live in those two
|
|
agreements. And the draft-and-comment step is a record: what a party said about
|
|
a study assumption at draft stage, and what it declined to say, sits in that
|
|
record alongside the final report.
|
|
|
|
## What to ask for, and what the record will not support
|
|
|
|
Where a dispute turns on an SIA, the productive order is the order in which the
|
|
record was made, not the order of the pleadings. The application first, and the
|
|
IESO's FAQ names the instrument: Form 128 initiates the SIA process. Then the
|
|
two agreements. Then the information the applicant supplied, with dates, because
|
|
the study step begins once all required information has been provided:
|
|
completeness is the hinge on which a year-long stage moves. Then the draft SIA
|
|
report and each set of comments on it. Then any revised draft. Then the final
|
|
report with the NoCA or the NoDR. Then the CIA.
|
|
|
|
The final report may already be public: the IESO states that it "will be
|
|
published on the IESO website in the Application Status table at the end of the
|
|
month in which it was finalized". Upstream of all this sits an optional
|
|
technical feasibility study, a "confidential service" provided "on a
|
|
cost-recovery basis to identify and mitigate potential issues with various
|
|
connection options"; whether one was run often explains why a particular option
|
|
was chosen.
|
|
|
|
Two arguments the published process will not carry. First, the queue. Ontario
|
|
has no interconnection queue. The IESO is explicit: it "is not using an
|
|
'interconnection queue'", adopting instead "the concept of 'committed projects'
|
|
that is defined in Section 3.3 of Market Manual 1.4: Connection Assessment and
|
|
Approval", and there is "no option to 'skip the interconnection queue'". Each
|
|
assessment follows the timelines in section 5.8 of that manual. A head of loss
|
|
framed as a lost place in a queue rests on a mechanism the system operator says
|
|
it does not operate.
|
|
|
|
Second, differential treatment. Renewable generation is not assessed
|
|
differently: "The treatment of new renewable generation facilities is no
|
|
different than any other new facility, the normal System Impact Assessment (SIA)
|
|
process applies to the connection of all generation facilities, renewable or
|
|
non-renewable, equally." A delay theory resting on technology-specific handling
|
|
has nothing in the published process to stand on.
|
|
|
|
## Why more contracts are about to depend on this
|
|
|
|
As this is written in August 2026, the gate in front of large loads is being
|
|
rebuilt around the assessment, not in place of it.
|
|
|
|
Section 28.1 of the Electricity Act, 1998 came into force on 11 December 2025.
|
|
Unless a transmitter or distributor is satisfied that the "specified connection
|
|
requirements" have been complied with, it "shall not" connect or reconnect a
|
|
"specified load facility". That category is defined to include a data centre
|
|
meeting criteria that may be set out in the regulations, and a facility whose
|
|
demand at the point of connection exceeds a prescribed amount. The section
|
|
arrived through Bill 40 of the 44th Parliament, 1st Session — the Protect
|
|
Ontario by Securing Affordable Energy for Generations Act, 2025 — which
|
|
received Royal Assent on 11 December 2025 as chapter 22 of the Statutes of
|
|
Ontario, 2025. Its transition rule turns on a date and a form: the section does
|
|
not apply where a connection request made in accordance with the Transmission
|
|
System Code or the Distribution System Code was submitted to the transmitter or
|
|
distributor before 3 June 2025, the day Bill 40 had First Reading.
|
|
|
|
The regulation that would fill in those criteria is the part to watch. The
|
|
Ministry of Energy and Mines' August 2026 consultation on an economic and
|
|
strategic assessment framework for new data centres describes the province as
|
|
"considering drafting" a regulation that would require new large data centres to
|
|
obtain government approval to connect or reconnect. Its comment period runs to
|
|
12 September 2026, and the same notice carries the Ministry's estimate that
|
|
data-centre connection proposals could total more than 10,000 MW cumulatively.
|
|
|
|
None of that displaces the SIA; it sits on top of it. A large load will still be
|
|
assessed for its effect on the reliability of the integrated power system, in
|
|
stage two, and its transmitter will still run a CIA. What changes is the number
|
|
of contracts written against a connection date whose gating conditions were
|
|
still under consideration as at August 2026.
|
|
|
|
## Reading the study and the contract on the same page
|
|
|
|
Grid connection disputes are argued through technical studies. I work as a
|
|
machine-learning and DevOps infrastructure engineer. The study assumptions, the
|
|
modelling inputs and the constraint that produced a condition are documents I
|
|
read directly and work through with the parties.
|
|
|
|
In a [mediation](/mediation/) that means a technical disagreement can be tested
|
|
in the room rather than deferred to an expert exchange. In a
|
|
[commercial arbitration](/arbitration/) it means the first procedural order can
|
|
be built around the documents that decide the matter.
|
|
[The shape of an engagement](/process/) sets out where each one starts.
|
|
|
|
Connection is one of the areas I take appointments in, set out at
|
|
[energy and grid disputes](/practice/energy/); its large-load half overlaps
|
|
with [technology and data disputes](/practice/technology/). Every date above is
|
|
as at August 2026, and the instruments move. Nothing here is applied to a
|
|
particular matter, and each party to a dispute should have their own legal
|
|
advice.
|