A+ Rulebooks: Airtable & Baserow
The uncontested GOLD standard for Knowledge Capture

A+ Rulebooks: Airtable & Baserow
Why Airtable and Baserow are the Gold Standard for Rulebooks in the SSoT.me Ecosystem
When it comes to managing business rules, logic, and knowledge in a unified, accessible format, Airtable and Baserow stand head and shoulders above the rest. But why are they considered the Gold Standard for Single Source of Truth (SSoT) systems? Why do they fit so perfectly into the SSoT.me (pronounced so-Tee-me) ecosystem? Let’s explore the specific features that make Airtable and Baserow indispensable tools for managing even the most complex business logic.
What Makes Airtable and Baserow So Powerful?
At their core, Airtable and Baserow are not just "fancy spreadsheets". They’re dynamic, living, breathing systems of truth that handle business logic with clarity, precision, and adaptability. These platforms let you create rulebooks that can be understood, executed, and modified without writing code, all while ensuring consistency and avoiding the dreaded "drift" that occurs in traditional requirements documents and user stories.
Here’s a look at the key features that make them the gold standard for this purpose:
1. Normalized Schema 🔧
A normalized schema is the foundation of every robust rulebook. It’s a method of organizing data into clear, non-redundant relationships where every entity exists once and only once.
-
What it means: Every "thing" in your business (like Customers, Products, or Orders) gets its own table. No duplicate data, no scattered references. Instead, you have one authoritative "Customer" table, one "Product" table, and one "Orders" table.
-
Why it matters: Changes propagate instantly. If a customer's name changes, you update it once, and that change reflects everywhere it's used. No "find and replace" or manual updates.
-
Example: Instead of writing "Premium Customer" in 20 user stories, you store "Customer Type" in a dedicated Customer table. The system knows which customers are "Premium" because that information exists only in one place.
Key Benefit: By defining relationships clearly, the normalized schema eliminates redundancy and "drift," keeping every aspect of your rulebook consistent.
2. Lookups 🔎
Lookups allow you to reference related data from other tables automatically.
-
What it means: Instead of copying and pasting information, lookups allow you to "pull in" relevant data from related tables.
-
Why it matters: With lookups, every table remains clean and focused on a single concept. For example, an "Orders" table can pull in the customer's contact info via a lookup from the "Customers" table. If the customer’s phone number changes, it’s automatically updated in the "Orders" table too.
-
Example: Suppose your "Invoices" table needs to know the "Payment Status" of an order. With a lookup, you can display the latest Payment Status from the "Payments" table in every relevant Invoice.
Key Benefit: Lookups eliminate the need for manual updates and copy-pasting. Every connected record stays in sync automatically, preventing misalignment of rules, logic, and facts.
3. Rollups 💰
Rollups allow you to aggregate or summarize related records — and this is where things get really powerful.
-
What it means: A rollup takes values from linked records and summarizes them with calculations (like sums, counts, or averages).
-
Why it matters: Rollups create "live" metrics directly within your SSoT. You can track Lifetime Customer Value or Total Open Orders for a customer in real-time — no separate dashboards or reports required.
-
Example: A "Customers" table might have a rollup field called "Total Lifetime Spend" that automatically sums up all the "Order Amounts" from the Orders table. The moment a customer places a new order, this total updates instantly.
Key Benefit: Rollups turn your rulebook into a live system. They bring in real-time metrics that can trigger rules, decisions, and automations.
4. Calculated Fields 🧐
Calculated fields let you define business rules directly within your rulebook, using formulas like "if/then" logic and arithmetic.
-
What it means: Calculated fields are like Excel formulas on steroids. You can define conditions like "If Payment Status = 'Overdue', then Risk = 'High'".
-
Why it matters: This is where rules come to life. With calculated fields, you’re not just documenting logic — you’re executing it.
-
Example: You can create a calculated field in an "Orders" table that says, "If (Delivery Date - Today) < 3, then Status = 'At Risk'". Now, every single order status updates in real-time without human intervention.
Key Benefit: Your business logic becomes a live, self-executing system, not just "text" in a requirements document. Change the logic once, and the entire system updates automatically.
Why Airtable and Baserow Are Perfect for SSoT.me
The SSoT.me (pronounced so-Tee-me) philosophy is all about freeing business logic from syntax-locked formats like requirements docs, user stories, and code. These "syntax-locked" artifacts are vulnerable to drift — every time a change is made, it must be updated in every single place it's mentioned (user stories, test cases, logic in code, etc.).
Airtable and Baserow solve this problem by centralizing the rules and logic. Instead of writing "Deliveries must be completed in 7 days" in 5 different user stories and hardcoding it into the system, you define it once in Airtable or Baserow. That’s it. No more "cascade of time" — just one change in one place.
-
Declarative, Not Procedural: Instead of defining how to calculate a deadline, you define what it is (e.g., Delivery Date = Order Date + 7 days). It’s simple, clear, and timeless.
-
Syntax-Free Knowledge: The rules aren’t buried in natural language ("Orders must be delivered in 7 days"), but instead exist as live, machine-readable logic.
-
Change Once, Propagate Everywhere: If your "7-day delivery" rule changes to a "10-day delivery" rule, you update one field. The entire system updates automatically.
Can This Handle Complex Business Logic? 🔄
Yes, it absolutely can. Complex business logic isn’t about "more lines of code" — it’s about managing relationships, calculations, and logic in a way that’s self-consistent, adaptable, and free from drift.
What kinds of logic can Airtable & Baserow handle?
-
Eligibility Criteria: Track "Premium Customers" whose lifetime spend exceeds $10,000.
-
Alert Triggers: Identify "At Risk" orders when delivery windows shrink.
-
Multi-Condition Logic: Calculate loyalty rewards points or define customer risk based on multiple factors.
With these four components (normalized schema, lookups, rollups, and calculated fields), you’re not limited to "basic rules". You’re working with complex, dynamic systems that adapt in real-time.
Final Thoughts
Airtable and Baserow aren't just "nice tools" for managing data. They are the definitive platforms for building living, timeless rulebooks. By using normalized schemas, lookups, rollups, and calculated fields, you’re not just defining rules — you’re building a system that enforces them. Changes propagate instantly, rules stay in sync, and your team’s energy shifts from firefighting to innovation.
If you’re looking for the Gold Standard of Rulebooks, look no further. Airtable, Baserow, and SSoT.me (so-Tee-me) are leading the way to a future where business rules aren’t "written" — they’re executed.
Effortless Onboarding
Here are the simple steps to get from an idea in your head, to a fully fleshed out request for proposal, RPF, that you can shop around.
BRCC Compliance Matrix
This matrix demonstrates how platforms handle BRCC compliance, focusing on knowledge graphs and readonly fields.
| BRCC Candidates | Knowledge-Graph | Readonly Fields | ||||
|---|---|---|---|---|---|---|
| Schema | Static Data | ACID Compliant | Lookups | Aggregations | Calculated | |
| Airtable | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Baserow | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| DBML + XML + CSV schema + data + calculated fields | ✔ | ✔ | X | ✔ | ✔ | ✔ |
| JSD + JSON + YAML schema + data + calculated fields | ✔ | ✔ | X | ✔ | ✔ | ✔ |
| SQL Server | ✔ | ✔ | ✔ | X | X | X |
| MySQL | ✔ | ✔ | ✔ | X | X | X |
| Postgres | ✔ | ✔ | ✔ | X | X | X |

