Rootwall Scheme Rulebook
Contents
  1. The Rootwall Scheme Rulebook
  2. In plain English — not part of the Rules
  3. Drafting notes — read once, then ignore
  4. Part 1 — The Scheme
  5. 1. Purpose and status
  6. 2. What the Scheme does not do
  7. 3. Defined terms
  8. Part 2 — Membership
  9. 4. Admission
  10. 5. Standing
  11. 6. [Reserved]
  12. 7. Change of circumstances
  13. 8. Withdrawal, and propagation
  14. Part 3 — Scope Classes
  15. 9. Publication
  16. 10. Admission into a class
  17. 11. Acceptance
  18. 12. Local tightening
  19. 13. Method kind mapping
  20. 14. Versioning
  21. Part 4 — Conduct
  22. 15. General obligations
  23. 16. Delegation and the intersection rule
  24. 17. Ceilings
  25. 18. Honest labelling
  26. 19. Change control
  27. Part 5 — Evidence
  28. 20. The evidence standard
  29. 21. Integrity and repudiation
  30. 22. Retention
  31. 23. Reconciliation
  32. 24. What the Scheme will not receive
  33. Part 6 — Incidents
  34. 25. Disclosure
  35. 26. Cooperation
  36. Part 7 — Breach and consequence
  37. 27. What is a breach
  38. 28. What is not a breach
  39. 29. Determination
  40. 30. Consequences
  41. 31. Payment
  42. 32. Review
  43. Part 8 — Evidence provision
  44. 33. The witness function
  45. Part 9 — The Scheme's own obligations, the rulebook itself, and governing law
  46. 34. Amendment
  47. 35. The Scheme's obligations to Members
  48. 36. The emission interface
  49. 37. Governing law
  50. Schedules
  51. Schedule 1 — Standing
  52. Schedule 2 — Consequences
  53. Schedule 3 — Scope Class template
  54. Schedule 4 — Periods
  55. Schedule 5 — Consumed mechanisms
  56. What changed
  57. 1.3 — 15 September 2026
  58. 1.2 — 2 September 2026
  59. 1.1 — 2 September 2026
  60. Known limitations of this rulebook

The Rootwall Scheme Rulebook#

Version 1.3. Last updated 15 September 2026. Adds clause 15.6: a Member answers for every use of its own credentials, whoever used them. Widens clause 25.1(a) to match. See What changed, at the end of this document.

Status. In force. The generic rulebook — every clause here is vertical-independent and can be read by any Member in any sector. Every period the Rules depend on has a value (Schedule 4).

Two schedules are completed on admission rather than in advance, and that is the design rather than an omission. The content of the Scope Classes (Schedule 3) and the Liquidated Sums (Schedule 2) describe operations against a specific interface — permitted Method Kinds, ceilings, what must be asserted, and sums proportionate to what that class permits. A generic version of either would describe nothing. They are written with the Member on admission, and what a Member signs names the completed schedules for its own interface. The structure each must take is fixed in this document and is not negotiated. The figures shown in Schedule 2 indicate the order of magnitude the Scheme works in.


In plain English — not part of the Rules#

Read this if you want the shape before the detail. Nothing here is a Rule and nothing here can be relied on. Where this section and a clause disagree, the clause wins.

  1. The problem. Two companies let software talk to each other's systems. Something goes wrong. Today nobody can prove what actually happened, because each side only has its own logs and there is no reason to believe either of them.

  2. What Rootwall is. A members' club with published rules. You get checked once before you join, against a standard anyone can read. You are not checked by each company you deal with.

  3. What members send us. Every time two members' systems talk, both sides separately send us a short signed record of what happened. Not the contents of the messages — just who, what, when, how many. Each record is a few hundred bytes.

  4. What we do with it. We put the two records side by side. If they agree, we write down that nothing went wrong — which is what most members are actually paying for. If they disagree, we put both sides on notice and ask them to explain.

  5. What breaking a rule costs. Your standing in the club, and sometimes a fixed sum published in advance, paid to the other company. Never to us. We take no cut of anything.

  6. What we deliberately cannot do. We are never in the middle of the traffic. We never see the contents of a message. We never decide who owes whom money. We hold the record and hand it over, to both sides at once, when someone needs it.

  7. How long we keep it. Six years — the period in which someone could still sue over one of these calls. Members keep the small set of supporting items behind their own records for two years. Clause 22 explains why those two numbers differ.

  8. Every deadline is written down. How long you have to tell us something, how long we have to tell everyone else, how long you have to explain a disagreement, how much notice we owe you before changing the rules. All of it is in Schedule 4, and none of it is at our discretion.

  9. Your keys are your responsibility. If someone else uses the credentials you were given, it counts as you, whoever they were. That is deliberate: a company with its own money at stake looks after its keys, and a key that is well looked after is a key that is hard to steal. Clause 15.6.


What this document is. The rulebook is the product. Everything else in the Scheme — the emitters, the schema, the reconciliation — exists to make these clauses operable.

How to read it. Part 1 defines terms and states the Scheme's limits before its powers. Parts 2–6 are obligations. Part 7 is consequence. Part 8 is what the Scheme gives back. Part 9 is what binds the Scheme itself, how the rulebook changes, and what law governs it.

Numbering is stable. Clauses removed in a later version are marked [Reserved] and their numbers are never reused. A rulebook that renumbers itself breaks every contract that cites it.


Drafting notes — read once, then ignore#

Four conventions run through this document and each is deliberate.

(a) Obligations are keyed to a role, never to a party. The rulebook says "a Member acting in the Emitting Role shall", not "the agent operator shall". Today the Emitting Role is always held by the calling party, but a rulebook written around "the operator" cannot accept a Member who emits in the other direction without being rewritten. Keying to roles costs a word now and saves a rewrite later.

(b) The word "penalty" does not appear. In English law a "penalty clause" names the unenforceable version of exactly what this Scheme relies on. The defined term is Liquidated Sum — an amount fixed in advance as a genuine pre-estimate of the administrative and governance cost of a breach, published before any breach occurs. Every clause is drafted to support that characterisation.

(c) Where the Scheme cannot see, it allocates rather than infers. Several clauses place an obligation on a Member to do something the Scheme cannot verify. That is not an oversight. The alternative — the Scheme forming a view from statistical inference — is rejected outright at clause 29.4.

(d) Every "shall" on a Member maps to a breach category, or it is not a rule. Clause 27.1 closes the list of breaches. An obligation stated in Parts 2–6 that appears nowhere in clause 27 is decorative, and a rulebook full of decorative obligations is not credible. Clause 27.9 exists to catch the obligations a Member owes to the Scheme rather than to a counterparty. Where an obligation still has no consequence, that is recorded in Known limitations rather than left for a Member to discover.

(e) The Scheme asks for nothing it does not need. Where these Rules oblige a Member to hold or do something, the obligation is drawn to the narrowest thing that makes the Scheme's own record work, and says so. Clause 22.3A is the worked example. An obligation drawn wider than its purpose reads as a records-management policy imposed by a stranger, and a prospect is right to refuse it.


Part 1 — The Scheme#

1. Purpose and status#

1.1# These Rules constitute the Rootwall Scheme (the Scheme). They are contractual. They have no statutory force and the Scheme claims none.

1.2# The Scheme is a governed overlay on the public internet. It does not provide, operate or replace any network, transport or connectivity. Traffic between Members runs exactly as it runs today.

1.3# The Scheme administers accountability for programmatic access between Members: it admits a Member against a published standard, holds independently signed records from both sides of a Session, determines whether a Rule has been broken, attaches a consequence when one has, and supplies evidence to Members when loss is in dispute.

1.4# These Rules bind each Member from the date of its admission. A Member's obligations under Part 5 (Evidence) and Part 6 (Incidents) survive termination of membership. An obligation in respect of Assertions the Scheme holds survives for the Retention Period; the obligation to retain Substantiating Material survives for the Substantiation Period.

2. What the Scheme does not do#

Stated before the Scheme's powers, deliberately. A limit discovered by a Member later is overselling; a limit stated first is scheme design.

2.1# The Scheme is never a counterparty. It is not party to any transaction, contract or dealing between Members, and acquires no rights or liabilities in respect of any of them.

2.2# The Scheme is never in the data path. It does not sit between Members, does not proxy, route, inspect or relay traffic, and its availability is not a dependency of any Member's operations. If the Scheme is wholly unavailable, Members continue to transact and the only consequence is deferred emission under clause 20.6.

2.3# The Scheme does not receive payloads. It receives Assertions: structured statements about Sessions. It does not receive request or response bodies, argument values, personal data beyond identifiers, or any Member's log estate. Clause 24 states this as a limit on the Scheme itself, not only as a permission for Members, and clause 36.4 requires the emission interface to be incapable of receiving the material rather than merely undertaking not to.

2.4# The Scheme does not determine loss. It determines whether a Rule was broken. It takes no position on whether any Member suffered harm, on the amount of any harm, or on causation. See Part 8.

2.5# The Scheme does not adjudicate disputes between Members, does not arbitrate, does not provide a claims forum, and does not underwrite, pool or indemnify any risk.

