V1 · The Four Rhythms

1. Why the clock exists

Much of the platform’s work happens without anyone signing in. Background jobs settle closed periods, re-forecast every book, build and submit market bids, poll the System Operator and reconcile the Market Operator’s files — on a fixed SAST clock. Knowing the clock explains why screens change overnight and what “it will be there in the morning” actually means.

This volume is the home for that clock. It amalgamates the orientation preview (V0 §6), the trader operating cadence (V3 §18), and the operations index (V21 §3) into four rhythms you can learn end to end — each with what runs, how it runs, what you see, and a data-driven example.

1.1 The four rhythms at a glance

Two contract triggers run alongside the scheduled jobs: daily activation of SIGNED physical PPAs whose start date has arrived; hourly expiry of stale proposals. They are not a fifth rhythm — they keep deal state honest while the four rhythms turn (§6).

1.2 How to read this volume

Each rhythm chapter follows the same shape:

1. Problem — what would break if this rhythm stopped.
2. Process — step-by-step what the job does and how.
3. Schedule — when it fires (SAST).
4. Worked example — numbers from full_demo · seed 42, with figures.
5. What you see / what you do — seat-facing consequences.
6. Bridge — where screens and formulas are taught in depth (V3–V8).

Data. Unless a chapter stamps otherwise: full_demo · seed 42 · stages S04/S09 · sealed 2026-07-15 · times SAST per the platform schedule.

Careful. The spine in every volume is a reading map. The clock is the operating map: strategy runs nightly whether or not you are dealing; the market day loops daily; settlement re-runs when late data arrives. This volume teaches the operating map.

1.3 The market clock, and why it is simpler than most

The wholesale market has its own clock, nested inside the platform’s. Three periods and one offset are the whole of it.

Every timestamp is +02:00, never Z. South African Standard Time is a fixed two hours ahead of UTC and South Africa has no daylight saving. So a market instant is written 2026-07-15T18:00:00+02:00 — with the offset spelled out, never a bare Z and never a bare local time like 2026-07-15 18:00. A timestamp without an offset is the single easiest way to settle the wrong hour, and an hour is real money.

A Trading Period is one hour, starting at minute 00. Volumes, prices and penalties are all per Trading Period. The finer data the market also requires — five-minute and four-second — is evidence, kept and reported and used to justify instructions; it is added up to hours before any money is calculated.

A Trading Day is always exactly 24 Trading Periods. No 23-hour spring-forward day, no 25-hour fall-back day, no repeated hour. This is a genuine simplification over European markets, and the platform asserts it rather than assuming it — if the country ever adopts daylight saving, the assertion fails loudly on the first affected day instead of quietly dropping or duplicating an hour’s money.

Two counters, and neither counts calendar days. Settlement deadlines are stated in business days — not Saturdays, not Sundays, not gazetted South African public holidays.

Long weekends move these dates and are meant to. Good Friday 2026 is 3 April and Family Day is 6 April, so SD+1WD from Thursday 2 April is Tuesday 7 April — a four-day close. The holiday list is published data, not built into the platform: a mid-year gazette is absorbed by republishing the settlement calendar, with nothing to redeploy.

Careful. SD+7WD (when your query window closes) and D+7 (when verified metering is finalised) are counted differently — business days versus calendar days. In a week with a public holiday they fall on different dates, and the mismatch is a known gap in the published Market Code rather than something the platform chose.

2. Rhythm 1 — the settlement chain (gold)

The problem: a signed PPA says who sells energy to whom, and at what price — but it does not, by itself, say how much energy actually moved yesterday, or how many rand that is worth. Meters keep ticking; the commercial answer has to be computed after the clock closes a slice of time. Without a scheduled settlement run, those slices never become a shared bill: parties argue from different spreadsheets, and nothing is ready to send as a statement.

2.1 Words first — what settlement is talking about

Before the nightly job, six ideas:

Settlement is the platform’s job of turning what happened in a closed slice of time into who owes whom. It reads meters (and nominations where the contract uses them), applies the PPA’s price and network charges, and writes money rows both parties can inspect. Deep dive: V8.

A window (also called the period) is that closed slice. For a daily contract it is one calendar day; for a monthly contract, one calendar month. The contract’s settlement frequency chooses how often windows close. Each contract × window becomes one settlement period record on screen — the place you open Energy balance and Ledger for that day or month.

The ledger is the double-entry money book for that period: every rand that appears for one party appears equal-and-opposite for another, so the rows sum to zero (Σ = 0). Individual rows are line items (energy, losses, UoS, and so on).

