Work sample · Case study

d.process
Low-code, before the word existed.

A platform where applications aren't written, they're described: a custom d.script language, a custom compiler and virtual machine, federated queries across SQL, LDAP and files. Designed and built by me between 2006–2022 at Datron a.s. In production since 2010 — still running in public administration today.

Discuss the project About me Back to homepage
100% remote · working with clients across the Czech Republic

16 years

of development and operation — from language design to production deployment

since 2010

in continuous operation in public administration — the Liberec Region Authority

a custom DSL,
compiler, VM

built from scratch, not assembled from someone else's libraries

Three layers, one truth

The d.script language

A domain language for describing forms, processes and business rules. A real grammar, not JSON configuration.

Compiler + VM

d.script compiles to bytecode and runs on its own virtual machine — the same principle I first built for the MSR-84 robot back in 1997.

Agnostic model

The application is described independently of where it will run. The target platform is chosen by the runtime — not decided by the developer up front.

Federated queries

One JOIN, three different data sources

A query in d.process doesn't distinguish where the data actually comes from. The same JOIN combines rows from a relational database, entries from a directory service, and rows from a flat file — as if they were all one table.

SQL
relational database — primary transactional data
LDAP
directory service — identities and permissions
CSV / files
flat sources — lookup tables, imports, legacy data
→ one JOIN
across all three sources at once, no ETL step in between

The contract is the truth. Everything else is a projection.

One model, many interfaces

The screen, the report and the API response are all just different views of one contract. When a rule changes, it changes in one place — and propagates everywhere on its own.

SSS — security in the model

Permissions belong in the data model, not on the screen. Server Side Security applies regardless of where the request came from — and can't be bypassed by switching clients.

"Everything must have an architecture." d.process was never about what the application looks like in month one, but about what the thousandth change costs. That's the whole difference between a system that gets maintained and one that gets worked around.

In production

Demonstrable longevity

✓ Liberec Region Authority

First d.process deployment — 2010. Public-administration process and form-based workflows built on the same runtime and the same contract model as the single source of truth, with the architectural core essentially unchanged to this day.

✓ Public administration — further workflows

Further deployments on the same runtime, with no need to recompile the architecture for every workflow change.

The same architectural philosophy is behind the ATRUST platform today.

Atra + Atrust — the successor to d.process

The same idea — the contract as the single source of truth — rebuilt for an era where an AI agent is as ordinary a consumer of a system as a web or desktop client.

More about me and my work →

Want an architecture
that survives twenty years?

Write me a few lines about your project or system. The first consultation is free of charge and takes place online.

jakub@lebeda.eu →

Ing. Jakub Lebeda · Atriplex Algorithmics · Company ID (IČO) 19074671 · +420 607 720 317 · Provodín, Czech Republic