Long-Running Autonomous Workflows Without External Orchestration

Regulatory Framework

The regulatory perimeter surrounding long-running enterprise workflows is dense. ISO 9001 requires that the organization "determine, provide and maintain the infrastructure necessary for the operation of its processes," and that documented information be controlled, retrievable, and protected from unintended alterations across the entire process lifecycle. ISO/IEC 25010 elaborates this by defining reliability sub-characteristics including maturity, availability, fault tolerance, and recoverability that apply to any system executing business-critical work over extended durations.

FDA 21 CFR Part 11 imposes the strictest requirements on workflows that touch life-science records: electronic records must include "secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records." Section 11.10(e) demands that audit trails be retained for at least as long as required for the underlying records and be available for agency review and copying. SR 11-7, the Federal Reserve and OCC supervisory letter on model risk management, parallels these requirements for any quantitative model embedded in a workflow, requiring "effective challenge" and continuous outcomes monitoring across the model lifecycle.

GDPR Article 30 obligates controllers and processors to maintain a record of processing activities that includes the purposes of processing, categories of data subjects, recipients, transfers, retention schedules, and security measures. For a workflow that touches personal data, every step is a processing activity, and the workflow's state transitions are the primary source of truth for Article 30 compliance. BPMN 2.0 standardizes the visual and semantic representation of these processes, AsyncAPI standardizes the event interfaces between workflow steps, and OASIS WS-Reliability standardizes message-delivery guarantees that workflows depend on for cross-organization handoffs.

The aggregate effect is that any workflow operating over weeks or months in a regulated industry must produce a tamper-evident, time-stamped, role-attributed history of every state change, prove that no events were lost across system failures, and reconstruct any historical state on demand for regulators or auditors. These are not optional engineering quality attributes; they are the baseline conditions for legal operation.

Architectural Requirement

Translating the regulatory perimeter into architecture yields a precise requirement set. The workflow must be durable across infrastructure failures of arbitrary duration. It must be deterministic in its replay of historical state, so that an audit conducted three years after the fact reaches the same conclusions a real-time observer would have reached. It must carry an append-only history with monotonic timestamps and verifiable actor attribution. It must support dormancy intervals that exceed the lifetime of any single host, runtime, or container, because regulatory workflows commonly wait weeks for external responses, regulatory comment periods, or scheduled review cadences.

The workflow must additionally tolerate version drift. Definitions change while instances are in flight; a six-month compliance review started under version 4 of the policy must complete under version 4 even after version 5 has been deployed, while remaining auditable against both. It must support recursive sub-workflow delegation with full lineage, because regulatory work is rarely flat: an approval workflow spawns document-collection sub-workflows that spawn external-party reminder loops, each with its own state, deadlines, and audit obligations. Finally, it must integrate cleanly with the surrounding standards stack: BPMN diagrams must be executable artifacts, AsyncAPI channels must be the agent's I/O surface, and WS-Reliability semantics must hold end-to-end across organizational boundaries.

A sound architecture therefore needs to bind state, execution logic, audit history, and policy version into a single addressable unit whose identity persists across infrastructure transitions. The unit must survive when the host dies, when the runtime is upgraded, when the orchestration framework is replaced, and when the operating organization itself reorganizes its compute fabric. The architectural requirement is not for a more reliable orchestrator. It is for the workflow to stop being an operand of an external system and become a first-class persistent object.

Why Procedural Compliance Fails

Current implementations attempt to satisfy the regulatory framework procedurally, by composing an orchestration engine, an event store, an audit-logging pipeline, a secrets vault, a workflow definition repository, and a separate observability stack. Temporal, Camunda, Apache Airflow, AWS Step Functions, and similar frameworks externalize workflow state and rely on the surrounding infrastructure to reconstitute durability, audit, and recoverability. Procedural compliance with Part 11, GDPR Article 30, and SR 11-7 then becomes the union of all the procedural compliance properties of the surrounding stack: the audit trail is whatever the logging pipeline captured, the durability is whatever the event store guaranteed, the role attribution is whatever the identity provider stamped onto each call.

This compositional approach fails for several reasons. First, the audit trail is not intrinsic to the workflow. It is reconstructed by joining records from systems with independent retention policies, clock skews, and access controls. A regulator asking for the complete history of a single workflow instance receives an answer that is the product of joins across orchestrator state, audit logs, identity logs, secret-access logs, and external-system call logs. The integrity of the answer depends on every component remaining consistent across the entire retention window, which often exceeds a decade for life-science records.

Second, durable execution frameworks based on event sourcing trade orchestration overhead for replay overhead. As event logs grow, replay times expand, non-deterministic side effects must be quarantined, and version migrations of workflow definitions require careful event-log compatibility analysis. The very mechanism that provides durability becomes the operational bottleneck, and it does not eliminate the orchestrator dependency; it merely relocates the complexity.

Third, the orchestration tier becomes a single regulatory failure domain. A configuration error, a version skew, or an upgrade incident in the orchestrator simultaneously affects every workflow instance. For an insurance carrier with fifty thousand concurrent multi-week claims workflows, an orchestrator outage is a regulatory event affecting fifty thousand records simultaneously. Fourth, BPMN diagrams, AsyncAPI specifications, and policy documents drift relative to the executing code, because the executing code lives in the orchestrator's internal representation while the standards artifacts live as design-time documentation. Procedural compliance reviews then audit the documentation, not the executing system.