An adjustment is a correction the pipeline adds on top of the plain energy price — for example spill (generation nobody used), shortfall (demand the PPA did not cover), or banking (unused wheeled energy carried forward). Adjustments are written as their own line items so a closed period is never silently rewritten.

A statement is the document each party reads: the same ledger, filtered to their seat, versioned and hashed. IPP2 sees a receivable; OffTaker C sees a payable — one truth, two views.

Chain reconciliation (“chain recon”) is a second check, mainly on the 1st after monthly settle. When energy passes IPP → trader → off-taker on linked PPAs, recon asks whether volumes and trader margin still add up across those legs. It is not the same as matching a Market Operator invoice (V9 §8).

Note. Status words you will see on a period — DRAFT → PRELIMINARY → FINAL — mean “still computing”, “numbers are in but may change if a late meter arrives”, and “frozen for the statement”. Detail: V8 §11.

2.2 What the process does

The settlement chain is the gold rhythm: on a fixed SAST schedule it closes each window and runs the pipeline so ledgers and statements appear without anyone signing in.

1. Select frequency — the runner wakes for one frequency (DAILY, WEEKLY, MONTHLY or QUARTERLY). Only contracts on that frequency are in scope for this wake-up.
2. Open the period for the closed window — for each ACTIVE contract on that frequency, create or refresh the settlement period that covers the window that just ended (yesterday, last week, last month, …).
3. Run the five-stage pipeline — Resolve → Match → Price → Adjust → Ledger (V8 §2):
   • Resolve gathers metered (and nominated) kWh for the window.
   • Match pairs supply with demand and applies losses.
   • Price applies the PPA tariff (and related network charges).
   • Adjust adds spill, shortfall, banking and similar corrections.
   • Ledger writes the zero-sum line items.
4. Chain reconcile (monthly) — after monthly settle, trader chains are checked so volumes and margin still add up across legs (V8 §10).
5. Issue statements — on finalisation (or on demand), each party gets their filtered, versioned view of the ledger (V8 §9).

2.3 When it runs (SAST)

2.4 Worked example — daily physical thread

Data. full_demo · seed 42 · stage S09 · physical PPPA-202607-138209764 (IPP2 Atlantis Wind → OffTaker C Midrand DC, FIXED 85 c/kWh, DAILY) · period 2026-07-09 · DRAFT.

Step 1 — wake at 01:00. The DAILY runner selects every ACTIVE daily contract. The thread PPA is in that set. The closed window is calendar day 9 Jul 2026.

Step 2 — Resolve. Supply from MTR-NERSA-GEN-1002 = 41,418.44 kWh; demand from MTR-OTS-thin_offtaker_c_private = 38,933.333 kWh (after any late-meter re-settle — V0 §3.3 · V8 §3).

Step 3 — Match. matched = min(41,418.44, 38,933.333) = 38,933.333 kWh. At 6% loss, delivered = 38,933.333 × 0.94 = 36,597.333 kWh. Spill on supply = 41,418.44 − 38,933.333 = 2,485.107 kWh.

Step 4 — Price. Seller energy at 85 c/kWh on delivered: 36,597.333 × R 0.85 = R 31,107.73.

Step 5 — Ledger. Equal-and-opposite energy lines (network/UoS add their own zero-sum pairs):

Step 6 — Statement. IPP2’s statement shows a receivable; OffTaker C’s shows a payable — same rows, filtered seats.

2.5 What you see / what you do

Where this is taught. Pipeline, statuses and UI: V8. Worker card: V21 §3 · SettlementRunner.

3. Rhythm 2 — the strategy loop (purple)

The problem: your portfolio does not sit still overnight. Wind and solar forecasts change, load shapes drift, a battery schedule ages, a new PPA member appears on a pool, yesterday’s market clearing taught you something about tomorrow. Strategy is the seat where you plan that portfolio — what you expect to generate, what you expect to sell or buy, and whether the plan still fits your risk limits.

If that plan is not refreshed on a clock, three things go wrong at once:

1. The numbers on Overview become yesterday’s story — you cannot tell whether margin, coverage or spill still look healthy.
2. Flexible delivery commitments for next month are never drafted for you — you either miss the external nomination deadline or invent quantities by hand.
3. When the market desk builds tomorrow’s day-ahead bid at 03:00, it has only a stale open position to offer or buy — so you either miss the gate or bid the wrong megawatts.

