Table of Contents

Workflow Engines, Human Approval Systems, and Governed Execution

Christopher D. Cavell
Published

Pattern classification: Alternative Pattern

Difficulty: Intermediate

Prerequisites: Recommended — Acknowledgment and Audit Residue and Scoped Capability and Host-Owned Execution. Human-in-the-Loop Governance Workflows is useful follow-on reading for a deeper review lifecycle.

Terminology note: This comparison uses workflow engine, human approval, governance decision, scoped authority, and host-owned execution as architectural terms. Products differ widely. A workflow product may include authorization, rules, approvals, policy evaluation, audit history, or task assignment. The comparison is about responsibilities and trust boundaries rather than product categories or vendor features.

Workflow engines and governed-execution pipelines can look remarkably similar from a distance.

Both may:

  • Pause.
  • Resume.
  • Retry.
  • Wait for an external event.
  • Route to a human.
  • Record history.
  • Escalate.
  • Continue only after some condition is satisfied.

That similarity can lead to a false architectural choice:

Do I need a workflow engine or a governance layer?

Often, that is not the right question.

A better decomposition is:

Workflow engine
=
What step happens next?

Policy / governance
=
May this action happen under these constraints?

Human approval
=
Has an authorized reviewer approved this action?

Execution boundary
=
Does valid authority exist to perform the side effect now?

These questions may be answered by different components.

They may also be answered inside one platform when that platform already expresses the required semantics clearly.

The architectural goal is not to maximize layers.

It is to keep state, decision, human disposition, and execution authority distinct wherever the requirements depend on those distinctions.

Quick Orientation

Concern Primary question Typical responsibilities What it does not prove automatically
Workflow orchestration What happens next? Durable state, sequencing, retries, timers, compensation, external events, long-running process coordination That the next action is currently permitted by authoritative policy
Human approval Has an eligible person approved or rejected this exact request? Reviewer assignment, approval/rejection, separation of duties, approval history, escalation, expiration That policy still allows the action or that the executor has narrow execution authority
Governed execution May this intent proceed under current constraints? Authoritative context, explicit outcomes, policy identity, reason codes, provenance, acknowledgment/escalation semantics That the workflow has durable scheduling, retry, task-routing, or compensation machinery
Execution authority May this executor perform this side effect now? Scope, audience, resource, operation, lifetime, use count, freshness, boundary validation That the workflow reached the right business state or that a human approved the request

This table is not a product comparison.

A mature workflow platform may implement several rows.

The important question is whether the system can still answer which responsibility produced which evidence and authority.

A practical starting rule is:

Use workflow plus ordinary authorization when the process only needs durable coordination inside one trust boundary. Add separate governance when independently owned or changing policy must be evaluated as its own decision. Add scoped execution authority when a later or different executor should receive less authority than the requester or workflow engine holds.

What Breaks When the Boundaries Collapse

The separation matters because several production failures otherwise look deceptively valid:

Workflow state = Approved
Artifact revision changed after review
        ↓
Old approval is replayed against a different proposal

Retry fires after regional policy changed
        ↓
Old permission is treated as current authorization

Workflow state = ReadyToExecute
Current policy = Denied
        ↓
Executor runs because process readiness was mistaken for authority

These are different failures, but they share one cause: evidence from one boundary is treated as proof of another.

Why the Boundaries Overlap

Long-running processes naturally accumulate several kinds of control. A production deployment workflow may wait for a change window, request approval, deploy, verify, and roll back. The workflow engine can coordinate all of those steps and preserve process state.

The same deployment may still require answers that are not merely process position:

Is this release still permitted by current production policy?
Is the change window still open?
Is the reviewer eligible for this environment?
Did the artifact digest change after approval?
What exact authority may the deployment worker exercise?

Those questions may be expressed inside the workflow platform or delegated to another policy component. Physical separation is optional; semantic clarity is not.

1. Workflow Orchestration

A workflow engine is primarily concerned with durable process progression.

A representative model is:

Workflow instance
   ↓
