Back to blog
Framework Apr 11, 2026 9 min read

Inside the DEX Runtime: How JSON Descriptors Become Production Interfaces

From 600 lines of React to 40 lines of JSON

A vendor onboarding screen we migrated last month has 37 fields, four conditional sections, three approval paths, and a drill-through to a contract detail view. The original Oracle Forms version was roughly 2,400 lines of PL/SQL and form logic. A hand-written React port came in at 610 lines across six files. The DEX descriptor is 43 lines of JSON.

The descriptor isn’t shorter because we cut features. It’s shorter because the runtime carries everything that doesn’t change between screens.

What the runtime actually does

The runtime is the boring 90%. Authentication against the enterprise IdP. RBAC enforcement on every field and action. Audit logging in a format SOX auditors already know how to read. Form validation with the same error messages on the client and the server. Localization. Keyboard navigation. Optimistic updates with rollback. Export to Excel. Print layouts. Accessibility down to the focus ring.

None of that belongs in a descriptor. Putting it there would turn every screen into a liability. The runtime handles it once, in TypeScript, in code we own and test.

The descriptor schema

A descriptor has five top-level sections: data, layout, logic, integrations, and access. Each one is validated against a JSON Schema before anything renders. The validator runs in the browser, in the build pipeline, and in the LLM’s tool-use loop, so malformed descriptors fail in the same place every time.

The data section names entities and fields from the semantic layer. The layout section describes regions, not pixels. The logic section declares rules — “approval required when amount exceeds threshold” — rather than imperative code. Integrations reference named endpoints from an OpenAPI document. Access references roles from the RBAC system.

Nothing in the descriptor is a free-form string that the runtime has to interpret heuristically. Every reference resolves to something the runtime already knows about.

Why we didn’t build a visual editor first

The obvious product for this architecture is a drag-and-drop builder. We deliberately built the runtime and the descriptor schema first, with a plain text editor as the only authoring surface, and then added AI generation before we added a visual editor.

The reason is boring. A visual editor constrains what you can express to what the editor can draw. A schema constrains what you can express to what the runtime can execute. The second constraint is the one that matters for production systems. Once the schema is right, the visual editor is straightforward. If the schema is wrong, the visual editor papers over the problem until a customer hits an edge case the editor never showed them.

Extension points

Every enterprise screen has at least one thing the descriptor can’t express. A custom calculation. A legacy SOAP endpoint nobody wants to touch. A regulatory-specific widget. The runtime handles these through named extension points — TypeScript modules that the descriptor references by name.

This keeps the descriptor declarative while leaving escape hatches for reality. We’ve found that roughly 5% of screens need an extension, and the ones that do usually need exactly one. The other 95% stay pure JSON.

What this costs us

Every architectural choice has a bill. Ours is the runtime itself. It’s a non-trivial piece of TypeScript that has to be maintained, tested, and versioned carefully, because every screen in production depends on it. A bug in the RBAC enforcement layer is a bug in every screen at once.

We treat the runtime the way a database vendor treats a query planner. Conservative releases. Extensive regression suites. Backward compatibility on the descriptor schema measured in years, not sprints. That’s the price of making the descriptors cheap.

The takeaway

JSON descriptors aren’t a trick. They’re a division of labor. The runtime owns the parts that have to be right every time. The descriptor owns the parts that change per screen. The LLM writes the descriptor. The auditor reads the descriptor. The user sees a production interface that behaves like enterprise software because enterprise software is what the runtime was built to render.