Build the vertical. Skip the substrate.

The technical contract

LatticeKit's primitives are designed to be composed and extended without forking. The contract is small, consistent, and OpenAPI-3.1 backed across every endpoint.

• Multi-tenant by default. Every entity carries tenantId and optional subTenantId (locations, departments, business units). The tenant filter is uniform across primitives; sub-tenant scoping is one trait away.
• Opaque cross-primitive references. Primitives reference each other by string id, never by a database foreign key. Each primitive can scale or be deployed independently when that becomes a need.
• Schema-first contracts. One OpenAPI 3.1 spec with 197 endpoints across every primitive, generated from route introspection so it doesn't drift.
• RFC 7807 problem details. Every error is a structured, content-typed application/problem+json. Try-it works because the contract is real.
• Prefixed UUIDv7 ids. Stable, sortable, debuggable; you can tell a Booking id from a Resource id at a glance.
• Migration by connector, not by hand. Korell reads CSV / JSON / XLSX / ZIP, and for onboarding a book of customers off an incumbent we will connect directly to a read-only replica of your PostgreSQL, MySQL or SQL Server database and map your schema onto the platform's model with you — same dry run, same per-row validation, same id remap, re-runnable so the cutover is not a freeze.
• Audit event outbox. Every state change writes one event to a shared outbox. Daneel workflows, Speaker dispatch, Palver real-time, Pelorat reporting, Magnifico campaigns — all consumers, one source.

The AI-native authoring surface

Demerzel ships an operator console with an MCP tool registry over every primitive. Your customers (and AI agents acting on their behalf) can configure complex behavior — new offers, pricing rules, message templates, workflow DAGs — without your engineering team being the bottleneck.

Ellis (in build) takes that one step further: your customers author their own assistants — a definition naming the audience, the authority they run with, the tools they may call, the persona and the surfaces — and an assistant can never exceed the person talking to it. Their tools are platform capabilities plus the business's own workflows, exposed by name with a declared input schema. Assistants travel in the tenant bundle, so one you define for customer one applies to customer two.

Daneel's DAG engine is the platform for "when X, do Y, then Z" across every primitive. branch, switch, parallel, sleep, wait-for-event, wait-for-signal, loop, CEL triggers, three execution backends (sync, sqs, temporal). Your tenants compose their own workflows; you don't ship a release for every business-rule change.

What you keep

LatticeKit gives you the substrate. You keep:

• Your vertical knowledge — the regulations, the jargon, the workflows, the integrations your customers actually need.
• Your tenant-facing UX — LatticeKit's Demerzel is the operator console; your product is the customer-facing surface on top.
• Your data model on top — primitives let you reference them by opaque id, so your vertical-specific entities live alongside.
• Your margins — LatticeKit's value is the platform layer, not the per-transaction take rate.

The plain-language version of this page, for whoever decides: For software companies → · Starting a SaaS →

Where to start as a developer

Open the Foundation API reference — 197 live endpoints with try-it. Walk through the seven-call getting-started flow to feel the contract. Then read Seldon, Terminus, and Daneel — the three primitives that define the cross-primitive contract pattern; the rest follow the same shape.