2.6# The Scheme does not detect all misuse. Clauses 16.6 and 24.2 state the two hard limits on what it can see, and Known limitations records the rest. The Scheme allocates responsibility and caps blast radius. It does not prevent compromise.

2.7# The Scheme does not issue identity. It consumes identity and authentication mechanisms operated by others and relies on the mechanisms named in Schedule 5. The Scheme does issue a Membership Attestation — a statement that a named party is admitted to a named Scope Class at a named date — which asserts nothing about who that party is and is worthless without an identity mechanism it does not operate. Attestation of admission is not issuance of identity, and the two shall not be conflated in any statement made by or about the Scheme.

2.8# The Scheme does not recognise intermediaries. Where traffic between two Members passes through a gateway, host, proxy, broker or any other party, that party is not a party to the Session, is not admitted, and is not known to the Scheme. Clause 15.5 governs. The Scheme's subject is the consequential transaction between two named companies, and adding a third name to the record does not make the transaction more attributable — it makes it less.

2.9# The Scheme does not set a Member's records policy. It requires a Member to retain one narrowly defined set of items behind its own Assertions, for one stated period, for the reason given at clause 22.3A. It has no interest in anything else a Member keeps or discards, does not inspect a Member's retention arrangements, and imposes no records obligation beyond clause 22.3.

3. Defined terms#

Terms defined here are capitalised throughout.

Affected Member — the Member to which a Liquidated Sum is payable, determined under clause 31.2.

Assertion — one structured, signed record describing one thing that happened in a Session, emitted to the Scheme by a Member under Part 5. An Assertion is a statement made to a third party under these Rules, not a log entry retained by its author. The distinction is operative: a missing Assertion is a breach, not an outage.

Delegation — the authority of an identified Principal, obtained and recorded under clause 16.3, on which a Member in the Emitting Role opens a Session. A Scope Class states whether Delegation is required and at what binding.

Direction — the field on an Interaction Assertion recording which of the two Members initiated that Interaction. Direction is a property of an Interaction; role is a property of a Session, and the two do not vary together. See clause 20.4A.

Divergence — a state in which the Assertions emitted by the two Members to a Session cannot be reconciled under clause 23.

Emitting Role — the role held, in respect of a Session, by the Member that initiates the Session. Receiving Role — the role held by the Member whose systems are addressed. A Member may hold either role, and may hold different roles in different Sessions. Roles are fixed for the life of a Session and do not change because an individual Interaction runs in the other direction.

Intermediary — any party through which traffic between two Members passes, and which is not itself a party to the Session. See clauses 2.8 and 15.5.

Interaction — a single invocation of one method, and its response, within a Session. One Assertion is required for each Interaction (20.2) and ceilings are measured in Interactions unless the Scope Class states another unit. Where the boundary between Interactions is ambiguous at a Member's interface, the mapping filed under clause 13.2 governs.

Liquidated Sum — an amount fixed in Schedule 2 in advance of any breach, payable under clause 31 by a Member in breach to an Affected Member.

Matched Pair — the state in which the Assertions emitted by both Members to a Session reconcile under clause 23.

Member — a party admitted to the Scheme under Part 2 and holding Standing other than Expelled.

Membership Attestation — a statement issued by the Scheme that a named party is admitted to a named Scope Class, valid until its recorded expiry or until revoked under clause 8.2.

Method Kind — a category of method named in a Scope Class, to which a Member in the Receiving Role maps the methods its interface exposes under clause 13.2. Scope Classes name Method Kinds and never methods.

Principal — the identified natural or legal person on whose authority a Session is conducted.

Retention Period — the period stated in Schedule 4 for which the Scheme retains Assertions (22.1). It binds the Scheme and does not bind any Member. The period binding a Member is the Substantiation Period.

Rule — any provision of these Rules, of a Scope Class, or of a Schedule.

Scope Class — a permission profile published by the Scheme under Part 3. A Scope Class has two sections: an emitting section, binding the Member that holds the Emitting Role in a Session under that class, and a response section, binding the Member that holds the Receiving Role. A Member is admitted into the emitting section under Part 2 and accepts the response section under clause 11.1.

Session — a bounded sequence of Interactions between two Members, identified by a single Session Identifier. A Session has exactly two parties: the Member that initiates it and the Member whose systems are addressed. An Intermediary is not a party (15.5).

Session Identifier — the identifier generated by the Member in the Emitting Role and echoed by the Member in the Receiving Role, which joins the two Members' Assertions for reconciliation. It shall be globally unique and shall incorporate the identifier of the Member that generated it.

Standing — a Member's current state under Schedule 1: Good, Under Review, Suspended or Expelled.

Substantiating Material — in respect of one of a Member's own Assertions, only those items that Assertion identifies but does not contain, namely:

(a) the authority's assertion identified by digest under clause 16.3;

(b) the argument values from which a digest asserted under clause 20 was computed; and

(c) the record identifying the build asserted under clause 19.1.

This list is exhaustive. Substantiating Material is not a Member's logs, log estate, monitoring data, message contents or business records, and nothing in these Rules requires a Member to retain any of those. See clause 22.3A.

Substantiation Period — the period stated in Schedule 4 for which a Member retains the Substantiating Material for its own Assertions (22.3). It binds a Member and does not bind the Scheme.


Part 2 — Membership#

4. Admission#

4.1# Admission is a single assessment of an applicant against the published standard for the Scope Class applied for, performed by or on behalf of the Scheme, and recorded.

4.2# An applicant shall satisfy the Scheme, in respect of each Scope Class applied for, that it:

(a) is a legal person capable of being bound by these Rules, and identifies the natural persons who control it;

(b) can technically emit every Assertion type required by that Scope Class, within the emission deadline stated in it (clause 20), through the interface at clause 36;

(c) operates a change-control process sufficient to identify which build of which software was running in any Session it conducts under these Rules (clause 19). An applicant is not required to demonstrate change control in respect of any period before its admission. A criterion expressed against the Retention Period would exclude every applicant younger than that period, which is an accident of drafting and not a standard of competence;

(d) can, where the Scope Class requires Delegation, obtain and record the matters at clause 16.3 from an authority it can name;

(e) maintains an incident response process capable of meeting Part 6;

(f) accepts these Rules without amendment.

4.3# Admission is to a Scope Class, not to a counterparty. No Member negotiates admission with another Member, and no Member is required to assess another Member.

4.4# The Scheme shall record, and make available to Members, for each admitted Member: its identifier, its Scope Classes, the date of admission, the assessment reference, its Standing, and the expiry of its admission.

4.5# Admission expires on the date recorded under 4.4 and shall be renewed by reassessment. Admission does not lapse merely because a Scope Class is superseded; clause 14 governs.

5. Standing#

5.1# Standing is a state, not a score. The Scheme shall not publish, calculate or supply any rating, ranking, reputation index or probability in respect of any Member.

5.2# The four Standing states, their effects and the grounds for entering and leaving each, are set out in Schedule 1.

5.3# A change of Standing takes effect when recorded by the Scheme and shall be notified to the Member concerned and to any Member that has accepted a Scope Class held by that Member.

5.4# Standing consequences are load-bearing. Where these Rules provide for a Standing consequence and no Liquidated Sum, that is deliberate and is not a lesser outcome.

6. [Reserved]#

Sponsorship was removed at version 0.4. In its principal configuration it was incoherent: where a sponsoring Member was also the counterparty to the Session — which is the ordinary case, since a Member sponsors a party it wants to transact with — the sponsor was simultaneously the Affected Member entitled to the Liquidated Sum and jointly liable for it. Sponsorship is in any event a scaling mechanism, and at one bilateral relationship it earns nothing. The part of it worth keeping — a Member answerable for a party acting on its behalf — survives in the narrower and non-degenerate form at clause 15.5. Clause 8.3 already preserves any Member's freedom to vouch for another bilaterally, without the Scheme's involvement. This number is not reused.

7. Change of circumstances#

7.1# A Member shall notify the Scheme within the period stated in Schedule 4 of: a change of control; a change to the natural persons identified under 4.2(a); loss of any capability relied on at admission; or the commencement of insolvency proceedings. Failure to notify is a breach under clause 27.9.

7.2# A Member shall apply for reassessment before operating outside the Scope Classes it holds. Operating outside a held Scope Class is a breach under clause 27.2 and is not cured by a subsequent application.

7.3# Notification under 7.1 places a Member Under Review under Schedule 1. That is a review of the notified change and not an adverse finding, and the Scheme shall record it as such. A Member that notifies is in a better position than one that does not, and clause 27.9 exists so that this is true rather than merely asserted.

8. Withdrawal, and propagation#

8.1# A Member may withdraw on notice. Withdrawal does not affect obligations under Part 5 and Part 6 in respect of Sessions before the effective date, nor liability for sums already due.

8.2# Revocation propagates, and the published register is the authority. Where a Member's Standing becomes Suspended or Expelled, or where its admission to a Scope Class is withdrawn:

(a) the Scheme shall record the change in the register published under clause 35.1, with effect from the time the change takes effect, and the register is authoritative as to a Member's Standing and its admissions;

(b) the Scheme shall notify every Member that has accepted that Scope Class, as soon as reasonably practicable and in any event within the period in Schedule 4;