The strategy loop is the purple rhythm that keeps the book decision-ready: nightly re-forecast, a monthly look-back against reality, and a mid-month nomination draft — each feeding a different decision.

3.1 Words first — book, KPI, nomination and DAM

A book is one party’s whole strategy portfolio on the platform — its pools, members, runs and risk limits. Traders, off-takers and IPPs each get a book the first time they open Strategy. Think of it as the planning workbook for that seat.

A KPI (key performance indicator) is a headline number the engine computes from a run so you can judge the book at a glance — for a trader, things like margin, coverage %, spill % and shortfall %; for an off-taker, bill saving; for an IPP, realised R/MWh. Overview cards and directory chips are just KPIs made visible. They are only as fresh as the last completed run.

A risk snapshot is the frozen daily copy of those KPIs (plus limit checks) written after the nightly run. Re-running the same calendar day updates that day’s snapshot; it does not create a second one. When Overview’s timestamp advances, the snapshot moved.

A nomination is a binding, hour-by-hour promise of how much energy a flexible member will deliver (or take) next month. Settlement later reads those quantities when there is no meter for that seat. A nomination plan is the workbench object that holds the draft: it moves PROPOSED → APPROVED → SUBMITTED. The 20th worker only creates PROPOSED plans — you still decide.

DAM means Day-Ahead Market. In plain terms: the day before electricity is delivered, registered parties must tell the Market Operator how much they want to sell or buy in each of tomorrow’s 24 hours, and at what reservation prices. That package is a DAM bid. There is a hard deadline — gate closure at 10:00 SAST the day before delivery. Miss it and the bid expires unsubmitted. (The IntraDay Market / IDM is a later correction window for individual hours; it is Rhythm 3’s story, not this one.)

A DAM position (also open or net position) is what the book is long or short after bilateral PPAs and the strategy allocation are applied — spill left to sell, or shortfall still to cover — hour by hour. The Bid Desk turns that position into a bid ladder. Without a fresh strategy run, the position is wrong even if the bid machinery works perfectly. Full market loop: V1 §4 · V9.

A BRP (Balance Responsible Party) is the registered party financially accountable for the gap between its market schedule and metered actuals. One registration can cover one or more books (V9 §3).

3.2 How KPIs, nomination proposals and DAM positions solve the problem

Put differently: the nightly run scores the book (KPIs), the 20th run prepares a commercial commitment (nominations), and every night’s position feeds the market desk half an hour later (DAM). One engine, three audiences.

3.3 What the process does

Three scheduled moments, one continuous loop:

A · Nightly re-forecast (02:30 daily) — RunNightly

1. For every strategy book (trader, off-taker, IPP), resolve BRP / BESS market inputs first when the book is market-wired.
2. Build a rolling 12-month forecast window (what generation and load look like ahead, under uncertainty).
3. Run a P50 allocation pass (central case), then a P90 stress pass (tougher case) — P50/P90 here are forecast grades, not market prices.
4. Dispatch any active BESS as part of the run.
5. Compute Margin@Risk, per-pool breakdown and limit checks → KPIs.
6. Freeze today’s risk snapshot. Derive the hour-by-hour open position the DAM build will read at 03:00.

B · Backcast (04:00 on the 4th) — RunBackcast

1. After prior-month settlement and recon have had time to land, build an ACTUAL strategy run for last month from settled actuals.
2. Score the book against what really happened — so KPIs can be compared to forecast, and nomination performance can light up.

C · Nomination proposals (05:00 on the 20th)

1. For every active nominated member, build a next-month nomination plan in PROPOSED state.
2. Skip members that already have APPROVED or SUBMITTED plans for that month — the worker never overwrites your commitment.
3. Expand hour templates into reviewable rationale (Cu/Co, q*, scenarios) for the Nominations workbench (V3 §9).

3.4 Worked example — T1 overnight, then one DAM hour

Data. full_demo · seed 42 · Trader 1 · T1 Renewables Pool book · BRP-T1-DEMO · stage S09. DAM ladder numbers from the BidBuilder canonical hour-12 example (V9 §4).

Nightly (02:30) — keep the book honest. The book has eight seeded pools, PPA-backed supply members, a firm demand member (OffTaker A in Trader Sales), Rosslyn BESS on Firm, and a nominated Flexible member.

Illustration — one hour inside the nightly run (open demand after firm cover; MWh; network losses ignored for clarity):

