A governed pipeline from requirement to production
You describe the system you need. A local AI proposes it as schema-validated configuration — never code. Every change is validated, dry-run, and approved by a human before it applies, and every mutation lands in an append-only audit log.
Eight gates between a request and your production system
Every structural change — whether proposed by the AI, submitted through the MCP endpoint, or made manually in Studio — passes through the same gated loop. There are no exceptions and no shortcuts; the gates are the product.
Constrain
The agent inspects system state, decomposes the request into ordered tasks, and emits schema-validated artifacts — declarative configuration only, never executable code.
Validate: Schema
Every artifact must pass Zod schema validation. Malformed output cannot proceed — the exact validation error is fed back to the agent.
Validate: Rules
Business-rule validation checks referential integrity and platform invariants. Failures retry at most three times, then escalate to a human.
Dry-Run
A migration dry-run produces the exact database plan and quantifies affected data. Nothing is mutated at this stage.
Human Approval
A named approver reviews the changeset with every mutation enumerated. Destructive items require individual confirmation with the data at risk named.
Transactional Apply
Plans apply in dependency order, each in its own transaction. A failure halts the changeset — no partial-item corruption.
Audit
Every mutation is written to the append-only audit log and migration ledger: full diff, actor type, approver, and rollback DDL.
Resume
Build sessions are checkpointed. A server restart or interruption resumes the session exactly where it stopped — no lost work, no repeated approvals.
One changeset, every mutation enumerated
A request like “Build me a CRM” decomposes into an ordered task list — collections, relations, roles, pages, workflows. The resulting artifacts group into a single changeset for one auditable approval, and the review is explicit by design:
- Every mutation enumerated: each change is listed with its dry-run result — nothing is hidden behind a summary.
- Destructive items individually confirmed: anything that can lose data — dropping a field, narrowing an enum — names the specific data at risk and requires its own confirmation; there is no “confirm all” shortcut.
- Editable before approval: filter by task, inspect diffs and database plans, and remove items from the changeset before approving.
- Attributable: the approval is recorded against a named approver in the audit log, alongside the full diff.
✦ Changeset: 14 changes
12 safe · 2 destructive
// Task Rail
1 ✓ Collections (5)
2 ✓ Relations (3)
3 ✓ Roles (2)
4 ✓ Pages (3)
5 ✓ Workflows (1)
// Changes
▸ + collection customers (6f) ✓ safe
▸ + collection deals (8f) ✓ safe
▸ ~ narrow enum deal.stage
⚠ destructive: 3 rows in 'on_hold' would be invalidated
[ confirm this item ]
▸ + page /deals (kanban) ✓ safe
...
[ Approve & apply 14 changes ]
approver: recorded in audit_log
"Build me a CRM" — end to end
Follow a build request from natural-language requirement to production application, gate by gate.
Step 1: You state the requirement
You open the AI build dock in Studio and type: “Build me a CRM with customers, deals, a pipeline kanban, and email notifications when deals change stage.”
The build-time agent — LangGraph orchestration over a local LLM via Ollama — inspects current system state and, where a build-scoped knowledge base is attached, retrieves domain context to ground its proposals. It then decomposes the request into an ordered task list.
// Build session checkpointed
✦ Agent: Decomposing request...
Task 1/5: Collections
→ emit CollectionSpec(customers)
→ Zod schema validation ✓
→ business rules ✓
→ dry-run ✓
Task 2/5: Relations
→ emit FieldSpec(deals.customer_id)
→ type: belongsTo → customers
→ Zod schema validation ✓
→ dry-run ✓
Task 3–5: Roles, Pages, Workflows
→ all validated ✓
→ all dry-run ✓
✦ Changeset ready: 14 changes
12 safe · 2 destructive (individually confirmed)
[ Approve & Apply 14 Changes → ]
Task 1: Collections
→ emit CollectionSpec(customers)
fields: name, email, phone, company
→ Zod schema validation ✓
→ business rules ✓
→ dry-run: CREATE TABLE app_x.customers...
→ safe (0 rows at risk)
//
Task 2: Relations
→ emit FieldSpec(deals.customer_id)
type: belongsTo → customers
→ Zod schema validation ✓
→ rules: customers exists? ✓
→ dry-run: ALTER TABLE app_x.deals...
→ safe
//
Task 3-5: Roles, Pages, Workflows
→ all validated, all dry-run
Step 2: The agent emits and validates each artifact
Each task emits schema-validated artifacts — declarative configuration, never executable code. Every artifact passes Zod schema validation, business-rule validation (for example, “does the target collection exist for this relation?”), and a migration dry-run that produces the exact database plan and quantifies affected data.
When validation fails, the agent receives the precise validation error and retries — at most three times. If it cannot satisfy the constraints, it escalates to a human rather than forcing the change through.
Step 3: A human reviews the changeset
All validated plans group into one changeset. You see every mutation enumerated with its dry-run result. Destructive items — such as narrowing an enum — name the specific data at risk and require individual confirmation; there is no “confirm all” shortcut.
The task rail shows planning progress. You can filter by task, view the database plans, inspect diffs, and remove items before approving. The approval itself is recorded against you in the audit log.
✦ Changeset: 14 changes
12 safe · 2 destructive
// Task Rail
1 ✓ Collections (5)
2 ✓ Relations (3)
3 ✓ Roles (2)
4 ✓ Pages (3)
5 ✓ Workflows (1)
// Changes
▸ + collection customers (6f) ✓ safe
▸ + collection deals (8f) ✓ safe
▸ + relation deals→customers ✓ safe
▸ + page /customers ✓ safe
▸ + page /deals (kanban) ✓ safe
▸ + workflow deal_stage_changed ✓ safe
...
[ Approve & apply 14 changes ]
// Applying changeset
Plan 1/14: CREATE TABLE customers
→ ✓ applied (tx committed)
→ ledger: migration #m001
→ audit: actor=ai_build, approver=u123
//
Plan 2/14: CREATE TABLE deals
→ ✓ applied
...
//
Plan 14/14: CREATE WORKFLOW
→ ✓ applied
//
✓ Changeset complete: 14/14
✦ Application in production
/customers → table + form
/deals → kanban board
workflow: deal_stage_changed → email
// Next: configure AI Employees
[ Configure Deal Analyst → ]
Step 4: Transactional apply, then a running system
Approved plans apply in dependency order, each in its own transaction. If a plan fails, the changeset halts: applied items remain (each with stored rollback DDL), and remaining items are marked skipped. There is no partial-item corruption, and no request ever sees a half-applied app.
Your CRM is now in production. Users log in under role-based permissions, work customers and deals on the kanban, and the workflow sends stage-change notifications. From here you can configure AI Employees — role-bound, data-only assistants that summarize deals, extract details, and answer questions within the same permission boundaries as their human colleagues.
AI Employees work on data — within enforced boundaries
Once an application is in production, AI Employees handle data tasks under the same three server-side authorization layers as human users. The build surface is hard-denied to them: an AI Employee can never alter application structure.
Beside Blocks
Embed an AI Employee next to a table or kanban. Users ask "summarize Q3 deals" and receive answers grounded exclusively in data their role permits them to see, with sources cited.
In Workflows
Add an AI Employee as a workflow node. It executes mid-flow — classify a support ticket, extract key data, summarize a record — and the workflow continues, with the AI action audited.
In Inbox
AI Employees receive tasks in an inbox — summarize, extract, classify — and present results with source citations, every run recorded in the audit log.
See the governed build loop on your infrastructure
Walk through the pipeline with our team, or request an evaluation license and run a governed build end to end in your own environment.
Self-hosted — your data never leaves your network · Every change human-approved and audit-logged · SSO/OIDC available · We support your security review.
The governed AI application platform. A local AI builds business systems as validated configuration, every change is human-approved, and it all runs on your infrastructure.