---
title: "Tenancy and scope"
summary: "How LatticeKit isolates one business from another, how locations and business units narrow that further, and what a caller needs to know about which scope its credentials carry."
---

# Tenancy and scope

Every piece of data in LatticeKit belongs to exactly one **tenant** — one business.
Nothing crosses between tenants. This is the platform's strongest guarantee and the one
that everything else assumes.

## Where the tenant comes from

A caller never states which tenant it is acting for as an ordinary parameter. The tenant
is carried by the credential — a verified token claim, or the grant an API key or
connected agent resolves to. It cannot be overridden by a header or a request body. (A
location *within* a business — where a business has several — follows the same rule for
connected agents; how a first-party console session selects its location is described
with the console.)

This matters if you are integrating: **there is no "act on behalf of tenant X"
parameter.** A credential is scoped to one business, and getting a second business means
getting a second credential.

## Sub-tenants: locations and business units

A business with more than one location can model each as a **sub-tenant**. A record
either belongs to one sub-tenant, or is tenant-wide.

The distinction is made per kind of record, not per row, so it stays consistent:

- **Location-private** — a schedule, a booking, a resource. These belong to the place
  they happen, and a location does not see another's.
- **Tenant-shareable** — a product, a customer, a price list. These normally belong to
  the business as a whole.

A business also picks how strictly this applies. A **lenient** posture lets tenant-wide
records be seen from inside a location, which is usually what people expect. A
**strict** posture does not, and is the stronger isolation — it is deliberate, not a
default.

## What a caller sees

If your credential carries a sub-tenant scope, reads are filtered to it and writes are
checked against it. You will not see other locations' data, and an attempt to write
outside your scope is refused rather than silently redirected.

If your credential has no sub-tenant scope, you see the business as a whole.

This is enforced centrally rather than screen by screen, so it behaves identically
whether the caller is a person in a console, an automated workflow, or a connected AI
agent. For a connected agent there is no path with weaker rules.

## Practical consequences

**A record's scope is set when it is created** and is not casually changed afterwards.
Deciding scope before a second location opens is much cheaper than deciding it after.

**Reports and realtime feeds are keyed by tenant and sub-tenant together**, so
per-location figures are the default rather than something to filter for.

**Cross-tenant queries do not exist.** If you need to compare two businesses you operate,
you query each and combine the results yourself.