Nexo

Nexo lets an application expose its own concepts through a typed scripting language, so people can express rules and produce structured results in those terms.

The application declares what scripts may use: its records, their properties and the operations it implements. Nexo checks each script against those declarations before it runs, and evaluates it into plain, immutable data.

An example

A billing application keeps customers and their invoices. It gives each script one customer, with a name, a credit limit and invoices. It declares what scripts can read: a customer's invoices, an invoice's amount, whether it is paid, and daysOverdue, which the application computes from the invoice's due date and the date it gives the evaluation.

This script summarizes what a customer owes, charging a 5% late fee on any invoice more than 30 days overdue:

import Billing

let outstanding = customer.invoices.where(not it.paid)
let lateFee = invoice => if invoice.daysOverdue > 30 then invoice.amount * 0.05 else 0 end
let owed = outstanding.sum(it.amount + lateFee(it))

return {
    account = customer.name,
    amountDue = owed,
    status = if owed > customer.creditLimit then "on hold" else "in good standing" end,
    overdue = outstanding.where(it.daysOverdue > 0) {
        number = it.number,
        daysOverdue = it.daysOverdue,
        fee = lateFee(it)
    },
    summary = $"{outstanding.count} of {customer.invoices.count} invoices outstanding"
}

The application evaluates the script on November 1, 2026. Northwind Traders then has four invoices: one paid, one 42 days overdue, one 7 days overdue and one not yet due. Its credit limit is 1,000. The script gives:

{
    "account": "Northwind Traders",
    "amountDue": 1015,
    "status": "on hold",
    "overdue": [
        { "number": "INV-102", "daysOverdue": 42, "fee": 15 },
        { "number": "INV-103", "daysOverdue": 7, "fee": 0 }
    ],
    "summary": "3 of 4 invoices outstanding"
}

What the example shows:

• The application's terms. customer.invoices and invoice.daysOverdue are the billing application's concepts. daysOverdue runs the application's own code, and the script reads it as it reads any property.
• A rule stated once. lateFee is written once, and both the amount due and each overdue line apply it.
• One readable place. Filtering, the total, the credit check and the shape of the result are in one script, rather than spread through application code.
• Plain data out. The result has the shape the script writes, ready to send, store or compare.

Why Nexo

Applications often need to let people express calculations, rules and structured results in the application's own terms. Nexo makes that a contract between the application and its scripts:

• the application declares the vocabulary, and Nexo checks each script against it before anything runs;
• evaluation computes and shapes data, and produces it immutable;
• a change a script asks for is a request the application carries out, never a side effect of reading;
• the application sees what scripts use, from their declarations before they run and from hooks as they evaluate.

The billing example shows each part:

Strength	Why it matters
The application's own vocabulary	The script works with customer.invoices and daysOverdue, the billing application's concepts, not a generic data model. daysOverdue is an operation the application implements.
Checked before it runs	Writing it.amout in the total is refused before anything runs: "'amout' is no member of the vocabulary", at line 5, column 28. Leaving out import Billing, or comparing customer.name with a number, is refused the same way, with its location.
Expressions, collections and structured output	One script filters the invoices, totals them, checks the credit limit, writes the summary's text and shapes the result.
Functions and composition	lateFee is written once, and both the total and each overdue line apply it, so the fee changes in one place.
An explicit host boundary	The script reads only the customer the application binds, as a frozen copy, through members Billing and Nexo declare. daysOverdue runs the application's code, and nothing the script does changes the application's data.
Definitions as data, with canonical text	nexo.parse gives the script as a JSON definition to store or inspect, and nexo.format gives the text above back from it, so a definition a tool generates reads as a script written by hand.
Reads reported as it evaluates	Hooks the application gives an evaluation are told of each member it invokes, daysOverdue among them, so the application knows what the summary read. Each member also declares how it changes: daysOverdue is unobserved, since nothing signals that a day has passed, so when to evaluate again is the application's choice.

Why a language of its own. Nexo began as DOMQL's query language. As it grew, it became a project of its own, so it could take its own direction and evolve on its own. DOMQL now declares the DOM to it as a module, as any application declares its vocabulary.

An application could embed a general-purpose scripting language instead. It would then have to build the restrictions, the checking and the integration itself. Nexo is designed so they hold together, in the language and in its runtime. That is a deliberate choice, and maintaining a language is its cost.

