Contact us

Assembler · Intelligence & action

Change a rule.
It’s live.

Declare the business. The engine runs it. Every action audited by construction.

Book a scoping session How it works

Your rules set the beat; every tick is one action, logged. Click the watch to stop it: no tick, no action.

Before Assembler

Click the ones you recognise. Each one shows what changes.

Tonight, somewhere in your company.
What this adds up to 0 of 6

Assembler is the part that acts.

Versioned rules and agents over the governed record, with one audit and safety pipeline across every action.

See how it works

After Assembler

The same six, once Assembler is running.

Click any card to flag or unflag that problem.

Want rules your team can change today?

Book a scoping session See how it works

How Assembler works

The application is metadata.

Nothing moves until it is let through. Each tick, one step: the record comes in, every rule is checked, then the action fires and is logged.

1 · Declare it

Entities, fields, links, rules, workflows, screens and AI, declared as JSON. A new domain needs no compiled code.

2 · The engine runs it

Tables, APIs, forms and lists are built from the model, with access enforced at the data layer.

3 · Change a rule, not a release

Versioned, overlaid per customer and upgraded without a release, with every change and action audited.

How it is built

Java 25Spring BootPostgreSQL + pgvectorApache KafkaValkeyTemporalApache CamelLangChain4jOryOpenTelemetryReactFlutter

Every layer is open source. Any Java team can extend it, with no proprietary language to learn. Runs fully inside your environment, air-gapped where required.

Open formatsNo lock-inAir-gapped
Where it runsAn operations floor watching governed workflowsPhoto slota-runs.jpg · 16:9
Operations running on the governed record.

Industries that use Assembler

And, just as clearly, what it is not.

Process changes ship the day they are decided.

Rules, workflows and AI all run from one model, and every action is logged.

Pick your industry

See every industry

Assembler · action Photo slota-what.jpg · 16:9
Governed action on the record.

What it is

  • Model-driven operations: objects, versioned rules, workflows and AI agents. Apps generate from the model, API-first for custom front-ends.
  • One audit, access-control and safety pipeline over every operation and AI call.
  • Governed AI that acts only within the rules you define.

What it is not

  • Not a low-code app builder. Keep your low-code on top via APIs.
  • Not a workflow tool on ungoverned systems. Governance is the primitive.
  • Not an AI model. It governs and orchestrates them.

Case studies

Where Assembler is used. Pick an industry, or let it run.

Industry · Commodities

We gave an agri trader live prices and tariffs

The problem

Prices, tariffs and crop data sit on portals that break the scrapers built to read them, and trading rules shift with the season.

How we solved it

Maintained feeds plus collectors running inside their own systems, with trading rules versioned over the record.

The result

Traders work from current data, and the rules move with the market.

Read the full story

What was going on

The trading desk lived on prices, tariffs and crop reports published on government and market portals. Their scrapers broke whenever a portal changed its layout, and the trading rules, which shift with the season, sat in spreadsheets only a few people could edit.

What we did

  1. Quarry replaced the fragile scrapers with maintained feeds, plus collectors running inside the trader’s own systems for the sources nobody else covers.
  2. When a portal changes, the feed is fixed on our side. The desk just keeps receiving data.
  3. In Assembler, the trading rules became versioned rules over that data. A seasonal change is a new version of a rule, not a new spreadsheet.

What changed

Traders work from current data, and the rules move with the market. When a rule changes, everyone can see which version made which call.

Quarry + Assembler

Industry · Trade

We turned five inboxes into one clearing flow for a trade house

The problem

Each party holds one piece of the picture, and the clearing record is assembled by hand from all of them.

How we solved it

Outside data brought in and joined into one record, then cleared by versioned rules with every step logged.

The result

One path through the process instead of five inboxes.

Read the full story

What was going on

Clearing a single trade meant chasing data from every party involved. Each one held a piece of the picture, and someone stitched the clearing record together by hand from five different inboxes.