From that run to a DAM bid — hour 12 (canonical numbers). After allocation, some energy is still unsold (spill). For the noon hour the BidBuilder demo leaves two spill components — the book’s open long position:

At 03:00 (still the day before delivery) the market worker builds that ladder and submits it for BRP-T1-DEMO. Gate is 10:00. When the prototype clears at SMP R 980 / MWh, both rungs clear:

That revenue is only possible because the 02:30 run first computed the 6.71 MWh position. A stale book would have offered a different volume or missed the gate entirely.

20th at 05:00 — nomination proposal. Separately, the nominated Flexible member receives a PROPOSED plan for next month. Example evening cell (illustrative newsvendor shape from V3 §9):

That 7.5 MWh hour becomes three 20-minute nomination rows of 2.5 MWh each when you Approve → Submit — the grain settlement Resolve reads when the seat is meterless (V0 §3.3).

3.5 What you see / what you do

Where this is taught. Pools, runs, nominations, BESS: V3. Trader cadence summary: V3 §18. DAM mechanics and Bid Desk: V9 §1 · V9 §4. Workers: V21 §3 · RunNightly · RunBackcast · ProposeNominations.

4. Rhythm 3 — the market day (blue)

The problem: bilateral PPAs and the strategy book never cover every kilowatt-hour perfectly. Some hours you still have extra energy with nowhere contracted to go. Other hours you are still short and would otherwise top up from the grid at a high retail price. The wholesale market is the public place where those leftovers and gaps can be traded with other participants — but only if someone takes responsibility for what was promised to the market versus what actually happened on the meters.

That responsibility sits on a clock. The day before delivery you must declare how much you want to sell or buy. During delivery the grid operator may change your instructions. The day after, any gap between your cleared promise and metered reality is priced as a penalty or a poor recovery. Miss the declaration deadline and you never traded at all — the leftover or gap simply stays on your book.

The market day is the blue rhythm that runs that whole loop: declare → clear → deliver → price the difference.

4.1 Words first — BRP, market, bids and deviations

Who is on the market? The South African Wholesale Electricity Market (SAWEM) is operated by a Market Operator (MO) — the clearing house that receives bids, sets one clearing price per hour, and publishes the accepted volumes. The System Operator (SO) is different: it keeps the physical grid stable and can issue instructions (curtail a plant, change a dispatch) on delivery day. You talk to the MO about trades; you answer the SO about physics.

A BRP (Balance Responsible Party) is the registered legal party that may bid on SAWEM and that pays when its market promise and its meters disagree. Think of it as the account the market bills. One organisation registers once; that registration can cover one or more strategy books. In the demo the registration is BRP-T1-DEMO on Trader 1’s book. A book with no BRP registration never enters this rhythm — Strategy and Settlement still run; the market desk simply stays dark.

Why bid at all? Strategy already tried to match supply and demand inside your portfolio (§3). Whatever is left — spill you cannot place bilaterally, or shortfall you cannot cover from your PPAs — is your open position. Bidding puts that remainder onto the public market so you can:

• sell leftover energy for a wholesale price instead of letting it earn little or nothing, and/or
• buy missing energy at wholesale instead of paying a high grid top-up tariff.

If you never bid, those leftovers and gaps stay private problems. If you bid and clear, the market writes a schedule — the official MW the BRP is expected to deliver or consume each hour.

Sell bid vs buy bid. Direction follows the open position for that hour:

Markets quote R/MWh (rand per megawatt-hour). A useful conversion: 1 c/kWh = R 10 / MWh. SAWEM clears at a single SMP (System Marginal Price) per hour — everyone who clears trades at that SMP, not at their own rung. Offers clear when the rung is ≤ SMP; buys clear when the limit is ≥ SMP.

What is a deviation? After delivery, meters say what actually flowed. The imbalance (the priced form of a deviation) is:

imbalance = actual − scheduled

• Under-delivery (actual below schedule when you were meant to sell, or you consumed more than scheduled when you were meant to buy) is expensive — the prototype charges about 1.35 × SMP.
• Surplus (you over-delivered or under-consumed vs schedule) recovers poorly — about 0.65 × SMP.

So a deviation is not a moral failure; it is the bill for being wrong relative to the promise the MO accepted. Optimistic forecasts that clear big volumes and then under-deliver get punished on purpose.

Gate. The DAM gate closes at 10:00 SAST the day before delivery. Bids built or submitted after that expire — a gate miss. The platform builds bids at 03:00 so there is time to fix problems before 10:00.