(c) any Membership Attestation issued in respect of that Scope Class ceases to be valid;

(d) a Member in the Receiving Role shall cease to accept Sessions relying on that admission from the earlier of the time it is notified under (b) and the time the change is recorded in the register under (a), and shall record its compliance in its Assertions. Failure to do so is a breach under clause 27.9;

(e) a Member in the Receiving Role does not breach (d) by accepting a Session in reliance on the register as it stood at the time of that Session.

8.2A# Why the register and not the notification. Notification depends on the Scheme being reachable on a particular day. The register does not: it is published, it is checkable at the moment a Session is offered, and a Member in the Receiving Role that consults it is protected by 8.2(e) whatever the Scheme is doing that day. The notification under 8.2(b) is a convenience and is not the mechanism any Member is required to depend on. This is deliberate: an obligation whose value depends on the Scheme answering the telephone is worth less than one a Member can discharge for itself.

8.3# A Member in the Receiving Role does not breach these Rules by continuing to accept a counterparty under a separate bilateral contract of its own. The Scheme governs Scheme membership, not a Member's freedom to contract.


Part 3 — Scope Classes#

9. Publication#

9.1# The Scheme publishes Scope Classes. A Scope Class is identical for every Member admitted into it. It is not negotiated, not varied per Member, and not varied per relationship.

9.2# Each Scope Class shall state, at minimum: permitted and forbidden Method Kinds; whether Delegation is required and at what binding; ceilings expressed over at least one time window; required Assertion types; the emission deadline; a version; and an effective date. The template is Schedule 3.

9.3# The content of a Scope Class is written with the Member in the Receiving Role on admission. It describes operations against that Member's own interface, and the Scheme does not publish content for an interface it has not been shown. Schedule 3 states the structure that content must take, and that structure is not varied per Member (9.1).

9.4# Ceilings in a Scope Class are the outer bound of what the class can ever mean. They are not a target and are not fitted to any relationship. Fitting happens under clause 12.

9.5# Ceilings shall be expressed over a window. A ceiling expressed only per Session is evaded by splitting work across Sessions and is not a Rule for the purposes of these Rules.

9.6# A Scope Class has two sections. The emitting section binds the Member holding the Emitting Role in a Session under that class. The response section binds the Member holding the Receiving Role. The two sections are two sides of one Session, not two profiles of one Member: a Member admitted into the emitting section of a class is not thereby bound by, or entitled to the benefit of, its response section.

9.7# A Scope Class may extend the Substantiation Period for Members admitted into it, and shall not shorten it (22.3, Schedule 4). This follows the logic of clause 12.2: stricter is always available, looser never is.

10. Admission into a class#

10.1# A Member is admitted into one or more Scope Classes under Part 2. The record of that admission is what travels: one assessment, accepted wherever the class is accepted.

10.2# A Member shall not claim, in an Assertion or otherwise, a Scope Class it does not hold in Good or Under Review Standing.

11. Acceptance#

11.1# A Member in the Receiving Role declares to the Scheme which Scope Classes it accepts. It makes that declaration once, to the Scheme, and not per counterparty. Acceptance binds the accepting Member to the response section of that class (9.6).

11.2# Any Member holding an accepted Scope Class in Good Standing may open a Session with a Member that has accepted it. No further agreement between those Members is required by these Rules.

11.3# A Member may be admitted into the emitting section of one class and accept another. The two acts are independent, and neither implies the other.

12. Local tightening#

12.1# A Member in the Receiving Role may apply, at its own interface, any restriction stricter than the accepted Scope Class permits. It may do so privately, without notifying the Scheme, any counterparty, or any other Member, and without agreement from anyone.

12.2# A Member may always be stricter. A Member may never be looser. A Member in the Receiving Role shall not accept a Session that the Scope Class does not cover, nor permit a ceiling above the class ceiling, nor waive a requirement the class imposes.

12.3# Restriction applied under 12.1 is not a Rule for the purposes of Part 7. A refusal under 12.1 is not a breach by any Member and carries no consequence for anyone. Clause 18 governs how such a refusal is labelled.

12.4# The restriction is private; the refusal is not. Clause 18.1 requires every refusal to be labelled and the label is emitted to the Scheme. A Member in the Receiving Role should therefore understand that the Scheme can see that it refused an Interaction and how it characterised the refusal, but not the policy that produced the refusal. Clause 29.4 prevents the Scheme from deriving any consequence from the pattern.

13. Method kind mapping#

13.1# A Scope Class names Method Kinds, not methods. It cannot know what any Member's interface exposes.

13.2# A Member in the Receiving Role shall map each method its interface exposes to a Method Kind, shall file that mapping with the Scheme, and shall keep it current. The mapping is of effect, not of signature. Where a single exposed method performs several operations behind the interface, it maps to the Method Kind of the most consequential of them. Failure to file, or to maintain the mapping as its interface changes, is a breach under clause 27.9.

13.3# Mapping a method to a Method Kind that understates its effect is a breach under clause 27.5, attributed to the Member that filed it. This obligation exists because only that Member knows what its own methods do, and the Scheme cannot check.

14. Versioning#

14.1# A Scope Class is versioned. A Member is admitted into a specific version.

14.2# Where the Scheme publishes a new version, it shall state a transition period. A Member in the Receiving Role that has accepted the earlier version is not taken to have accepted the later one; acceptance is per version, so a Member that does not accept the new class stops accepting Sessions under it automatically, by a policy it already set.

14.3# A Member moving between Scope Classes is reassessed. A Member operating within its class notifies; it does not renegotiate.


Part 4 — Conduct#

15. General obligations#

15.1# A Member shall operate within the Scope Class it claims, in every Session.

15.2# A Member shall not present, rely on or permit the use of a Membership Attestation by any party other than itself or an Intermediary acting on its behalf under clause 15.5, for whose conduct it remains answerable.

15.3# A Member shall not take any step whose purpose or effect is to prevent the Scheme reconciling a Session, including but not limited to: using a Session Identifier that is not unique; suppressing Assertions; or emitting Assertions that its own systems did not generate.

15.4# A Member shall respond to a reasonable request from the Scheme relating to its compliance within the period in Schedule 4. Failure to respond is a breach under clause 27.9.

15.5# Intermediaries. Traffic between two Members may pass through any number of gateways, hosts, proxies or brokers. None of them is a party to the Session, none is admitted, and the Scheme does not know them.

(a) The parties to a Session are the Member that initiates it and the Member whose systems are addressed. Both emit (20.1), and their two Assertions are the record.

(b) A Member is answerable under these Rules for the conduct of any Intermediary acting on its behalf, as if it had acted itself. Where an Intermediary acts on behalf of the Member in the Emitting Role, its conduct is that Member's conduct; where it acts on behalf of the Member in the Receiving Role, its conduct is that Member's.

(c) A Member shall not assert that an Intermediary's act was not its own, and no explanation based on the involvement of an Intermediary is admitted against a determination.

(d) Whether a party is an Intermediary of a Member, or is a Member in its own right conducting a separate Session, is determined by legal person and by who the Assertions name — not by deployment. Where a party operates its own interface, is addressed by a Member and emits its own Assertions, it is a party to a Session and not an Intermediary.

The point of this clause is that the Scheme does not care what is between A and B. It cares what happened at B, and both A and B say so under signature. Adding a third name to the record does not make the transaction more attributable.

15.6# Credentials. A Member is answerable under these Rules for every Interaction conducted with a credential issued to it by a counterparty Member to authenticate it in Sessions, or with a key it has registered under clause 20.5, as if it had conducted that Interaction itself, whoever in fact conducted it.

(a) That a credential or key was compromised, stolen, disclosed or used without the Member's authority is not an explanation admitted against a determination.

(b) Disclosure of the compromise under clause 25.1(a) before the Scheme identifies the breach is a mitigating factor under clause 30.4, and is the only respect in which the compromise bears on the consequence.

(c) A Member shall not assert that an Interaction conducted with its own credential or key was not its own.

(d) Nothing in this clause makes a Member answerable where no Rule was broken (28.4).

The point of this clause is the one the whole Scheme rests on. A Member with its own money at stake protects its credentials at its own cost, without being asked, and a credential that is well protected is one that is hard to steal. A rule that excused a Member whose credentials were taken would remove the reason to protect them.

16. Delegation and the intersection rule#

16.1# Where a Scope Class requires Delegation, a Member in the Emitting Role shall not open a Session except on the authority of an identified Principal.

16.2# The intersection rule. The effective permission for any Interaction in a Session is the intersection of:

(a) the Method Kinds permitted by the Scope Class;

(b) the authority actually granted by the Principal;

(c) any restriction applied under clause 12.1; and

(d) what the Principal is themselves entitled to do at the Member in the Receiving Role.

It is never the union of any of them. A Member in the Emitting Role may not do what the Principal cannot do, and a Principal may not cause a Member to act outside its Scope Class.

16.3# A Member in the Emitting Role shall record, and assert under clause 20, in respect of each Session requiring Delegation: the identified Principal; the type of Principal and the party to which it belongs; the authority that authenticated the Principal; a digest sufficient to identify the authority's assertion without reproducing it; the time authority was granted and the time it expires; the scope of authority granted; and every hop in the chain of delegation.