Current state
   ↓
Transition condition
   ↓
Next activity
   ↓
Persist state
   ↓
Wait / retry / continue

Typical concerns include:

  • Durable workflow state.
  • Sequencing.
  • Timers and deadlines.
  • Retries and backoff.
  • Compensation.
  • Long-running processes.
  • External events.
  • Human tasks.
  • Correlation across asynchronous work.
  • Resume after process or host failure.

These are substantial architectural responsibilities.

Workflow State Is About Process Position

A workflow state such as:

AwaitingManagerApproval

usually answers:

Where is this process in its lifecycle?

A state such as:

Approved

may answer:

Which business transition has occurred?

Neither label necessarily tells a later executor:

Which exact side effect may I perform now, against which resource, under which still-current constraints?

A workflow may encode that information, but the state name alone does not establish it.

Retries Are Not Policy Revalidation

Suppose a workflow activity failed because a downstream API was unavailable.

The engine may correctly retry:

Attempt 1 -> timeout
Wait 30 seconds
Attempt 2 -> retry

But the retry mechanism does not automatically mean:

The policy decision made 20 minutes ago is still fresh.
The approval is still valid.
The caller still has authority.
The resource has not changed.

A retry policy answers when to try again.

A governance freshness rule answers whether execution is still permitted when the retry occurs.

Those may be the same check in a simple workflow.

They should not be assumed equivalent merely because they execute in the same activity.

Compensation Is Not Undoing Governance

Workflow engines often model compensation for distributed or long-running work.

For example:

Reserve inventory
   ↓
Charge payment
   ↓
Shipping fails
   ↓
Refund payment
   ↓
Release inventory

Compensation is an operational recovery model.

It does not erase the historical fact that an earlier decision or side effect occurred.

Decision evidence may still need to preserve:

Why the original action was allowed
Which policy applied
Which approval existed
Which action executed
Which compensation later ran

Operational reversal and historical provenance are different concerns.

2. Human Approval Systems

A human approval system introduces a person into the lifecycle.

A representative path is:

Request
   ↓
Assign reviewer
   ↓
Reviewer evaluates
   ↓
Approve / reject
   ↓
Record disposition
   ↓
Continue or terminate

Typical concerns include:

  • Reviewer assignment.
  • Approval and rejection.
  • Separation of duties.
  • Approval history.
  • Escalation.
  • Delegation.
  • Expiration.
  • Quorum or multi-reviewer rules.
  • Reviewer eligibility.
  • Human rationale.

These capabilities may be built into a workflow platform, implemented by an application, or provided by a specialized approval system.

Approval Is a Human Disposition

The repository's Human-in-the-Loop Governance Workflows material distinguishes acknowledgment, approval, override, and execution authority.

That distinction matters here.

A human approval can establish:

Eligible reviewer R
approved exact request X
at time T
for reason Y

It does not automatically establish:

All current policy constraints are satisfied.

or:

The deployment worker may now execute any deployment operation.

The domain may deliberately define approval as the governing decision.

That can be perfectly valid.

But that should be an explicit rule, not an accidental side effect of a button named Approve.

Approval Can Expire or Become Stale

A workflow may retain an approval forever unless configured otherwise.

The domain may require something narrower:

Approved artifact digest = abc123
Approved environment = production
Approved until = 15:00 UTC

If the artifact becomes def456, the old approval may no longer apply.

If the execution occurs after 15:00 UTC, the approval may need refresh.

If a policy freeze begins, a still-recorded approval may no longer be enough.

The workflow history remains true:

Reviewer approved at 14:10 UTC.

The execution decision may still be:

Denied at 15:05 UTC because the approval expired.

Both records can be correct.

3. Governed Execution

Governed execution focuses on the transition from proposed intent to permitted side effect.

The Learning model is:

Intent
   ↓
Authoritative context
   ↓
Policy / constraints
   ↓
Explicit decision
   ↓
Acknowledgment / escalation / human review when required
   ↓
Scoped authority when required
   ↓
