Every answer here is settled somewhere in the rulebook, and this page says where.
A membership scheme for the API traffic between two named companies. An organisation whose agents call somebody else's API is assessed once against a published standard rather than separately by every counterparty. From then on, each time the two systems talk, both sides independently send Rootwall a short signed record of what happened — who, under whose authority, against which declared scope, with what outcome. Rootwall puts the two records side by side. Where they agree, that agreement is itself the record. Where a rule was broken, a consequence published in advance attaches.
It is a scheme, in the sense that Visa is a scheme. It is not a network, a gateway or a piece of infrastructure, and no traffic passes through it.
The chain is worth stating in full, because it is spread across four clauses:
So Rootwall's real instrument is loss of access across the whole membership, and the money is a matter between the two companies with better evidence than they would otherwise have.
What survives is the part a scheme is for. The departure is recorded. Revocation reaches every member that accepted that scope class, so it is not a quiet exit. Readmission is a fresh admission, not a restoration. And the affected member still holds two independently signed accounts of what happened — which is what a claim actually needs.
What does not survive is compulsion. A member facing a sum larger than its membership can withdraw or accept expulsion, and suspension means nothing to a party already leaving. Recovery is then an ordinary contract claim, with better evidence than either side would otherwise have.
Structured statements about sessions. Never the contents of anything. No request or response bodies, no argument values, no member's logs. Assertions carry the names of arguments and a cryptographic digest of their values, never the values themselves.
This is a limit on Rootwall and not merely a permission for members: the emission interface is required to be incapable of accepting that material — to reject it rather than receive and discard it. It follows that Rootwall cannot determine anything that would require reading an argument value, and no clause claims otherwise.
No. Rootwall is never in the path of any call. If Rootwall is entirely unavailable, members carry on transacting and the only consequence is that records are sent later.
You already have gateways and API security products, and those are controls you operate against traffic you can see. The argument here is not that you cannot block a misbehaving agent. It is that today, when you do, nothing happens to the party that sent it, and the next company it calls gets no warning.
Agent and workload identity is a crowded and fast-commoditising field — Web Bot Auth, MCP-I, SPIFFE and others. Rootwall consumes those and builds none of them.
Identity answers this agent is who it claims to be. It does not answer was that within what it was allowed to do, and who says so besides the party claiming it. The gap Rootwall occupies is one layer up: accreditation against a published standard, and a consequence when the standard is broken.
Rootwall issues one thing, a membership attestation, which states that a named party was admitted to a named scope class on a named date. It asserts nothing about who that party is and is worthless without an identity mechanism Rootwall does not operate.
Rulebook 2.7, Schedule 5.
A divergence is a question, not a finding. Both parties are placed Under Review and asked to explain within a published period. Under Review is not an adverse finding, participation continues, and it expires automatically after thirty business days unless Rootwall has determined something — so nobody can be left in limbo indefinitely.
If it turns out one side simply failed to send records, that is an evidence failure. If it turns out work was done outside the instrumented path, that is a false assertion. Which one it is comes from the explanation, not from a guess.
Nothing is scored, inferred or compared against a baseline. Determination is the comparison of a record against a published rule; Rootwall is expressly forbidden to derive any consequence from a model, an anomaly score or a member's history. There are no false positives because there is no detection.
Because a partner programme is a gate, and a gate assesses a build.
Every published partner programme we have read approves an integration before it goes live and reassesses it on a cycle of one to three years. Some carry real conduct rules and the power to remove a partner. The furthest any of them goes is a right to inspect on demand, and a right invoked at will is not a record kept by default.
That is a published survey rather than an impression. Roughly one hundred UK and EU platforms were read on 28 August 2026. Seven publish a partner rulebook and all seven are named and quoted; every document cited is linked to an archived copy taken on the day it was read, because one of them was replaced by its author while the survey was being written.
The second difference is portability. Your programme binds your marketplace, is enforceable by you alone, and travels nowhere. An integrator working with five platforms carries five separate regimes and is observed by none of them.
No, and that is the product rather than a stance. Rootwall applies the rules identically to every member and may not vary, waive or disapply a rule for anyone. A scope class is identical for every member admitted into it. The consequence for the same breach in the same role is identical across the membership. An admission is worth something to the next company precisely because it was not negotiated with the last one.
Two things are written with you rather than handed to you: the scope class for your own interface, and the sums attached to it. Those describe operations against a specific API, so a generic version would describe nothing. Everything else is the same document for everybody.
You may always be stricter at your own interface, privately, without telling anyone. You may never be looser.
$6,000 a year if you own the API, $1,000 a year if your agents call one, plus $350 to join either side and $1,200 for each scope class assessment on the calling side. The full schedule is published, for the same reason the rulebook is.
Nothing is ever paid to Rootwall for breaking a rule. Where a sum is payable for a breach it goes to the member that was harmed. The rulebook forbids any such sum reaching Rootwall, and forbids that clause being amended.
What you sign is membership that starts on an agreed date, not software that has to arrive on one. When it starts is settled with you.
The organisation exposing the API — the one carrying the loss today, because when an agent misbehaves against it there is no accountable counterparty to send the loss to.
The rules bite where two things are true at once: you cannot switch off this class of traffic, because it is your revenue or your integration ecosystem is your moat; and you can drop any individual operator without losing the class. Compulsion is what makes governance worth buying. Fragmentation is what gives the consequence teeth.
Blocking is not the same as being covered. By the time you block, the call has already happened, the loss is already yours, and there is still nobody to send it to.
The rulebook, in force and published in full, every clause citable and stably numbered. The schedule of fees. The version history. The record schema and the reconciliation mechanism.
The scheme is new and is taking its first members — and what a founding member gets is not available afterwards. The scope class for your interface is written with you: which method kinds a caller may use, the ceilings on them, and what has to be asserted about each session. That document then becomes the published standard every other company in your sector is admitted against. Founding members are named on the register, and credited on the standard they helped write if they want to be.
Timing, commencement and what your first class would cover are settled in the first conversation.
Write to info@rootwall.ai and name the interface you have in mind. There is nothing to install, nothing to sign, and no form.
The first conversation is about whether this is your problem, and what a scope class for your interface would have to cover — which method kinds a caller may use, the ceilings on them, what has to be asserted about each session. That is the part of the rulebook that cannot be generic, and for a founding member it is written with you rather than handed to you.
If it is worth continuing: the sums that attach to that class, then a membership agreement of a few pages with a start date agreed between us.