[acc.*]

An [acc.*] section declares a group of accounts — the ledgers that a resource allocation system credits and debits, and that water users draw against. Accounts are declared as a headed table, one row per account, in the same style as a loss table:

[acc.entitlements]
accounts = name,     size,
           smith,    150,
           jones,    420,
           town_hp,  90,

The section name is the group; each row is one account. acc.entitlements is an account group you can target as a whole; smith is an account you can reference and record individually.

Accounts are pure state

An account holds a name, a size, and a running balance — nothing else. It has no behaviour and no calendar: a row never resets, never refills, and never schedules anything. Every change to a balance is either a [ras.*] action or a water user's take. A group that no RAS targets is perfectly valid — it is simply a ledger that only users touch.

This split is deliberate: accounts are the nouns, resource allocation systems are the verbs. See Allocation systems for the why.

The accounts table

Column	Required	Meaning
name	yes, first	Account name — a bare lowercase identifier, unique across every group.
size	yes	Account size [ML] — the entitlement volume that percentages are taken of. May be an expression.
initial	no (defaults to 0)	Opening balance [ML] at the start of the run, within [0, size].
pair	no	Paired account — a reference to an account declared elsewhere, not a declaration. The pairing is symmetric: declare it on either account's row, and [ras.*] action arguments read the other end as self.pair.<field> from both sides. An account can be in at most one pair. Nothing else about a paired account is special — it is drawn on via a user's accounts list like any account.

Columns are addressed by the header, not by position, so name, size, initial and name, initial, size are equivalent. An unknown column name is a load error — a typo like intial fails loudly rather than silently leaving every account at zero. accounts is the only property an [acc.*] section may contain; anything that does something belongs in a [ras.*] section.

A carryover pairing in full — the pool is an ordinary account, first in the user's order of use, and the grant is an authored rule targeting the pool (see the carryover recipe):

[acc.entitlements]
accounts = name,  size, initial, pair,
           smith, 1000, 0,       smith_co,

[acc.pools]
accounts = name,     size,
           smith_co, 250,       # size = the carryover cap

[ras.carryover]
targets = acc.pools
trigger = start_water_year(7)
action  = set(0.9 * self.pair.balance)   # pool = 0.9 x smith's remaining balance

Referencing accounts from nodes

A water user references accounts it draws on with the accounts property — a comma-separated list, never a declaration:

[node.smith_pump]
type = regulated_user
accounts = smith
order = 12

List order is order of use: accounts = smith_carryover, smith_annual draws the first account down before touching the second. The available volume is the sum, and debits cascade in order. See regulated_user / unregulated_user.

Recordable series

Account state is published as ordinary series — readable in any dynamic expression and recordable in [outputs]:

Series	Meaning
acc.<name>.opening_balance	Balance after the RAS step, before any take — a stable snapshot every expression reader sees regardless of node order.
acc.<name>.closing_balance	Balance at the end of the step.
acc.<name>.debits	Water taken by users this step (not policy changes).
acc.<name>.allocation	Allocation to date: balance plus use since the last reset (see Allocation systems).
acc.<name>.allocation_pct	Allocation as a percentage (nominally 0-100) of the account size. NaN for a zero-size account (and NaN counts as true in a condition, so a bare acc.<name>.allocation_pct trigger on such an account fires every step). The allocation percentage may be >100% — the allocations are not clamped to the account size.
acc.<name>.use	Water taken since the last reset_allocation — the use term of the allocation. Fed only by user takes, like debits.
acc.<name>.committed	Orders accepted by regulated users against this account and not yet due, as the step's ordering begins — their best guess of the diversions to come. A forecast, not a debit: the balance does not move until the water is diverted, and opening_balance − committed is the headroom the step's orders are capped by. Each order leaves the tally on the step after it falls due, delivered or not. Written before ordering, like opening_balance.
acc.<name>.size	Account size, as declared.
acc.<name>.initial	Opening balance at the start of the run, as declared (defaults to 0 if omitted).

opening_balance, closing_balance, debits, allocation, use and committed are also published for the group aggregate, summed over its members: acc.<group>.use, acc.<group>.closing_balance, and so on — so a resource assessment can write / acc.gs.size instead of a magic total that silently goes stale when an entitlement changes.

allocation_pct is also made available as a group aggregate: the group allocation over the group size. That is a mean of the members' own allocation_pct weighted by account size, so it can differ from any one member's value. Members drift apart when:

• they start at different percentages (initial as a proportion of size);
• a RAS action works in absolute amounts — credit(20) is a larger share of a small account than of a large one;
• an action sets the balance without regard to water already used — set_full after a take leaves that member above 100%;
• a balance-setting action such as credit, set or scale caps the balance at the account size, so one member stops rising at its cap while another keeps going (allocate and set_full are not capped).

Note that this is the allocation held, which can differ from the percentage an allocate action announces (see ras.<name>.pct) — allocate never reduces an account's allocation, and other actions can increase it.

size and initial are also group aggregates — the sum of member sizes and opening balances — but like their per-account counterparts above, they're fixed for the whole run rather than computed, so they read cleanly everywhere, from the very first line of the model, with no write-timing caveat and (like const.*) no offset syntax. opening_balance and committed are written before ordering and flow, so they read cleanly mid-step. The others are written at end of step; reading them earlier in the same step needs the previous-step offset, e.g. acc.smith.closing_balance[-1, 0] — including use, whose [-1, 0] read on a reset morning is still the old period's total (the reset fires later that same step).

Rules

• Account and group names are bare lowercase identifiers and share one flat namespace — every name, account or group, must be unique.
• A user drawing its balance down does not reduce its allocation; the water moves from the balance into the use tally.
• Accounts carry no behaviour. To reset, refill, limit, or announce, use a [ras.*] section.