---
title: "Customers, consent and communications"
summary: "How LatticeKit models the people a business knows, how they are grouped into households, tiers and staff rosters, and why every outbound message is checked against recorded consent and refused when it is absent."
---

# Customers, consent and communications

## People

A **person** is a human the business knows — a customer, a member, a member of staff, a
guest on someone else's booking. One person record, whatever roles they hold: somebody who
books a court, works two shifts a week and is on a family membership is one person, not
three.

People carry contact details, [consents](#consent), and attributes the business defines
for itself. What a gym needs to record about a member is not what a salon needs, so the
attribute set is the business's to define rather than a fixed schema.

## Groups

A **group** is the universal "this person belongs to something" model. Households,
membership tiers, teams, class rosters and staff are all groups, differing by kind rather
than by having separate systems.

This is why a membership tier can gate a booking, a household can share a balance, and a
staff rota can drive who is allowed through a door — they are the same mechanism asked
different questions.

Membership in a group can be ranked, which is what makes "primary account holder" or
"lead instructor" expressible without a special case.

## Consent

Consent is recorded per person, per channel, and per purpose. Marketing email is a
different consent from a booking confirmation by SMS.

**Communications are checked against consent and refused when it is absent.** This is the
important behaviour and it is worth stating plainly: the check fails **closed**. If
consent cannot be established, the message is not sent. There is no path that sends first
and reconciles afterwards, and no way for a caller to assert consent it does not have.

The practical consequence for an integrator: a send can be refused for consent reasons,
and that refusal is a normal, expected outcome rather than a fault. Handle it — see
[errors](errors.md).

Some communications are exempt because they are not marketing and the person initiated
them: a sign-in link, a password reset, a receipt for something just bought. The exemption
is narrow and defined by the platform, not by the caller.

## Channels

Messages go out over email, SMS, push notification, webhook, or in-app, behind one
interface. A message is composed from a template the business controls, so wording,
branding and language are configuration rather than code.

Sending is subject to per-business daily caps per channel. This protects the shared sender
reputation from one runaway business; an over-cap send is recorded and refused rather than
silently dropped, so it is visible.

## Entitlement

Whether a person may do a thing — book this offer, enter this door, receive this
discount — is asked as a question rather than stored as a flag, because the answer depends
on current group membership, tier, and any conditions the business wrote. See
[expressions](expressions.md).

Asking rather than storing is what stops entitlement drifting out of date when somebody's
membership lapses.