IDM. The IntraDay Market is a later correction window for individual hours when the forecast drifts after the day-ahead clear. Same sell/buy idea, tighter deadline (delivery minus 60 minutes by default).

4.2 What the market day does

Relative to delivery day D, the blue rhythm does four jobs:

1. D−1 morning — declare. Turn the book’s open position into sell and/or buy bids and submit them before the gate.
2. D−1 midday — absorb the clear. Fetch the accepted schedule (MW and SMP the MO actually gave you).
3. D — operate. Watch SO instructions and IDM drift; re-bid or acknowledge when the physical plan changes.
4. D+1 — settle the gap. Price yesterday’s imbalance; later in the month, match the MO’s settlement file to your own records.

4.3 What the process does (D−1 → D → D+1)

4.4 Worked example — sell at noon, deviate next day

Data. full_demo · seed 42 · BRP-T1-DEMO · T1 Renewables book · role Trader · safety margin R 10 / MWh. Sell ladder from the BidBuilder hour-12 example (V9 §4); imbalance pattern from the demo Imbalance screen (V9 §6).

Why this hour needs a sell bid. After the 02:30 strategy run, noon still has unsold energy (spill): firm take-or-pay 5.00 MWh worth 0 c/kWh to keep, and wind 1.71 MWh worth 40 c/kWh. Net open position = +6.71 MWh long. Bilateral PPAs did not absorb it — so the BRP offers it on DAM instead of leaving it idle.

D−1 03:00 — build the sell ladder.

Contrast — a buy hour (same rules, opposite direction). A P90 evening hour with 6.0 MWh firm-demand shortfall and Eskom top-up at 210 c/kWh becomes one buy line at 210 × 10 − 10 = R 2,090 / MWh limit: “I will pay up to this to avoid grid top-up; I will not pay more.”

D−1 12:00 — clear. Prototype SMP at noon is R 980 / MWh. Both offer rungs are ≤ 980, so both clear. Accepted schedule for the hour: 6.71 MWh sold. Revenue 6.71 × 980 = R 6,575.80 (you receive SMP, not your rung prices).

D — SO and IDM. Every 15 minutes the poller ingests SO instructions; a curtailment on an IPP in the book reduces available energy and can widen imbalance if you do not correct via IDM. Every 30 minutes IDM compares drift to tolerance and may force a re-bid while that hour’s gate is still open.

D+1 06:30 — deviation becomes a bill. Suppose meters show you only delivered 5.20 MWh against the 6.71 MWh schedule — short 1.51 MWh. That gap is the deviation. Prototype imbalance charge at 1.35 × 980 on the short volume is the price of missing the promise (V9 §6). The demo Imbalance screen also shows a full-day ~20% under-delivery pattern so you can see every hour’s short MWh and which members’ forecast error drove the gap.

3rd 07:00 — MO file. Last month’s MO settlement file is matched line by line: MATCHED / WITHIN_TOLERANCE / VARIANCE / MISSING_* (V9 §8). This is invoice matching — not the same as chain recon on PPAs (§2).

4.5 What you see / what you do

Where this is taught. SAWEM primer through consoles: V9. Strategy position that feeds the bid: §3. Worker cards: V21 §3.

5. Rhythm 4 — the IPP programme (teal)

The problem: an Independent Power Producer (IPP) owns a power plant — wind, solar, or similar — and sells that plant’s energy to one or more buyers under signed contracts (PPAs). The plant does not make the same number of megawatt-hours every month: weather, season and outages change what it can produce. Buyers also do not all have the same claim when the plant makes less than everyone hoped for — some are first in line, some share fairly, some wait until the others are filled.

So every month the IPP faces a practical commercial question:

“Given what we now expect this plant to make next month, and given the promises we have already published to existing buyers, how much energy is still safe to sell to someone new — without promising the same kilowatt-hour twice?”

If that question is answered from a stale spreadsheet, two failures are common: the IPP oversells (new contracts that the plant cannot honour when generation is tight), or the IPP undersells (leaves sellable headroom idle while the sales team thinks the plant is full). The teal IPP programme rhythm is the platform’s fixed monthly answer: on the 5th at 04:00 it refreshes the forecast, walks every buyer through the published allocation order, and publishes how much is still sellable.

5.1 Words first — plant, promises, hierarchy and headroom

An IPP is the organisation that owns (or operates) the generator. On the platform that plant is a generator site — the sell-side site with technology, capacity and meters. The demo cast’s example is IPP2 Atlantis Wind.

