V12 · Systems Operator

1. What is the System Operator

The Market Operator sold everyone a slot on the highway for 18:00. Someone still has to watch the bridges. That someone is the System Operator.

This volume is that seat. The BRP volume (V9) teaches what a participant does with an instruction after it arrives. The Market Operator volume (V11) teaches auctions and money. This chapter is the job itself: who the System Operator is, what it is for, how it talks to the Market Operator and to every Balance Responsible Party, and which notices leave this desk.

1.1 The problem this seat exists to solve

A cleared market schedule is an economic answer: who wanted to generate or consume, at which price, for which hour. The grid is a physical answer: frequency must stay near 50 Hz, voltage must stay in band, and a corridor can only carry so many megawatts before a line trips.

Those two answers disagree every day. The market may want 75 MWh across a wire that can take 60. A solar farm may be scheduled to inject when a fault has already taken the corridor out. A unit that offered reserve may not actually be able to hold it. Somebody has to change what plants do after the auction, without quietly rewriting the ticket price everyone already paid.

That is the System Operator’s problem. It keeps the power system secure, and it leaves a paper trail so the Market Operator can pay for the diversion under ancillary rules rather than by changing the System Marginal Price.

1.2 What the System Operator is

The System Operator is the grid’s physical authority — the party the Market Code charges with keeping the interconnected system inside its operating limits. In the product that is the /so console (fifth landing card when you sign in as SO).

It is not the Market Operator. The Market Operator admits participants, runs the auctions, publishes the SMP, holds credit cover and invoices. It does not throw a switch. It does not certify that a unit can hold instantaneous reserve. It does not declare an emergency.

It is not a BRP. A Balance Responsible Party is financially accountable for the gap between what it scheduled and what its meters show. The System Operator is accountable for the wires those meters sit on.

It is not Eskom-the-seller or Eskom-the-wires-business in the wheeling sense. Those seats live in V21. The System Operator here is the SAWEM role: constrained scheduling, dispatch, reserve certification, and the notices that follow.

Traffic-control metaphor. The Market Operator is the person with the gavel and the settlement office. The System Operator is air-traffic control. It can divert a flight after the slot was sold. The diversion is paid under safety rules, not by changing the fare on every other ticket.

1.3 What it does

Six jobs, and they are all this volume:

The 15 MWh cut is not a cheaper SMP. It is a System Operator decision, accounted in the ancillary pot, usually at the unit’s own offer. Mixing those two stories is how people add a PPA bill to a market imbalance and call it one invoice.

1.4 How it works with the Market Operator

The two operators share a Trading Day — one calendar day in SAST for which the market sold energy — and they do not share a job. Think of a produce market that also has a fire marshal. The auctioneer (Market Operator) sells the stalls and writes the invoices. The fire marshal (System Operator) decides how many people the hall can hold, can empty a corridor if a door jams, and must leave a written order so the auctioneer’s books can pay for the diversion. Same building, same day, two clipboards.

This section walks that shared day in the order it actually happens. Every term is introduced in plain words before it is named.

The registry step is drawn in the middle of the day because that is when you notice it on the consoles. In life it runs continuously: a new plant can be filed on a Tuesday in June and still change Wednesday’s solve.

Before the gate — they both read the same map

A gate is a published clock after which a kind of bid may no longer be accepted. The day-ahead gate is 10:00 the day before delivery (D−1). After 10:00 the Market Operator freezes who offered what for tomorrow, then solves — stacks the cheap supply against demand and finds one price for the hour. You cannot solve honestly if you do not know where each plant sits and how much can move between those places.

That knowledge is the network model: a published picture of the grid in two layers.

1. Zones. The country is cut into geographic areas so the market can tell when a corridor is full. Everything inside one market registration — a Trading Unit — must sit in one zone. A Trading Unit is not “your company.” It is the bundle the market will nominate, schedule and balance as one thing. A solar farm in the Northern Cape and a factory in Gauteng cannot share a Trading Unit, because they do not share a zone (§2.1).
2. Corridors. A corridor is the set of wires between two adjacent zones. The model must say, for each pair, how many megawatts may flow in each direction — Z1 → Z4 1000 MW is one such sentence. Cross-border links to the rest of southern Africa are listed the same way, import and export bounded separately, because a link operated as an import is not a two-way pipe (§2.5).

Metaphor. Before an airline sells Tuesday’s seats, someone publishes the airport map and the runway lengths. The ticket desk (Market Operator) uses that map to know which flights can connect. Air-traffic control (System Operator) is the author of the map. If the map is wrong, the ticket desk will sell a connection the runway cannot take.

The Market Code requires the System Operator to publish this model three months before the market opens. It has not done so. What both seats see today is therefore a platform estimate, stamped PROV-2026-07, and every screen that shows a zone says so. The areas do not overlap (good), they cover only about a fifth of the country (not good), and every corridor figure is derived from an assumed circuit count — never a declared limit (§2.3).

Until the real model arrives, the Market Operator and the System Operator are looking at the same estimate. That is deliberate. Two desks with two maps would clear a plant into a zone the other desk does not believe exists.

Follow along. Seat: so@webill.net. Path: Network Model → Map (/so/network-model?tab=map). If the map is empty, press Load provisional zones, then click Z1. You should see the Northern Corridor polygon and the PROV-2026-07 stamp. The Market Operator’s coverage / gap export of the same register is V11 §12.

On the solve — two schedules, one price

Clearing (the solve) is the Market Operator stacking every accepted bid and offer for an hour and finding the last megawatt-hour needed. That last unit sets the System Marginal Price (SMP) — one country-wide price for the hour. Everyone who cleared trades at that price. Your offer decided whether you cleared, not what you are paid.

That first solve ignores the wires. It answers: if the grid could carry anything, who would run? The result is the unconstrained schedule. It is the economic story, and it is what the energy pot settles against.

The System Operator then applies the network model: corridor limits, reserve that must be held back, interconnects that did or did not arrive. Units get cut or moved. The result is the constrained schedule — what may physically run. The SMP does not get recalculated. The 15 MWh the wire refused is paid under ancillary rules, usually at the unit’s own offered price, not by making everyone’s ticket cheaper.

Metaphor. The auctioneer sold 75 seats on a bus. The fire marshal counts the exits and says only 60 may board. The ticket price stays what the auction discovered. The 15 people turned away are compensated under the safety rulebook, not by refunding everyone else a slice of the fare.

The Market Operator cannot invent those limits. It must be told three facts the System Operator owns. On Bidding → Daily (/mo/bidding) those facts appear as three traffic lights:

Each light answers one question only: has the System Operator sent this fact yet? It is not a score of how good the numbers look. The Market Operator writes the fact when /internal/so/:input arrives. Until then the pigeonhole is empty.

Metaphor. Three parcels must land on the auctioneer’s desk before the 14:00 publication. Demand and reserves are due at 10:00 the day before trading (D−1). Interconnect is due at 13:30 D−1. Each light is the stamp on that parcel’s pigeonhole — not a verdict on what is inside the box.

Three stamps. Watch the interconnect pigeonhole through one morning — the other two lights work the same way, only their due time is 10:00.

Present. The parcel is in the pigeonhole. The System Operator sent a message. You have something to clear with. Green does not mean the numbers are healthy, and it does not mean “the network is clear.” An empty constraint list that did arrive is still Present — the box came; it happened to be empty.

Unknown. The pigeonhole is empty and the due time has not come. You are still waiting. That is not an all-clear and it is not an alarm. At 12:00 D−1 the interconnect is usually Unknown: 13:30 has not struck, and nothing has arrived. Wait.

Late. The due time has passed and the pigeonhole is still empty. Now it is an alarm. At 13:31 D−1 with no interconnect the light is Late. The 14:00 publication is at risk; Daily’s exception list says so.

If the parcel arrives after the due time, the light flips to Present. Late means still missing, not arrived late.

Careful. An empty published-constraint list is labelled because nothing bound, not because the network was clear. Inventing corridor limits on the Market Operator chalkboard is forbidden (V11 §12.7).