16.4# A Member in the Emitting Role shall not conduct any Interaction after the expiry recorded under 16.3. An Interaction after expiry is a breach under clause 27.3 and no explanation is admitted against it.

16.5# Limb (d) of the intersection rule is enforced by the Member in the Receiving Role, which knows the Principal's entitlements, and by no one else. A Member in the Receiving Role shall verify the Delegation presented against the authority named, by a method it can state, and shall record the result. Recording verification as performed when it was not is a breach under clause 27.5.

16.6# Parameter-level limits are enforced only by the Member in the Receiving Role. Assertions carry the names of arguments and never their values (clause 24.2), so the Scheme cannot determine whether a permitted method was invoked with impermissible parameters. A Member in the Receiving Role shall enforce the Principal's parameter-level authority at its own interface. This is an obligation on that Member, not a capability of the Scheme, and the two shall not be conflated in any statement made by or about the Scheme.

17. Ceilings#

17.1# A Member shall not exceed a ceiling stated in its Scope Class, measured over the window stated in that class, per counterparty. Only Interactions initiated by the Member in the Emitting Role count against that Member's ceiling. An Interaction initiated by the Member in the Receiving Role (Direction, clause 20.4A) is excluded from the count.

17.2# Exceeding a ceiling is a breach whether or not any Member suffered harm and whether or not the Interactions concerned were otherwise permitted.

17.3# A Member shall not set, file or influence the ceiling applicable to it. Ceilings are published by the Scheme and are identical for every Member in the class.

18. Honest labelling#

18.1# A Member in the Receiving Role that refuses an Interaction shall label the refusal as either:

(a) a class refusal — the Interaction was outside the Scope Class; or

(b) a local refusal — the Interaction was within the Scope Class and was refused under clause 12.1.

18.2# A class refusal is evidence of a breach by the Member in the Emitting Role. A local refusal is not, and carries no consequence for anyone.

18.3# Mislabelling a refusal is itself a breach under clause 27.5, attributed to the Member that labelled it. Local refusals will substantially outnumber class refusals in normal operation; a Scheme that treated them alike would turn every prudently restrictive Member into a source of false accusations against its counterparties.

19. Change control#

19.1# A Member shall assert the build identifier of the software conducting each Session.

19.2# A Member shall be able to identify, for the Substantiation Period, which build was running in any Session. Inability to do so is a breach under clause 27.6. The record by which it does so is Substantiating Material (clause 3).


Part 5 — Evidence#

20. The evidence standard#

20.1# Both Members to a Session shall emit. A Session evidenced by one Member only is not evidenced for the purposes of these Rules.

20.2# Each Member shall emit, for each Session, at minimum: a session-open Assertion, an Assertion for each Interaction, and a session-close Assertion. A Scope Class may require more. It may not require less.

20.3# Each Assertion shall carry the Session Identifier. This is the join key. Without a shared identifier the two records cannot be reconciled at all, and a Session for which the two Members assert different identifiers is a Divergence under clause 23.

20.4# Each Assertion shall identify its emitter and the role its emitter held in that Session. Direction and emitter identity are explicit fields and shall not be implied by the shape of the record.

20.4A# Each Interaction Assertion shall carry its Direction — whether the Interaction was initiated by the Member in the Emitting Role or by the Member in the Receiving Role. Direction does not change either Member's role (clause 3). It exists so that an Interaction is attributed to the Member that initiated it: without it, an Interaction initiated by the Member in the Receiving Role would count against the other Member's ceiling (17.1) and be tested against a Scope Class it never invoked (27.2). An Interaction initiated by the Member in the Receiving Role is recorded and reconciled, and is governed only by the response section of the Scope Class (9.6), which may be empty.

20.5# Each Assertion shall be signed by its emitter with a key registered with the Scheme. Registration of a key is not issuance of an identity (2.7).

20.6# Assertions shall be emitted within the deadline stated in the Scope Class. Where the emission interface is unavailable, a Member shall retain Assertions and emit them on restoration; Assertions emitted late for that reason are not a breach, and the Member shall assert the reason. The record published under clause 36.5 is the reference against which that reason is determined.

20.7# Emission is not urgent, is not in the data path, and shall not be a dependency of any Member's operations.

21. Integrity and repudiation#

21.1# An Assertion is a statement to the Scheme, made under these Rules, with consequences for making it falsely.

21.2# A Member repudiating an Assertion bearing its own signature commits a breach under clause 27.5, independently of whether the content of the Assertion was accurate.

21.3# A Member shall not alter, delete or re-sign an Assertion after emission. Corrections are made by emitting a further Assertion identifying the record corrected. Purporting to alter or withdraw an emitted Assertion otherwise than by correction is a breach under clause 27.5.

21.4# A gap in the Interaction sequence within a Session is a question the Member shall answer on request. Sustained or unexplained gaps are a breach under clause 27.6.

22. Retention#

22.1# The Scheme shall retain Assertions for the Retention Period stated in Schedule 4.

22.2# The Retention Period is set by the period within which a dispute between Members may realistically arise and is not chosen freely. Evidence that expires before a dispute surfaces is not evidence. That period is a function of the limitation period applicable under the law stated at clause 37; the two clauses are set together (37.3).

22.3# A Member shall retain the Substantiating Material for its own Assertions for the Substantiation Period stated in Schedule 4. Failure to do so is a breach under clause 27.9.

22.3A# Why this obligation exists, and where it stops. Clause 16.3 requires a Member to assert a digest of the authority's assertion rather than the assertion itself, and clause 24.1 forbids the Scheme to hold the underlying material at all. The Scheme therefore holds a fingerprint of something it does not have, and a fingerprint identifies nothing once the thing it identifies has been destroyed. The party disadvantaged by that destruction is not the Member that destroyed it but its counterparty, who can no longer test the record it relied on.

This clause is a protection for the counterparty. It is not a records-management policy and the Scheme does not have one. It reaches only the three items listed in the definition of Substantiating Material and reaches nothing else. A Member's logs, monitoring data, message contents and business records are its own affair, are not required by these Rules, and are not inspected by the Scheme (2.9).

22.3B# After the Substantiation Period, retention is a Member's own choice and its own risk. A Member that cannot produce the Substantiating Material for one of its own Assertions may not rely on that Assertion in any matter under Part 7 or Part 8, and to that extent the Assertion of a counterparty that can produce its own stands unopposed. This is an evidential consequence and not a determination; expiry of the Substantiation Period ends the obligation at 22.3 and this clause is what remains.

22.4# The Scheme shall destroy an Assertion on expiry of its Retention Period and shall record that it has done so. The Scheme shall not retain an Assertion beyond that period save under clause 22.5. An evidence store that never deletes has no lawful basis for the personal data at 16.3, and is a standing liability to every Member in it.

22.5# Destruction is suspended, and the obligation at 22.3 continues, in respect of any Session that is the subject of: a Divergence under review (23.5); a determination under review (32.1); a release requested or made under Part 8; or a requirement under clause 33.5. Suspension lasts until that matter concludes and no longer. No Member may require suspension on any other ground, and the Scheme shall not suspend destruction generally.

23. Reconciliation#

23.1# The Scheme reconciles the Assertions emitted by the two Members to a Session.

23.2# Reconciliation compares session totals and the Interaction sequence, including the argument digest and the Direction recorded for each Interaction. Totals are compared first because a disagreement there is dispositive without further comparison. Agreement on totals does not conclude the comparison, and a Session in which the totals agree but the sequences, digests or Directions do not is a Divergence.

23.3# A Matched Pair is recorded where the two Members' Assertions reconcile. A Matched Pair is a positive record that nothing happened, and exists so that the absence of incident is evidenced rather than assumed.

23.4# A Divergence is recorded where they do not, including where: one Member asserts an Interaction the other does not; totals cannot be reconciled; argument digests for the same Interaction differ; the Members record different Directions for the same Interaction; the Interaction sequences differ in order or content; or the Members assert different Session Identifiers for the same Session.

23.5# A Divergence is a question, not a determination. On recording a Divergence the Scheme shall place the Members concerned Under Review and shall require an explanation within the period in Schedule 4. Failure to respond within that period is a breach under clause 27.6.

23.6# Where a Divergence is explained by an emission failure at one Member, the consequence is that at clause 27.6. Where it is explained by Interactions conducted otherwise than through the Member's own instrumented path, the consequence is that at clause 27.5.

24. What the Scheme will not receive#

24.1# The Scheme shall not receive, request or retain: request or response bodies; the values of any argument; any Member's log estate; or personal data beyond the identifiers required by clause 16.3.

24.2# Assertions carry the names of arguments and a digest of their values. They do not carry the values. It follows that the Scheme cannot determine anything that would require reading an argument value, and no clause of these Rules shall be read as claiming otherwise.

24.3# A Member emitting anything at 24.1 to the Scheme commits a breach under clause 27.5, and the Scheme shall destroy the material. Clause 36.4 requires the emission interface to reject such material rather than receive it.

24.4# Substantiating Material is not emitted. It is held by the Member, is not sent to the Scheme, and is not requested by the Scheme except as a Member may choose to produce it in a matter under Part 7 or Part 8. Nothing in clause 22.3 permits the Scheme to receive material clause 24.1 forbids it to hold.


