Skip to main content
Every Tenancy is registered as one of two kinds, and the kind decides whether its records stand for real money.

​
Kinds

Two kinds are admitted, and a Tenancy is one of them for its whole life.
A Tenancy’s kind is stated once, when it is registered, and a second statement is refused. No operator command turns a sandbox Tenancy into a live one.
A key authenticates for one Tenancy. Your organization may hold a sandbox Tenancy and a live one at the Console. The path of every request names which of the two it acts on.

​
Isolation

Nothing crosses from one Tenancy to the other.
  • A key issued for one Tenancy authenticates for no other.
  • A Product configured on one is not readable on the other, and neither are its versions.
  • A Client registered on one is not registered on the other.
  • A Loan, a Receipt, and every figure derived from them belong to the Tenancy that recorded them.
  • A Reference is unique inside one Tenancy, so the same Reference is free on the other.
The two Tenancies share no key, no Product, no Client and no Loan; the diagram carries nothing the list above does not.

​
Restrictions

The kind narrows one caller at the Console and no other. An agent is a caller your identity provider signed as acting on a person’s behalf rather than as the person. On a live Tenancy every act that touches a real book is refused to one. That is issuing, servicing, accelerating, cancelling, retracting, writing off, reporting a Receipt, reversing one, and registering a Client. Minting a key is refused to an agent on both kinds. A key reaches a chat transcript and a model provider’s logs, which are places you do not control and the Platform cannot audit. The rule belongs to the Console. A key carries a scope and no actor, so the API serves a sandbox Tenancy and a live one alike.