---
title: "Expressions"
summary: "Conditions in LatticeKit — who qualifies for a discount, which bookings a rule covers, when a workflow branches — are written in a small expression language, validated when saved and evaluated fail-safe at runtime."
---

# Expressions

Several things in LatticeKit are conditions rather than settings: which customers an
audience includes, whether a discount applies to a cart, which bookings an access rule
covers, whether a workflow takes one branch or another.

These are written as expressions in a small, safe subset of a standard expression
language. It has comparison and boolean operators, arithmetic, string and list
operations, membership tests, and field access on the record being evaluated. It has no
loops, no function definitions, no I/O, and no way to reach anything outside the value it
was handed.

## Validated when written, not when run

An expression is parsed and checked at the moment it is saved. A malformed one is
rejected there — in front of the person writing it — rather than throwing at two in the
morning inside a batch job.

This is the main reason conditions are a language rather than an accreted pile of
special-case flags. Configuration that can express logic eventually needs to; the only
question is whether that logic is checkable.

## Fail-safe at runtime

If an expression somehow still errors when evaluated — because the record it was handed
lacks a field it expected, say — the result is treated as **false**, not true.

That means a broken rule denies rather than grants: a discount does not apply, an
audience does not include, an access rule does not admit. Failing open would turn a typo
into free entry.

## What an expression can see

Each place an expression is used hands it a defined set of fields, and it can see nothing
else. An audience expression sees customer attributes; a cart discount expression sees
the cart; an access rule sees the booking and the person. The available fields are part
of the contract for that feature, and referring to a field that is not offered is a
validation error at save time.

## Practical notes

**Keep them short.** An expression that needs a comment is usually two rules.

**They are evaluated frequently.** An audience expression may run against every customer;
an availability rule against every slot. They are cheap by design, but complexity is
still multiplied.

**The same expression means the same thing everywhere.** The language is implemented
identically on the server and in the browser-side renderer that previews tenant-facing
pages, so a rule that previews one way does not behave another way in production.