Canonical

Data Platform

Schema-driven · Enterprise-ready

Define the schema once. Everything else is derived.

Define a schema once and derive persistence, validation, admin UI, REST, OpenAPI 3.2, GraphQL, permissions and events from the same canonical definition.

Explore the platformDeveloper portalSee use casesOpen the schema registry

For developers

Start with the portal: architecture, step-by-step guides and copy-paste REST, GraphQL, webhook and SDK examples.

Open the developer portal →

  • Architecture

    Registry, compiler, delivery layer, tenancy and the account hierarchy that scopes every contract.

  • Knowledge base

    Guides for modelling, publishing, localisation, permissions and release promotion.

  • API cookbook

    Runnable REST, JSON:API, GraphQL, webhook, SDK and MCP examples with tokens and scopes.

Live reference contract

The documents below are generated from this site's own shared reference registry — the models behind the blog and use cases. They are not, and never contain, another tenant's schema: a request scoped with an API token or the x-account header returns only that account's models. Your own endpoints, tokens and event streams are listed in the Interface Explorer.

Reference OpenAPI 3.2Reference GraphQL SDLReference schema registry

Persistence

Compiled DDL creates real, typed Postgres tables with system columns, indexes and join tables.

Validation

Server-authoritative coercion and rules — required, unique, ranges, regex, components.

Admin UI

Lists, filters and forms generated per model. No handwritten screens.

REST API

One query language: filter, sort, fields, include, cursor pagination.

OpenAPI 3.2

A live document regenerated on every schema publication.

GraphQL

SDL and executable resolvers built from the same registry.

Permissions

Role-based access down to individual field reads and writes.

Events & audit

Append-only audit trail plus a domain-event outbox for webhooks.

A single canonical definition

Schemas are versioned. Publishing previews the diff, reports destructive changes, then compiles migrations and regenerates every downstream contract.

{
  "key": "alarm_definition",
  "kind": "collection",
  "localized": true,
  "fields": [
    { "name": "code", "kind": "text", "required": true, "unique": true },
    { "name": "severity", "kind": "enumeration",
      "validation": { "enumValues": ["info", "warning", "critical"] } },
    { "name": "category", "kind": "relation",
      "relation": { "target": "alarm_category", "cardinality": "manyToOne" } },
    { "name": "seo", "kind": "component", "component": { "target": "seo_meta" } }
  ]
}

From the blog

These posts are stored as article entries and rendered through the platform delivery layer — the site is its own reference implementation.

All articles →

Read next

Where to start

Three short reads that explain the model-once approach end to end.