An example scope class

A scope class is the document that says what a caller may attempt against your interface, how often, and what happens when it goes outside. This is a worked one, so you can see the shape before you write yours.

Everything on this page is illustrative. It is not published, it binds nobody, and no member is admitted into it. The real one for your interface is written with you.

Illustrative example · 3 September 2026 · Clause references are to the rulebook, version 1.2

Before the example: what a scope class can and cannot say

This is the part people get wrong first, and it is worth a minute because it explains the shape of everything below.

Rootwall never sees what is inside your traffic. Records carry the names of arguments and a digest of their values — never the values.

So a scope class governs what a caller may attempt, not what its payload contains.

In a scope class: which kinds of operation are permitted, how many, over what window, whether the caller must hold a delegation from a named principal, and what has to be asserted about every session.
Not in a scope class: anything that would require reading a value. A maximum field length, a permitted date range, a rule about what may appear in a search string. The scheme could not check these, and the rulebook says no clause may be read as claiming it can.

Those rules still exist — they live at your own edge. The rulebook lets a receiving member apply any restriction stricter than the class permits, privately, without notifying the scheme or anybody else. You may always be stricter. You may never be looser. A refusal under that right is not a breach by anyone and carries no consequence.

Clauses 12.1 to 12.4, 13.1, 24.1 and 24.2.

The example: a read-only class for a REST interface

Reference SC-READ-1 · version 1.0 · ILLUSTRATIVE

What the caller may attempt

Method kind	Permitted	Meaning
`read.record`	Yes	Retrieve one identified record
`read.collection`	Yes	Retrieve a list or search result
`create`	No	Bring a new record into existence
`update`	No	Change an existing record
`delete`	No	Remove a record
`payment.initiate`	No	Move money
`notify.external`	No	Cause a message to a third party

The class names kinds, not methods, because it cannot know what your interface exposes. You map each of your own endpoints to a kind and file that mapping with the scheme. The mapping is of effect, not of signature — if one endpoint does several things behind the scenes, it maps to the most consequential of them. Mapping something to a kind that understates its effect is a breach, attributed to you, because only you know what your methods do.

Clauses 13.1 to 13.3.

Ceilings

Limit	Ceiling	Window
All interactions, per counterparty	600	1 hour
All interactions, per counterparty	5,000	24 hours
`read.collection` onlyList and search operations are heavier and are capped separately	200	1 hour
Concurrent open sessions, per counterparty	10	—

Ceilings are measured per counterparty and count only interactions the caller initiated. Windows are stated because a per-session ceiling is evaded by splitting the work across sessions.

Delegation

Required. Every session is opened on the authority of an identified principal — a named person or organisation on whose behalf the caller is acting.
Maximum validity: 24 hours from the point the caller obtained it.
The principal is named in the record, and the caller asserts that it verified the authority. Recording a verification as performed when it was not is a breach.

What must be asserted

By both sides, for every session: a session-open record, one record per interaction, and a session-close record.
On every record: the shared session identifier, the emitter and its role, and for each interaction the method kind, the direction, the names of the arguments and a digest of their values.
On the calling side: the delegation reference and the identifier of the build that was running.
Emission deadline: within 15 minutes of session close. Emission is not urgent, is not in the data path, and is never a dependency of your operations.
Response section: not applicable. This is a plain request-and-response interface, so the receiving side never initiates.

Clauses 20.1 to 20.7 and 9.6.

What it costs to break each rule

Sums are fixed in advance, published before they apply, and identical for every member breaking the same rule in the same role. They are paid by the member in breach to the member affected, never to Rootwall — which cannot receive any sum on breach under a clause that cannot be amended.

Breach	Standing	Sum
Attempting a forbidden method kindAn attempt is a breach whether or not it succeeded	Under Review; Suspended on repetition	$1,000 per session
Operating without a valid delegationOr after it expired, or beyond what the principal authorised	Under Review; Suspended on repetition	$1,000 per session
Exceeding a ceiling	Under Review	$250 per window
A false or misleading recordIncluding mislabelling a refusal, or understating a method's effect	Under Review; Suspended on repetition	$2,500 per record
Failing to produce a record, or to answer in timeEither role. See the note below	Under Review; Suspended if sustained	$2,500 per session

Aggregate cap: $25,000 per member, per counterparty, per rolling 30 days, across all categories. Consequences to standing are not capped. The cap limits the scheme’s consequences and not anybody’s liability at law.

Why failing to produce a record costs more than most of the breaches it might hide. The rule is that the sum for evidence failure, per session, may never be lower than the highest per-session sum for an actual breach in the same class. Here that is $1,000, so $2,500 clears it comfortably.

A member that has just broken a rule must not find silence cheaper than admitting it. That single constraint is what makes the rest of the scheme work.

Why these numbers look small, and they are meant to. A sum here is a pre-estimate of what the breach costs the member affected by it to deal with — an engineer and someone in risk, a few hours for something contained. It is not damages, it is not a measure of loss, and it is not the scheme’s costs.

The deterrent in this scheme is standing, not money. Sums set high enough to frighten would stop being a pre-estimate of anything, and would invite a court to call them a penalty and strike them out. A reader who thinks these are too low has misread what they are for.

Assessment fee for a class of this shape: $1,200, paid once by the calling side on first admission into it, with renewal at $600. A class permitting mutating operations takes more work to assess and carries a higher fee. The whole schedule is published.

The same interface, one step riskier

For contrast, and because the shape of the change is the point. SC-WRITE-1 would permit create and update alongside the read kinds, and everything else moves with it:

Tighter ceilings on the mutating kinds than on the read ones, because the consequence of getting them wrong is not symmetrical.
A shorter delegation validity — hours rather than a day.
Higher sums, because a wrongly created or altered record costs the affected member more to unpick than a wrongly read one.
A higher assessment fee, because there is more to assess.

What does not change: the rules themselves, the evidence standard, the consequences framework, or anything in the rulebook. A scope class is a permission profile. It never varies a rule — the scheme cannot vary a rule for anybody.

How the real one gets written

You list what your interface exposes and map each method to a kind. You are the only party that knows what your own methods actually do.
We set the ceilings together, against what your ordinary traffic looks like rather than against a number we invented.
The sums are set with the class, as a pre-estimate of what a breach of each category would cost you to deal with. You are the party they are paid to, so you are the party who knows.
It is published, and every company admitted after you is held to it. Once written it is not yours privately — it is the standard for that shape of interface.

The first company through does not get a discount. It gets to decide what the rules say.

Classes are versioned, and a member is admitted into a specific version. Where a new version is published, a transition period is stated. Nobody is moved onto new rules overnight.

Clauses 9.1 to 9.7, 14.1 and 14.2, 30.2.