Enterprise Integration Kernel · Written in Rust
Enterprise integration. Reinvented in Markdown.
An integration platform that connects HTTP, SOAP and gRPC with readable flows. Validate, transform and route messages on infrastructure you control.
What it changes for your team
Your support desk answers “where is my message?”
Support finds a delivery by its correlation ID, sees for each flow how many messages are pending, retrying or dead-lettered, and reads its trace. A sysadmin replays a dead-lettered message under the same ID, and the replay is recorded.
- Find, Support
- Queue, Support
- Trace, Support
- Replay, Sysadmin
One program in place of a stack of products
The front door, transformation and routing, a persistent queue with retry and dead-letter, and the message journal run in one program.
An assembled integration tier
- API gateway
- Integration runtime
- Message broker
- Log store
- Admin console
NexusFabric
- Front door
- Transformation and routing
- Persistent queue
- Message journal
- Management UI
More engines, no cluster to manage
Start the same program again on the same host. File locks are all that coordinates the copies: no orchestrator, no consensus, no node registry.
same program, same state directory, file locks
Every flow is checked before it takes traffic
When you publish a flow, the platform checks the shape of its routing block, its name, its transforms and its SOAP version.
XSLT outside the supported subset is refused at publication, not run some other way.
Four doors, one delivery bracket
Choose a door to follow one delivery.
| Synchronous request | Handover to a queue | Schedule | The gRPC door | |
|---|---|---|---|---|
| Arrives by | HTTP or SOAP, on the run route | HTTP, on the enqueue route | A six-field schedule in the flow header | A separate port |
| Access gate | The shared gate | At enqueue time | Not applicable — the trigger is internal | The same as on HTTP |
| Delivery bracket | Executor::deliver All four doors enter through the same delivery bracket, the queue at the worker, not at the handover. Deduplication on a key, request-to-response correlation and response memoisation are decided in one place, not rewritten per door. | |||
| Verdict | A delivery that arrives by a synchronous request, a schedule tick or a gRPC call leaves a | |||
| Outcome | Where a verdict is written, its nuance is in the | |||
| Channel | http | queue | cron | grpc |
The gate is closed by default and runs before the body: an unauthenticated caller causes no body read and no parsing. Which door a delivery came in through is read from a journal column, not from the kind of the event. The gRPC door serves unary methods only.
The pair a delivery leaves in the journal
| event | channel | outcome | tenant | flow |
|---|---|---|---|---|
received | http | none | meridian | shipment-intake |
completed | http | succeeded | meridian | shipment-intake |
The queue does not write the received and verdict pair. | ||||


How a message travels
- The gate decides before the body
The request passes the gate before a single byte of body is read. A caller without a credential gets a 401 and learns neither whether the flow exists nor how much body it would have been allowed to send.
- The ceiling is resolved, then the body is read up to it
A message ceiling is resolved per access point: the flow’s own, if it declares one. A body announced over the ceiling gets a 413 before a single byte is read.
Executor::deliveris the one bracketAll four doors enter
Executor::deliver: deduplication, correlation and the memoised response are decided in one place, not rewritten per door.- The steps run in order
A
validateguard refuses at the first rule that is false, aroutepicks one arm and converges after the guard’s last arm, anntdfence produces the next document. An unhandled error enters the## Fault:section, if the flow has one. - One verdict per delivery
A delivery that exits through the
## Fault:section is not committed as a success: a corrected duplicate runs instead of replaying the memoised fault. - The journal says which door it came in through
The channel is a column, not a kind of event:
http,grpc,queueorcron.
Read this diagram as text
- The caller sends the request to a flow route.
- The access gate decides first, and it is closed by default. Here a caller without a credential gets a 401 and one whose credential does not cover the flow gets a 403; each refusal leaves an
access_deniedevent. - The message ceiling is resolved, then the body is read up to it. A body over the ceiling stops with a 413 and reaches no step.
Executor::deliveris the bracket all four doors enter through. Deduplication and correlation are decided here.- The flow steps run in order.
- The delivery ends in a verdict, exactly one.
- A refusal by the gate or by the ceiling goes straight to the journal, without touching the steps.
- The journal records the received event, the verdict, the channel the delivery came in on, and the
outcomecolumn.
What your team reviews is checked at publication
A flow is a Markdown file: a header, an optional description, then the steps. Your team reviews it like any other change. Publication compiles it.
tests/battery/corpus/meridian/01-shipment-intake.flow.md — the egress step, lines 34-40, is left out.## Step: check-booking
```validate
$.shipmentId != null | "shipmentId is required" | syntactic
$.hubCode != null | "hubCode is required" | syntactic
$.parcelCount > 0 | "parcelCount must be greater than zero"
$.weightKg > 0 | "weightKg must be greater than zero"
```
…
## Step: acknowledge
response_status: 202
```ntd
{
"status": "ACCEPTED",
"shipmentId": "{{ $.echo.shipmentId }}",
"waybill": "{{ $.echo.waybill }}",
"hubCode": "{{ $.echo.hubCode }}",
"parcelCount": {{ $.echo.parcelCount }}
}
```$ nexus validate flows/01-shipment-intake.flow.md
ok flows/01-shipment-intake.flow.md
flow: shipment-intake
tenant: meridian
steps: 3tests/battery/corpus/acme/stricate/p10-xslt-necoborabil.flow.md, in full.---
flowmarkdown_version: 0.1
flow: p10-xslt-necoborabil
tenant: acme
effects: []
---
## Step: x
```xslt
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<xsl:apply-templates select="*"/>
</xsl:template>
<xsl:template match="*">
<copiat><xsl:value-of select="."/></copiat>
</xsl:template>
</xsl:stylesheet>
```$ nexus validate flows/p10-xslt-necoborabil.flow.md
error: step 'x': this XSLT sheet is outside the subset this platform compiles, and there is no XSLT engine at run time — unsupported XSLT construct <xsl:apply-templates>: recursive template application requires a runtime XSLT engine. Rewrite the step as `ntd`: it expresses the same transformations, and its failures are visible here rather than at the first message. `descendants()` covers `//name` searches, `string()` takes an element's text, and `{{ if }}` / `{{ for }}` cover `xsl:choose` and `xsl:for-each`
error: 1 validation error(s)What is counted
The figures below describe the shape of the product and are read from the code.
- 1program to install, patch and back upthe door, transformation, the queue, the journal and the management UI
- 4doors a delivery arrives throughHTTP, queue, schedule and gRPC, all through one delivery bracket
- 3roles in the management UISysadmin, Developer and Support, on an enforced boundary
- 28event kinds in the journalreceipts, verdicts and refusals among them
The platform, by chapter
- ProtocolsThe inbound doors, the outbound calls and the ceiling on a message.
- TransformationsThe flow language, the guards, routing, and what is refused at publication.
- ObservabilityThe measured unit, the verdict of a delivery, and the retention window.
- SecurityThe gate, the tenant, the interface roles, and what never reaches an error message.
Licence and version
- Version described here
- 1.30.0
- Licence
- Commercial, proprietary. No public download and no source code.
- Availability
- By contract, on request.
Walk through it with the people who wrote it
Bring one integration you run today. We go through the flow, the journal and the management UI with you.
Third-party product names such as Rust are trade marks of their owners.