Glossary
This glossary defines core terms used throughout the system. The definitions focus on how the concepts behave in practice and how they connect to the rest of the documentation.
Table
A table defines a type of entity in the system. It groups rows that share the same structure.
Examples include Person, Booking, or Room.
Tables form the foundation of the data model and determine how information is organized.
→ Learn more: /documentation/data-model/tables/
Column
A column defines a single attribute within a table.
Each column has a specific type and stores one value per row.
Examples include name, start date, or status.
Columns define what kind of information can exist in the system.
→ Learn more: /documentation/data-model/columns/
Row
A row represents a single instance of a table.
For example, one person, one booking, or one room.
Rows are the primary units that rules, classifications, and relations operate on.
Rows are always identified by a unique ID.
→ Learn more: /documentation/foundations/ids-and-row-identity/
Relation
A relation connects rows between two tables.
Relations make it possible to navigate between entities and combine data across the model.
For example, a Booking may be related to a Person and a Room.
Relations enable traversal, filtering, and cross-table logic.
→ Learn more: /documentation/data-model/relations/
Data model
The data model is the complete structure of tables, columns, and relations.
It defines how information is organized and how different parts of the system connect.
All other parts of the system—rules, views, scheduling, and integrations—are built on top of the data model.
→ Learn more: /documentation/data-model/
Classification
A classification evaluates a row and returns a result, typically true or false.
Classifications are used to define logic in the system, such as filtering, permissions, and rules.
They can be based on values, logic, or relationships between rows.
→ Learn more: /documentation/classifications/
Predicate
A predicate is a condition used inside a classification.
It compares values and determines whether a condition is met.
Examples include checking if a date is before another date, or if a number is within a range.
Predicates are the building blocks of classifications.
→ Learn more: /documentation/classifications/predicates/
Read rule
A read rule controls whether a row is visible to a user.
It evaluates a classification and either allows or blocks access.
Read rules are applied dynamically when data is accessed.
→ Learn more: /documentation/permissions/read-rules/
Write rule
A write rule controls what happens when data is created or modified.
It evaluates a classification and can block the change, warn the user, or require confirmation.
Write rules ensure that data changes follow defined constraints.
→ Learn more: /documentation/permissions/write-rules/
Schedule
A schedule defines a set of time intervals generated from rules.
Schedules are used to control availability, bookings, and time-based constraints.
They are built using sequences and filters rather than fixed lists of time slots.
→ Learn more: /documentation/scheduling/
View
A view presents data in a structured way for users.
Examples include tables, calendars, and charts.
Views are derived from the data model and respect all rules and permissions.
→ Learn more: /documentation/interface/views/
API
The API provides structured access to the system’s data and behavior.
It follows the data model, meaning tables, columns, and relations define how data can be queried and modified.
The API respects the same rules and permissions as the interface.
→ Learn more: /documentation/integrations/api/
Related resources
Related concepts