Part 6 — Incidents#

25. Disclosure#

25.1# A Member shall notify the Scheme, within the period in Schedule 4, on becoming aware of:

(a) any compromise of a key registered under clause 20.5, or of any credential issued to it by a counterparty Member to authenticate it in Sessions;

(b) any compromise of a Membership Attestation;

(c) any conduct by it, or by an Intermediary acting on its behalf, that it believes to be a breach of these Rules;

(d) any failure of its emission capability expected to persist beyond the emission deadline;

(e) any incident affecting a counterparty Member arising from a Session.

25.2# Self-disclosure under 25.1(c) before the Scheme identifies the breach is a mitigating factor under clause 30.4. A Member is not obliged to incriminate a counterparty and no duty to report another Member's conduct is imposed by this clause.

25.3# The Scheme shall notify a Member of any incident disclosed to it that concerns a Session to which that Member was party.

26. Cooperation#

26.1# A Member shall cooperate with the Scheme's enquiries into a Divergence or a suspected breach, and shall respond within the period in Schedule 4.

26.2# Cooperation means answering questions about that Member's own Assertions and its own compliance. It does not require a Member to provide payloads, log estates, or access to its systems, and the Scheme shall not request them.

26.3# A Member shall cooperate with a counterparty Member's reasonable enquiries arising from a Session between them. The Scheme is not a party to that exchange and does not enforce this clause; it is stated so that a Member knows what is expected of it, and a Member that considers a counterparty uncooperative has its remedies at law and under Part 8, not under Part 7.


Part 7 — Breach and consequence#

27. What is a breach#

27.1# Only the matters in this clause are breaches. Nothing else in the conduct of a Session carries a consequence under these Rules.

27.2# Operating outside a held Scope Class — conducting or attempting an Interaction of a Method Kind the Scope Class forbids, or operating without holding the class claimed. An attempt is a breach whether or not it succeeded and whether or not the counterparty was ever at risk. Only Interactions initiated by the Member in the Emitting Role are tested against that Member's Scope Class (20.4A).

27.3# Operating outside Delegation — conducting an Interaction without the Delegation the Scope Class requires, after the expiry recorded under clause 16.3, or outside the authority granted by the Principal.

27.4# Exceeding a ceiling — crossing a ceiling published in the Scope Class, measured over the window stated, per counterparty, counting only Interactions initiated by the Member charged (17.1).

27.5# False or misleading assertion — including: mislabelling a refusal (18.3); mapping a method to a Method Kind that understates its effect (13.3); recording verification as performed when it was not (16.5); repudiating one's own signed Assertion (21.2); purporting to alter or withdraw an emitted Assertion otherwise than by correction (21.3); misrecording the Direction of an Interaction (20.4A); emitting Assertions not generated by one's own systems (15.3); asserting that an Intermediary's act was not one's own (15.5(c)); asserting that an Interaction conducted with one's own credential or key was not one's own (15.6(c)); or emitting prohibited material (24.3).

27.6# Evidence failure — failing to emit a required Assertion within the deadline other than under clause 20.6; sustained or unexplained sequence gaps (21.4); inability to identify a build (19.2); failing to respond within a period stated in Schedule 4 (23.5, 26.1).

27.7# [Reserved] — failure of a sponsored party. Removed at 0.4 with clause 6. Attribution for a party acting on a Member's behalf is now at 15.5(b), determined under 27.2 to 27.6 against the Member itself. This number is not reused.

27.8# Non-payment of a Liquidated Sum by the date due (clause 31.4).

27.9# Failure of an obligation owed to the Scheme — failing to notify a change of circumstances (7.1); failing to cease accepting Sessions on notification of revocation (8.2(c)); failing to file or maintain a current method mapping (13.2); failing to respond to a request from the Scheme (15.4); or failing to retain Substantiating Material for the Substantiation Period (22.3). A breach under this clause ordinarily has no Affected Member and carries a Standing consequence only (31.2).

28. What is not a breach#

28.1# A local refusal under clause 12.1, by either Member.

28.2# Late emission caused by the unavailability of the emission interface, asserted under clause 20.6 and consistent with the record published under 36.5.

28.3# A Divergence, until determined under clause 23.6. A Divergence is a question.

28.4# Conduct within a Scope Class that a Member or the Scheme considers undesirable but which breaks no Rule. The Scheme does not make a Member answerable where no Rule was broken.

28.5# Volume, timing or pattern that differs from a Member's own history or from the membership's observed norms. See clause 29.4.

28.6# Notification under clause 7.1, or self-disclosure under clause 25.1(c). Neither is a breach and neither is evidence of one.

28.7# An Interaction initiated by the Member in the Receiving Role, save as the response section of the Scope Class provides (9.6, 20.4A).

28.8# Disposal of Substantiating Material after the Substantiation Period has expired. The consequence is evidential and is stated at 22.3B.

29. Determination#

29.1# Determination is the comparison of an Assertion against a published Rule. It is arithmetic and it does not involve the Scheme forming a view.

29.2# The Scheme shall determine a breach on the face of the Assertions held and the published Rules in force at the time of the Session, and shall record: the Rule, the Session, the Assertions relied on, and the Member to which the breach is attributed.

29.3# The Scheme shall not determine a breach on the basis of an Assertion emitted by one Member alone where the Rule requires both, save that failure by the other Member to emit is itself determined under clause 27.6 against that other Member.

29.4# The Scheme shall not derive any consequence from a statistical baseline, a model, an anomaly score or a comparison with any Member's history or with the membership. Observed usage may inform the Scheme's review of whether a ceiling is set sensibly, and may inform the next version of a Scope Class. It shall never produce a consequence in respect of an individual Session or Member.

29.5# The Scheme shall notify a determination to the Member concerned and to any Affected Member.

30. Consequences#

30.1# A determination carries the consequence stated in Schedule 2 for that category of breach: a change of Standing, a Liquidated Sum, or both.

30.2# The Liquidated Sums for a Scope Class are set with that class, on the admission of the first Member into it, and published before they apply to anyone. They are set as a genuine pre-estimate of the Affected Member's administrative and governance cost of dealing with a breach of that category — investigating what occurred, establishing its own exposure, and responding to the Scheme. They are not a pre-estimate of the Scheme's costs, which the Affected Member does not incur, and they are not a measure of loss. They are published before they apply. Schedule 2 states the structure they must take and gives illustrative figures.

30.3# A consequence attaches to the breach of an obligation held in a particular role. Where a Member holds different roles in different Sessions, the consequence for a breach is that stated in Schedule 2 for the role in which the obligation broken was held. The consequence is identical for every Member breaching the same Rule in the same role.

30.4# Where Schedule 2 publishes a range rather than a fixed amount, the Scheme shall have regard, in determining where within that range a consequence falls, only to: whether the Member self-disclosed under clause 25.1(c) before the Scheme identified the breach; whether the same Rule has been breached by that Member within the period in Schedule 2; and whether the Member cooperated under clause 26. It shall have regard to no other matter. Where Schedule 2 publishes a fixed amount, this clause applies only to the Standing consequence.

30.5# A consequence is owed whether or not any Member suffered harm.

31. Payment#

31.1# A Liquidated Sum is payable by the Member in breach to the Affected Member. No Liquidated Sum is payable to the Scheme.

31.2# The Affected Member is the counterparty to the Session in which the breach occurred. Where a breach spans Sessions with more than one counterparty, the sum is apportioned by the number of Sessions affected. Where no counterparty can be identified — including breaches of Part 5 disclosed by reconciliation alone, and breaches under clause 27.9 — the consequence is a Standing consequence only and no Liquidated Sum arises.

31.3# The Scheme does not collect, hold, route or take a share of any Liquidated Sum. It records that the sum is due, and records payment or non-payment as notified by the Affected Member.

31.4# A Liquidated Sum is due within the period stated in Schedule 2, running from the date of determination or, where review is sought under clause 32, from the date the review is determined. Non-payment by that date is itself a breach under clause 27.8, evident on the face of the record and requiring no investigation, and carries the Standing consequence in Schedule 1.

31.5# An Affected Member may waive a Liquidated Sum owed to it. Waiver does not affect any Standing consequence and shall be notified to the Scheme.

31.6# The aggregate cap. The total of all Liquidated Sums payable by one Member to one counterparty in respect of breaches occurring within any rolling window stated in Schedule 2 shall not exceed the cap stated there. The cap is a limit on the Scheme's consequences and not on any Member's liability at law; nothing in it restricts what an Affected Member may recover from a counterparty by any other route (32.4). The cap exists because a sum expressed per Assertion is otherwise unbounded, and an unbounded sum is neither a genuine pre-estimate nor something any Member's risk function can approve. Standing consequences are not capped.

32. Review#

32.1# A Member may seek review of a determination within the period in Schedule 4.

32.2# Review is limited to whether the Rule relied on was in force and applicable; whether the Assertions relied on are those held; whether the determination follows from them; and whether the consequence applied is that published. Review is not a rehearing, is not an arbitration, and does not extend to the merits of the Rule.

32.3# The Scheme shall determine a review on the documents. There is no hearing.