A buyer is anyone who has (or will have) a contract to take energy from that plant — an off-taker, or a trader who then sells on. Those contracts are PPAs. When many buyers share one plant, the IPP must publish a single rule for who gets served first when there is not enough energy for everyone. That published rule is the Global Allocation Hierarchy (often just “the hierarchy”): a versioned ordering of buyers into tiers. Settlement later uses the same hierarchy to carve real meter readings (V8 §6).

Allocation tiers are the three ways a buyer can sit in that order:

Without a hierarchy, “who loses when the wind is quiet?” is an argument. With one, it is a published procedure.

FG — Forecasted Generation is the platform’s best estimate of how many MWh the plant will make in the coming month (from the plant’s resource model and recent history). It is a prediction, not a meter reading. Think: “we expect about this much energy to exist.”

ED — Expected Demand is how much each existing buyer is realistically expected to ask for under their contract next month (capped by history and contract ceilings). Summed across buyers it is ED_total — “how much of that forecast is already spoken for by people we already serve.”

CO — Contractual Obligation is what each buyer is projected to actually receive once FG is pushed down the hierarchy. CO never exceeds that buyer’s ED: if the plant is short, lower-tier buyers get less (or nothing). CO is the honest “you will get this under this forecast,” not the wishful “your contract says up to this.”

AES — Available Energy for Sales is the leftover headroom after existing buyers are covered in that forecast:

AES = max(0, FG − ED_total)

If FG is 12,000 MWh and existing buyers are expected to take 9,400 MWh, AES is 2,600 MWh — the amount Sales may still offer to new buyers without double-selling the forecast. If ED_total exceeds FG, AES is zero: the plant is already fully spoken for on paper.

HAF — Historical Availability Factor is a score between 0 and 1 that asks a different question: “how bankable is this plant’s paper availability, given what actually happened?” It blends physical performance, stability and how reliably buyers were served historically. The contracting guard uses HAF (and related checks) so the sales desk cannot casually offer firm deals the evidence does not support (V4 §5 · V4 §13).

Together: FG is what the plant might make; hierarchy + ED → CO is who already owns that forecast; AES is what is left to sell; HAF is how hard you should trust the story when signing.

5.2 What the process does (5th at 04:00)

The IPP monthly forecast fan-out runs for every ACTIVE generator site on the programme:

1. Build FG — forecasted generation for the month from the site’s resource model and effective dates (V4 §8).
2. Push through the hierarchy — apply the published Global Allocation Hierarchy (PRIORITY → PRO_RATA → FIXED) so each buyer’s CO is what they will actually receive under this FG.
3. Compute AES — max(0, FG − ED_total) — headroom still safe to offer.
4. Refresh HAF inputs — historical factors that feed the contracting guard.
5. Surface on IPP Strategy — Overview revenue-gap, Forecast report, Sales / firm-viability cards update from the new month row.

5.3 Worked example — IPP2 Atlantis Wind

Data. full_demo · seed 42 · seat ipp_2@webill.net · IPP2 Atlantis Wind · illustrative month shaped like the programme math (verify live FG on Forecast).

Hierarchy walk (illustrative peak band, MW): demand to serve 10.00 MW in one hour. Priority 10 (Buyer A) takes 3.00 MW to its cap; the equal Priority 20 tier (Buyers B and C) splits the remaining 7.00 MW at weights 1:3 → 1.75 + 5.25; Priority 30 (Buyer D, FIXED) gets 0 because the hour’s requirement is already met.

Conservation on the tier split: 3.00 + 1.75 + 5.25 + 0 = 10.00 ✓. Those CO MWh roll into the month’s ED total; AES is what Sales may still offer under the contracting guard (V4 §13).

5.4 What you see / what you do

Where this is taught. Full IPP volume: V4. Settlement’s consumption of hierarchy waterfalls: V8 §6. Worker: V21 §3 · IPP monthly forecast fan-out.

6. Contract triggers and how the rhythms interlock

The four rhythms in chapters 2–5 are scheduled jobs — work the platform runs at fixed times on the SAST calendar (01:00 settlement, 02:30 strategy, and so on). They are not the only movers.

Two triggers watch deal records themselves and flip status when a calendar condition becomes true. They are not a fifth rhythm. They keep contracts and proposals honest so the four rhythms always see the right lifecycle state.

6.1 Daily — activate SIGNED physical PPAs