Follow along. Seat: mo@webill.net. Path: Market Operator → Bidding → Daily. You should see #so-input-demand, #so-input-reserves and #so-input-interconnect. Before 13:30 D−1 an empty interconnect is Unknown. After 13:30 an empty interconnect is Late, not a present green.

On the registry — the SO must be told who exists

The registry is the shared list of who may trade and what each plant can actually do. The Market Operator keeps it: applications, Trading Units, meters, standing data. The System Operator cannot dispatch a unit it has not been told about, and it cannot believe a reserve number the participant typed in.

Three events on that list are the System Operator’s business:

1. A Trading Unit is registered or modified. A new plant (or a change to an existing one) has a name, a zone, capacities, ramp rates. Tomorrow’s solve will treat it as real.
2. A Point of Delivery is added or removed. A Point of Delivery is one metered point where energy enters or leaves the grid. Every meter has two owners in the market — that is why adding or removing one is not a private filing. The System Operator needs the node if it is going to instruct the plant; the Market Operator needs it to settle the meter.
3. Reserve certification is requested. Reserve is capacity a unit holds back so it can move when the System Operator calls — regulating (continuous nudge), instantaneous (seconds), ten-minute (a slower call), and synchronous-condenser operation (spinning for voltage, no net energy). The Market Code says those capacities are “agreed by the SO.” Until this desk certifies a megawatt figure and an SO reference, the certified capacity is 0.000, and every availability indicator on every submission is forced to U (unavailable). The participant wizard does not even offer those fields (§6).

When any of those three happens, the Market Operator writes a RegistrationNotice — a dated row: this unit was born / this meter was added / this plant asked to be certified. That is the §7.1(2) share: the Code requires the System Operator to be told, and to be able to prove it was told.

Metaphor. The licensing office (Market Operator) issues a truck licence. It must send a copy to the traffic police (System Operator). The police sign the copy so nobody can later claim the truck was never on the books. The police also do the brake test; the licensing office is not allowed to stamp “certified for 50 MW of instantaneous reserve” because a form said so.

Two motions, both required:

• Push. The notice appears on /so/registry → Inbox. You acknowledge it. Acknowledge is a signed receipt, not a courtesy tick. An unacknowledged share is a compliance gap.
• Pull. You can also fetch the whole list: GET /internal/mo/registry. The Code allows both. The inbox is “what changed since I last looked”; the pull is “give me everyone.”

Certification itself is a decision on the Certification Queue: a MW or MVAr figure plus an SO reference, or a decline with a reason. Revocable, forward only. The Market Operator can see the result; it cannot make it.

Follow along. Seat: so@webill.net. Path: Registry (/so/registry) → Inbox. Acknowledge a row. Then Certification Queue — a pending request shows 0.000 until you certify. The participant side of the same standing data is V9 §3.7.

After delivery — one number three parties must agree

Delivery is the hour the electrons actually moved. Three quantities now exist for the same Trading Unit, and they are not synonyms.

If nobody instructed you, Instructed Energy equals Contracted Energy and a 5 % metering allowance applies — miss by less than 5 % and the difference settles at the ordinary hourly price, with no penalty. The moment this desk issues one manual instruction, two things change together: you must keep instructing every later hour until you hand control back, and the allowance stops applying for every instructed hour (§3.5).

Instructed Energy is not a cap and not a vibe. An instruction is three things together: be at 480 MW, at 18:20, ramping at 8 MW per minute. The plant cannot teleport, so it ramps, and the energy the market credits is the area under that ramp. On the teaching hour that working is 475.234 MWh — you can add the segments yourself (§3.4).

The System Operator issues the trajectory. The Market Operator prices the gap between that trajectory and the meter (and, separately, the gap between contracted and instructed). The BRP can dispute the arithmetic if their own addition disagrees. All three must arrive at the same Instructed Energy figure, because that figure is the yardstick for every balancing payment.

Then the money splits into three pots, so a System Operator decision cannot quietly rewrite the auction.

Worked hour. Market wanted 75 MWh; the corridor allowed 60. Energy pot still books 75 × SMP and still nets to R 0.00 across the market. The 15 MWh cut is an ancillary line, usually at the unit’s own offer — not a new, quieter SMP. Full arithmetic: V9 §1.5 · V9 §13.

Note. A missing commercial-log entry on a non-dispatchable curtailment moves that same 15 MWh from “compensated at your offer” to “penalised at the balancing price.” The log is why the System Operator’s notice is not optional reading (§3.6).

What the Market Operator cannot do

Three acts look tempting on /mo and are this desk’s, not theirs.

It cannot edit a price curve to hide a constraint. A price curve is the five-block offer a Trading Unit sent for an hour — the ladder the solve stacked. If a corridor is short, the honest move is a constrained schedule plus an ancillary line. Changing the ladder after the gate would make the energy pot tell a story the bids did not tell. If a curve is wrong, the BRP fixes the registry or sends a new sequence. Solve and Publish on Daily call the same WB.Sawem.Cycles wrappers the cron jobs call; there is no second “make the chalkboard look clear” button (V11 §12.7).

It cannot certify reserve. Certified megawatts are an engineering agreement with a reference and an effective date. A form the participant submitted is not that agreement. Until you certify, the capacity is 0.000 and the unit cannot truthfully offer the reserve (§6).

It cannot raise a zone-constraint flag. A zone-constraint flag is a runtime statement that a zone’s imports, exports, or both are constrained now — not a sentence in the published model. While it is in force, members of a Balancing Group (a BRP’s request to net long and short positions across their own units) who are pushing in the constrained direction drop out for those Trading Periods only. That is a network decision with a settlement consequence. Raise and lift live on /so/network-model?tab=map, with an impact preview, and both write a RegistrationNotice so the Market Operator and every affected party learn about it (§5.5).

Metaphor, one last time. The auctioneer may not redraw the fire exits on the chalkboard so the room “looks” under capacity. The fire marshal writes the order, the auctioneer invoices it, and the guests see the same number on their bill.

1.5 How it works with BRPs

A BRP feels the System Operator in four places, and they are easy to confuse.

1. The zone on the registration. Everything inside one Trading Unit must sit in one network zone. A book that looks like one business can become three market registrations, each balanced separately (§2.2). The BRP sees the zone on site screens, Trader Pools, and the public allocate API. The System Operator owns the map those screens read.

2. The instruction on the feed. Path: Market › SO (/org/brp/so). Every dispatch, curtailment or outage arrives as a card. Acknowledge is a round-trip to the System Operator API, not a local tick. The moment one manual instruction issues, the unit leaves its intraday schedule: the System Operator must instruct every subsequent period until it hands control back, and the 5 % metering allowance stops applying (§3.5).