32.4# A Member that disputes a determination beyond the scope of 32.2 may withdraw from the Scheme under clause 8.1 and pursue any remedy it has at law. Nothing in these Rules excludes, restricts or replaces any Member's rights against another Member.

32.5# Effect of a request for review. A determination is recorded when made. A Member that has requested review is Under Review under Schedule 1 until the review is determined; a Standing consequence of Suspension and the period for payment under 31.4 both run from the date the review is determined. Where a review succeeds, the determination is set aside and the Scheme shall record the reason under 35.4. Review does not extend the Standing effects of any other determination.


Part 8 — Evidence provision#

33. The witness function#

33.1# Where a Member notifies the Scheme that it is in dispute with another Member concerning loss arising from one or more Sessions, the Scheme shall release the Assertions it holds for those Sessions. The Scheme does not test whether a dispute exists; a Member may obtain the record of any Session to which it was party, and the notification requirement is a formality rather than a gate.

33.2# The Scheme shall release those Assertions to both Members, simultaneously, in the same form, whether or not both requested them.

33.3# The Scheme shall take no position. It shall not characterise the Assertions, shall not state whether loss occurred or was caused, shall not quantify anything, and shall not appear, advocate or opine for either Member.

33.4# Release under this Part is not a determination and does not require one. Determination under Part 7 concerns Rules; this Part concerns loss, and the Scheme has no function in respect of loss beyond release.

33.5# The Scheme shall release Assertions to a court, regulator or other authority where legally required, and shall notify the Members concerned unless prohibited from doing so.

33.6# A request under this Part suspends destruction of the Assertions concerned under clause 22.5, and continues a Member's obligation under 22.3 in respect of the same Sessions, until the matter concludes.


Part 9 — The Scheme's own obligations, the rulebook itself, and governing law#

34. Amendment#

34.1# The Scheme may amend these Rules. An amendment shall state its effective date and shall not apply to Sessions conducted before that date.

34.2# The Scheme shall notify Members of an amendment not less than the period stated in Schedule 4 before it takes effect.

34.3# A Member that does not accept an amendment may withdraw under clause 8.1 before the effective date without consequence under these Rules.

34.4# No amendment shall introduce a Liquidated Sum payable to the Scheme, place the Scheme in the data path, give the Scheme a function in respect of loss, make the Scheme a Member, or permit the emission interface to receive the material at clause 24.1. These are constitutional limits on the Scheme and are not amendable under this clause.

35. The Scheme's obligations to Members#

35.1# The Scheme shall publish: these Rules; every Scope Class and its version history; Schedule 1 and Schedule 2; the specification of the emission interface and its version history (36.1); the availability record (36.5); and the register of Members, their Scope Classes and their Standing.

35.2# The Scheme shall apply these Rules identically to every Member and shall not vary, waive or disapply a Rule for any Member.

35.3# The Scheme shall not act as a Member, operate an agent, expose an interface governed by these Rules, or hold any interest in a Member. The emission interface at clause 36 is not an interface governed by these Rules and its operation is not participation in the Scheme.

35.4# The Scheme shall record the reason for every determination and every change of Standing, and shall make that record available to the Member concerned.

35.5# How this Part is enforced. The obligations in clauses 35 and 36 are owed by the Scheme to Members. They are not enforced by Standing or by a Liquidated Sum, because the Scheme cannot suspend itself and no sum is payable to or by it under these Rules (31.1, 34.4). They are enforced by exit: a Member that does not accept how the Scheme discharges them may withdraw under 8.1, or decline an amendment under 34.3, and the constitutional limits at 34.4 are not amendable. This asymmetry is deliberate and is recorded in Known limitations as the floor of the Scheme's enforceability.

35.6# The Scheme shall destroy Assertions when required by clause 22.4 and shall not retain them otherwise. This obligation is of the kind described at 35.5.

36. The emission interface#

36.1# The Scheme shall operate an interface by which Members emit Assertions, and shall publish its specification.

36.2# Emission is not a Session and the Scheme is not a Member. The interface is not governed by these Rules; if it were, emission would itself require Assertions from both parties under 20.1, those Assertions would describe a further Session, and the Scheme would determine breaches in proceedings to which it was a party. The obligations in this clause are of the kind described at 35.5.

36.3# The specification shall be versioned. The Scheme shall state a transition period before a new version becomes mandatory, not shorter than the period in Schedule 4, and shall accept the previous version throughout it. No Member is required to re-instrument without notice.

36.4# The interface shall be incapable of accepting the material at clause 24.1. It shall reject, rather than receive and discard, any submission containing a request or response body or the value of any argument. Clause 24.1 states what the Scheme will not receive; this clause requires that it cannot.

36.5# The Scheme shall publish a record of every period in which the interface was unavailable. That record is the reference against which an assertion under clause 20.6 is determined, so that late emission excused by unavailability is arithmetic under 29.1 rather than a Member's own word against the Scheme's. Where a Member asserts unavailability and the published record does not show it, the Scheme shall put the matter to the Member under 26.1 before determining anything.

36.6# The Scheme shall not require, as a condition of emission, that a Member use any product, service or intermediary in which the Scheme holds an interest.

36.7# Nothing in this clause creates a service level owed to any Member. Where the interface is unavailable, clause 20.6 applies, no Member is in breach, and the Scheme's availability remains not a dependency of any Member's operations (2.2).

37. Governing law#

37.1# These Rules, and any dispute or claim arising out of or in connection with them, are governed by the law of England and Wales.

37.2# The courts of England and Wales have non-exclusive jurisdiction over any dispute or claim arising out of or in connection with these Rules. A Member may bring proceedings in the courts of its own jurisdiction where the law of that jurisdiction permits it to do so, and the Scheme submits to those courts for that purpose.

37.3# Clause 22.2 depends on this clause. The Retention Period is derived from the period within which a claim on these Rules may be brought, which under 37.1 is six years for a claim founded on simple contract. A different governing law gives a different limitation period and therefore a different Retention Period, and the two are set together or neither is defensible.

37.4# Nothing in this clause excludes, restricts or replaces any right a Member has against another Member under any other contract or under any other law (32.4), nor any right a Principal or other person has under data protection law.


Schedules#

Schedule 1 — Standing#

State Effect Entered when Left when
Good Full participation. Membership Attestations valid. On admission; on resolution of Under Review; on completion of a Suspended period and remedy; on a successful review (32.5). On entering any other state.
Under Review Participation continues. Membership Attestations valid. A Member in the Receiving Role is notified and may restrict under clause 12.1. On a Divergence (23.5); on a determination for which review has been requested (32.5); on notification under clause 7.1. On explanation accepted; on determination; on determination of a review; or automatically on expiry of the maximum period in Schedule 4, whereupon Standing returns to Good.
Suspended Membership Attestations invalid. Members in the Receiving Role shall cease to accept Sessions under clause 8.2. On repeated breach within the period in Schedule 2; on non-payment (31.4); on failure to respond (27.6) after notice; on sustained breach of 27.9. On remedy and payment of sums due.
Expelled Membership ends. Obligations under Parts 5 and 6 survive, each for its own period (1.4): the Scheme holds the Assertions for the Retention Period, and the former Member retains Substantiating Material for the Substantiation Period. On sustained or deliberate breach; on repudiation of these Rules. Not applicable. Readmission is a fresh admission.

Under Review is a state that exists precisely so the Scheme has something to do that is not adjudication. Entry under clause 7.1 records a change notified by the Member and is not an adverse finding (7.3).

Schedule 2 — Consequences#

How the sums in this Schedule are set

The structure below is fixed and is not negotiated. The amounts are set with the Scope Class they belong to, on the admission of the first Member into that class, and are published before they apply to anyone (30.2). A sum that is not proportionate to what its class permits is not a deterrent, so a sum cannot be set before the class it attaches to exists.

The amounts shown here indicate the order of magnitude the Scheme works in, so that a reader can see what kind of instrument this is — cost recovery, not damages. They are derived from first principles under clause 30.2 and from no external benchmark. Figures are in USD.

These sums are consequences, not fees. Every amount in this Schedule is payable on breach of a Rule, by the Member in breach, to the Affected Member (31.1). None of them is a fee for membership, admission, assessment or any service, and no fee of any kind is payable to the Scheme (31.1, 34.4). What it costs to join the Scheme and to remain in it is not stated in these Rules and is set out in a separate schedule of fees. A reader looking for the price of membership will not find it here, and that is deliberate: this is a rulebook, and these are the sums attached to breaking the rules.

Role is the column clause 30.3 indexes on. Where a category is marked Either, the obligation broken is one both roles hold, and the consequence is the same in both.

Breach category Clause Role Standing consequence Liquidated Sum — order of magnitude
Operating outside Scope Class 27.2 Emitting Under Review; Suspended on repetition USD 1,000–2,500 per Session
Operating outside Delegation 27.3 Emitting Under Review; Suspended on repetition USD 1,000–2,500 per Session
Exceeding a ceiling 27.4 Emitting Under Review USD 250–500 per window exceeded
False or misleading assertion 27.5 Either Under Review; Suspended on repetition USD 2,500–5,000 per Assertion
Evidence failure 27.6 Either Under Review; Suspended if sustained USD 2,500 per Session where an Affected Member is identified; none otherwise (31.2)
Non-payment 27.8 Not role-specific Suspended None
Obligation owed to the Scheme 27.9 Either Under Review; Suspended if sustained None (31.2)