Host-owned execution
   ↓
Decision and execution evidence

Typical concerns include:

  • Authoritative policy context.
  • Explicit decision semantics.
  • Policy identity and version.
  • Reason codes.
  • Scoped authority.
  • Host-owned execution.
  • Decision provenance.
  • Revalidation after delay.
  • Distinct acknowledgment and escalation states.

Governed execution is therefore not primarily a scheduling system.

It does not need to know how to implement durable timers, distributed retries, compensation graphs, or reviewer inboxes unless the application chooses to make it responsible for those things.

Policy Decision Is About Permission, Not Progress

A governance result might be:

Allowed
Denied
Deferred
AcknowledgmentRequired
EscalationRecommended

Those outcomes answer:

What may happen under the evaluated constraints?

They are not necessarily workflow states.

For example:

Workflow state = AwaitingExternalWindow
Governance result = Deferred

may coexist.

Later:

Workflow state = ReadyToDeploy
Governance result = Allowed

The workflow tracks progression.

The policy decision tracks permission.

The two can be mapped together when that simplifies the system, but they are not semantically identical.

4. The Execution Boundary

The final side effect belongs to a host or executor.

That component may be:

  • A background worker.
  • A deployment runner.
  • A payment service.
  • An infrastructure controller.
  • A data-export worker.
  • A device gateway.
  • A local application service.

The execution boundary asks:

What authority is acceptable here, for this exact operation, at this exact time?

For a simple system, the answer may be ordinary authenticated caller authority.

For a delayed or higher-consequence system, the answer may be a narrowly scoped continuation artifact.

For example, a teaching payload might carry only the authority needed for one export:

{
  "authorityId": "cap-789",
  "operation": "data.export",
  "resource": "dataset-2026-08",
  "destination": "partner-123",
  "intentFingerprint": "sha256:abc123...",
  "audience": "export-worker",
  "expiresAt": "2026-08-24T15:00:00Z",
  "maxUses": 1
}

The exact token or capability format is implementation-specific. The architectural point is that the later executor receives bounded continuation authority, not the requester's standing permissions and not a free-floating Approved = true.

A useful shape is:

Workflow says: step may run
        +
Human record says: reviewer approved
        +
Policy says: currently allowed
        +
Execution authority says: this executor may perform this exact side effect
        ↓
Host executes

Not every system needs all four conditions.

The value is in knowing which ones the use case actually requires.

Preserve Four Important Distinctions

Four distinctions should remain visible even when one product implements several of them:

Distinction First concept means Second concept means Why the difference matters
Acknowledgment vs. authorization An identified actor accepted a warning or condition The actor may perform or request the operation Acknowledging risk does not create permission
Approval vs. capability An eligible reviewer approved an exact proposal A bounded executor may perform an exact side effect A review disposition can justify authority without becoming the authority
Workflow state vs. policy decision Where the process is in its lifecycle What the process may do under current constraints ReadyToExecute can coexist with a current Denied result
Decision evidence vs. workflow history Why a policy outcome was produced What operational steps, retries, timers, and tasks occurred Process history does not automatically reconstruct policy identity, reasons, or execution scope

The records can be correlated and even stored together. The requirement is to avoid treating evidence from one meaning as proof of another.

Scenario 1: Workflow Engine Plus Ordinary Authorization Is Sufficient

Consider an employee onboarding process:

Create employee record
   ↓
Wait for HR data completion
   ↓
Create standard mailbox
   ↓
Assign baseline groups
   ↓
Schedule orientation

Assume:

  • Only authenticated HR staff may start the workflow.
  • Standard onboarding templates define the allowed baseline groups.
  • All actions are routine and reversible.
  • No exceptional privileges are granted.
  • No separate legal or regional policy evaluation is required.
  • Each activity uses ordinary service authorization.
  • The workflow engine already provides durable state, retry, timeout, and history.

A reasonable architecture is:

HR user
   ↓
Ordinary authorization
   ↓
Workflow engine
   ↓
Authorized application/service activities

