NexusFabric

NexusFabric is an integration platform. You describe an integration as a flow — a Markdown file with a small amount of front matter and a sequence of steps — and the platform compiles it, stores it, and executes it deterministically.

---
flowmarkdown_version: "0.1"
flow: forward-order
tenant: acme
effects: [http_egress]
---

## Step: validate
```validate
$.orderId != null   | "orderId is required"   | syntactic
$.total > 0         | "total must be positive"
```

## Step: enrich
```ntd
{
  "orderId": "{{ $.orderId }}",
  "total": {{ $.total }},
  "receivedAt": "{{ date_format(now()) }}"
}
```

## Step: forward
effects: [http_egress]
endpoint: https://orders.example.com/ingest
method: POST

Register the tenant, deploy, issue a key, and it is reachable over HTTP:

$ nexus tenant create --id acme --display-name "Acme Ltd"
$ nexus deploy forward-order.flow.md --version 1.0.0
$ nexus keys create --tenant acme --label demo --scopes '*'
created  API key id=1
  key:   nxk_4f19c0b27ad3489e93f5c1e6a70d2b84

$ curl -X POST http://localhost:9090/flows/acme/forward-order/run \
       -H 'Authorization: Bearer nxk_4f19c0b27ad3489e93f5c1e6a70d2b84' \
       -H 'Content-Type: application/json' \
       -d '{"orderId":"A-1","total":42}'

Three commands rather than one, because none of them is implied by another: a tenant is a registered entity and deploy refuses to invent one from a typo in tenant:, and a flow route requires a key unless the server was started with --no-auth. See Getting started for the same sequence at length.

What it is for

Moving messages between systems that do not speak the same protocol, with rules in between. A flow can accept JSON over HTTP and emit SOAP; accept XML and call gRPC; validate, reshape, route, fan out, retry, and record every step.

It fits well when:

• Protocols differ at the two ends. JSON in, protobuf out. XML in, SOAP out. The platform converts between them natively rather than through string manipulation.
• The transformation is the work. Most of what an integration does is reshaping and validating, not computing. That belongs in a file a reviewer can read, not in code.
• You need to answer “what happened to message X”. Every execution carries a correlation ID through a structured log, and every deployment and privileged call lands in a hash-chained audit trail.
• Delivery must survive a restart. Asynchronous submissions go to a write-ahead log before they are acknowledged, with configurable retries and a dead-letter queue.

It fits poorly when the work is genuinely computational, when you need sub-millisecond latency, or when the integration is a single HTTP call with no rules — a shell script is a better answer for the last one.

How it works

  .flow.md  ──parse──▶  AST  ──compile──▶  IR  ──store──▶  content-addressed
                                            │              storage (blake3)
                                            │
  request  ──────────────────────────────▶ execute ─────▶ response

Four properties follow from this shape:

Compilation is separate from execution. nexus compile turns a flow into an intermediate representation and tells you about every error it can see — unknown effects, malformed expressions, references to things that do not exist — before anything is deployed.

Artifacts are immutable and addressed by content. The compiled flow is stored under the blake3 hash of its own bytes, and that hash is verified on every read. A deployed version cannot change under you; a new version is a new artifact.

Execution is sequential and deterministic. Steps run in file order. The same input against the same artifact produces the same output, apart from effects that are explicitly non-deterministic — the clock, random values, and the network — and those must be declared.

Effects are declared, not discovered. A step that reaches the network says so in its effects: list. A step that does not declare an effect cannot perform it: the executor checks before running, so a flow cannot quietly acquire a capability the author did not write down.

What is in the box

Inbound	HTTP (JSON, XML, SOAP 1.1/1.2), gRPC (unary), scheduled by cron, queued, or from a connector
Outbound	HTTP (JSON, XML, SOAP), gRPC (unary and server streaming), OAuth2
Transformation	Template language with native XML construction; a compiled subset of XSLT 1.0/2.0
Composition	Sub-flow inlining, per-item fan-out, parallel scatter-gather, fire-and-forget
Reliability	Write-ahead queue, exponential backoff, dead-letter queue, per-step timeouts, opt-in deduplication and request/response correlation
Security	API keys with scopes and per-key rate limits, secrets from the environment, TLS with private CAs
Observability	Structured logs with payload masking, hash-chained audit trail, a management UI
Tooling	Command-line interface, language server, VS Code extension

Read Getting started next, or Core concepts if you would rather understand the model before writing anything.