Aggregate cap (31.6): USD 25,000 per Member, per counterparty, per rolling 30-day window, across all categories. Standing consequences are not capped.

Why these numbers are small. The deterrent in this Scheme is Standing, not money — clause 5.4 says so. A Liquidated Sum is a pre-estimate of what it costs the Affected Member to deal with the breach (30.2): an engineer and someone in risk, a few hours for something contained, a day or two for something needing real investigation. Sums set high enough to frighten would stop being a pre-estimate of anything and would invite exactly the characterisation drafting note (b) exists to avoid. A reader who thinks these are too low has misunderstood what they are for.

Fixed in this version:

Schedule 3 — Scope Class template#

Content is written with the Member on admission (9.3). Every published Scope Class shall contain at least:

Element Requirement
Class identifier and version Unique; versioned; effective date stated
Description What a Member in this class does, in one sentence
Emitting section The obligations below, binding the Member in the Emitting Role (9.6)
Permitted Method Kinds Enumerated
Forbidden Method Kinds Enumerated
Delegation Required or not; binding (per Session or per Interaction); whether the Principal must be named
Ceilings At least one windowed ceiling (9.5), stating the unit counted; per-Session figures may be stated as a secondary bound
Required Assertion types At minimum session-open, Interaction, session-close
Emission deadline Seconds
Substantiation Period Stated only where the class extends the period in Schedule 4. A class may extend and shall not shorten it (9.7)
Response section The obligations of the Member in the Receiving Role (9.6). Declared and empty. For a class covering a plain request/response API this section is not applicable rather than deferred: the Member in the Emitting Role exposes no surface the counterparty can address, so there is nothing for it to govern. It becomes live only for a class covering a protocol in which the Receiving Member may initiate Interactions — MCP sampling and elicitation, webhooks, callbacks — and until it is written, such Interactions are recorded and reconciled but not governed (20.4A, 28.7).

Schedule 4 — Periods#

Complete at this version. Every period the Rules depend on has a value.

"Business day" means a day other than a Saturday, Sunday or public holiday in England and Wales (37.1). Periods expressed in months or calendar days run continuously.

Period Clause Owed by Value
Notification of change of circumstances 7.1 Member 10 business days
Notification of insolvency proceedings 7.1 Member 2 business days
Notification of revocation 8.2(b) Scheme 1 business day. The register under 8.2(a) is updated with effect from the change itself and is authoritative
Response to a Scheme request 15.4, 26.1 Member 10 business days
Explanation of a Divergence 23.5 Member 10 business days
Maximum period Under Review Schedule 1 Scheme 30 business days
Incident disclosure 25.1 Member 72 hours
Retention Period — binds the Scheme 22.1 Scheme 72 months
Substantiation Period — binds a Member 22.3, 19.2 Member 24 months. A Scope Class may extend it and shall not shorten it (9.7)
Request for review 32.1 Member 20 business days from notification of the determination
Notice of amendment 34.2 Scheme 60 calendar days
Emission interface transition period 36.3 Scheme 180 calendar days — the minimum a Member has to re-instrument

Periods payable under Schedule 2 — the period for payment of a Liquidated Sum (31.4), the repetition period for 30.4 and Schedule 1, and the rolling window for the aggregate cap (31.6) — are set in that Schedule with the sums, and are not repeated here.

Three of these are the Scheme's own deadlines and not a Member's, and they are the ones worth reading first: notification of revocation, the cap on Under Review, and notice of amendment. A rulebook that only puts clocks on Members is a rulebook a Member is right to distrust.

Why 1 business day for notification of revocation, and why it is no longer load-bearing. Under 1.0 this was the only period the Scheme could not miss without undermining membership, because a Member in the Receiving Role stopped accepting a revoked counterparty only from the time it was notified. Clause 8.2 was amended at 1.1 so that the published register carries the guarantee instead. The register is updated with effect from the change itself, a Member may check it at the moment a Session is offered, and 8.2(e) protects a Member that relies on it. The one-day period remains as a discipline on the Scheme and its breach is a real breach — but a Member's protection no longer depends on the Scheme meeting it, which is the point of the change.

Why there is a maximum period Under Review. Schedule 1 says a Member leaves Under Review on expiry of a period in Schedule 4. Without a cap, a Member could be held Under Review indefinitely — participation continues, but counterparties are notified and may restrict under 12.1, so indefinite Under Review is suspension by attrition without a determination and without a route to review under clause 32. Thirty business days, after which Standing returns to Good unless the Scheme has determined something. The burden of concluding a review sits with the Scheme, which is correct: it opened it.

Why 72 hours for incident disclosure. It is the clock a security function already runs, being the personal-data breach notification period under UK and EU data protection law. Choosing a familiar number costs the Scheme nothing and removes an argument about whether the period is reasonable.

Why 60 days' notice of amendment. Under 34.3 a Member that does not accept an amendment may withdraw before it takes effect. That right is worth only as much as the time to exercise it — long enough to read the change, take advice and re-plan an integration.

Why 180 days to re-instrument. Clause 36.3 says no Member is required to re-instrument without notice. Changing an emission format is engineering work that must find a slot in someone else's roadmap, and two quarters is the shortest honest answer.

These periods are convention, not measurement. Unlike the two retention figures, none of them is derived from anything external, and none has been tested against an operator. They are the numbers most likely to move when the first Member reads them, and moving them is an amendment under 34.1 rather than a redrafting.

Why 72 months. Clause 22.2 requires the period to be the realistic dispute window rather than a free choice. Under the law stated at 37.1 a claim founded on simple contract must be brought within six years. It is also the period the Scheme can justify holding the personal data at 16.3 — namely as necessary for the establishment, exercise or defence of legal claims — so the same figure satisfies both the evidential requirement and the data protection constraint. Cost played no part in it and could not: at measured volumes six years of a busy relationship costs the Scheme a few pounds a year.

Why 24 months, and why it is a different number. The Substantiation Period binds a Member and costs the Scheme nothing, so it is not set by the Scheme's convenience. It is set at the period within which a challenge to a specific Assertion realistically arrives, and no longer, because the obligation is an entry cost for every applicant and clause 22.3A limits it to what makes the Scheme's record work. Members whose own regime requires longer will set longer, by their own policy or through a Scope Class under 9.7. Beyond the period, clause 22.3B applies and the choice is the Member's.

Schedule 5 — Consumed mechanisms#

The Scheme consumes and does not operate the following. This list is maintained by the Scheme and its contents are not Rules.

Function Mechanism Note
Member and workload identity SPIFFE / WIMSE Consumed
Automated client identity Web Bot Auth Consumed
Agent identity and delegation transport KYA-OS / MCP-I Consumed
Principal authentication The Member's own identity provider Named in Assertions under 16.3; never operated by the Scheme
Signature Ed25519 or as stated in the schema Keys registered under 20.5; registration is not issuance (2.7)

The Scheme builds none of these. The gap is accreditation and enforcement, not identity. The one thing the Scheme does issue — the Membership Attestation (2.7) — states that a party was admitted, not who it is, and is worthless without the mechanisms above.


What changed#

Most recent first. Every superseded version stays published at its own address, linked from the version history page.

1.3 — 15 September 2026#

One clause is added and one is widened. No obligation is removed and no period or sum changes.

New clause 15.6 — credentials. A Member is answerable for every Interaction conducted with a credential issued to it by a counterparty, or with a key it has registered, as if it had conducted that Interaction itself, whoever in fact conducted it. That a credential was compromised, stolen, disclosed or used without authority is not an explanation admitted against a determination. Prompt disclosure is a mitigating factor under clause 30.4 and nothing more. Clause 27.5 gains the matching breach: asserting that an Interaction conducted with one's own credential was not one's own.

Why. Under 1.2 a Member was answerable for an Intermediary acting on its behalf (15.5), but nothing said what happened when someone who was not acting on its behalf used its credentials. A Member could have argued that such Interactions were not its own. That argument would have removed the incentive the Scheme depends on: a Member protects its credentials because a misuse of them costs it, whoever carried it out.

Clause 25.1(a) is widened from a compromise of the signing key registered with the Scheme to a compromise of any credential a counterparty issued to the Member. The credential most likely to be taken is the one used to call a counterparty's interface, and 1.2 did not reach it.

Made before the Scheme had any Members, so no notice under clause 34.2 was required. Numbering is unaffected: 15.6 is a new number and no number is reused.

1.2 — 2 September 2026#

No clause is changed and no obligation is added, removed or varied. One entry is added to Known limitations: that the Scheme is operated by one person, that clause 22.1 obliges it to hold Assertions for six years and Part 8 to release them throughout that period, and that no escrow, custodian or successor arrangement presently stands behind either.

Why it is stated rather than solved. Storage is not the constraint — six years of a busy relationship costs the Scheme around $14 a year. Continuity is, and the instruments that answer it cost real money for a Scheme that has no Members yet. The position taken is to say so plainly now and to put a named custodian in place before the first Member is admitted, rather than to publish a promise the Scheme cannot presently keep. Known limitations exists so that no Member discovers something later; a limitation the Scheme knows about and leaves off that list would be worse than the limitation itself.

