Core Concepts

Six decisions underlie everything else. Understanding them makes the rest of the documentation feel obvious rather than arbitrary.

Where to find it

Architect Panel → Data:

• Datastores — the first concept, made concrete

Architect Panel → Security:

• Permissions — the third
• Record Access Roles — row-level access

Architect Panel → Activity:

• Activity Log — the fourth
• Audit Chain — its tamper evidence

Architect Panel → Configuration:

• Multitenancy — the fifth

1. Datastore-first

You describe your data once, and the table, forms, views, search index, API, audit trail and permission surface are derived from it.

What it buys: a change is made once and appears everywhere. What it costs: the data model matters enormously, and a poor one is felt in every layer above it. Spend the time there.

2. Declarative interface

You describe pages — what to show, in what order, gated by what — rather than building components.

What it buys: screens that stay consistent and keep up with the data model on their own. What it costs: a genuinely unusual interface is more work here than in a blank editor. Custom screens remain available for when that is the right answer.

3. Grant-only access

Permissions are granted to groups. There is no deny mechanism, because there is nothing to deny — anything not granted is already refused.

What it buys: "why can this person see this?" always has a traceable answer, and accidental over-sharing is hard. What it costs: you cannot express "everyone except" in one step; you grant to those who should have it.

4. Audit as a first-class record

Changes are logged with the row before and after, the acting identity and the origin address. Entries are hash-chained and sealed on a schedule, so alteration is detectable.

Reads are logged too, but per datastore, by choice — read volume is high, so you enable it where it matters rather than everywhere.

What it buys: you can evidence what happened, not merely assert it. What it costs: volume, and audit data that holds copies of your records and must be governed accordingly.

5. Real multi-tenancy

One installation can host many isolated tenants, each with its own data, theme, domain and administration. Isolation is either a tenant column in a shared database or a database per tenant.

What it buys: one application to operate and upgrade rather than one per customer. What it costs: the isolation mode is a decision to take before tenants exist, because changing it afterwards is a migration.

6. Deliberate schema change

Application deployments and database changes are separate, deliberate acts. Schema work is planned, applied and rolled back as its own step.

What it buys: no surprise migration during a routine release, and a schema change that is reviewed as the significant event it is. What it costs: it will not happen by itself — it is a discipline the team keeps, not a guarantee the platform enforces.

How they hang together

The first two are about building quickly. The third and fourth are about being able to answer for what the system did. The fifth is about operating it at scale, and the sixth about changing it safely.

Most platforms deliver the first two. The value of the middle pair shows up in the second year, when somebody asks a question about last March.

Worked example

A regulated organisation is asked to demonstrate that a decision recorded in March has not since been altered. Concept 1 means the record has one definition; concept 4 means the change history holds the before and after; the audit chain means the history can be shown to be intact; concept 3 means the list of people who could have altered it is short and enumerable. The answer takes an afternoon rather than a project.

Recommendations

• Invest in the data model — everything else derives from it.
• Enable read auditing on personal data, not universally.
• Fix the tenancy model before go-live.
• Treat schema change as its own reviewed step.