---
title: "Identifiers"
summary: "Every LatticeKit id is a short type prefix followed by a time-ordered unique suffix, which makes ids self-describing, safe to log, and safe to pass between parts of the platform as opaque strings."
---

# Identifiers

Every record in LatticeKit has an id that looks like this:

```
bk3Qm8kFvR2nWxYt7pLc4Hs9
```

Two parts, with no separator between them: a short prefix naming what kind of thing it
is (two to four letters), then a unique, time-ordered suffix of 22 letters and digits.
Ids are 24 to 26 characters depending on the prefix, always strings, always
case-sensitive.

## Why the prefix is there

**An id tells you what it is.** `bk…` is a booking, `inv…` an invoice, `prsn…` a
person. A log line, a support ticket or an error message containing an id is
self-explaining — nobody has to look it up to know what they are holding.

**A wrong id fails safely.** Passing a booking id where an offer id belongs is simply
not found — the same `404` an id from another business gets — never something else
that happened to share a number. Some endpoints check the prefix at the route and
refuse a malformed id outright; either way you get a not-found, not a wrong record.

**Ids are safe to pass around.** They reveal nothing about storage, ordering, or how
many of something exist. A sequential integer tells a competitor your booking volume;
these do not.

## Why the suffix is time-ordered

The unique part is generated so that ids created later sort after ids created earlier.
That is not something to rely on for business logic — it is a database property. It
means ids written at the same time land near each other in an index instead of
scattering, which keeps large tables fast as they grow.

Do not use id ordering to determine when something happened. Records carry explicit
timestamps for that.

## Rules for callers

**Treat ids as opaque.** Do not parse them, construct them, or derive one from another.
The prefix is documented so you can recognise a type, not so you can build an id.

**Do not assume an id is a foreign key.** Many references between parts of the platform
are plain strings with no database relationship behind them — see
[tenancy](tenancy.md) and [what LatticeKit is](what-is-latticekit.md). An id that
resolves today is not guaranteed to resolve after the thing it names is deleted.

**Compare exactly.** Ids are case-sensitive. Do not trim, lowercase or normalise them,
and do not assume one length — the prefix decides it.

**Store them as strings.** They are not numbers and will not fit in an integer column.

## Prefixes you will meet often

| Prefix | What it names |
|---|---|
| `prsn` | A person — customer, member or staff |
| `bk` | A booking |
| `offr` | An offer — something bookable or purchasable |
| `avlb` | An availability — when an offer can be taken |
| `inv` | An invoice |
| `ord` | An order |
| `tn` | A tenant |

There are well over a hundred prefixes in use. The reliable way to learn one is to read
it off a record you already have, not to guess it.