Gateway

There is no gateway configuration file. What can be called is what has been published: the flow brings its own name and the route appears with the artifact. Nothing is declared a second time, somewhere else.

Environment configuration is asked for by the flow, by name. A declared key the installation does not supply stops the boot and names the key — it is not discovered at the first message, with an empty value forwarded downstream. The same check runs without starting anything, and the command exits non-zero when a key is missing.

The price is written down, not discovered. A configuration value is captured once, at start-up, so changing configuration requires a restart — otherwise the start-up check would have verified values other than the ones the platform runs on. Same for the gRPC door’s routing table: it is built at start-up, so a flow published after that needs a restart before it is routable. And a boot scan cannot stay silent: a registry that cannot be listed stops the boot rather than looking checked.

• The credential is an API key, presented in Authorization: Bearer. The gate is closed by default; starting with no gate exists as an explicit option and announces itself on every boot.
• The authentication method is the tenant’s declared property, and a method this build cannot perform is refused at the tenant’s registration. Today that list accepts one word: the API key.
• A key carries scopes and, optionally, the list of flows it may call. A flow can require a given scope, and the requirement is checked after the artifact is loaded — that is where it is written.
• The gate runs before the body: a caller without a valid credential causes no body read and no parsing.
• An attributable refusal enters the audit chain with its subject, never carries the credential, and spends the caller’s ceiling — so a refusal cannot be used as a write pump. The audit is a record, not a doorman: if the row cannot be written, the refusal is still a refusal.
• A SOAP request goes through the same gate, unchanged. A refusal is plain HTTP 401 or 403, never a SOAP Fault — a fault carries a success status, and a gateway routing on status would forward the refusal as an answer.

What the platform performs

Key verification, scopes, the flow allowlist, the throughput ceiling, and the audited refusal.

What sits in front of it

TLS termination, a client’s mTLS, and any identity federation — OIDC or OAuth 2.0. The gRPC door is h2c, in the clear.

The platform does not verify an identity provider’s token: it reads no JWKS and validates no issuer, audience or expiry. If the front door has to be OIDC or OAuth 2.0, that requirement is settled in front of the platform, and what reaches the gate stays the API key.

And two things that do not authenticate, said because otherwise they are assumed: a credential inside a SOAP message body does not authenticate — the capability does not exist at all; and a signature over a webhook body produces neither a tenant nor rights, so it does not stand in for the key.

The ceiling is set on the key, when it is issued. Both message doors — synchronous and queue — spend from it, and a throttling refusal says when to come back: four headers on 429. Connector telemetry does not spend the ceiling, so a connector sharing the key does not pay twice for the same message.

• The ceiling is per credential — not per tenant, not per route, not per IP address. A key with no ceiling is unlimited; there is no installation-wide default and no global ceiling.
• The counter lives in the process’s memory: a restart empties it, and two instances have two counters. It is not a shared ceiling.
• A key’s ceiling does not change after issue. You revoke the key and issue another.
• The management UI does not pass through the limiter: neither its pages nor its login form are throttled.
• With the gate off there is no ceiling and no counter — the check lives inside the gate, and the gate does not run.
• On the gRPC door a throttling refusal is ResourceExhausted plus retry-after; the four X-RateLimit-* headers belong to the HTTP door.

• The measured unit is the delivery, not the request: received plus exactly one verdict. Which door it came through is read from the channel column, not from the kind of event.
• The typed verdict has its own column — succeeded, fault_handled, failed — and can be filtered on.
• A flow can carry a six-field schedule, and a tick leaves the same pair as a request, on the cron channel.
• One retention window governs both journal sinks — rows and files — in a single pass, wired into the serving process. The default is 30 days.

Version described on this site

1.2.0

Licence

Proprietary commercial, granted by contract. Nothing is published.

How we treat a break in the contract: at 1.0 the response envelope disappeared — the response is the flow’s output, unwrapped, with a Content-Type derived from the body’s shape — and the break is declared, not slipped into a minor release.

“Auditable” means exactly one thing here: the blake3 chain of policy acts — chained and verifiable, verified on demand from a command or from the button on the audit page, which names the sequence number of the entry that was touched. What the chain proves is that no entry changed in place; there is no anchor outside the installation, so whoever can write the file can rewrite the chain from a point onward. It does not mean source code — this is not open source, there is no open repository, and we do not invite anyone to read the code.

• There is no /metrics and no metric export of any kind.
• There is no journal export to an external collector — no syslog, no OTLP, no statsd, webhook, fluentd or Kafka. There are exactly two destinations, both local: a database and the daily rotated files.
• Masking applies at the journal sink and only to JSON, on object keys. A body written to a queue is carried as plain JSON; the checksum there is integrity, not a cipher.
• The retention window governs the journal and reaches no further: it does not touch the queues, the registry, the audit chain or flow state.

• SecurityHow far an unauthenticated caller gets, and what does not leak into a log.
• ObservabilityWhat can be read about a delivery, and how long it stays written.