Skip to content

v0.1.5 — HIL Phase 1: holds queue + resolution API

Choose a tag to compare

@leodavidsec leodavidsec released this 04 Jul 10:16

Reeflex v0.1.5 — HIL Phase 1: holds queue + resolution API

HOLD becomes operational. A require_approval verdict now materializes a persistent hold; a principal the operator designates resolves it; an approved action can be re-submitted and allowed exactly once.

The first decision is deterministic. The second decision is yours. Core provides the mechanism — the holds API, the audit of the handover — never the gray-zone judgment. Core still never executes actions.

What's in it

  • Holds queue — event-sourced append-only JSONL store + in-memory index, lazy expiry, single-use, TTL (default 4h). Each hold binds the sha256 of the action-defining projection ({action, axes, magnitude, target}) — a modified action cannot ride an old approval.
  • Holds API (same bearer as /v1/decide): GET /v1/holds, GET /v1/holds/{id}, POST /v1/holds/{id}/resolve.
  • Approval principals — human | agent (AIL) | automation. Resolution policy is the operator's, per rule (shipped default: human-only). actor != approver enforced in core; the systemic rule stays a terminal deny (resolvable by no one). decided_by records type:identity verbatim — the EU AI Act Art. 14 oversight-allocation evidence. Zero LLM in the FIRST decision path.
  • Kill-switchREEFLEX_FREEZE=true denies all non-read verbs instantly; reads pass; flips audited.
  • Outbound hold webhookhold.created / hold.resolved / hold.expired / freeze.flipped; fire-and-forget, bounded queue, at-most-once, never blocks /v1/decide. Makes BPMN/SOAR/n8n integration possible without vendor connectors — core builds the socket, not the engines.

Pull

docker pull ghcr.io/reeflex-io/reeflex-core:v0.1.5

Digest: sha256:ca6f0488290721db16db5c9ff3b1af8acb3b14010a7f0f2e5d37d87abab3a2ac (also latest).

Verified

  • CI green: 207 core tests (1 intentional platform skip) + 9/9 OPA policy.
  • Anonymous GHCR pull confirmed for both tags (digest match).
  • Live smoke on the release image: a bulk-delete returns require_approval + hold_id + expires_ts; the full handover (decide → hold → resolve → resubmit-with-approval → allow → consumed) is proven end-to-end over HTTP.

Docs

reeflex-core/README.md (Holds & human-in-the-loop) and reeflex-spec/SPEC.md (approval object). Full changelog: CHANGELOG.md.

Core-only. Adapters unchanged. Phase 2 = adapter re-submission + surfaces (WordPress admin, Slack, CLI, MCP holds server).