Intent, serialized.
A system, derived.
DIS compiles a declarative specification into a complete, working application — the backend, data model, API, and interface all derived from a single source, then validated against their own construction.
meta:
version: "2.0"
domain: "clinic"
topology database:
kind: "postgresql"
port: 5432
entity Appointment:
field id: u64 @primary_key @auto_increment
field doctor_id: u64 @required
field scheduled_at: timestamp @required
field reason: string @max_length: 512
contract AppointmentFutureTime:
scope: "CreateAppointment"
invariant: "req.scheduled_at >= now"
enforcement: "pre_condition"
on_violation: "abort"
message: "Appointments must be scheduled in the future"
operation CreateAppointment:
input: "doctor_id:u64, scheduled_at:timestamp, reason:string"
output: "Appointment"
create: "Appointment doctor_id=req.doctor_id, scheduled_at=req.scheduled_at, reason=req.reason"
operation CompleteAppointment:
input: "id:u64"
output: "Appointment"
bindings: "appointment:Appointment@id"
guard: "appointment.status == 'scheduled'"
mutate: "appointment.status = 'completed'"→ Parsing ADL ................... ✓ (28ms) → Validating entities ........... ✓ (12ms) → Checking invariants ........... ✓ (8ms) → Emitting Rust/Axum ............ ✓ (2.1s) → Emitting PostgreSQL schema ..... ✓ (340ms) → Emitting React frontend ........ ✓ (1.8s) → Emitting tests (24) ............ ✓ (920ms) → Emitting Docker + K8s .......... ✓ (210ms) ✓ 162 files generated
Define it once.
Emit a coherent system.
DIS derives backend, schema, API, and interface from a single specification. Because each layer is generated from the same source, the pieces cannot drift out of agreement.
A declarative source of truth
The application's structure and rules are expressed once, in a readable specification. DIS treats that specification as canonical and derives every layer from it.
Authority carried in the spec
Access and policy are declared up front and compiled into the generated system — enforced as part of the build, not bolted on after the fact or lost in documentation.
Consistency by construction
Schema, API, and interface descend from one source, so they stay in agreement by design. A change to the model propagates across every emitted surface at once.
A deployable, coherent system
The result is a runnable application — server, data model, API contracts, tests, and deployment scaffolding — produced as real files, not a mockup.
entity Appointment:
field id: u64 @primary_key @auto_increment
field doctor_id: u64 @required
field scheduled_at: timestamp @required
field reason: string @max_length: 512
entity Doctor:
field id: u64 @primary_key @auto_increment
field name: string @required
field specialty: string @required
relation doctor:
from Appointment.doctor_id → Doctor.id
operation CreateAppointment:
input: "doctor_id:u64, scheduled_at:timestamp, reason:string"
output: "Appointment"
create: "Appointment doctor_id=req.doctor_id, scheduled_at=req.scheduled_at, reason=req.reason"#[derive(Serialize, Deserialize, Clone)]
pub struct Appointment {
pub id: u64,
pub doctor_id: u64,
pub scheduled_at: DateTime<Utc>,
pub reason: String,
}
pub async fn create_appointment(
State(pool): State<PgPool>,
Json(req): Json<CreateAppointment>,
) -> Result<Json<Appointment>, AppError> {
// contract enforced: req.scheduled_at >= now
let row = sqlx::query_as!(
Appointment,
"INSERT INTO appointments (doctor_id, scheduled_at, reason)
VALUES ($1, $2, $3) RETURNING *",
req.doctor_id, req.scheduled_at, req.reason
).fetch_one(&pool).await?;
Ok(Json(row))
}One description, every layer. The same input produces a working server, database, API docs, tests, and deployment setup — so the pieces stay in step without manual syncing.
From specification to running system.
DIS parses the specification, derives the structure to build, validates its rules, emits every layer, and confirms the result is sound before delivery.
Specify the system.
DIS constructs it.
DIS transforms a specification into a working, self-validated system. Every capability below reflects the compiler's actual behavior today; what is not yet wired is stated as coming soon rather than implied.
A specification that becomes an application
DIS consumes a declarative specification and compiles it into the backend, data model, API, and interface. A verified run on disk substantiates it: a 1,418-line spec yielded a full generated codebase.
- ✓ Backend, schema, API, and UI from a single source
- ✓ Real, generated code — not a mockup
- ✓ One canonical specification to maintain
Verified output, attested on disk
DIS validates its output as it generates and rejects anything invalid. Every compiled run is hashed into a signed Merkle ledger — see the live root on the evidence page.
- ✓ Faults surfaced at generation time
- ✓ Invalid output rejected, never shipped
- ✓ Download → hash → compare against the ledger
Regeneration keeps your manual work
Hand-tune generated code, change the spec, regenerate — your manual edits come back. Marked regions are re-injected; whole files under custom/ are preserved. DIS is the generator you can iterate with, not just one-shot.
- ✓ BEGIN/END MANUAL regions re-injected on every build
- ✓ custom/ overlay files win over generated output
- ✓ Regenerate freely without losing agent work
Attestable releases — live
Every compiled run is hashed into a SHA-256 Merkle ledger signed by the control plane. Verify any artifact byte-for-byte — the live root and per-file hashes are on the evidence page.
- ✓ Each build carries a verifiable hash
- ✓ Download → hash → compare
- ✓ Live merkle root on /evidence
Your coding agent,
upgraded to a whole-application builder.
Hook DIS into the harness you already use. Your agent goes from writing files to shipping complete applications — and keeps its work when things regenerate.
Tell your agent what to build
You describe the app in plain language — entities, workflows, rules. Your agent turns that into a short, readable DIS specification. No boilerplate, no scaffolding by hand.
Your agent compiles the whole thing
One command — or one MCP tool call — and DIS writes the full codebase: server, database schema, API, frontend, tests, and deploy setup. Real files, ready to run.
Run it, break it, fix the spec
You and your agent run the app, hit a bug, and fix it where it belongs — in the specification. Recompile, and every layer updates together. No hunting through five codebases for the same change.
Your hand-written work survives
If your agent hand-tunes something DIS generated, that work is kept when the project regenerates. DIS never wipes manual edits — it re-applies them on top of the fresh build.
Regenerate the whole project.
Keep every manual edit.
This is what makes DIS usable by real agents. Most generators are a one-way door: hand-tune the output and you can never regenerate. DIS breaks that loop. Your agent can change the spec, regenerate the entire application, and all the code it wrote by hand — the custom logic, the careful fixes, the bespoke pieces — comes back intact.
// BEGIN MANUAL: custom_helpers
pub fn my_custom_rule(x: i64) -> i64 { x * 2 }
// END MANUAL: custom_helpers
// regenerated code below stays in sync with the specAnything inside BEGIN/END MANUAL markers is snapshotted before regeneration and re-injected after. The rest of the file updates to match the new spec.
your-app/
custom/
dashboard.tsx ← hand-written, never touched
auth_helpers.ts ← hand-written, never touched
backend/ ← regenerated fresh each time
frontend/ ← regenerated fresh each timeFiles under custom/ are copied over the generated tree after every build. Keep whole hand-written files here; they win over generated output, every time.
Verified on a real regeneration. A 363-line clinic specification was regenerated with a hand-written region and a custom overlay in place — both survived, the regenerated files changed, and the rebuilt app compiled.
Sample projects, compiled end to end.
Every number below is from an actual DIS run — generated, built, and verified end to end. Backend: cargo build. Frontend: tsc. "Build" shows warnings / errors.
| Project | Spec lines | Files | Lines | Build |
|---|---|---|---|---|
| Control plane exemplar (largest) | 1,418 | 234 | 12,331 | 0 / 0 |
| SaaS exemplar | 504 | 206 | 11,279 | 0 / 0 |
| Clinic exemplar | 363 | 160 | 8,116 | 0 / 0 |
| Inventory exemplar | 336 | 164 | 7,820 | 0 / 0 |
Capabilities verified on the running system.
Everything here was tested against the live endpoint — not mocked, not planned, running now.
One-click connect
Paste one URL into your AI app and approve in the browser. OAuth 2.0 with PKCE and dynamic client registration handles the rest — no key copying, no config files. Verified live end to end.
Memory that persists
The platform remembers across sessions. Recall relevant patterns before you build and report outcomes after — a stored marker returns verbatim on a later recall. Verified against the running system.
Fair, enforced limits
Every tier has a real quota and rate limit, enforced per key on the live endpoint — trial, developer, team, and beyond. What you are told is what is enforced.
From specification to deployed system,
without the friction.
The end-to-end journey DIS performs: author a specification, derive a coherent system, validate it, and deliver something runnable. Anything not yet wired is flagged as coming soon.
Author the specification
The system's structure, data, and rules are captured in a declarative specification — human-readable, yet precise enough for a compiler to derive an application from.
DIS derives the application
From the specification, DIS generates the backend, data model, API, and interface as real files on disk — a coherent system, not a mockup.
It validates its own output
Before treating the output as complete, DIS verifies it is sound and reports precisely when it is not. This self-verification is being strengthened with each compiler release.
You receive a runnable system
The deliverable is deployable software — a working server, data model, API contracts, and deployment setup — an integrated whole rather than hand-assembled fragments.
Every release attested — coming soon
Carrying a permanent, verifiable record on each release — one you can confirm and roll back — is the next milestone. It is not yet active, so it is marked coming soon rather than claimed.
Ready to see it in action?
Explore the evidence of every compilation. Or jump straight into the API portal and start building.