A message enters through one door and leaves with a verdict

NexusFabric takes a message at one of four doors — HTTP, queue, schedule or gRPC — passes it through the same access gate and the flow declared in a file, then leaves exactly one verdict in the journal.

The L1 journal: deliveries filterable by tenant, flow, level and outcome, each row expandable to its full fields. — The journal of a running installation. The data belongs to the showcase tenant Meridian Logistics (showcase).

Four doors, one gate

Synchronous request
HTTP, on the run route. The message runs immediately and the caller gets the flow output unwrapped, with the status the flow declares.
Handover to a queue
HTTP, on the enqueue route. The message is written to a log on disk, the caller gets a 202, and a worker picks it up from there, with retries and a dead letter queue.
Schedule
A flow can carry a six-field schedule. A tick leaves the same received plus verdict pair in the journal as a request does, on the cron channel.
The gRPC door
A separate port routes the call to a flow through the same access gate and the same delivery bracket as the HTTP door.

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.

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 key 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, from three layers: the installation, the flow, the egress step. A body that exceeds it gets a 413 and leaves a fault event in the journal.
Executor::deliver is the one bracket
All four doors enter through the same delivery bracket. Deduplication on a key, request-to-response correlation and response memoisation have no code of their own on any door.
The steps run in order
A validate guard refuses at the first rule that is false, a route picks one arm and converges after the guard’s last arm, an ntd fence produces the next document. An unhandled error enters the ## Fault: section, if the flow has one.
Exactly one verdict
A delivery leaves a received event and exactly one verdict: completed, fault or delivery_refused. The nuance sits on the outcome column beside it — succeeded, fault_handled or failed.
The journal says which door it came in through
The channel is a column, not a kind of event: http, grpc, queue or cron. A schedule tick leaves the same received plus verdict pair as a synchronous request.

The gate is first, the ceiling second. That is why a caller without a key announcing a body over the ceiling gets a 401, not a 413: the ceiling is internal installation state and is not disclosed before authentication.

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. Without a valid credential the request stops here, with a 401 or a 403, and leaves an access_denied event.
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::deliver is 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: completed, fault or delivery_refused.
A refusal by the gate or by the ceiling goes straight to the journal, without touching the steps.
The L1 journal records the received event, the verdict, the channel the delivery came in on, and the outcome column.

The file you write

A flow is a Markdown file: a header saying who owns it and which effects it may use, then steps. Guards, transforms and the response are written in fences, each with its own language. Below, two fences from a real flow in the compliance corpus: a guard that refuses explicitly, at the first rule that is false, and a step that declares its response status.

tests/battery/corpus/meridian/01-shipment-intake.flow.md — the egress step between the two fences, lines 34-40, is left out: it carries an endpoint the battery substitutes at run time.

## 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 }}
}
```

The flow language

What is counted

The figures below describe the shape of the product and are read from the code.

4doors a delivery arrives throughHTTP, queue, schedule and gRPC, all through one gate
10fence languages in a flow filetransform, guards, routing, loop, parallelism
23event kinds in the journaleach with an emission site required mechanically
25fields always maskedcannot be switched off; a flow can add to the list
16error variants in a single mapone exhaustive match, no catch-all arm

What it refuses to do

The limits sit here, next to the capabilities, so an unsuitable case can be ruled out on the first page.

The queue delivers at least once. The platform does not promise exactly-once at the door; what it offers is declarative deduplication on a key written in the flow.
It exports no metrics. What happened is read from the delivery journal and the management interface, not from a monitoring system.
It does not encrypt at rest. The databases and the queue files are encrypted at the disk or volume level, not by the platform.
The gRPC door serves unary methods. A streaming method gets an explicit refusal, not a silent degradation.
The gRPC routing table is built at start-up. A flow published afterwards is routed at the next restart.
Environment configuration is captured at start-up. A configuration change requires a restart, so that the start-up check covered exactly the values the platform is running on.

Coverage

Which protocols and which effects exist in the platform today, inbound and outbound.
Protocol or effect	Inbound	Outbound
HTTP, JSON	synchronous on the run route, asynchronous on the enqueue route	HTTP call from a step
XML	the same doors, with an XML Content-Type	HTTP call, with an XML Content-Type
SOAP 1.1 and 1.2	detected from the body; WSDL 1.1 generated on its own route	envelope composed on the egress step
gRPC	a separate door, unary methods	unary and server streaming, with TLS and mTLS
Schedule (cron)	a six-field schedule in the flow header	not applicable
Queue	the enqueue route, a log on disk, at-least-once delivery	queue publication from a step
JMS, over STOMP	a separate connector, handing over on the queue route	not built
Files in a directory	a separate connector, handing over on the queue route	not built
Secrets from the environment	not applicable	secret read from a step
OAuth2 client_credentials	not applicable	token acquisition from a step

The platform, by chapter

Licence and version

Version described here: 1.2.0
Licence: Commercial, proprietary. No public download and no source code.
Availability: By contract, on request.

Four doors, one gate

Synchronous request

Handover to a queue

Schedule

The gRPC door

How a message travels

The gate decides before the body

The ceiling is resolved, then the body is read up to it

Executor::deliver is the one bracket

The steps run in order

Exactly one verdict

The journal says which door it came in through