What a physical PPA is, in this context. A physical power purchase agreement is a signed commercial promise that real energy will wheel from a seller’s meter to a buyer’s meter. After both parties sign, the contract is SIGNED — legally complete — but it may still be waiting for its commercial start date (the first day the deal is meant to run). Until that date arrives, the platform must not treat the deal as live standing instructions.

What the trigger does. Once a day, around 00:00 SAST, the platform looks at every SIGNED physical PPA. If today’s date is on or after that contract’s start date, the status flips to ACTIVE.

Why it does it. Settlement (§2) and strategy (§3) only treat ACTIVE contracts as standing instructions — periods to open, energy to allocate, nominations to draft. If activation were left to a human click, a deal that should have started on Monday could sit SIGNED until someone remembered; overnight settlement would skip it; the first bill would be late or missing. The daily trigger removes that gap: when the start date arrives, the deal is live by morning without anyone signing in.

What you see. On the contracts register the status badge moves to ACTIVE. On the next settlement-frequency tick for that contract (daily at 01:00, monthly on the 1st, and so on), the first settlement period for the new window becomes eligible.

6.2 Hourly — expire stale proposals

What a proposal is, in this context. Before a PPA exists, one party sends a proposal — a commercial offer (price, volume shape, term) that the counterparty can accept, counter, or ignore. While it is waiting, the proposal sits in PENDING. Offers are not meant to live forever: the sender sets an expiry (a date/time after which the offer is no longer open for acceptance).

What the trigger does. Every hour, the platform finds PENDING proposals whose expiry time has passed and moves them to EXPIRED. The initiator can usually renew (up to a limit) — renewal returns the offer to PENDING with a fresh expiry. The trigger never invents a new deal; it only closes ones that outlived their stated window.

Why it does it. Without expiry, an old PENDING offer could be accepted weeks later — after prices, load or intent have moved — and suddenly become a binding path toward a contract nobody still meant. That is a “zombie offer”: commercially dead, still clickable. Hourly expiry keeps the handshake honest: if the window closed, the status says so. Renewal is an explicit human choice to reopen, not silence.

What you see. On the proposal lifecycle rail the state moves to EXPIRED. Renew (when allowed) puts it back to PENDING with a new expiry countdown.

6.3 One week on the cast — how rhythms stack

The triggers above keep deal state correct. The four rhythms keep operations moving. On the same SAST calendar they interlock — each feeds the next — without inventing a fifth cadence.

What “interlock” means here. One overnight on the demo cast is not four unrelated alarms. Strategy refreshes the book; half an hour later the market builds bids from that refresh; settlement closes yesterday’s commercial truth; the next morning imbalance prices yesterday’s market promise against meters. Later in the month, separate day-of-month jobs refresh monthly settle, MO invoices, backcasts, IPP headroom and nomination drafts. Reading the week left to right shows why the clock order matters: later jobs consume what earlier jobs wrote.

Reading the figure.

1. Nightly pair — at 02:30 strategy re-forecasts Trader 1’s book and freezes KPIs and the open position; at 03:00 the market job builds day-ahead bids from that position. Bid without a fresh snapshot and you offer yesterday’s leftovers.
2. Daily settle pair — at 01:00 settlement closes the thread PPA’s daily window into a ledger; the next morning at 06:30 imbalance prices what the BRP scheduled versus what meters showed. Commercial settle and market deviate are related days, different questions.
3. Month strip — the 1st closes monthly PPAs and chain-checks trader legs; the 3rd matches the Market Operator’s invoice file; the 4th scores last month as ACTUAL in strategy; the 5th refreshes IPP forecast and sales headroom; the 20th drafts next month’s nominations for your approval.

Nothing in this picture invents a fifth rhythm — it is the four coloured cadences plus the two deal triggers sharing one SAST calendar. Full timetable: §7.

7. The full schedule

Master timetable. Feature depth lives in chapters 2–5 and in the operations catalog.

Where the ops cards live. Failure modes, retries and what to do when a job sticks: V21 §3. Orientation catalogue of every run: V0 §6. When the platform schedule in configuration changes, reconcile the published job list against COVERAGE.md Matrix 3.

8. Common questions

Plain-language answers to the questions people ask when a rhythm surprises them overnight. Each answer explains the concepts first, then what to check.

8.1 Why did my settlement numbers change overnight?

Short answer. Something new arrived for a period that was not yet frozen — usually a late meter — so the daily settlement job at 01:00 ran the pipeline again and rewrote the ledger.