A separate governance-decision service, capability issuer, acknowledgment ledger, and policy-provenance store would add substantial ceremony without protecting a meaningful additional boundary.

The workflow engine plus normal authorization is enough.

Durability alone does not justify a separate governance layer.

Scenario 2: Human Approval Is the Governing Decision

Consider publication of a routine internal policy announcement.

Requirements:

  • The author submits the exact draft.
  • One eligible communications manager must approve it.
  • Approval is bound to the draft revision.
  • Any draft edit after approval invalidates that approval.
  • Rejection stops publication.
  • No separate risk model, legal hold, regional rule set, or post-approval capability is required.
  • The same application publishes immediately after valid approval.

The domain may legitimately define:

Eligible reviewer approval of exact revision
=
Governing decision to publish

The workflow can model:

Draft
   ↓
AwaitingApproval
   ↓
Approved
   ↓
Publish

Here, adding another component that independently returns Allowed after merely checking that approval exists could duplicate the exact rule already expressed by the approval workflow.

The architecture should still preserve:

  • Reviewer identity.
  • Reviewer eligibility.
  • Exact revision identity.
  • Approval timestamp.
  • Rejection behavior.
  • Expiration if the domain requires it.

But approval itself can be the policy rule when the business requirement genuinely says so.

Scenario 3: Approval, Policy, and Execution Authority Remain Separate

Consider a high-consequence export of restricted customer data to an external partner.

Requirements:

  • A business owner may request the export.
  • A data steward must approve the exact dataset and destination.
  • Regional policy must permit the destination.
  • Current classification must allow export.
  • A legal hold can appear after approval.
  • The export runs later in a background worker.
  • The worker must not inherit the requester's broad standing permissions.
  • Export authority should apply to one dataset, one destination, one operation, and a short time window.
  • Duplicate execution must be controlled.
  • The organization must reconstruct the decision afterward.

A useful architecture is:

Export request
   ↓
Workflow instance
   ↓
Human steward review
   ↓
Approval disposition
   ↓
Rebuild authoritative policy context
   ↓
Governance evaluation
   ├── Denied  → terminate / return to review
   └── Allowed → issue narrow export authority
                    ↓
             Background export worker
                    ↓
        Validate authority + current conditions
                    ↓
               Perform export
                    ↓
      Workflow history + decision / execution evidence

The workflow engine owns:

  • Durable progression.
  • Human task lifecycle.
  • Waiting and retries.
  • Completion state.

The human approval system establishes:

  • Eligible reviewer disposition.
  • Exact reviewed intent.

The governance layer establishes:

  • Current policy outcome.
  • Policy identity and reason codes.
  • Whether the stale or changed context still permits export.

The execution boundary establishes:

  • Whether the worker currently holds acceptable, narrow authority.

This separation earns its complexity because the requirements depend on it.

Scenario 4: A Separate Governance Layer Would Duplicate the Workflow Engine

Now consider a workflow platform that already models a purchase request under a fixed internal rule set.

Its workflow definition already provides:

Requester identity
Department budget owner
Purchase amount
Cost center
Approval threshold
Reviewer eligibility
Separation of duties
Approval expiration
Reason codes
Versioned workflow definition
Durable history
Execution activity owned by the same trusted application

The rule is straightforward:

Amount <= $5,000
   ↓
One eligible budget-owner approval
   ↓
Create purchase order

Suppose a proposed governance service would do only this:

Read workflow state = Approved
Read amount <= $5,000
Return Allowed

and then pass control back to the same application.

That extra layer has not introduced a new trust boundary, new authoritative context, new policy owner, new execution-authority model, or new provenance requirement.

It has restated the workflow rule in another place.

The likely costs are:

  • Duplicate policy definitions.
  • Drift between workflow and governance rules.
  • More deployment coordination.
  • More failure modes.
  • Harder debugging.
  • Ambiguous ownership when the two disagree.

In this case, the better design is likely:

Treat the workflow definition as the policy-bearing implementation for this use case rather than creating a second governance layer that mirrors it.

