klieo-workflow-api
Embeddable axum router that fronts
klieo-workflow over REST. A caller submits a declarative
WorkflowDef as JSON; the service compiles it against a host-supplied Registry
allow-list, runs it on the klieo runtime, and reports status — so workflows can be
authored in any language (Python, Java) while all execution stays in Rust.
Endpoints
| Method | Path | Purpose |
|---|---|---|
GET |
/health |
Unauthenticated liveness probe (200, body ok) — for an orchestrator with no credential to present. |
POST |
/runs |
Submit a WorkflowDef + input envelope. Compiles synchronously (invalid → 400 with a typed error), then runs it in the background. Returns 202 { run_id }. |
GET |
/runs/{id} |
Poll run status + result (404 if unknown). |
GET |
/registry |
Enumerate the palette (registered model / tool / subflow ids) a workflow may reference. |
GET |
/runs/{id}/events |
Server-Sent Events stream of live run progress (live-tail; best-effort). |
Mounting
let router = new
.with_authenticator // required
.with_app // klieo App — supplies bus/memory/tools/context
.with_registry // the allow-list of models/tools/subflows
.with_run_store // KvStore-backed run state
.build?;
The host constructs the App and Registry; the service reads neither secrets
nor an LLM of its own (each agent node swaps in its registry-resolved model, so
App.llm is unused by workflow runs).
Contract
- Auth: every request is authenticated;
POST /runsrequires theklieo.workflow.runscope, reads (GET /runs/{id},GET /runs/{id}/events) requireklieo.workflow.read. The run'sauthoris stamped server-side from the caller identity — never client-supplied.klieo.workflow.readalone only authorizes reading runs the caller itself authored; a read for a different-author run returns404(not403) so a run's existence is never disclosed to a non-owner.klieo.workflow.read.alladditionally grants cross-author reads, for an operator/support identity. - Idempotency: a submit is keyed by the canonical hash of the definition plus its input; a retried submit collapses to the original run rather than starting a second.
- Bounded: concurrent runs are capped (excess →
429withRetry-After); the request body is size-limited; every run has a wall-clock timeout. - Terminal-write guarantee: a run always reaches a terminal status
(
succeeded/failed/aborted) — a panicking or timed-out flow is recorded as failed/aborted, never leftrunning.
Limits (v1)
Run status is a volatile poll cache (durable run outcome lives in the provenance chain). No stored/named workflows — the definition travels in every request. No HITL suspend/resume. Single global registry.
Deploying
klieo-workflow-api — not klieo-server — is the
deployable run-service surface: klieo-server is a publish = false
reference demo, not meant to serve real traffic. Embed this crate's router
in your own binary (see Mounting, above), then deploy that binary using the
klieo-compliance repo's deploy/ tree (Docker Compose, Helm, Terraform)
as the topology reference — swap its compliance-server container image for
yours; the reverse proxy, secrets, and networking shape carry over
unchanged. klieo is pre-production: deploy/ does not itself prescribe
autoscaling or canary rollout — add those only if your deployment needs
them.