Assembler: frequently asked questions

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.

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.

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.

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.

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.

You declare entities (Assembler calls them molds), their fields (slots) and the relationships between them. Assembler then creates the real database tables, the APIs, and the forms and lists to work with them. Around fifteen field types are supported, including money, percentages, dates and times, picklists with allowed state transitions, lookups, files, computed formulas and encrypted fields.

Rules (gauges) are declared as condition trees or decision tables and evaluated by Assembler's own rules engine. A rule can block or derive values when a record is saved, decide a branch in a workflow, or run from a button or an API call. Each rule can carry test cases, and a rule cannot go live if its own tests fail. A rule that cannot be evaluated is treated as a refusal, never as a pass.

Workflows (grooves) are declared as BPMN-aligned process flows with approvals, notifications, gateways, timers, loops, sub-processes and steps that read and write data, evaluate rules, call external systems or invoke AI. They run on a durable execution engine, so a process can wait days for an approval and survive restarts. Workflows start on a schedule, on a data event, by webhook, by API or by hand.

Approval steps create tasks in one inbox shared by workflows and AI agents. Tasks are offered to roles, claimed and decided with the decision options and comments the process requires, and service-level timers expire overdue tasks so they can be escalated. Every decision records who made it and when.

Yes. Rules, workflows, screens and AI configuration are versioned metadata. You change them, test them and commission them, and the change is live, with a full audit trail and the ability to roll back to the previous version.

No. Forms, lists and navigation are rendered at runtime from metadata, on the web and on mobile, and navigation is filtered by each user's permissions. Forms support conditional show, hide and require rules, cascading lookups, wizards, related-record tables and charts. Each workspace can carry its own brand, logo and colour theme.

Yes. Reports are defined in the business vocabulary of your model, with joins, measures, filters and charts, and the engine resolves them to physical queries while enforcing each user's row-level access. Reports export to CSV, Excel and PDF and can run on a schedule. Document templates produce PDFs such as quotes, invoices and certificates, including right-to-left and Indic scripts.

Cognition is Assembler's agentic operating system: the layer that runs AI agents and agent teams inside your applications, governed by the same access control, audit and rules as everything else. Every AI capability is declared as metadata, so it is versioned, overlaid per customer and upgraded without a release.

Agents use your own entities, rules, workflows and reports as tools: they can query and update records within their permissions, start workflows, evaluate rules, run reports, call external tools over MCP and delegate to other agents. They are authored as visual graphs and can work in teams through supervisor, delegation, handoff and fan-out patterns, with confidence-based escalation to a more capable agent or a person.

Agents are event-driven out of the box. They fire on schedules, on platform events, on signed webhooks or on demand, and long-running agent sessions use durable execution, so they survive failures and can pause for human approval.

You choose the model per capability: frontier model APIs, cloud AI platforms, or models you host yourself, such as through vLLM or Ollama, or any OpenAI-compatible endpoint. Privacy routing keeps sensitive data on models inside your walls, and Assembler can run AI entirely on self-hosted models for air-gapped deployments.

Every AI call passes through one governance pipeline. It includes a catalogue of guardrails (such as PII redaction, prompt-injection detection, grounding checks and denied topics), validation of tool results before they reach the model, a per-agent circuit breaker with a manual kill-switch, and human approval gates before or after sensitive actions. Each agent carries a risk tier framed against the EU AI Act, and high-risk agents need a named accountable party and separation of duties before they go live.

Yes. Every call is traced and every call is budgeted: each model call is recorded as an OpenTelemetry trace, checked against workspace and application budgets, and audited with who ran which agent, on which model, at what cost, however the run ended.

Yes, in both directions. Assembler agents can use tools from external MCP servers, with outbound connections denied by default until allowed, and Assembler serves its own entities, rules, workflows and reports as tools to other agents over MCP.

Not necessarily. You can use model APIs, your existing model-serving infrastructure, or self-hosted models. Assembler owns the metadata, routing, governance and audit around each model call; model hosting and fine-tuning runs remain with your infrastructure team. AI inference cost is yours directly, through your own API keys or GPUs.

Each workspace is isolated at the database layer, with its own schemas, row-level security and privilege-separated database roles, rather than by an application filter that someone might forget. Isolation checks fail closed.

Access is declared in the same metadata as the data, at three levels: object (who can see, create or act on each entity), field (which fields each role can read or edit) and row (which records each user can reach, for example their own, their team's or their branch's). Restricted fields are removed from reads, exports and searches, not just hidden on screen. The same rules apply in reports and to AI agents.

Through the Ory identity stack: passwords, one-time codes and passkeys (WebAuthn), with account recovery and verification flows. Identity is enforced at the edge before any request reaches a platform service, and one person can belong to several workspaces with different roles.

Fields can be declared as encrypted. They are protected with envelope encryption, masked by default, decrypted only on an explicit request by a permitted user, and every decryption is audited. Master keys can come from your key management service, and keys can be rotated without downtime.

Every state change, every record's full history, every decryption, every login, every workflow decision and every AI call. Every change is also published as an event in the same transaction as the data, so nothing is missed by downstream systems.

Every capability is available through REST APIs, and every state change is published as an event that external systems can subscribe to or receive by webhook. An integration layer built on Apache Camel connects ERP and other business systems, with field mapping, retries and circuit breakers. File feeds, email capture and spreadsheet import and export are built in.

Yes. Assembler is API-first, and each application has its own API gateway, so front ends can be rendered from metadata or built bespoke on the same APIs, rules and permissions.

They are sibling platforms, deployed independently. Quarry acquires external data and Smelter harmonizes it into one governed record; Assembler receives that record through its integration layer, over events or webhooks, and acts on it with rules, workflows and agents. Assembler itself contains no crawler and no data-pipeline engine.

Inside your environment: private cloud or on premises, on containers or Kubernetes, air-gapped where required. It emits metrics, logs and traces over OpenTelemetry into whatever monitoring you already run. RUSH can operate it for you inside your walls as a managed service.

Yes. One installation hosts many isolated workspaces, and each workspace can run several applications side by side under one navigation and search. Applications are installed, upgraded and uninstalled per workspace, and industry templates and customer-specific changes are layered on top so they survive upgrades.

Java and Spring Boot, PostgreSQL with pgvector, Apache Kafka, Valkey, Temporal, Apache Camel, LangChain4j, the Ory identity stack, OpenTelemetry, React and Flutter. Every layer of the underlying stack is open source, so any Java team can extend it.

Assembler is licensed for a term of 3, 5 or 10 years in Starter, Growth and Enterprise editions. Each edition includes a defined production capacity, a number of applications and a number of non-production environments, with support coverage that increases by edition; extra applications and disaster-recovery environments are available as add-ons. Annual support and updates accompany the licence; managed operations and application builds are optional services.

No. AI inference is billed by your model provider or runs on your own GPUs, so you pay for it directly and at cost.