Archived historical specimen.

The current runnable public workflow demo is reliable-ai-workflow-demo.

This repository remains available for provenance and can be reactivated if its specific specimen is needed.

wedge-case-1

A tiny state-machine specimen for keeping an item-level hold from silently becoming a workflow-level hold.

The one question

How can an item remain held without silently holding the whole workflow?

A workflow has several items. One of them is held — it is waiting on something. The easy mistake is to read that one held item as "the whole workflow is held." This demo separates the two, so a held item can sit next to a workflow that is still moving.

Quick start

node demo.mjs          # print the run
node demo.mjs --play   # print it line by line

No install. No signup, no network, no dependencies — just Node.js.

What you see

One workflow, release-001, with three items:

• build-check — continue
• rollback-plan — hold, with blocks_workflow: false and human_check: false
• license-review — route, handed to license-review-owner with a remaining_decision

Even though rollback-plan is held, the workflow stays open — because the hold is marked blocks_workflow: false. Then an evidence-added event satisfies the item's reopen condition, the item moves hold -> continue, and a handoff-requested event moves the workflow open -> close-current-intake.

close-current-intake
approval: not-evaluated       (handoff-ready. not approved to deploy.)

Two namespaces

Item states and workflow states are separate.

• item state: continue · clarify · request-evidence · route · hold
• workflow state: open · hold · close-current-intake

hold appears in both, but the item hold and the workflow hold are not the same object. continue is an item state only; the workflow is never continue — it is open.

What this workflow is — and is not

This is a handoff-preparation (intake) workflow, not a deployment-approval workflow.

Its goal is not "decide whether to deploy." Its goal is "make this release request handoff-ready": sort what is settled, what is held, and what is routed, so the next owner can pick it up.

That is why a held rollback-plan does not stop the workflow — the workflow is not deciding to deploy. And close-current-intake is not deploy permission; it reports approval: not-evaluated. A routed item (license-review) can still be open at close, because the owner who decides it (license-review-owner) and its remaining_decision are written down and can be carried to the next owner. Close means "ready to hand on" — not "resolved," and not "approved."

Without this framing, the aggregation rule ("a held item does not hold the workflow") can look dangerous. It is only safe because this workflow never claims the authority to approve a deploy.

blocks_workflow is an input, not a policy

This specimen does not decide what should block a workflow. It is not a domain policy engine and not a rule engine. blocks_workflow is a value given by the fixture. The specimen only reads it, and its single job is to keep a hold from silently propagating to every item: the workflow holds only when an item marked blocks_workflow: true is held.

What the fixture values mean

These are values in one hardcoded fixture, not general claims:

• human_check: false on an item means this toy item does not request a human check. It is not a claim that human review is unnecessary, and not a statement about accountability.
• evidence-added satisfying a reopen condition is a state transition — it means the condition was met, not that the evidence is sufficient or correct.
• The single fixture is an illustration of the state semantics, not a recommended release gate or policy.

Continues wedge-case-0

wedge-case-0 separated the kinds of halt for a single action — PASS, HOLD, STOP. wedge-case-1 receives a HOLD and asks the next question: across several items, what is held, and what can still move? It adds a second axis — item scope vs workflow scope.

Case 1 does not bring PASS or STOP into its own state model. Its item states are continue / clarify / request-evidence / route / hold; its workflow states are open / hold / close-current-intake. (PASS / HOLD / STOP above describe Case 0, not Case 1.)

Where it sits

Engines like LangGraph (interrupt and resume), Temporal (messages to a running workflow), OPA (policy decisions), and OpenTelemetry (traces) handle the machinery. This is not a replacement for any of them. It is a minimal specimen of the state semantics that can sit on top: an item-level hold that does not become a workflow-level hold.

Non-goals

• not an approval engine
• not a policy engine
• not a deployment system
• it does not make legal or license decisions
• not a production-ready orchestration framework

The single fixture is hardcoded and the checks are simple placeholders.

Tests

node --test

The tests pin the executable invariants: a held non-blocking item keeps the workflow open; a routed item needs a remaining decision; reopen is never a state; close needs both a handoff event and the handoff-ready check; the same fixture produces identical output bytes; every trace cause resolves inside the fixture.

Ran the demo?

Open an issue and leave one sentence — which transition matched what you expected, and which didn't.

For related runnable specimens and field notes, visit the Jinen Project public hub.

---

MIT-licensed. No dependencies. One fixture, one output.