> ## Documentation Index
> Fetch the complete documentation index at: https://docs.capcells.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Sandbox and live

> The two kinds a Tenancy is registered as, what each one permits, and what does not cross between them.

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.

| Tenant kind | What the records are                                                       | What is permitted                                                           |
| ----------- | -------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
| `sandbox`   | Loans, Receipts and Clients that stand for nothing and are owed to nobody. | Every operation the Platform serves, including acts a live Tenancy refuses. |
| `live`      | Loans that are real money owed by real people.                             | Every operation, with one caller narrowed.                                  |

<Warning>
  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.
</Warning>

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.

```mermaid theme={null}
flowchart LR
  subgraph sandbox["Tenancy: sandbox"]
    sk["key"] --> sp["Product"] --> sl["Loan"]
    sc["Client"] --> sl
  end
  subgraph live["Tenancy: live"]
    lk["key"] --> lp["Product"] --> ll["Loan"]
    lc["Client"] --> ll
  end
```

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.

| Caller                          | On a `sandbox` Tenancy             | On a `live` Tenancy                                           |
| ------------------------------- | ---------------------------------- | ------------------------------------------------------------- |
| A person signed in              | Every operation their role permits | Every operation their role permits                            |
| An agent acting on their behalf | Every operation                    | A loan preview, a Product configuration, and a version of one |

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.