Data model at a glance
Not a full list of tables, but the conceptual structure: which entities exist and how they
relate. The schema has 162 tables in the public schema, and row-level security is enabled on every one of them.
The layers
Tenant layer. A tenant is an organisation or advisory firm with its own shielded environment, its own branding and its own configuration. A user is a member of one or more tenants, with a role per tenant; anyone who works on a canvas has a role on it (owner, editor or reader), even without being a member of the tenant. Invitations to an organisation and to a single canvas have a table each; membership only comes into being when the invitee accepts the invitation. Every change in membership and participation is recorded as an event.
Canvas. The central unit of work: one assignment, one client. Everything you fill in is attached to a canvas, which in turn is attached to a tenant. This includes the uploaded documents and the text blocks derived from them, with their meaning representation. A document has versions; for each part that rests on an earlier version, what changed between the versions is recorded.
Worksheet data. Each domain (customers, processes, people, IT, change, strategy) has its own set of tables. The domains differ fundamentally, and a design of its own per domain makes every worksheet stronger. Strategy contains, besides the core and the themes, the measurement of digital maturity; the IT worksheet places information domains in five layers; and the worksheets come with event tables that record, per proposal, theme and improvement action, what changed, when and by whom. They all follow the same authorisation pattern.
Capability layer. Capabilities, their clustering, and the gaps between current and desired level. Evidence is attached to a gap (references to existing pain-point tables from the worksheets), along with coverage in the form of initiatives.
Reporting layer. A report definition contains sections, and a section contains blocks. A text block carries both the generated and the edited version, plus the source references. Every export is kept as a snapshot.
Supporting. Background tasks with status and progress; usage logging per AI call; a central configuration table for labels and prompts; the AI model catalogue with prices and settings per AI button; and the messages of "What's new", per release in Dutch and English.
Two design principles
Reuse existing structures instead of duplicating them. The evidence link of the capability layer points to the pain-point tables that the worksheets already fill. This gives one truth about what is going wrong in the organisation.
Extend additively only. Both the capability layer and the reporting engine are designed so that they do not change existing tables, only add to them. The worksheets remain the source of truth; reporting reads from them and never writes back. This keeps later changes cheap and the risk of regressions low.
One base for the schema
The schema is captured as a single base file of 47,108 lines, made from production, followed by the migrations that come after it (on 30 October 2026: the base plus 26). An empty database can be built from it in one step, with the privileges of every table and function written out. The 818 migrations from before the base are kept as an archive. A new table that is not tied to a canvas or user is classified in a register as platform configuration, customer data or environment data, and a check asks for it.
Configuration over code
Labels, prompts and methodology terminology live in the database, not in the code, with a default value and an optional variant per tenant. This lets an organisation use its own language and its own framework without a single line of code changing.