Fifth, GDPR Article 17 erasure obligations and Article 20 portability obligations are operationally expensive when state is fragmented across the stack. Locating every byte of a data subject's footprint across orchestrator state, event logs, audit logs, derived projections, and downstream caches is a forensic exercise rather than a structural query.

What the AQ Primitive Provides

Memory-resident execution treats each workflow instance as a self-governing persistent object that carries its own state, its own execution logic, its own audit history, and its own policy version as intrinsic typed fields. The object's identity is durable across infrastructure transitions. Its memory is append-only by construction, time-stamped at the moment of mutation, and signed by the actor whose operation produced the change. The audit trail is not a separate artifact; it is the object's memory, inseparable from the state itself.

When a compliance review reaches a step that requires waiting for external documents, the object enters dormancy with a typed wake trigger expressing the condition: arrival of a specific document class, expiration of a regulatory deadline, or receipt of an explicit human approval. The object consumes no compute while dormant, but its full state remains addressable. When the trigger fires, the object resumes, evaluates the new input against its policy constraints, records the resulting state transition into its memory, and either advances or re-enters dormancy. The substrate provides persistence and trigger delivery; it does not interpret workflow semantics.

Determinism is preserved because every state transition is recorded with the inputs that produced it, the policy version under which it was evaluated, and the actor attribution of any human or system that participated. Replay produces identical results because the inputs and policy are bound to the history. Version drift is handled structurally: the object's policy version is one of its fields, and the substrate routes every operation through the version active at the object's birth unless an explicit migration is invoked, in which case the migration itself is recorded.

Sub-workflow delegation is recursive. A parent compliance review spawns child document-collection workflows as memory-resident sub-objects, each with its own dormancy, its own audit history, and its own policy version, but lineage-linked to the parent. The lineage is traversable as a structural query rather than reconstructed from join keys. BPMN definitions become the executable artifact rather than design-time documentation, AsyncAPI channels are bound to the object's typed I/O surface, and WS-Reliability semantics hold because the object itself is the durable endpoint.

Compliance Mapping

The mapping from memory-resident workflow objects to the regulatory framework is direct. ISO 9001 requirements for documented information control are satisfied because every artifact, decision, and approval is bound into the workflow object's append-only memory and is retrievable by object identity. ISO/IEC 25010 reliability sub-characteristics map to substrate properties: maturity to the substrate's verified persistence semantics, availability to the substrate's redundancy guarantees, fault tolerance to the object's deterministic recovery from any persisted state, and recoverability to the structural property that the object's memory is its sole source of truth.

FDA 21 CFR Part 11 audit-trail requirements are satisfied as a structural property: the time-stamped, attributed, tamper-evident record is not a side-effect of logging but the object's intrinsic memory. Section 11.10(e) retention obligations map to the substrate's retention policy on the object, not on a separate logging pipeline. SR 11-7 effective-challenge requirements are satisfied because each model invocation embedded in the workflow records its inputs, version, outputs, and post-hoc outcome observation as lineage entries, producing the continuous monitoring the supervisory letter demands.

GDPR Article 30 records of processing activities map directly: every step in the workflow object is a recorded processing activity, with purpose, categories, recipients, and retention bound into the object's memory. Article 17 erasure becomes a structural operation on a single object identity rather than a forensic sweep across the stack. Article 20 portability is the export of the object's typed fields. BPMN 2.0 process definitions become the workflow object's executable schema, AsyncAPI channels become its typed interfaces, and OASIS WS-Reliability delivery guarantees hold end-to-end because the object is the addressable durable endpoint that the standard contemplates.

Adoption Pathway

Adoption proceeds incrementally rather than as a forklift replacement. The first stage replaces the orchestrator only for new workflow categories, deploying memory-resident workflow objects on a substrate that exposes BPMN-conformant definitions, AsyncAPI-conformant channels, and Part 11-conformant audit retrieval. Existing orchestrated workflows continue unchanged. Compliance teams validate the new substrate against ISO 9001, Part 11, and Article 30 requirements using the same evidence packages they would prepare for any production system, with the advantage that the audit trail is intrinsic and therefore reduces evidence-collection cost.

The second stage migrates high-volume, long-duration workflow categories where the orchestration tier is the operational bottleneck or the regulatory failure domain. Insurance claims, healthcare treatment plans, regulatory submissions, and quality-management non-conformance workflows are typical first migrations because their durations exceed the comfortable replay horizon of event-sourced engines. Migration is performed as a parallel run in which new instances launch on the memory-resident substrate while existing instances complete on the legacy orchestrator, eliminating cutover risk.

The third stage retires the orchestration tier itself once the remaining workflow population is small enough to migrate or sunset. At this point the substrate is the durable execution environment for the enterprise, and procedural compliance work shifts from per-system evidence assembly to substrate-level certification. SR 11-7 model-risk reviews, Part 11 audit-trail attestations, and Article 30 processing inventories are produced by querying the substrate, not by orchestrating the surrounding stack. The architectural commitment is that durability, auditability, and governance become structural properties of the workflow object rather than emergent properties of the operational environment.