1.1 — 2 September 2026#

One amendment, made before the Scheme had any Members, and therefore requiring no notice under clause 34.2.

Clause 8.2 — revocation propagation. Under 1.0 the Scheme undertook to notify every affected Member within one business day, and a Member in the Receiving Role was required to stop accepting a revoked counterparty from the time it was notified. The consequence was that a Member's protection depended on the Scheme being reachable on a particular day, which is an availability promise the Scheme should not make and a Member should not have to rely on.

1.1 moves the guarantee to the published register. The register is updated with effect from the change itself and is authoritative (8.2(a)); a Member in the Receiving Role must stop accepting from the earlier of notification and the register entry (8.2(d)); and a Member that relies on the register as it stood at the time of a Session does not breach (8.2(e)). The notification duty survives at 8.2(b) with the same one-business-day period, as a discipline on the Scheme rather than as the mechanism Members depend on. New clause 8.2A explains why. Schedule 4 is updated to match.

Nothing else changed. No other clause, no Schedule other than 4, no period other than the re-pointing of the revocation row from 8.2(a) to 8.2(b).


Known limitations of this rulebook#

Carried here deliberately so that no Member discovers them later.

Silence may be cheaper than emission. Clause 29.3 prevents the Scheme determining a substantive breach on one Member's Assertion alone. A Member that has just breached can therefore emit nothing and face only the evidence-failure consequence at 27.6 instead of the substantive one. Schedule 2 requires the evidence-failure sum to be not lower than the highest per-Session substantive sum, which removes the arithmetic incentive. Unresolved: whether that is sufficient, or whether sustained non-emission by a Member whose counterparty has emitted should escalate to Suspension faster than 27.6 otherwise provides. It cannot be solved by presumption — inferring the substantive breach from the counterparty's Assertion alone is precisely what 29.1 and 29.4 forbid.

Exit is the floor of enforceability. Every consequence in Part 7 ultimately rests on a Member wanting to remain a Member. A Member facing a Liquidated Sum larger than the value of its membership can withdraw under 8.1 or accept Expulsion, and the Scheme has no mechanism to compel payment; clause 27.8 threatens Suspension, which is meaningless to a party already leaving. The Affected Member's remedy at that point is at law on the contract, with the Scheme's Assertions as evidence under Part 8 — which is the honest description of what the Scheme provides. This is the single largest gap between what a scheme with regulatory backing can do and what this one can.

The Scheme's own obligations are enforced only by exit. Clause 35.5 states this. Members are asked to instrument against an interface operated by a party they cannot suspend and cannot fine. The constitutional limits at 34.4 are the only hard protection, and they are hard only because the Scheme says so in a document it also controls. A Member large enough to care will ask for that protection somewhere other than the rulebook.

There is an evidence cliff between 22.1 and 22.3, and it is the price of the split. The Scheme holds an Assertion for 72 months; the Member need hold the Substantiating Material behind it for only 24. Between month 25 and month 72 an Assertion may be unbackable by its own author. The design answer is that an Assertion does not depend on its Substantiating Material, because it is corroborated by a second, independently signed record from a party with an opposing interest (23.1–23.3) — which is the argument the whole Scheme rests on. The residual is real: a counterparty can time a challenge to arrive after the Substantiation Period, and 22.3B allocates the disadvantage to the Member that disposed. That allocation is deliberate and may be wrong.

The Scheme cannot see whether Substantiating Material was retained. Clause 22.3 is an obligation of the kind at drafting note (c): the Scheme allocates it and cannot verify it. In practice a breach of 22.3 becomes visible only when the material is asked for, which is in a matter under Part 7 or Part 8, at which point 22.3B does most of the work and the 27.9 consequence adds little. The honest description is that 22.3 is enforced evidentially and only nominally by Standing.

Clause 12.2 has no consequence. A Member in the Receiving Role that is looser than its accepted Scope Class breaks clause 12.2, but clause 27 does not name that conduct as a breach and 27.1 closes the list. Schedule 2 accordingly marks 27.2, 27.3 and 27.4 as Emitting-Role breaches, because on the current drafting that is all they can be. Unresolved: whether 27.2 should be widened to attach to the Receiving Role, and whether the Scheme can in fact see a looseness breach — a Session accepted outside the class reconciles perfectly if both Members assert it honestly, and is visible only because the Method Kind asserted is one the class forbids.

Admission and acceptance are two mechanisms with a gap between them. A Member that only ever receives is admitted under Part 2 — but 4.1 assesses it "against the published standard for the class applied for", and the emitting section of that class describes conduct it never performs. Clause 11.3 records that admission and acceptance are independent acts, but not what a receive-only Member is admitted into. The candidate fix is to make admission itself role-parameterised — admitted into class X in the Emitting Role, or into class X in the Receiving Role — collapsing two mechanisms into one and preserving 11.1's real point, that acceptance is declared once to the Scheme and never negotiated per counterparty. Not done in this version: it is structural and deserves a decision rather than a drafting pass.

The masking problem, now unmitigated. A Member in the Receiving Role that restricts prudently under clause 12.1 may stop a misbehaving counterparty below the ceiling in its Scope Class. No breach is recorded, and the next Member in the Receiving Role — restricting less tightly — receives no warning. Unresolved: whether repeated local refusals should become reportable above a threshold, and whether that would amount to the Scheme forming a view contrary to clause 29.4.

The Scheme detects consequence, not cause. Where a Member in the Emitting Role is compromised — by prompt injection or otherwise — every Interaction may remain within its Scope Class and every Assertion may reconcile perfectly. What catches it is the windowed ceiling at clause 17, and nothing else, and only after the fact. The Scheme caps blast radius. It does not prevent compromise.

Parameter-level misuse is invisible to the Scheme. Clause 24.2 is a hard limit. Clause 16.6 places the obligation on the Member in the Receiving Role, and the Scheme cannot verify that it was discharged.

Reverse-direction Interactions are attributed but not governed. Clause 20.4A records who initiated an Interaction so that it is charged to the right Member, and clause 28.7 confirms that an Interaction initiated by the Member in the Receiving Role breaks no Rule. What such an Interaction may and may not do is governed by the response section of the Scope Class, which is empty. For a plain API that is correct and permanent; for MCP sampling and elicitation it is a real gap, and a hostile Receiving Member's callbacks are recorded but unconstrained.

Chained Sessions are not linked. Where a Member in the Receiving Role for one Session is the Member in the Emitting Role for another — B receives from A and calls C — the two Sessions reconcile independently and nothing in the record connects them. A breach at C cannot be traced back to A through the Scheme. This is deliberate at this version; clause 15.5 keeps the Scheme's subject to two named parties per Session.

These Rules contain no funding model. Nothing states how the Scheme is paid for. Admission assessment, retention and operation of the emission interface all have a cost, and clause 31.1 forecloses the obvious source by prohibiting any Liquidated Sum payable to the Scheme. A membership or assessment fee is not inconsistent with these Rules but is not stated in them, and is to be set out in a separate schedule of fees. Retention is not the load-bearing part of that cost: it is measured at a few pence per gigabyte-year. The costs that actually grow are write operations at the emission interface and the Scheme's own labour under clause 23 and Part 8.

The Delegation requirement has no implementation anywhere. Clause 16.3 requires a Member in the Emitting Role to emit something no current implementation produces. It is a real adoption cost and the only genuinely novel requirement in these Rules.

Two questions for a lawyer.

  1. Whether a Liquidated Sum as structured in Schedule 2, including the aggregate cap at 31.6, survives the English-law test separating liquidated damages from an unenforceable penalty. Partial answer found. Reapit Foundations' published Developer Terms carry a fixed liquidated sum for breach of its approval process — in force, drafted by counsel, and published in advance, which is evidence that a published fixed administration sum survives the test. It does not close the question: the aggregate cap at 31.6 is a different instrument and has no such precedent.
  2. Jurisdiction under clause 37.2, and whether English law is the right choice at 37.1 given that Members are expected in the EU. The question has a concrete consequence attached rather than being abstract: 37.3 makes the Retention Period a function of the answer.

The Scheme is operated by one person, and its longest obligation outlives that fact. Clause 22.1 obliges the Scheme to hold Assertions for the Retention Period — 72 months — and Part 8 obliges it to release them to Members throughout. Both are promises that an institution will still exist, and still answer, in six years' time. The Scheme is presently a single operator, and no escrow, custodian or successor arrangement stands behind either obligation. Storage is not the constraint: six years of a busy relationship costs the Scheme around $14 a year. Continuity is, and it is not something a Member can verify or the Rules can compel. Clause 35.5 already records that the Scheme's obligations are enforced only by exit, and exit is worth nothing against a Scheme that has ceased to exist. Unresolved, and it should be resolved before the first admission: whether a named custodian or a third-party escrow takes custody of the Assertions if the Scheme stops operating. A Member is entitled to ask what the arrangement is before it signs, and to be told.

These Rules have never been operated. No Session has been conducted under them and no determination has been made.