The platform

An app is a definition. Everything else is the platform's job.

Records, fields, relationships, lifecycles and rules are declared, not coded. From that definition the platform generates the screens, the API, the validation and the reports — and applies the same guarantees to every app it carries, whether we shipped it, you extended it, or the AI builder drafted it.

Built once

Four things are built once, and every app inherits them.

One model of the organisation

One people list, one organisation chart, one legal-entity tree. Every app reads from them and writes to them. A person is one record whether they are a director, an approver, a risk owner or an expense claimant.

One way of deciding access

Role-based privileges combined with scoping from the organisation tree, evaluated by one engine that fails closed on any error. What a person is shown and what they may act on come from the same decision — there is no way to leak a count, a row or a field through a report that the screen would have hidden.

One way of governing records

Every record has a lifecycle — draft, active, closed, whatever the app declares — and every transition is attributed and dated. Nothing is hard-deleted. Sensitive records log their reads before returning data, so "who looked at this" has an answer.

One semantic model

Because the app's definition says what each field means, how it compares and who may see it, the platform can answer questions across any app without a reporting project. Dashboards are governed documents, not exports.

What every app comes with

Built in, not bolted on.

Reports, questions and dashboards

Ask a question across any app. The answer is trimmed to what the asker may see, by the same engine that trims the screens. There is no BI project and no semantic model to build.

Tasks, obligations and notifications

Recurring obligations raise tasks on schedule, lifecycle transitions notify the people who need to act, and everyone has one "my work" view across every app.

A builder, and an AI to drive it

Extend our apps or create your own, by hand or by describing what you need. Changes are drafted, reviewed and published like any other governed record. How the AI builder works →

Why it matters commercially

What one platform buys you

A new app is a decision, not a procurement

Every app is included on every plan, and so is anything you build. Adding one means switching it on or publishing it — no new contract, no new vendor review, no new line in the budget.

New apps arrive already governed

Sensitivity levels, organisation scoping, lifecycles and the audit trail apply from the first record. An app published in March passes the same security review the rest passed in January, because it is made of the same things.

Nothing to join, ever

Apps share the same people, the same organisation structure, the same legal entities — so there are no sync jobs between them, no export-and-reimport, and no quarterly reconciliation of systems that drifted apart.

Changes are governed like records

Configuration changes are drafted, reviewed and published — attributable, dated and reversible, the same way the apps treat their own data. The model that governs your records governs changes to the system itself.

Upgrades don’t cost you your changes

Your changes are kept separate from the product’s own definitions. When the product upgrades, yours are replayed on top — previewed first, not overwritten, not re-implemented.

Under the hood, briefly

What an architect will want to know

Tenancy

Every tenancy is its own database, on shared or dedicated infrastructure, in a named region. The app catalogue is compiled once per process; a tenancy is the base plus its own changes, so a thousand tenants do not mean a thousand copies of the product.

Expressions

Rules are written in CEL, a checked expression language with no side effects, validated at publish time against the official conformance suite. A rule cannot call out, loop forever or escalate privilege.

Identity

Single sign-on through your identity provider (OIDC), user provisioning through SCIM, MFA where it belongs — at the IdP. A person is one account across every app.

Verification

The access engine's central property — that the list a person is shown and the set they may act on come from one decision — is property-tested, not asserted. So is the rule that compiling the same definition twice gives byte-identical output.

Hosting, security and what is not yet certified →

For the architecture review

The questions a CIO will ask

Is this another snowflake?

No. Extension is a governed, reviewable activity a capable administrator can own — with an implementation partner when you want one. It is not a development project, and the output is a definition the platform understands, not code to maintain.

What's the lock-in?

Your data exports in open formats at any time with no exit fee, and your definitions are readable documents, not a proprietary binary. We would rather earn the renewal.

Who maintains it?

We maintain the platform and the shipped apps. Your changes are replayed on each upgrade, with a preview of anything that conflicts. Nobody has to re-implement configuration after a release.

We're working with design partners now.

A small number of organisations shaping the first release, in exchange for early access, direct influence over what ships next, and pricing that reflects the risk of going first.