Governance is a responsibility, not a requirement to deploy a separate service.

Scenario 5: AI-Originated Action Requires Acknowledgment, Policy, and Scoped Authority

Consider an AI operations assistant that analyzes production telemetry and proposes restarting a degraded service.

Requirements:

  • The AI may propose the restart but cannot perform it directly.
  • An authenticated operator must acknowledge the expected availability impact.
  • Current production policy must still permit the restart for that service, environment, and incident state.
  • The relevant change window or incident exception may change after the AI creates the proposal.
  • A host-owned operations worker performs the restart.
  • The worker should receive authority only for one service, one environment, one operation, and a short lifetime.
  • The system must preserve the AI proposal, acknowledgment, policy decision, authority issuance, and execution result as correlated but distinct evidence.

A useful flow is:

AI proposes: restart service payments-api in production
        ↓
Workflow records proposal and waits
        ↓
Operator acknowledges expected impact
        ↓
Rebuild authoritative service + incident context
        ↓
Governance evaluation
   ├── Denied  → no authority; no restart
   └── Allowed → issue narrow service.restart authority
                    ↓
             Host-owned operations worker
                    ↓
           Validate scope + freshness
                    ↓
                Restart service

The boundaries remain explicit:

AI proposal
≠
Human acknowledgment
≠
Policy decision
≠
Execution authority

The acknowledgment means the operator accepted a defined consequence or condition. It does not make a disallowed restart permissible.

The governance decision determines whether the proposed restart may proceed under current authoritative constraints. It does not itself perform the restart.

The scoped authority gives the operations worker only the continuation permission required for the exact side effect. It does not give the AI standing production credentials or general control of the environment.

This is the same separation used elsewhere in the article, with one additional source-of-intent rule:

An AI-originated proposal should enter the workflow as proposed intent, not arrive at the execution boundary as inherited authority.

A workflow engine may still own the waiting, acknowledgment task, timeout, retry, and correlation behavior. A policy component may still be separate or embedded in that platform. The important property is that AI authorship of the proposal does not collapse workflow state, human acknowledgment, current policy, and execution authority into one implicit permission.

For a fuller treatment of AI tool mediation, continue with Governed AI Tool Gateway.

When a Workflow Engine Can Carry Governance Responsibilities

Scenario 4 generalizes to a simple rule:

A workflow engine can carry governance semantics when it already owns the authoritative facts, policy identity, decision outcomes, reviewer rules, revalidation or expiration behavior, evidence, and execution handoff the domain requires.

The deciding question is not where the rule runs, but whether the implementation can explain and enforce those semantics without copying policy from another authority. If the engine would need to duplicate independently owned policy, rely on stale workflow state, or treat Approved as broad execution permission, workflow should coordinate the process while policy or authority remains a separate semantic boundary.

When Separate Policy Evaluation Earns Its Place

A separate governance or policy boundary becomes more useful when the responsibility itself is separate, for example when:

  • Several workflows share one policy. Customer, partner, support, API, scheduled-job, and AI-tool paths may all depend on the same regional or organizational constraint.
  • Policy ownership differs from workflow ownership. Security, legal, safety, or regional teams may own rules that workflow authors should not redefine independently.
  • Policy changes faster than workflow definitions. A rule may need immediate update without redesigning every process.
  • Authoritative context must be rebuilt at decision time. Classification, legal hold, tenant state, risk, region, or emergency status may make stored workflow facts stale.
  • Decision provenance has independent value. The organization may need to reconstruct why an action was allowed even if the workflow platform changes.
  • Execution crosses a trust boundary. A later worker, gateway, or external system may need narrow authority rather than a generic statement that the workflow reached Approved.

These are signals, not automatic mandates. A workflow platform that already owns and enforces these semantics can remain the policy-bearing boundary.

Approval Should Be Bound to an Exact Proposal

A common failure mode is treating approval as a free-floating boolean:

Approved = true

A stronger model binds approval to the material request:

Operation
Resource
Destination
Amount / quantity
Revision / digest
Requester
Relevant scope
Expiration

Then the workflow can detect meaningful drift:

Approved proposal fingerprint = A
Current proposal fingerprint = B
        ↓
Approval no longer applies

This matters whether approval is implemented inside a workflow engine or a separate review service.

The architectural principle is independent of tooling.

Delays Create Freshness Questions

Workflow engines make delay normal.

Governance must decide what survives that delay.

For example:

10:00  Request submitted
10:05  Human approved
11:00  Policy changed
12:00  Timer fired
12:01  Worker attempts execution

Possible strategies include:

Re-evaluate at execution time

Approval exists
   ↓
Rebuild current context
   ↓
Re-evaluate current policy
   ↓
Execute only if still allowed

Issue time-bounded authority after approval

Approval + policy allow
   ↓
Capability valid for 10 minutes

If execution occurs later, a new decision is required.

Pin a decision where the domain explicitly permits it

Some business processes intentionally treat an approval under policy version v7 as valid for the lifetime of a transaction.

That can be legitimate, but the choice should be explicit and auditable.

See Policy Versioning and Decision Provenance for the broader policy-drift problem.

Workflow History and Decision Provenance Can Be Linked

Keeping them distinct does not mean keeping them disconnected.

A useful correlation model can preserve references such as:

WorkflowInstanceId = wf-123
ReviewId = review-456
DecisionId = decision-789
CapabilityId = cap-321
ExecutionId = exec-654
CorrelationId = corr-999

Then an operator can reconstruct:

Workflow history
   ↕
Human review history
   ↕
Governance decision evidence
   ↕
Execution evidence

The records can live in one database or several systems.

The architectural value comes from preserving their semantics and correlations.

What About Escalation?

Workflow escalation and governance escalation can use the same machinery while preserving different meanings:

Workflow routing: reviewer timed out -> route task to manager
Governance outcome: EscalationRecommended -> specialist judgment is required

A clean composition is:

Governance outcome = EscalationRecommended
        ↓
Workflow transition = Create specialist review task

The decision explains why escalation is required; the workflow explains how it proceeds. See Escalation Patterns in Governed Systems.

What About Acknowledgment?

A workflow engine can persist an acknowledgment task without making acknowledgment equivalent to approval or authorization:

Show warning -> wait for actor acknowledgment -> continue

The record should remain bound to the actor, exact condition, relevant intent, and applicable decision context. Afterward, the host may still need current policy evaluation or narrow continuation authority. See Acknowledgment and Audit Residue.

A Composition Pattern

A higher-consequence system can compose the concerns without forcing one component to own everything.

Workflow engine
   │
   ├── owns durable process state
   ├── schedules activities
   ├── waits for external events
   └── routes human tasks
   │
   ▼
Governance evaluation
   │
   ├── rebuilds authoritative context
   ├── evaluates current constraints
   ├── returns explicit outcome
   └── records policy identity + reasons
   │
   ▼
Workflow transition
   │
   ├── Denied -> terminate / remediation
   ├── Deferred -> wait / retry later
   ├── AcknowledgmentRequired -> create acknowledgment task
   ├── EscalationRecommended -> route review
   └── Allowed -> continue
   │
   ▼
Scoped authority when needed
   │
   ▼
Host-owned executor

The workflow engine remains the orchestrator.

The governance component remains the policy decision boundary.

The executor remains the side-effect owner.

This is composition, not duplication, because each boundary has an independent responsibility.

Avoid These Failure Modes

Treating Approved as Universal Authority

Workflow state = Approved
        ↓
Any downstream action may execute

This is too broad when the approval applies only to one exact proposal.

Treating Retry as Permission Refresh

Activity retrying
        ↓
Therefore old decision is still valid

Retry timing and policy freshness are separate questions.

Treating Workflow History as Complete Decision Evidence

Task completed successfully

may not explain which policy, constraint, or reason allowed the operation.

Reimplementing Workflow Semantics in a Governance Service