When plain code is simpler. If the application's own developers write the logic, and nothing has to be checked against a vocabulary, kept as data or supervised, code in the application needs no language.

Install

From npm, as ES modules with their TypeScript declarations, which a module imports as import { nexo } from '@formaui-net/nexo':

npm install @formaui-net/nexo@preview

From NuGet, as one bundle, which a .NET web application serves at _content/nexo/nexo.js:

dotnet add package formaui-net.Nexo --prerelease

Until 1.0, npm's latest tag holds a deprecated placeholder, so install @preview, as above.

Run it

The application declares its vocabulary as a module, binds its data and evaluates the script. script holds the script's text above:

import { nexo } from '@formaui-net/nexo';

const { createPropertyDeclaration: property } = nexo.declarations;
const DAY = 24 * 60 * 60 * 1000;

const billing = nexo.createModule('Billing', {
    types: [
        {
            name: 'Customer',
            kind: 'structured',
            members: [property('name', 'String'), property('creditLimit', 'Number'), property('invoices', 'List<Invoice>')],
        },
        {
            name: 'Invoice',
            kind: 'structured',
            members: [
                property('number', 'String'),
                property('amount', 'Number'),
                property('paid', 'Boolean'),
                property('dueDate', 'String'),
                // The application's code, reading the date it gives the evaluation. Nothing signals
                // that the date has moved on, so the property is unobserved.
                property('daysOverdue', 'Number', {
                    updates: { changes: 'unobserved', reads: 'fresh' },
                    impl: ({ receiver, env }) => Math.max(0, Math.round((env.today - Date.parse(receiver.dueDate)) / DAY)),
                }),
            ],
        },
    ],
});

const customer = {
    name: 'Northwind Traders',
    creditLimit: 1000,
    invoices: [
        { number: 'INV-101', amount: 450, paid: true, dueDate: '2026-09-15' },
        { number: 'INV-102', amount: 300, paid: false, dueDate: '2026-09-20' },
        { number: 'INV-103', amount: 520, paid: false, dueDate: '2026-10-25' },
        { number: 'INV-104', amount: 180, paid: false, dueDate: '2026-11-20' },
    ],
};

const registry = nexo.createRegistry([billing]);
const bindings = registry.createBindings({ customer }, { types: { customer: 'Billing.Customer' } });

// Resolving checks the script against the vocabulary, before anything runs.
const resolution = registry.resolve(script, bindings);

resolution.type; // '{ account: String, amountDue: Number, status: String, overdue: List<{ number: String, daysOverdue: Number, fee: Number }>, summary: String }'

const summary = resolution.createEvaluator(bindings, { today: Date.parse('2026-11-01') }).evaluate().value;

summary is the result shown above, on any day, since the date comes from the evaluation and not the clock. A resolution serves any bindings of the same types, so the script is resolved once and evaluated for each customer. Embedding Nexo goes on to functions a module declares, calls the application carries out, and following what an evaluation reads.

Availability

Preview. Until the first release candidate, a decision may be replaced where a host's experience, correctness or a measured cost justifies it, and a version that breaks what the one before it allowed says how to migrate; from 1.0.0-rc.1 on, nothing breaks before 2.0. Both packages are published as previews, as Install shows. The implementation, 1.0.0-preview.2, implements language version 1.0.0-preview.1. The status overview says what is implemented, what remains, and what 1.0 requires.

Documents

Document	What it holds
Guide	Embedding Nexo in an application, by example
Specification	The contract, in two parts: the language, what a script means, and the runtime, what an application provides to run it
Language history	Each language version and what it changed
Changelog	Each release of the packages and what it changed
Status	What is implemented, and what remains
Design	How Nexo is built: its stages, modules, evaluation and tooling
Contributing	Report a bug, develop a change and run the checks

Build

./build.ps1

The gate runs the tests, bundles Nexo, builds the NuGet package project with no warnings and checks its formatting. The full gate, ./build.ps1 -Full, runs it, then packs the npm package @formaui-net/nexo and the NuGet package formaui-net.Nexo into artifacts/, and verifies each as a consumer installs it.

License

Apache License 2.0; see LICENSE and NOTICE.