3. The availability revision. If cloud arrives and the plant cannot deliver, the BRP tells the System Operator what it can now do (#availability-revision-form). That changes what the SO dispatches. It does not change Contracted Energy — that is an intraday re-declaration to the Market Operator. Doing the first and not the second means you are dispatched correctly and then charged imbalance against a schedule you never corrected (§3.7).

4. The banner that is not a command. A SYSTEM_CONDITION notice appears on the Bid Desk so the BRP has context. It has no target MWh and creates no curtailment line. Only a targeted instruction has a window, a quantity and a preview that can support an instructed imbalance split.

Why the BRP must still care: an SO instruction changes what “good delivery” means for imbalance. Being curtailed by the System Operator is usually settled differently from voluntarily re-declaring yourself down in IDM — one is the grid’s decision, the other is yours (V9 §5, V9 §6).

1.6 The notices it sends

The Market Operator broadcasts GENERAL / SYSTEM_STRESS / PRICE_CAP_EVENT text to every BRP (V9 §9). The System Operator’s notices are different: they are operational facts that change a limit, a certification, or a settlement number. The catalogue — four kinds, each with an example and the impact on the receiver — is §3.1. The order that costs money is §3.2. In short:

An empty notice list is not “the network is unconstrained.” It means nothing was flagged. The distinction matters on GET /api/v1/network-model/zone-constraints and on the Daily chalkboard.

1.7 What it does not do

• It does not set the System Marginal Price. That is unconstrained clearing on the Market Operator’s desk.
• It does not settle a PPA. Bilateral wheeling and CfD money is V8. Same megawatt-hour can appear in both stories without being one invoice.
• It does not compose a Balancing Group. Membership is the BRP’s (V9 §3.6). The System Operator can only exclude members for a flagged constraint.
• It does not file Trading Units. Participants file; the Market Operator reviews; this desk certifies reserve and acknowledges the share.
• It does not invent corridor limits. Until the real model is published, every capability figure is an estimate with its derivation attached (§2.5).

1.8 Where you sit in the product

Follow along. Seat: so@webill.net with password supersecret. Path: System Operator → Dispatch Desk (/so) → Network Model → Registry. The sidebar is those three items — there is no Zones item. Dispatch Desk opens on Issue (instruction and system condition), then Active and Issued. Network Model opens on Model (constrained scheduling cards; no API button on the card). Map is the zone polygons; API is the OpenAPI call and live JSON. Registry opens on IPPs (search and sort), then Inbox and Certification Queue. Then open a BRP seat (trader_1@webill.net) → Market → SO to see the receive side of the same day.

Where this is taught. The BRP primer’s short SO picture remains V9 §1.6. Auctions and money: V11. Imbalance after an instruction: V9 §6. Background polling and archive: V21 §3.

Data. full_demo · seed 42 · stage S08 (market loop).

2. Network zones

Screens: IPP Sites (/org/ipp-sites), OffTaker Sites (/org/off-taker-sites), Trader Pools (/org/trader-pools), Market Desk (/mo), SO Network Model (/so/network-model) — Model, Map, and API tabs.

2.1 The grid is divided into areas, and that divides your portfolio

The country is split into network zones — geographic areas the System Operator defines so the market can tell when a corridor is full and generation has to be moved.

One rule follows, and it is the one that reshapes a business:

Everything inside one market registration has to sit in one zone.

So you cannot put a solar farm in the Northern Cape and a factory in Gauteng into the same trading bundle. They are in different zones, and the market treats them as two separate registrations.

The nine provisional zones. Until the System Operator publishes its own constrained scheduling model, the register in force is the platform estimate stamped PROV-2026-07 (§2.3). It names nine areas:

Those codes are what site screens, Trader Pools and the public allocate API show when a location falls inside a polygon. Dominant is why the zone exists on the grid (solar injection, wind corridor, load centre, and so on). Core nodes are the substations the boundary is drawn around. Market implication is the short label the inferred register carries for what that zone tends to force in scheduling.

The SO Network Model page (/so/network-model). This is the System Operator’s own picture of the same register — not the MO’s coverage / gap export (V11 §12), and not a participant site list. Open it from the SO sidebar (Network Model), next to Dispatch Desk and Registry (§4 · §5 · §6). The page has three tabs, same tabs tabs-bordered chrome as the rest of the product (icon + label):

What Map does:

1. Shows the map. Every zone in force is drawn as a coloured polygon on a Leaflet map (street or satellite basemap). Hover a polygon for a tooltip: code, name, dominant, core nodes, and the provisional / model-version stamp.
2. Shows the Registry. Below the map, a table lists the same nine rows (code, name, dominant, core nodes). Click a row and the map pans and zooms to that zone’s bounds, briefly highlighting it; other open tooltips close so only the focused zone speaks.
3. Loads the provisional register when nothing is in force. If the database has no zone model yet, the page offers Load provisional zones, which writes Z1…Z9 from docs/references/market/spec/zones/fullspec.json as PROV-2026-07 and then draws them. A provisional banner stays visible for as long as that model is what the market is using.
4. Does not invent corridor limits. The Map is the geographic register only. Corridor figures live on Model (and on the API tab as JSON), and they stay labelled assumed (§2.3).

Follow along. Seat: so@webill.net. Path: SO app → Network Model (/so/network-model). You land on Model — click Z1 and the SAWEM drawer opens. Then Map (?tab=map). If the map is empty, press Load provisional zones, wait for the spinner, then click Z1 in the Registry — the map should pan to the Northern Corridor and show its tooltip. API (?tab=api) shows the request and the live result; copy either with the clipboard icon.

2.2 What a trader actually feels

Consider a portfolio that looks like one business: three generators and four customers, one contract book, one set of numbers you manage. If those seven sites fall across three zones, that portfolio becomes three market registrations — three Trading Units, each nominated, scheduled and balanced separately.

That last word is the expensive one. Being long in one zone does not cancel being short in another. Each registration carries its own imbalance, and each is settled on its own.

There is a way to net across them — a balancing group, taught in V9 §6 — but it is something you have to ask for, it is not automatic, and the System Operator can suspend it for a zone whenever that zone’s imports or exports are congested.

Where you see the number. The Trader Pools screen shows, per pool, how many Trading Units it will need and which zones its members sit in. That is the sizing figure for a market registration project: three zones means three of everything.

2.3 The map is provisional — read this before you plan on it

The System Operator is required to publish this map, together with how much power can flow between the areas, three months before the market opens. It has not done so.

What you are shown is therefore our best estimate, stamped PROV-2026-07, and every screen that shows a zone says so. Three things are worth knowing about it:

If your site is not covered, we tell you rather than guess. The site shows Unassigned, together with the nearest area and how far outside it falls. That nearest area is information, not an answer: registering the site there would put it in the wrong balancing group and expose it to congestion restrictions that do not apply to it. So the platform declines to choose.

What happens next. Every unplaced location goes onto one list, which we take to the System Operator as a single question: these are the places your published map has to cover. Nothing else about the site is affected — it keeps trading exactly as it does today, because zones only bind once the market opens.

Careful. When the real map arrives, boundaries will move. A site can change zone, and a portfolio that needed three registrations may need four. The market gives two months’ notice of a revision specifically so registrations can be adjusted, and that is the window in which the sizing number on the Trader Pools screen changes.

2.4 Checking a location before you commit

You can ask which zone a coordinate falls in before buying a site or signing anything, without an account. These three routes are still the live public register (/api/v1/registry/network-zones*); they have not moved. The same three calls, with this deployment’s live JSON, are on Network Model → API (/so/network-model?tab=api).

POST /api/v1/registry/network-zones/allocate HTTP/1.1
Host: market.example
Accept: application/json
Content-Type: application/json
X-Sawem-Market-Code-Version: 2.3
Idempotency-Key: 018f-demo-key-0001

{"lat": -27.6905, "lon": 23.0410}

For that coordinate — Kathu — the answer is not allocated, with Z1 named as the nearest area and the model flagged provisional. That is the honest answer, and it is available before a single row of registration data exists.

GET /api/v1/registry/network-zones returns the areas in force, and GET /api/v1/registry/network-zones/gaps returns the locations the model misses. Both are public, because the market rules make the map a published document. POST allocate is an unsafe method, so it still needs an Idempotency-Key even though it writes nothing.

Your organisation also has its own list. Market › Standing data hosts the org zone-gap desk: every site the provisional map cannot place, with the nearest zone and the offset, exportable as CSV. That desk lists the gaps. It does not invent a placement. “Include in nearest zone” is not an organisation action — that remains the conversation with the Market Operator and the System Operator. Zone allocation still blocks an unplaced site rather than snapping it.

Follow along. Seat: trader_1@webill.net. Path: IPP Sites → look at the BRP column; then Trader Pools → the BRP column. An ACTIVE Market BRP shows a Trading Unit count on Trader Pools (hover for TUID and zone), or Register with Market. On IPP / OffTaker Sites an unallocated site shows No Market Zone. A trader pool may register in any published zone — member location is not a gate.

Where this is taught. The SO’s map of the register is this section (§2.1). The MO’s side of the same data — coverage and the gap list it exports for the System Operator — is V11 §12. What a zone does to your imbalance is V9 §6. The three Trading Unit registration wizards (IPP GPS allocation, Off-taker GPS allocation, Trader pick-any-zone) are V9 §3.9B.

Data. full_demo · seed 42 · zone model PROV-2026-07 from the inferred register.

2.5 What can move between areas

Zones divide your portfolio; corridors decide whether the power can get out. The System Operator’s map is required to state, for each pair of adjacent areas, how much power the network between them can carry — and to list the cross-border links to the rest of southern Africa with the capacity on each.

You can see all of it in two seats. On BRP / Market → System Operator, above the instruction feed, the panel leads with the areas your own Trading Units sit in, because that is the part that constrains you; Show all zones opens the rest of the map, and an API button opens the raw JSON. On the System Operator console the same register is the Model tab (/so/network-model) — the full model, no “my zones” toggle, and no API button on the card (the JSON lives on the API tab).

For each area it shows:

Careful — every figure here is an estimate. The System Operator has not published capability, so each number is derived: an assumed count of circuits at an assumed voltage, rated for the loss of the largest one, then reduced for line length. Each carries an amber assumed chip, and hovering it shows the arithmetic. They are there so the market mechanics can be built and demonstrated — not so you can plan a connection against them. A green declared chip is what a real figure looks like, and none is green yet.

Why we show estimates rather than blanks. A blank tells you nothing you can argue with. A number with its derivation attached can be challenged one input at a time — “that corridor has three circuits, not two” — which is the conversation worth having with the System Operator. What makes it safe is not the absence of a figure; it is that the figure cannot pass the check that gates anything published to participants, and says so wherever it appears.

One estimate to treat with particular suspicion. The corridor out of the Northern Cape solar cluster (Z1 → Z4) is deliberately set below what that area’s plants could inject, because the map’s own notes already flag it for injection caps and redispatch. If any figure here turns out materially wrong, expect it to be that one.

Open Z2 and Import is blank. Open Z3 and Export is blank. That is the listed-direction story, not a broken wire. The next section walks the assumed set with the numbers on the card.

2.6 Why a zone can show no import, or no export

The trader’s problem: you open the Model tab, click Z2 (Western Corridor — wind), and Import capability is empty. Click Z3 (Cape Load) and Export capability is empty. It looks as if the Cape cannot send anything inland, and the West Coast cannot take anything in. That is not what the blank means.

Export and Import on a zone card are sums of the assumed corridors as they are written:

• Export = corridors where this zone is from_zone
• Import = corridors where this zone is to_zone

The assumed set lists each pair once, in the “natural” flow — generation out, load in, spine in the middle. If a zone never appears on one side of any pair, that sum is empty. The platform stores empty as no figure (nil), not 0. A zero would read as “forbidden.” An absent limit is honest: the model has not listed a corridor that way.

Careful. A blank is not “the network is unconstrained in that direction.” It is “this edition did not list a corridor in that direction.” §2.3 already said every figure is an estimate. The blank is the same honesty on the other side of the ledger.

The assumed corridors that touch Z2 and Z3

Data. PROV-2026-07 · assumption set ASSUMED-2026-08 · docs/references/market/spec/zones/corridor-assumptions.json. Every figure below is assumed, N−1 rated, length-derated, rounded down to 50 MW.

No row has to_zone = Z2. No row has from_zone = Z3. That is the whole of the blank.

The arithmetic on the card

Z2 export is the outbound sum:

950 + 2,000 = 2,950 MW

Z2 import has no inbound rows → blank.

Z3 import is the inbound sum:

2,000 + 2,000 = 4,000 MW

Z3 export has no outbound rows → blank.

The 2,000 MW on Z2 → Z3 is the same corridor counted twice: as Z2’s export and as Z3’s import. That is the pair seen from each end, not two wires.

How those two forwards were derived (the hover on the assumed chip):

Σ check on the card: 950 + 2,000 = 2,950. That is the number Model shows for Z2 Export capability.

Reverse sits on the pair — it does not fill the blank

Each listed corridor also carries a reverse figure. The rule in the assumption set: 0.70 of forward on a radial corridor into a generation-poor zone, 0.90 on the meshed spine.

Z2 → Z3 reverse: 2,000 × 0.70 = 1,400 MW
Z2 → Z4 reverse: 950 × 0.70 = 665 → 650 MW

If those reverses were rolled into Z2 as import, Z2 would show 650 + 1,400 = 2,050 MW in. They are not. Reverse stays on the pair so a reader can challenge the two-way story. The zonal totals only add the listed from / to. That is why Z2 Import stays blank even though the JSON has reverse_mw.

Interconnectors are a different line

Z2 still has a SAPP link: Aggeneis–Kokerboom (Namibia), 600 MW import and 600 MW export, assumed, attachment itself flagged. That row appears under SAPP interconnectors on the card. It does not fill Import capability. Zonal import/export are inter-zonal corridors only. A cross-border tie is bounded separately because a link operated as an import is not a two-way pipe (§2.5).

What this is for, and what it is not

The listing follows the register’s own labels: Z2 wind balancing, Z3 demand obligations, Z1 injection caps, Z7 import constraints. Generation zones are written as places power leaves; load zones as places power arrives. When the System Operator publishes the real model, a generation-poor Cape zone may well get an export limit, and a wind corridor an import limit. Until then the card tells you what this edition listed — and refuses to invent the other direction.

Follow along. Seat: so@webill.net. Path: Network Model (/so/network-model) → Model. Open Z2 — Export 2,950 MW, Import blank, corridors Z2 → Z4 and Z2 → Z3, plus the Namibia interconnector on its own line. Open Z3 — Import 4,000 MW, Export blank. Open Z9 — both blank, and the amber not represented sentence. The same JSON is on API (GET /api/v1/network-model).

Where this is taught. How a blank is stored (nil, not zero) and why a zero would forbid all export: the model code behind the card. Zone-constraint flags (runtime, not this listing) are §5.5. The OpenAPI body: V13 §4.5.

3. Notices

The Market Operator’s notice board is text — a general announcement, a stress message, a price-cap event (V9 §9). You read it. It does not, by itself, change what your plant must do or what you are paid.

The System Operator’s notices are facts that do something. One of them tells a plant to move. One of them is only a banner. One of them is a signed receipt that a unit now exists. Treat them as optional reading and you can be dispatched correctly and settled wrong.

This chapter first sorts those facts into four kinds, with a worked example and the impact on whoever receives each one. Then it slows down on the kind that costs money: the instruction (§3.2 onward).

3.1 What the System Operator notifies

Think of four pigeonholes on this desk. Every notice that leaves /so goes into one of them.

An empty list in any pigeonhole means nothing of that kind was sent. It does not mean the network is unconstrained. That distinction matters on the zone-constraint API and on Daily’s chalkboard.

Acknowledge is part of an order. On the BRP feed, SO Acknowledge calls the System Operator — it is not a local tick. A failed ack stays on the card and you can retry. A later query without the acknowledgement is a weaker query (§3.6).

Kind 1 — Orders

An order names a plant, a window, and what it must do. The desk issues it on /so. The BRP receives it live on Market › SO (/org/brp/so) — no refresh. The kinds you will see:

Example — a curtailment the BRP can add up. Seat: System Operator. Window 11:00–13:00 SAST, cap 8 MW, deemed 65.0c/kWh. The live preview (and then the BRP card) shows 17.11 MWh curtailed and deemed R 11,121.50 — the same two numbers, by construction (§4.3).

The order is three things together — a level, a time, and a ramp rate. The energy credited is the area under that ramp, not a step at the instruction minute. The working for 475.234 MWh is §3.3–§3.4.

Two extras that travel with an order

The commercial log. When the order curtails a solar or wind farm in an emergency, the Code wants a second entry in a commercial log. Same weather, same output: with the log the shortfall can settle at the unit’s own offer (often R 0 for a renewable); without it the whole shortfall can reprice at the balancing price. Worked 25 MWh: R 0 vs −R 68,571.50 (§3.6). The receiver of that paper is settlement and the BRP’s evidence pack — not a second card on the feed.

A missed hour. The moment one manual order issues, this desk must instruct every later hour until it hands control back. If 19:00 starts and there is no new order, that is a missing-instruction breach — a compliance gap on the SO side and a participant about to be settled against a stale level. It is surfaced (#missing-instruction-breach), not quietly filled with yesterday’s number (§3.5).

Careful. Do not issue a kind-2 warning to obtain curtailment treatment. Only a targeted order has a window, a quantity and a preview that can support an instructed imbalance split.

Kind 2 — Warnings

A warning is SYSTEM_CONDITION: LOW / MEDIUM / HIGH. The desk sets it once; every active BRP’s Bid Desk shows a banner.

Example. The SO sets grid stress to HIGH. Trader 1 opens Bid Desk and sees the banner. There is no target site, no MWh, no 17.11 MWh line.

Use it so a BRP does not mistake a market message for a dispatch command. If you need a plant to move, issue a kind-1 order.

Kind 3 — Registry notes

A registry note is a dated row: this happened on the books. The Code requires the System Operator to be told, and to be able to prove it was told. That row is a RegistrationNotice. It lands on /so/registry → Inbox. Acknowledge is a signed receipt, not a courtesy tick (§6).

Example A — a new plant. A participant finishes the wizard. The Inbox shows Trading unit registered. The SO acknowledges. The IPPs tab gains a row (0.000 certified reserve until this desk certifies). The Market Operator can see the same share.

Example B — a zone is tight now. On Network Model → Map the SO raises an export flag on Z3 for this afternoon (§5.5). That is not a sentence in the published model. It is a runtime fact. A RegistrationNotice (ZONE_CONSTRAINT_RAISED) goes out.

An empty flag list means no flag is in force — not that the endpoint is empty, and not that the network is unconstrained. GET /api/v1/network-model/zone-constraints says so in the note.

Kind 4 — Day-ahead facts

Before the Market Operator can publish tomorrow’s schedule it must be told three things this desk owns: demand, reserves, interconnect. Those arrivals are the three traffic lights on Bidding → Daily (/mo/bidding).

Example. It is 12:00 the day before. Interconnect is due at 13:30. The interconnect pigeonhole is empty → the light is Unknown (still time). At 13:10 a message arrives → Present. At 13:31 with nothing in the hole → Late, and Daily’s exception list says the 14:00 publication is at risk (§1.4).

Follow along. Seat: so@webill.net. Path: Dispatch Desk (/so) → Issue — issue a CURTAILMENT and read the preview. Then trader_1@webill.net → Market › SO — the same MWh and R on the card; SO Acknowledge. For a warning: on /so set System condition to HIGH, then open Bid Desk on the BRP seat — banner only. For a registry note: Registry → Inbox. For the lights: mo@webill.net → Bidding → Daily.

Careful. Kind 2 is not a cheaper way to write a kind 1. Kind 3’s empty flag list is not an all-clear. Kind 4’s green Present is not “the network is healthy.”

3.2 SO instructions

Kind 1 in detail — the order that changes Instructed Energy. If you only needed the four pigeonholes, §3.1 is enough.

Screen: Market › SO (/org/brp/so) and the hour drill-down on Bid Desk › Settlement. Both mount #instructed-energy-view — the ramp-segment table and the clause 13.4.1(3) dispute control. An hour without an instruction says so (#instructed-energy-empty).

Acknowledge calls the System Operator API. The tick on the card is the local projection of that round-trip; a failed ack stays visible and is retryable. Production uses SoGateway.Http, not the IPP-A mock.

The feed shows instruction reasons, control_state (schedule_standing vs so_controlled), and the consolidated clause 14.2(1) dispatch report. The moment the System Operator takes control, clause 11.4(10) obliges it to instruct every subsequent period and clause 13.5(4) removes your 5 % metering allowance. A missing instruction under so_controlled is a compliance breach (#missing-instruction-breach) — the standing schedule is not a fallback.

Availability revision (#availability-revision-form) posts /availability-revisions. A revision after the period has started is refused with clause 11.1(3)–(4) named. Dispute this value posts /instructed-energy/disputes. Event subscription is on the same page; poll-by-refresh (GET /events?since=) is labelled as the §16(2)(f) fallback.

The System Operator runs the physical system. It can tell your plant what to do, and what it tells you decides what you are paid — not through a tariff, but through a number called Instructed Energy.

3.3 What an instruction actually is

Not “reduce output”. An instruction is three things together:

Be at 480 MW, at 18:20, ramping at 8 MW per minute.

A level, a time, and a rate. Your plant cannot teleport, so it ramps — and the energy the market credits you with is the area under that ramp, not a step change at 18:20.

That is why the ramp rate matters. Getting from 465 MW to 480 MW at 8 MW/min takes 1.875 minutes, so the ramp starts at 18:18.125 — before the instruction time. Those 1.875 minutes are worth 0.234 MWh in the hour, and they are yours.

The rate is not something the System Operator picks freely. It comes from your registered rates, chosen by the transition: starting up to your minimum uses the start-up ramp, loading from minimum to maximum uses the loading ramp, coming back down uses the de-loading ramp, and shutting down uses the shut-down ramp. A transition that crosses your minimum takes the slower of the two — anything else would instruct a trajectory your plant cannot follow.

Note. Every instruction we show you names which of your four rates was applied and the clause it came from. On a plant whose start-up and loading rates differ by a factor of four, the wrong pick is a real number.

3.4 Instructed Energy, and why we show you the working

Instructed Energy is the megawatt-hours you would have delivered had you followed instructions exactly, ramps and all. It is the yardstick your delivery is measured against, so the System Operator, the Market Operator and you must all arrive at the same figure.

We show you the segments, not just the answer:

28 514.0625 ÷ 60 = 475.234 MWh. Sanity check: 20 minutes at 465 plus 40 at 480 is 475.000; the ramp starting 1.875 minutes early adds the 0.234.

You can add those up yourself, and if your arithmetic disagrees with ours the Market Code lets you dispute the value and have it adjudicated. The table is the evidence — which is exactly why we publish it rather than the single number.

Note. The Code’s own formula has no case for a couple of situations that arise every day — including a down-instruction at the top of an hour. We compute the trajectory directly, which answers all of them, and we say so on the figure rather than quietly filling the gap.

3.5 Once the System Operator starts dispatching you, it must keep doing so

This is the trap, and it costs money.

Ordinarily nobody instructs you at all: your most recent intraday schedule is the instruction, your Instructed Energy equals your Contracted Energy, and your 5 % metering allowance applies — a deviation inside it settles at the market price with no penalty.

The moment the System Operator issues one manual instruction, two things change together:

1. it takes on an obligation to instruct you before every subsequent hour of the day; and
2. your metering allowance stops applying for every hour that carries an instruction.

So a single instruction at 18:20 changes your exposure until the System Operator explicitly hands control back. A deviation that would have been free at 21:00 is now priced.

Careful. Nothing in the volumes tells you this happened. The desk shows a banner the moment a unit moves under System Operator control, and it says what changed in plain words. That banner is the only signal you get.

If the System Operator takes control and then fails to instruct you before an hour starts, that is a breach of its own obligation — and we surface it rather than quietly reusing the last instruction, because the last instruction may be hours stale.

3.6 A curtailment only protects you if it is logged commercially

The most valuable thing in this chapter for a renewable.

When the System Operator curtails a non-dispatchable unit — a solar farm, a wind farm — under an emergency or to reduce load, the Market Code requires that instruction to be duplicated into a separate commercial log. That duplicate is what makes it an instruction for settlement purposes.

The same physical curtailment then settles two ways:

Identical weather, identical output, identical telemetry. The difference is whether somebody made an entry in a log you cannot see.

So we check for you. We reconcile the curtailments we received against the commercial log the System Operator publishes, and where one is missing we raise it as a settlement query on your behalf — with the instruction, your acknowledgement, the telemetry and both Instructed Energy figures already attached. We do it at D+7, before the balancing statement is final rather than after the money has moved.

Note. Acknowledge instructions on the feed. The acknowledgement is part of the evidence bundle, and a query with it is a stronger query.

3.7 Two places to report a problem, and they do different things

If cloud arrives and you cannot deliver, there are two people to tell, and telling one is not telling the other:

Do the first and not the second and the outcome is precise: you are dispatched correctly, and then charged imbalance against a schedule you never corrected.

Careful. The revision screen and the API both say this at the moment you revise, and both give you the intraday gate you still have time to lodge against. It is the one warning in this manual written because the failure is silent, expensive and entirely predictable.

3.8 Read an instruction as an operational constraint first

An instruction changes what your asset is allowed to do. Investigate it before rebuilding a bid around it: the desk can show the condition, but it never turns an instruction into commercial advice.

Every instruction we show you carries its reason code. The Code entitles you to the reasons on request; we put them on the record without the request.

Where this is taught. V9 §5 owns the intraday market and Contracted Energy. V9 §13 owns the day-ahead money. Balancing — what happens to the difference between Instructed Energy and your meter — is V9 §6. Issuing from this seat is §4.

Data. full_demo · seed 42 · stage S08 (market loop) · ramp rates and the 5 % allowance come from the registry and the published market parameters.

4. Dispatch Desk

The Dispatch Desk is the room where you tell a plant what to do today. It is the first item in the SAWEM SO sidebar. The path is /so. You land here when you pick the System Operator card on / and sign in as so@webill.net.

Think of it as the radio in an air-traffic tower. The Network Model (§5) is the map of the runways. The Registry (§6) is the list of licensed aircraft. This desk is where you speak to a specific flight: slow down between 11:00 and 13:00, or the weather is bad for everyone.

The desk writes the same instruction row the Balance Responsible Party later sees on Market › SO (/org/brp/so). There is not a second, quieter copy. If the preview says 17.11 MWh, the BRP card says 17.11 MWh. That equality is the first check that the two seats are looking at one fact.

Where this is taught. What an instruction is, and how it changes Instructed Energy and imbalance, lives in §3. This chapter is the screen you press.

4.1 The operator’s problem

A cleared market schedule is a price answer. The grid is a physics answer. Those two answers disagree. A solar farm may be scheduled to inject 16 MWh in an hour when a corridor can only take 8 MW. Somebody has to clip that plant, write down why, and leave a paper trail so the Market Operator can pay for the clip under ancillary rules — not by quietly changing the day-ahead energy price everyone already paid.

That is this desk. You do four jobs here:

1. Set the grid-wide stress banner (System).
2. Issue a targeted order.
3. Watch which orders are still live (Active).
4. Prove what you already sent, and whether the BRP has seen it (Issued).

4.2 How the page is laid out

The page title is Dispatch Desk. The subtitle is Issue dispatch, curtailment and outage instructions and set the grid condition. If a simulation is running, a slim amber simulated ribbon sits under the title so you never mistake a lab run for the live grid (V21).

Under that sit four tabs, same tabs tabs-bordered chrome as Network Model. Each tab is a patch link — the address bar changes, the sidebar does not.

You land on System (§4.6). Issue is the second tab (§4.3). Nothing on Active or Issued can issue a new order. Nothing on Issue shows the history table.

4.3 Issue — the instruction form

Open the Issue tab (/so?tab=issue). The card is headed Issue instruction. This is the targeted order: one BRP, one site, one window. It is not a broadcast. Filling it is like filling a flight strip before you talk to the aircraft.

Every field below is required for a clean issue. If a required piece is missing or the window is backwards, the desk flashes Could not issue the instruction (check the fields) and writes nothing.

Once a Target BRP and a Cap are set, a Ranked reduction options strip (#so-issue-ranking) appears above the preview. Two cards sit side by side: Priced demand response (Prefer when a curve covers the need) and Unpriced shedding (Passed over, or Last resort when nothing is priced). Under them a table lists each block — available, price, taken, and why anything was skipped. The need is the Cap you typed. Read it before you press Issue. The worked numbers are in §4.10.

The last row of the form is not a field. It is the live preview (amber, only for Curtailment once the form can compute) and the Issue instruction button.

Note. Changing any field recalculates the preview immediately. You do not press a separate Preview button. Issue is the only submit.

4.4 What each Kind means

Kind on Issue is five coloured cards (#so-issue-kinds). Each card shows the title and, under it, the brief description — that is why there is no i icon. The same colour is the badge on Active, Issued, the IPP Notices tab (§6.4), and the BRP Market › SO feed. A sixth kind is written only from the System tab (§4.6).

Careful. Do not issue a SYSTEM_CONDITION to obtain curtailment treatment. Only a targeted order has a window, a site, a quantity and a preview that can support an instructed-imbalance split. The stress banner is context. It is not a command.

4.5 The live preview — why the two seats must agree

When Kind is CURTAILMENT and the form has a target book, a date, a forward window, a cap and a deemed price, an amber strip appears:

Forecast-shape effect: 17.11 MWh curtailed · deemed R 11121.50

That is not a guess you type. The desk reads the target book’s forecast for each hour in the window, subtracts the cap, and adds the leftovers. Then it multiplies the leftover energy by the deemed price.

Worked example — the teaching clip.

Data. full_demo · seed 42 · stage S08 (market loop) · the console test plants 16.40 MWh and 16.71 MWh in the two hours.

Step the arithmetic:

1. Hour 11 leftover: 16.40 − 8.00 = 8.40 MWh.
2. Hour 12 leftover: 16.71 − 8.00 = 8.71 MWh.
3. Curtailed energy: 8.40 + 8.71 = 17.11 MWh.
4. In kilowatt-hours: 17.11 × 1,000 = 17,110 kWh.
5. Deemed rand: 17,110 × 65 ÷ 100 = R 11,121.50.

Those two numbers are stored on the instruction. The BRP card is not allowed to recompute a different story. If the preview is empty, the form is not yet complete or the book has no forecast in that window — do not issue hoping the card will invent a quantity.

Other kinds do not show this strip. There is no forecast-shape clip to preview.

4.6 System condition

The System tab (/so) is the landing page. The card is headed System condition. This is the weather warning, not the speed ticket. A stress banner is not mixed with a plant order.

Current shows the latest stress this desk has declared, or an em dash when none has been set. Under that sit three coloured cards (#so-condition-cards) — not a drop-down. The title is the level; the sentence under it is what it means. The chosen card carries a Selected chip.

Choosing a level writes a SYSTEM_CONDITION instruction for every ACTIVE registration, for the whole of the trading date the desk is holding (midnight to midnight SAST). The site ref on those rows is GRID. The Bid Desk on the BRP side may show a banner. That banner is context. It does not clip a plant and it does not create a curtailment line.

Note. This card is the stress selector that is actually on /so. The Market Code also knows an Emergency Operating Condition, a commercial log, and a duty to keep instructing a unit once you have taken it off its schedule. Those rules are taught in §3. They are not a fourth tab on today’s desk.

4.7 Active — constraints that have not finished

Active (/so?tab=active) is the “what is biting now” list. A row is here only while its window is still open. When the end time passes, the row leaves this table. The history does not vanish — it stays on Issued, and after end-of-day archive it remains readable as evidence.

Kinds that can appear here: CURTAILMENT, DISPATCH_CONSTRAINT, OUTAGE_PLANNED, OUTAGE_UNPLANNED. A SYSTEM_CONDITION is not an open constraint in this table. A RESERVE_ACTIVATION is not either.

If nothing is open the card says No open constraints.

Filters (shown only when at least one constraint is open):

If filters hide every row the card says No constraints match these filters. The open set is still there — you narrowed the view.

Columns:

This table does not show acknowledgement. Acknowledgement lives on Issued. Active answers only: is this still in force, on which site, at what cap?

4.8 Issued — the evidence book

Issued (/so?tab=issued) is every instruction this desk has written, newest window first unless you sort it. The table fills a scroll box; the headers stay put while you scroll.

If nothing has ever been issued the card says None issued.

Filters (shown only when at least one row exists):

If filters hide every row the card says No instructions match these filters.

Columns:

Action is not a button you press. You cannot acknowledge from this seat. The BRP acknowledges on Market › SO (/org/brp/so). This column is the receipt coming back. Both seats stay live: issue arrives on the BRP feed without a refresh, and the acknowledgement flips this column without a refresh.

4.9 Follow-along — issue the teaching clip

Follow along. Seat: so@webill.net (SO) with password supersecret. Path: System Operator → Dispatch Desk (lands on System) → Issue. You should see: the Issue instruction form.

1. Leave Kind on the Curtailment card (already Selected).
2. Choose a Target BRP that has a forecast for tomorrow (the seeded IPP book in the console test is the teaching target). Site ref fills itself from that book’s generator site — do not type it.
3. On Window, tap From 11 (sky row) and To 13 (violet row). Set Cap to 8, Deemed price to 65, Reason to network constraint.
4. Watch the amber preview: 17.11 MWh and R 11121.50. The ranked-reduction strip appears once the Target BRP and Cap are set.
5. Press Issue instruction. The flash is Instruction issued to the BRP. The form resets.
6. Open Issued. The new row shows the same 17.11 / R 11,121.50 and Awaiting acknowledgement.
7. While the window is still in the future, Active also lists it (Kind, Site, Window, Cap MW).
8. On the BRP seat, Market › SO (/org/brp/so) shows the same card without a refresh. Press Acknowledge. Stay on Issued: Action flips to Acknowledged by BRP ✓ without a refresh.

The next strategy run for that book can emit CURTAILMENT lines. Imbalance marks those hours excused (V9 §6, §3).

Where this is taught. §3 owns the instruction and the BRP feed. V3 owns allocation effects. V21 owns SO polling and archive operations. V11 owns MO money. This desk does not price clearing and does not settle a PPA. It preserves the order and its source figures so later rooms can explain the outcome.

4.10 Choosing what to reduce

Where you need load reduction — asking customers to use less, or switching them off — the Market Code says you must consider the total economic cost (§11.4(6)). In market terms that means preferring priced demand response (a customer who already offered a curve the merit order can value) over unpriced shedding (a blunt switch-off with no price).

Worked example — 20 MW, one hour.

Data. full_demo · seed 42 · Trading Day 2026-07-15 · hour 18:00 · TU-IND1. The consumption curve is the one in V9 §4.18.

The factory wants 90 MW this hour. It already told the market what each slice is worth:

You need 20 MW of load reduction this hour. Two ways to get it:

Priced demand response (Load Curtailment, §2.1(117)). Take the cheapest volunteered block: the 20 MW the factory already priced at R 1 500. The customer keeps the furnace and the higher-valued slices. The merit order can value the clip.

1. Priced rands: 20 × R 1 500 = R 30 000.
2. Unpriced megawatts: 0.

Unpriced shedding (Load Shedding, §2.1(119)). Disconnect 20 MW with no bid behind it — the furnace, or any load that never offered a curve. There is no price for the §14.3(2) cost report to write.

1. Priced rands: R 0.
2. Unpriced megawatts: 20.

That R 0 is the trap. If you score “total economic cost” as a single rand figure, shedding looks cheapest every time — which is the conclusion §11.4(6) exists to prevent. Cost is the pair {unpriced MW, priced rands}, compared in that order. Twenty unpriced megawatts lose to zero unpriced megawatts, even though the priced path costs R 30 000.

If you later need 70 MW, you still walk the priced stairs first: 20 at R 1 500, 20 at R 2 600, 10 at R 4 800 (R 30 000 + R 52 000 + R 48 000 = R 130 000), and only then shed 20 MW of must-serve. The record is {20 unpriced MW, R 130 000} — and the Reason on the Issue form is where you write that the priced stack was not enough.

Today’s Issue form ranks those options for you once a Target BRP and a Cap are set. The Ranked reduction options strip (#so-issue-ranking) shows the preferred cost pair (priced demand response first) beside the unpriced-shedding counterfactual, and the table of what would be taken or passed over. Issuing stores that ranking on the instruction so the §14.3(2) cost report can be produced. The Reason is still where you write why you issued anyway, if you pass over a cheaper priced block.

Unpriced shedding is last, not forbidden. Sometimes there is nothing else, and the record should say that is what happened.

Where this is taught. The instruction itself is §3. The form you press is §4.3. The consumption curve the merit order already holds is V9 §4.18.

5. Network Model

The Network Model is the picture of the wires this desk schedules against. The path is /so/network-model. The page title is Network model. The subtitle is Constrained scheduling model — zones, inter-zonal capability and SAPP interconnectors (§3.3(4)).

§2 taught why the country is cut into areas, and why one registration cannot straddle two of them. This chapter is the screen: every tab, every card, every number, and the live flag that is not part of the published picture.

Two different statements live on this page. Do not mix them up.

The map is not the flag. An empty flag list does not mean “the network has no limits.” It means “nobody has put a temporary sign on a zone today.” The model can still say a corridor is thin.

There is no Zones item in the sidebar. The old /so/zones address still works: it opens this page on Map.

5.1 The three tabs

Same tabs tabs-bordered chrome as the Dispatch Desk. Each tab is a patch link.

You land on Model. Model and Map share one right-hand drawer. Click a zone on either tab and the same card slides in. The drawer has Info and Constrain; flags are raised and lifted on Constrain. The drawer on Model does not offer “open the model” — you are already there. The drawer on Map does.

5.2 Model — the capability cards

The Model tab is one white card headed Constrained scheduling model, plus a monospace version stamp (today that is often PROV-2026-07). The short text says these are the zones and inter-zonal capability this desk schedules against, and that capability figures stay labelled assumed until you publish under §3.3(4)(b).

There is no API button on this card. That used to open /api/v1/network-model in a new tab. The call and the live body now live on API. There is no Show only my zones toggle: this desk always sees the full model. A BRP on /org/brp/so sees their own zones first. You are not a BRP.

The amber banner appears when the model is not yet an SO declaration. Read it as: these numbers are estimates, not your signed figure. Under the heading it lists blockers — the reasons the model cannot yet be published — then explains that each figure is derived from an assumed circuit complement, rated N-1 with a length derate. Each corridor states its own derivation. They are replaced by your own figures when you discharge §3.3(4)(b).

If no zone model is loaded the card says the model cannot be shown. Go to Map and press Load provisional zones.

Each zone card shows:

Click a card (cursor, hover border) to open the drawer. The drawer has two tabs: Info (the card, corridors, interconnectors) and Constrain (the §3.3(6) flag). Export and import capability are the sums of those corridors — they are not typed in. You can add a corridor to a zone that is not already connected, or a new SAPP interconnector. Click the same zone again, or close, to put it away.

The footer under the grid is three facts, not decoration:

Follow along. Seat: so@webill.net. Path: Network Model (/so/network-model). You should see Model / Map / API. On Model, click Z1 — the drawer opens; there is no API button on the card.

5.3 Map — the country drawn

Map is the former /so/zones page. It answers where is this zone on the ground? and shall I put a temporary sign on it?

Banners at the top of the page:

Zone map card:

Registry table under the map (only when zones are loaded):

Click a row to pan the map to that zone and open the same drawer. The selected row is shaded. This table is not the participant Registry in §6. It is the zone register — a list of areas, not a list of plants.

The nine provisional rows and what they imply are taught in §2.1. Do not re-plan a portfolio from this table until the model is published (§2.3).

5.4 The zone drawer

The drawer is a right-hand panel. The backdrop click, or the X, closes it. The title is Z1 · Northern Corridor Zone (code, then name). Two tabs sit under the header: Info and Constrain. You land on Info.

Info

1. The same zone card as on Model — capability, corridors, interconnectors.
2. Edit capability — Export and Import are read-only sums of the corridors. Edit MW on each listed corridor, or on each SAPP interconnector attached to this zone. A one-way corridor also offers the empty reverse so you can declare the other direction. Add corridor declares one or both directions against a counterpart that is not already connected — zones that already have a corridor with this one are omitted. Each remaining zone in Select a zone is preceded by its colour dot. Add SAPP interconnector attaches a named cross-border tie to this zone. Save capability writes the listed figures over the assumed estimates. A blank corridor field returns that number to the estimate. Saved figures show a green declared chip. This is the model, not a flag. Every open SO Network Model desk and every BRP Market › SO (/org/brp/so) picks the change up without a refresh.
3. On Map only: Open full network model, which patches back to the Model tab.

Constrain

The §3.3(6) constraint flag form (§5.5) — a temporary sign, not a change to the wires.

5.5 Zone constraint flags

Path: Network Model — open a zone’s drawer, then Constrain. This is the missing half of §3.3(6), and it is yours, not the Market Operator’s. The MO Zones panel shows the same flags read-only.

A flag is a temporary “lane closed” sign. It is not a change to the published model. GET /api/v1/network-model/zone-constraints returns the flags in force. An empty set means no sign is up — not that the endpoint is missing, and not that the network is unconstrained.

Why it matters to money. While a flag is up, members of a Balancing Group who are pushing in the constrained direction drop out of the group for those Trading Periods only. That is a computed exclusion from AE − SE (actual energy minus scheduled energy), not a status you store on the group. See V9 §3.6 and V9 §6.7.

Raising a flag — every field:

As you change the form, an impact preview appears in amber:

N groups across M parties have members in Z1; under an export constraint their cover lapses for members delivering above schedule.

Read that before you confirm. You are making a network decision with a settlement consequence. The preview is so you can see the blast radius.

Flag constrained writes the flag, notifies the Market Operator and every affected party (RegistrationNotice), and flashes how many groups and parties may lose cover.

Flags already up list in the same card:

Lifting early is not a delete. It is a dated event: the sign was up, then it came down, and both moments are auditable.

5.6 API — the same facts as JSON

API is not a second model. It is the public HTTP contract for the picture you are looking at, plus the live body this deployment returns. The heading is OpenAPI — network zones and constrained scheduling model. The prose says these are public open data (§3.3(4)–(6)), the same operations as GET /api/v1/publication/openapi.

OpenAPI document opens that document in a new tab. Field semantics and who may call the routes are V13 §4.

Six operation cards, each with a method pill, the path, a one-line summary, optional description, then Request and Result blocks with Copy request / Copy result:

The first three are the §2.4 zone-register calls. The last three are the model and the runtime flags. Copy a request when you are showing an integrator what to send. Copy a result when you are showing what this environment actually contains.

Follow along. Seat: so@webill.net. Path: Network Model → API. The first card is POST …/allocate (Kathu, nearest Z1), then the two register GETs, then GET /api/v1/network-model. Copy a request, then its result.

6. Registry

The Registry is the room where you are told about plants, and where you agree how much reserve they may offer. The path is /so/registry. The page title is Registry. The subtitle is §7.1(2) registration notices, registered IPPs, and §7.2(q)–(t) certification decisions. Certified capacities are agreed here — never typed in by a participant.

Think of a driving-licence office. The participant fills in the form (the standing-data wizard). The Market Operator checks the file. You are the examiner for the four reserve stamps. Until you stamp them, the licence says 0.000 — and every reserve box on every bid must say U (unavailable). The student cannot stamp their own licence. That is why those four figures never appear as type-in fields on the participant wizard.

You also sign for the share of the register. When a Trading Unit is born, changed, or given a new Point of Delivery, a notice lands in your Inbox. Acknowledging it is the auditable §7.1(2) tick. You can also pull the full register with GET /internal/mo/registry. The push and the pull are the same share.

Where this is taught. What the thirty standing-data questions are, and why a silent zero is dangerous, lives in V9 §3.7. This chapter is your side of that file: the list, the inbox, the stamp, and the per-plant page.

6.1 The three tabs

Gold underline, each with a count pill. The count is the number of rows behind that tab, not a to-do badge with a different meaning.

New filings arrive live from the participant wizard. You do not refresh to see a new unit.

Follow along. Seat: so@webill.net. Path: Registry (/so/registry) → IPPs. Type a site, organisation, or BRP ref in the search box. Click IPP / site or MCR to sort. Hover a row, then the eye View. Inbox and Certification Queue keep their counts on the tab.

6.2 IPPs — the plant list

The card heading is IPPs — N. When a search is on it becomes N of M. The table fills the viewport; headers stay put while you scroll. Hover a row (amber).

Search. A box above the table. It matches site name, organisation name, or BRP ref. It does not invent plants. No IPPs match the current search means your filter is too tight, not that the register is empty. No generator sites have been registered with the market yet means the register itself is empty.

Sort. Click IPP / site or MCR. Click again to reverse. A chevron shows the direction. Other columns do not sort.

Columns:

There is no Certify / Chase / Suspend unit row of buttons on this desk. Those are Market Operator ops actions. Your certify action lives on Certification Queue, not on this table.

6.3 IPP detail — the three inner tabs

The per-plant page has a Registry back link, then a header whose title is the site name and whose subtitle is organisation · BRP ref · TUID.

Three iconed tabs:

You cannot edit standing data here. The participant supplies values with a provenance. You read. You stamp reserve on the queue.

6.4 IPP detail — Info

Completeness gate (amber, only when the unit cannot yet register): TUID cannot be registered: N of 30 fields have not been supplied. This is a work list, not an error. Missing fields are grouped by who can answer them — plant engineer, System Operator, finance — because those people work on different clocks. Each missing row shows the field label, the unit (MW, h, …), and the clause.

The field editor (read-only on this desk) is headed TUID — every §7.2 field, grouped as the Code groups them. Each row has: the label, the clause, the value (or an em dash), a provenance chip, and who owns the answer.

Provenance is where the number came from. A blank is not written as zero.

A solar farm’s minimum run time of 0 with engineering data is true. The same 0 with not supplied is a trap: the market would think it may cycle a coal plant hourly.

MCR basis is a sentence under the groups: which of the site’s three capacity figures (installed, inverter, export) was chosen as the sent-out rating, who decided, and why. If it says not recorded, nobody has said which number is “the” capacity.

Capacity group — §7.2(e)–(f), §9.3(4)(c)(vi)

Start-up profile — §7.2(j)

A start is hot, warm, or cold depending on how long the unit has been off. Think of an oven: still warm, cooling, or stone cold. Each flavour has a ramp, a cost, and a lead time. There is no cold threshold — cold is every start above the warm threshold.

Run-time limits — §7.2(k)–(l)

This is the dangerous-zero pair.

Ramp rates — §7.2(m)–(p)

Four rates, not one. Instructed Energy is the area under the ramp (§3), so the wrong rate is money.

Certified reserve capability — §7.2(q)–(t)

These four rows also have their own Reserve tab. On Info they appear in the catalogue. They are yours to agree, not the participant’s to type. Until you certify, the value is 0.000.

Settlement — §7.2(c)

Classification — §7.2(g)–(h), §2.1(63)

6.5 IPP detail — Reserve

The Reserve tab is the same four rows as the catalogue group, laid out as a board the Code can audit.

There is no “request certification” form on this desk. The participant starts the request. You answer on Certification Queue.

6.6 IPP detail — Notices

Instructions to this BRP. Every SO instruction issued to the target BRP, not only this site. A system-condition row for that BRP appears here too.

If none have been issued the card says None issued.

Each card shows:

This is a reading room. You do not issue from here. Issue lives on §4.

6.7 Inbox

The card heading is Registration inbox — N. Empty state: No outstanding notices.

Each row is a RegistrationNotice — a signed slip that the shared register changed.

Acknowledge is not “I approve the plant.” It is “I have seen this change.” Certification is a different stamp, on a different tab.

Kinds you should expect, in plain words:

6.8 Certification Queue

The card heading is Certification queue — N. The helper line: §7.2(q)–(t) capacities are agreed by the SO. Certify with a figure and reference, or decline with a reason. Empty state: No pending requests.

Each pending card shows the request, then a form.

On the request line:

Form fields you fill:

Buttons:

Bounds you should know before you stamp:

• Regulating and Instantaneous may not exceed the unit’s MCR. A unit cannot hold more reserve than it can produce.
• Ten-Minute is not bounded by MCR here. It can be met by starting a unit that is offline.
• SCO is not compared to MCR. Comparing MVAr to MW is a category error, not a conservative check.

Until you decide, every reserve availability indicator in every submission for that category must be U. Declaring A against an uncertified capacity is rejected. That is the whole point of this room: the market must not sell standby that you have not agreed the plant can hold.

7. Curtailment claims

The IPP registry detail has a Claims tab alongside Info, Reserve and Notices. It shows current claims for the selected unit, with method, status, deadline and payment evidence. The Dispatch Desk’s issued-instruction table adds a Claims column so the operator can follow an instruction into the recovery workflow.

The plant’s estimate remains distinct from the final determination. A provisional payment does not close a claim. The NERSA curtailment-cost export carries final paid cost, regime, claim reference and unrecovered value; missing determination stays missing. A Mock receipt is simulated and is never evidence that NTCSA received a claim.

The IPP’s curtailment chapter explains what a claim is, how the ended instruction creates it, how deemed energy is calculated, who may lodge, the 48-hour clock, evidence bundle, lodge and pay path, dispute and close, and both worked monetary examples.