AWS Step Functions

A Standard workflow definition and Go launcher were added to start one durable execution per control, with retries and an ECS task integration. Official documentation made the service integration clear, but deployment parameters and cloud infrastructure were not available for a live run.

What worked

The service model fit the need for work that survives the originating HTTP request, and the state-machine JSON validated locally.

What got in the way

No real workflow execution was observed because account configuration, substituted infrastructure parameters, and credentials were outside the available environment.

Modeled the assistant as a state machine with an activity for model turns and a task-token wait for human approve or reject, then wired start and resume from the existing API. Live executions were never run.

What worked

Choice routing, activity workers, and wait-for-task-token mapped cleanly onto planning, pause, and resume without putting that state in an application loop.

What got in the way

Construct details such as activity grants, token paths, and timeout fields had to be confirmed from bundled type definitions rather than from memory of the high-level docs.

Used documentation and the Java SDK to implement idempotent workflow startup and a callback-based Standard workflow in infrastructure configuration. The design compiled and linted but was not executed in AWS.

What worked

Standard workflows, explicit retries, and task-token callbacks matched the need for durable, auditable long-running processing.

What got in the way

Execution-name character and length constraints, callback timing, and queue-retention alignment required extra design attention.

Used official documentation to select Standard workflows, then implemented deterministic workflow starts, task-token callbacks, retries, priority branches, and an identifier-only state machine. The design linted and compiled but was not deployed.

What worked

Durable execution, callback tasks, long-running review support, and deterministic execution naming aligned closely with the workflow requirements.

What got in the way

Service-integration ARN validation required template corrections, and live execution semantics were not tested in an AWS account.

Consulted the service documentation for Standard Workflow callback-task-token support to assess durable human approval pauses. It directly supported the architecture decision, although no live workflow was deployed or exercised.

What worked

The documented callback approval capability matched the requirements for managed durable state and waiting for a person before writes.

A Standard Workflow definition and idempotent execution publisher were added for scan, urgent or routine extraction, review, and indexing. The long-running retry and callback model matched the requirements, though no state machine was deployed.

What worked

The workflow definition was valid JSON, and the service cleanly separated orchestration from authoritative clinical state in PostgreSQL.

What got in the way

Execution semantics, IAM permissions, callbacks, retries, and queue integrations were not verified against the hosted service.

Implemented deterministic workflow starts and a state-machine definition for scan, extraction, clinical review, approval, and indexing. JSON syntax and surrounding templates were validated, but no state machine was deployed.

What worked

The execution model fit durable retries, human review gates, and auditable state transitions well.

Designed a Standard workflow and integrated submission through the AWS SDK. The checked-in state machine includes retries, timeouts, isolated execution, progress transitions, and terminal-failure handling, but it was not deployed or exercised against AWS.

What worked

The workflow model expressed the complete durable lifecycle and service integrations needed after API and worker replacement.

What got in the way

No production credentials were available, so runtime execution and managed-service reliability were not observed.

Researched Standard workflow semantics, then defined a named durable workflow with transient retries and separate trusted and isolated Fargate stages. CDK assertions and synthesis validated the definition, but it was not run in AWS.

What worked

Standard workflows directly addressed restart survival, retry history, and explicit execution state without operating a queue cluster.

Configured a Standard workflow to move report generation off the request path, coordinate task stages, record terminal failures, and provide retries and timeouts. The template linted, but the workflow was not deployed live.

What worked

Standard workflows matched the need for durable, multi-minute execution and integrated directly with container tasks.

What got in the way

State input placement, failure handling, execution permissions, and monitoring dimensions needed careful manual review.

Designed and implemented a Standard workflow with per-stage checkpoints, retry and catch behavior, failure handling, and redrive-friendly state. The definition validated and packaged but was not deployed.

What worked

The service model directly addressed durable execution and avoided repeating already successful model calls after later-stage failures.

What got in the way

Runtime execution and retry behavior were not observed because no AWS deployment occurred.