What we did

  1. Quarry brought in the outside data each party publishes, in one format.
  2. Smelter joined every piece into one record of the trade, with each value keeping a note of where it came from.
  3. Assembler runs the clearing steps as versioned rules, and writes every step to a log the client owns.

What changed

One path through the process instead of five inboxes. When someone asks why a trade cleared, the answer is already in the log.

All three

Industry · Hiring

We made every interview provable for Nexaryth

The problem

Verification steps are run by hand, and afterwards there is no way to prove what happened.

How we solved it

Versioned rules and agents run the checks, with every action written to a log the client owns.

The result

A trail you can show, for every interview.

Read the full story

What was going on

Nexaryth runs verified interviews for remote hiring. Its identity and integrity checks were done by hand, and afterwards there was no reliable way to prove what had been checked, by whom, or when.

What we did

  1. Each check became a versioned rule in Assembler, with AI agents running the steps a person used to do.
  2. Every action, by a person or an agent, is written to a log Nexaryth owns.
  3. When a check changes, it becomes a new version, so past interviews still show the rules they were run under.

What changed

A trail you can show for every interview: what was checked, when, and under which version of the rules.

Assembler

Industry · Logistics

We let a freight forwarder change its process without engineers

The problem

The process changes constantly, and every change waits for an engineering slot.

How we solved it

Rules and workflows are changed in the model, not shipped as a release.

The result

The operations team changes the process the day they decide to.

Read the full story

What was going on

A freight forwarder’s process changes all the time: new carriers, new documents, new approval steps. Every change to its CRM waited in line for an engineering slot, so the operations team worked around the system instead of in it.

What we did

  1. In Assembler, the process became rules and workflows the operations team can read and change themselves.
  2. A change is a new version, switched on without a software release.
  3. If a change goes wrong, it is rolled back in one step.

What changed

The operations team changes the process the day they decide to. Engineering is free for everything else.

Assembler

See all case studies

up to 74% faster time-to-market; IT backlog cut by about half, for model-driven platforms. Category benchmark, Forrester / Gartner, 2026. Directional: your own measured results replace it per deployment.

FAQ

The basics of Assembler.

What is Assembler?

Assembler is an enterprise application platform in which the application is metadata. Your data model, access rules, business rules, workflows, screens, reports and AI agents are declared as configuration, and the Assembler engine runs them. A new business domain needs no compiled code, and a rule change goes live without a software release.

What problem does it solve?

Conventional development builds every business object by hand: a table, an API, a form, validation, a workflow and a permission model, each coded and released separately. Assembler replaces that loop with a declaration, so process changes ship the day they are decided and every action is audited by construction.

Who uses Assembler?

Process owners and administrators tailor installed applications through the design studio. Analyst-engineers build new applications as metadata. End users work in the generated web and mobile applications. Platform operators provision workspaces and install, upgrade and retire applications.

Is Assembler a low-code or no-code tool?

It is configuration over code, not zero code. Teams install and tailor applications without programming, and new domains are modelled by analyst-engineers who produce metadata rather than compiled code. Where something genuinely needs code, such as a bespoke screen component, it plugs into the platform through defined extension points instead of replacing it. There is no proprietary language: everything is standard Java, TypeScript and JSON.

What kinds of applications can we build?

Systems of record and operations such as CRM, case and asset management and back-office processes, high-volume transactional systems such as trade and order management, approval-heavy processes, portals with public intake forms, and integration hubs that connect ERP and other core systems. Applications already built on Assembler include a CRM with a freight-forwarding template and an agricultural commodity trading application.

See all 33 Assembler questions →

The other two platforms

Each is useful alone. Together they carry one piece of data end to end.

Quarry

All your outside data. One clean feed.

See QuarrySmelter

One number. Everyone agrees.

See SmelterStart here

Forty-five minutes with the people who built it.

Book a scoping session