Handeware Engine · handeware-run

A runtime that can always say what it did, and do it again.

The Engine executes workflows deterministically, suspends properly for human decisions, and records every transition as an event. Replay is not a debugging feature bolted on afterward — it is how the runtime resumes, which is why an audit bundle is a byproduct rather than a project. The agent slot ships unbound: a run never calls an agent nobody plugged in.

Model: Event-sourced, replayable
Core: Deterministic, non-LLM
Agents: Typed slot, unbound by default
Deploy: Container in your VPC

Static first, agentic when you say so

Most "agentic workflow" products start from the model and work backward toward reliability. We start from a deterministic core — expressions evaluated through a whitelist, DMN decision tables, gateways resolved in document order — and treat the agent as a typed, pluggable slot you bind deliberately, per node. An unbound slot is not a silent fallback; it is a refusal, logged as one.

That ordering is the whole governance story. You can put a workflow into production with zero agents, prove it against history, and then bind one node at a time — each binding visible in the evidence, each rollback a configuration change rather than a rewrite.

Human decisions are first-class suspensions

When a run reaches a human task it does not poll, block a thread, or hold a transaction open. It writes the task, suspends, and exits — with an exit code your scheduler can read. Later, an approval is appended to the log and the run resumes by replaying its own history. Completed steps keep their recorded results; replay never re-executes a side effect.

handeware-run start ./card_dispute.bpmn --handlers ./handlers.py
# exit 3: suspended at manual_review

handeware-run approve ./runs/r-4f2a1c9e manual_review \
    --decision '{"approved": true}' --actor "j.okoro"

handeware-run resume ./runs/r-4f2a1c9e     # exit 0: completed
handeware-run audit  ./runs/r-4f2a1c9e     # writes audit.html

What the evidence bundle contains

Element	Recorded
Event log	Every transition as one JSON object per line: run started, step started, completed, failed, retried, gateway taken, task created, decision recorded, suspended, completed, failed.
Gateway decisions	The expression evaluated and the edge taken — so a branch is explainable, not merely observable.
Human decisions	Actor, decision payload, and where in the sequence it landed.
Failure handling	Attempts, retries, and the boundary route taken when a step exhausted them.
Chain of custody	A hash of the handler code bound to the run; resuming with different code is refused unless explicitly overridden, and the override is itself evidenced.
Redaction	Credential-shaped strings and PAN-like digit runs masked before anything is written, with a hash of the original retained.

Deployment and procurement

Runs in your account. A container in your VPC. There is no Handeware control plane, no callback, no tenancy — which also means there is nothing of yours on our side to breach.
Batch-shaped, not server-shaped. Each invocation is one command: start, approve, resume, status, audit. It fits an ECS task or a scheduler slot without a long-lived service to babysit.
Bought the way your organization already buys. Multi-year private offers through AWS Marketplace, landing on your existing AWS bill; because it deploys into your own account, it sits naturally on the right side of committed-spend drawdown rules.

The path in

Nobody buys a runtime on a datasheet. The sequence that works: scan the estate → prove a chain against its own history → move that chain → then talk about a term. The proof is the qualification.