Workflow says Approved
Governance service says Allowed because workflow says Approved

with no additional context or boundary can create duplication rather than protection.

Reimplementing Governance Semantics in Every Workflow

The opposite failure also occurs:

Workflow A has its own legal-hold interpretation
Workflow B has another
Workflow C has a third

A shared policy boundary may be justified when the constraint is genuinely shared and independently owned.

Letting a Human Bypass Non-Overridable Rules

Human approval should not automatically convert every denial into allow.

Some constraints may deliberately remain non-overridable.

Decision Guide

Use the smallest architecture that expresses the real requirements.

Requirement Workflow engine only / ordinary authorization Human approval workflow Separate governance evaluation Scoped execution authority
Durable sequencing Strong fit Often included Not its primary role No
Retries / timers Strong fit Often included No No
Human task assignment Often included Strong fit Strong fit as a review trigger; weak fit for task assignment No
Exact reviewer disposition Optional Strong fit Consumes as evidence No
Shared authoritative policy across workflows Weak fit if rules must be copied Weak fit unless approval is the policy Strong fit No
Explicit Allowed / Denied / Deferred / AcknowledgmentRequired / EscalationRecommended semantics Fit only if modeled explicitly Weak fit by itself Strong fit No
Policy identity and reason codes Fit if persisted deliberately Weak fit by itself Strong fit No
Execution later in another trust domain Coordinates it May precede it Often useful Strong fit
Narrow operation/resource/time authority Weak fit unless the engine issues a bounded grant Not implied by approval May issue or authorize issuance Strong fit
Durable process history Strong fit Strong fit Decision history only Consumption/execution history only

No column is universally required.

The design should follow the lifecycle and trust boundary of the operation.

Testing the Boundaries

Tests should verify the distinctions the architecture claims to preserve.

Workflow Invariants

Timer fires once or idempotently
Retry policy follows configured limits
Cancelled workflow does not continue
Completed human task does not re-open silently

Human Review Invariants

Ineligible reviewer cannot approve
Self-approval is blocked where separation of duties applies
Approval binds the exact intent/revision
Expired approval does not satisfy current review requirements

Governance Invariants

Decision uses authoritative context
Policy identity is recorded
Reason codes match the outcome
Unavailable policy dependencies follow explicit degraded-mode behavior
Changed context can trigger re-evaluation

Execution Invariants

No valid authority -> executor invocation count = 0
Wrong resource scope -> executor invocation count = 0
Expired authority -> executor invocation count = 0
Replay beyond allowed use -> executor invocation count = 0
Valid authority -> only the bounded operation can execute

These tests can exist even if all responsibilities are implemented in one application.

Architectural separation is about semantics first, deployment topology second.

A Practical Rule of Thumb

Use the smallest architecture that preserves the lifecycle distinctions the requirements actually depend on. Workflow owns durable progression; human review owns a bound disposition; governance owns current policy semantics when those semantics are independently meaningful; and the execution boundary owns the authority required for the side effect.

Do not add a layer merely because the diagram looks more sophisticated with it.

A separate governance layer is justified by a separate governance responsibility, not by the presence of a workflow engine.

Key Takeaways

  1. Workflow orchestration answers what happens next; governance answers whether the action may happen under current constraints. The concerns can coexist in one product without becoming the same semantic responsibility.
  2. Human approval is a bound disposition, not automatically authorization or capability. Approval may be the governing rule in simple domains, but higher-consequence systems may still require current policy evaluation and narrow execution authority.
  3. Process readiness is not execution authority. ReadyToExecute can coexist with a current Denied result, and a later executor should validate the authority that is actually acceptable at its boundary.
  4. Workflow history and decision provenance answer different reconstruction questions. Correlate them rather than assuming operational history proves why an action was permitted.
  5. Use the smallest architecture that preserves the distinctions your requirements depend on. A workflow engine can carry governance when it truly owns the semantics; separate governance earns its place only when the responsibility is genuinely separate.

Read it. Run it. Question it. Improve it.

Edit this page