In plain words. A settlement period is one contract’s closed day (or week/month). While it is still PRELIMINARY, the platform is allowed to recalculate if better data shows up. When it reaches FINAL, the numbers are meant to stay put (except formal reverse/re-settle).

Overnight, the usual story is:

1. Yesterday’s daily job wrote a first pass from the meters it had.
2. A late reading landed after that pass.
3. At 01:00 the daily settlement job woke again, saw the new meter, and re-ran Resolve → Match → Price → Adjust → Ledger.
4. Your Energy balance and ledger amounts moved — same period, new truth.

Less often, a person clicked a controlled re-settle on purpose.

What you do. Open the period → check status → open Resolve source (which meter / nomination fed the run) and the content hash. Deep dive: V8 §3 · V8 §11 · §2.

8.2 Why is Overview still showing yesterday’s KPI time?

Short answer. The nightly strategy refresh at 02:30 has not finished a new run for your book — or the book has nothing ACTIVE to score — so the frozen daily snapshot never advanced.

In plain words. Overview’s headline numbers are KPIs (margin, coverage, spill, and so on) taken from the latest strategy run. After that run, the platform freezes a risk snapshot for the calendar day and stamps Overview with that time. If the stamp is still yesterday:

• the 02:30 scheduled job is still running or waiting,
• it failed and left the old snapshot in place, or
• your book has no ACTIVE pools/members, so the engine has nothing to allocate and writes no useful new snapshot.

What you do. Confirm background-job health in V21; confirm pools and members in V3 §4. Rhythm context: §3.

8.3 Why did I miss the DAM gate?

Short answer. The day-ahead market only accepts bids until 10:00 SAST the day before delivery. Something left the Bid Desk empty or late — often a stale strategy position, a clip, or a missing BRP registration.

In plain words. DAM is the day-ahead wholesale market: you must declare how much to sell or buy for tomorrow’s hours. The gate is the hard deadline (10:00). The platform builds bids at 03:00 so you have hours to fix problems — but if build never produces a submitted bid, 10:00 still closes and the bid expires (a gate miss).

Common causes:

What you do. On Bid Desk, check registration, clip strip, and whether a draft/submitted bid exists before 10:00. V9 §4 · §4.

8.4 Why is there no PROPOSED nomination on the 20th?

Short answer. The mid-month job only drafts plans for members marked nominated, and it never overwrites a plan you already approved or submitted — or the job itself did not finish.

In plain words. A nomination is next month’s hour-by-hour promise of how much a flexible member will deliver or take. On the 20th at 05:00 the platform creates a PROPOSED plan so you can review it before the external deadline. You still must Approve → Submit.

No PROPOSED plan usually means one of:

1. The member is not flagged nominated — the job ignores it.
2. A plan for that month is already APPROVED or SUBMITTED — the job skips so it cannot quietly replace your commitment.
3. The scheduled nomination job failed or has not run yet.

What you do. Open Nominations for the member/month; confirm the nominated flag; check background jobs in V21. V3 §9 · §3.

8.5 Why did AES drop on the 5th?

Short answer. On the 5th the IPP programme refreshed the month: either expected plant output (FG) fell, or energy already spoken for by existing buyers (ED) rose — so leftover headroom (AES) shrank.

In plain words.

• FG (forecasted generation) = how much the plant is expected to make next month.
• ED (expected demand) = how much existing hierarchy buyers are expected to take.
• AES (available energy for sales) = what is still safe to offer to new buyers:

AES = max(0, FG − ED)

If FG drops (worse wind/solar outlook) or ED rises (more contracted claim), AES falls. At zero, Sales should not offer more on that forecast.

What you do. Open Forecast for the month; confirm hierarchy version before offering AES; read HAF before firm offers. V4 · §5.

8.6 Is the spine the same as the clock?

Short answer. No. The spine is how you read the product story; the clock is how the platform operates every day.

In plain words. The lifecycle spine (Setup → Strategy → Deal → Nominate → Market → Settle → Statement) is a teaching map: one kWh’s journey through the manual and the screens. The clock is the set of scheduled jobs and triggers that run whether or not you are mid-deal — nightly strategy, daily settlement, market day, monthly IPP programme.

They touch the same world, but they are not the same thing:

This volume teaches the operating map (§1). The spine locator at the top of each volume is the reading map (V0 §4).

Next reads by seat: traders → V3 · V9; IPP operators → V4; commercial → V7 · V8; platform operators → V21 §3.