← Back to directory

idy-007c-contract.md

implementation/idy-007c-contract.md · 43.4 KB · 2026-11-02 12:48

IDY-007C Workflow Execution Contract

Contract identifier: IDY-007C-EXECUTION-V1

Version: 1.0

Status: FROZEN / APPROVED FOR IMPLEMENTATION; the recovery/reconciliation extension is implemented and locally verified, while the remaining authenticated-STAGING scenarios are explicitly tracked as unverified.

Owner: bounded workflow execution implementation contract.

Authority: This record is governed by the canonical workflow, identity/governance, time/events, semantics, implementation architecture and development documents. implementation-plan.md section 13 is planning source material, not this implementation contract. Frozen IDY-007A/007B contracts and implementation boundaries remain prerequisites. This record does not create a new D-number.

Implementation gate: `007C contract explicitly approved and frozen -> only then AGENT implementation may begin. The recovery/reconciliation extension authorizes only the bounded runtime scope stated below; its specification is not evidence of implementation.

Current implementation evidence (2026-09-18): The approved lease-bound finalization boundary is implemented through the Business-owned workflow_dispatch Operation, OperationInvocationService, CommandHandler, the generic conditional resource-claim predicate and the fixed dispatch participant. The focused IDY-007 regression suite passed with 58 tests / 231 assertions, including all five finalization targets. This evidence does not claim wake processing, expired-lease reclamation, retry/replay or a general recovery engine.

Recovery implementation evidence (2026-10-14): The bounded workflow_reconcile Operation, expired-lease quarantine participation, safe-resume evidence gate, known-Command reconciliation delegation and synchronous runner classification are present in source. The focused recovery gap regressions passed, including a legitimate second local Principal, negative safe-resume evidence and missing Command linkage cases. The complete isolated PHPUnit suite passed with 492 tests / 2,982 assertions. These checks use local IDY_TEST_IDY002; STAGING is only used as a read-only snapshot source. Direct STAGING evidence covers expired quarantine, explicit failure, stale revision rejection and ineligible recovery rejection. Same-Command browser replay, direct stale-token submission, unauthorized-Principal live denial, safe-resume live execution and uncertain-Command live reconciliation remain unverified because no safe authenticated candidate was available.

> Terminology supersession, 2026-11-02: "Principal" in this contract is superseded terminology for User. Principal is not a current architectural concept. Identifiers such as principal_id are legacy implementation details retained until a separately authorized migration (PRR-061). Contract semantics are otherwise unchanged, except that any statement treating automation or an integration as an independent identity or authority subject is superseded: automation operates under authority delegated by a User, with the technical executor recorded as execution provenance (see identity and governance).

Purpose and Invariants

IDY-007C consumes the committed eligible WorkflowExecution produced by frozen IDY-007B and performs bounded, sequential workflow interpretation for the pinned Workflow Definition object and exact revision. It persists inspectable node attempts, outcomes, current execution state, lease/recovery data and required Command/provenance links. Node resolution is WorkflowExecution -> pinned Workflow Definition revision -> exact node binding -> exact Workflow Node revision; current Node state is never consulted independently.

Authoritative data is the generic object/revision model: WorkflowExecution, Workflow Definition revisions, step-attempt objects, Outcome/Decision/Command/ActionExecution/Attempt/Provenance objects, Event objects and required history. workflow_dispatch is derived coordination metadata for discovery, claim, lease, fencing and bounded dispatch; it never overrides generic objects or grants authority.

The runtime is deterministic and useful without AI. All consequential mutations use the existing CommandHandler. The interpreter never performs direct repository CRUD, treats Event connectivity or lease ownership as authority, trusts client-selected Principal/Business/Policy/grant values, or executes arbitrary code. Frozen 007B admission identity, Event Type identity, Workflow Definition grammar, WorkflowExecution identity, migration 0007, Genesis, authentication and relationship semantics remain unchanged.

The supported node kinds are exactly condition, wait_for_event, request_approval, local_command and end. Unsupported kinds or continuations are refused into an inspectable suspended state. A dispatcher pass processes at most 100 node steps. Parallelism, recurrence, external effects and unknown-effect automatic retries are excluded.

WorkflowExecution Lifecycle

WorkflowExecution states are exactly:

Allowed transitions:

| From | To | Initiating condition and durable requirements | |---|---|---| | eligible | running | Atomic claim assigns fresh lease token, technical worker identity and expiry; current execution remains pinned. | | eligible | cancelled | Authorized Command cancellation wins before claim; cancellation evidence and status commit coherently. | | running | running | Fenced renewal or a committed node transition continues under the same valid lease token. | | running | waiting | Wait/approval node commits its step attempt, correlation/dependency data and wait registration, then releases the lease. | | running | eligible | Safe pass continuation under the current valid lease through release(); expired executions are not made eligible by Stage 2. | | running | succeeded | end success and terminal evidence commit under the valid lease. | | running | failed | Deterministic terminal failure and evidence commit under the valid lease. | | running | suspended | Cycle, unsupported continuation, exhausted bound, changed dependency, or unknown condition is durably explained. | | running | reconciliation_required | Command/Attempt outcome cannot be classified conclusively. | | waiting | eligible | Exact matching Event, Decision, or configured one-time UTC wake is durably recorded; waiter is re-eligible, not directly executed. | | waiting | cancelled | Authorized cancellation commits before the next local Action. | | waiting | suspended | Configuration/dependency invalidation or unsupported wait continuation requires review. | | succeeded, failed, cancelled | none | Terminal states cannot be silently resumed or rewritten. | | suspended | none in the current implementation | Review state cannot be silently resumed. A future governed recovery operation may add an explicit continuation only after current dependencies and evidence are rechecked. | | reconciliation_required | none in the current implementation | Unknown/reconciliation state cannot be silently resumed. A future governed recovery operation may add an explicit terminal or safe continuation decision under the rules below. |

Every transition is serialized by the durable coordination boundary and fenced by the current lease token where a lease exists. Generic object revisions, step-attempt evidence and dispatch metadata commit coherently. An expired worker cannot commit a state transition.

Dispatch Lifecycle

workflow_dispatch.dispatch_state has the exact vocabulary:

Dispatch state is coordination metadata, not an independent semantic state machine. A dispatch row must agree with the authoritative WorkflowExecution state, except during one transaction's locked transition. Terminal rows are retained for inspection and duplicate/recovery checks; they are not deleted to signal completion.

Allowed dispatch transitions mirror the execution transitions: eligible -> claimed|cancelled; claimed -> claimed|eligible|waiting|succeeded|failed|suspended|reconciliation_required; waiting -> eligible|cancelled|suspended; terminal/reconciliation states do not silently return to dispatchable states. A matching wake changes waiting -> eligible only after the wait evidence and execution revision commit. The current implementation has no wake processor and no recovery transition from an expired claimed row; those are specified future capabilities, not existing behavior.

The frozen 007B eligible dispatch row remains valid. Any additional columns/states require a new forward migration after 0007; migration 0007 is immutable.

Lease

Each claim assigns:

Claim, renewal, release and every node/state update occur in transactions and include the current lease token and execution identity in their predicates. A renewal is permitted only before expiry and only for the current token/worker. A stale, expired or changed token receives no authority to update and must not be treated as a successful step.

Lease ownership is not business authority. The worker uses the configured Workflow Principal/Business context and rechecks current authority, Policy, dependency versions and required object visibility at the node boundary. Lease transfer is not an in-place token handoff: expiry fences the old token. Stage 2 does not provide a new claim for an expired execution; any future claim after expired-state recovery requires a separately governed capability and a fresh token.

Before lease release or a terminal commit, all required execution, step-attempt, outcome, Command/Attempt linkage, error and dispatch evidence must be durable. A process crash leaves the lease to expire; Stage 2 preserves durable execution and Command/Attempt evidence for inspection and authorized reconciliation but does not make the expired WorkflowExecution eligible or clear its expired lease. Any future re-eligibility requires a separately governed recovery capability. Unknown external work is never automatically resent.

Fenced Execution Finalization

Stage 1 provides one additional narrowly scoped lease-bound operation:

finalizeLeasedExecution(execution_id, dispatch_id, worker_id, lease_token, target_state)

Its permitted target states are exactly:

This operation is a fenced execution finalization capability. It is not a general WorkflowExecution state mutation mechanism and does not replace or generalize release().

The operation must acquire the existing coordination lock using the established lock ordering, then verify transactionally:

1. the WorkflowExecution exists; 2. the dispatch row exists; 3. execution and dispatch identities match; 4. dispatch state is claimed; 5. authoritative WorkflowExecution state is running; 6. the exact lease token matches; 7. the exact worker identity matches; 8. the lease is unexpired; 9. Business identities are consistent; 10. the expected current WorkflowExecution revision is current; 11. current authorization requirements are satisfied; 12. the target state is in the permitted set.

On success, one finalization transaction:

The operation must reject without mutating either authoritative side when any identity, Business, revision, state, token, worker, expiry, authorization or target-state precondition fails. A stale worker, stale token, expired lease or invalid execution/dispatch identity cannot finalize, release, continue or overwrite a newer claim.

The existing release() operation remains unchanged. It performs ordinary bounded continuation only:

Stage 2 uses release() for ordinary continuation. It uses finalizeLeasedExecution() only when leaving running for waiting, succeeded, failed, suspended or reconciliation_required.

Waiting wake remains separate:

Wake processing must not use a released lease, overwrite a terminal or reconciliation state, or create a second continuation. Lease expiry continues to fence the old worker and does not automatically reclaim, finalize, resume or replay an execution.

Stage 2 expiry scope: IDY-007C Stage 2 does not implement expired-lease re-eligibility or any operation that changes an expired claimed/running execution to eligible. Expiry leaves the old execution and dispatch fenced and unresolved for this stage. Stage 2 may preserve and inspect durable evidence and may perform only reconciliation operations already authorized by the existing Command/Attempt contract; such reconciliation does not authorize re-eligibility, lease clearing, replay, retry, or resumption of the expired WorkflowExecution. Any future transition from this fenced state to eligible requires the separately governed recovery capability specified below. This deferral does not alter release(), finalizeLeasedExecution(), or the 100-step counter.

Stage 2 must persist required StepAttempt, Outcome and related evidence before calling finalization. finalizeLeasedExecution() atomically finalizes WorkflowExecution, dispatch and lease metadata; it does not claim to atomically persist arbitrary Stage 2 evidence. A crash between evidence persistence and finalization is handled using durable evidence and later governed recovery/reconciliation. No shared PDO transaction may be claimed unless an implementation provides and proves that boundary.

CommandHandler retains its existing transaction boundary. Stage 2 cannot enclose CommandHandler in one PDO transaction. Stable Command identity must exist before invocation; conclusive results permit continuation; uncertain results require reconciliation_required; unknown work must never be blindly replayed.

No generic workflow-state mutation may use this operation. No client, Workflow Definition, Event connectivity, lease worker, cached authority or AI output may select the target state or confer authorization.

Recovery and reconciliation extension — source implemented, deployment verification pending

This extension records the smallest conforming recovery contract for abandoned Workflow executions. It does not claim that the Operation, handler, recovery participant, inspection surface or tests exist. No runtime implementation, database migration or direct staging operation is authorized by this section alone.

Recovery Operation

The future generic Business-scoped Operation is named workflow_reconcile, revision 1, with a server-owned exact Operation identity derived through the existing Workflow Operation vocabulary. It targets the WorkflowExecution Type and accepts only:

already persisted Command identity.

The caller must be an authenticated Principal in the execution Business context with a current active Membership, AuthorityGrant and Policy permitting this Operation against the WorkflowExecution Type. The historical Workflow authority binding remains evidence of the execution context; it is not a permanent recovery grant. Recovery rechecks current authority, Business isolation, subscription/entitlement gate, exact execution identity, expected revision, pinned Workflow Definition revision and current dispatch identity. A technical worker identity or expired lease token is not recovery authority.

Expired-lease quarantine

An execution is eligible for quarantine_expired only when all of the following hold under the existing coordination lock:

1. the authoritative WorkflowExecution is running; 2. the dispatch row for the same execution is claimed; 3. the dispatch Business and execution Business agree; 4. lease_expires_at is present and is at or before the authoritative current UTC time; 5. the supplied execution revision is current; 6. no newer claim or state transition has won the coordination race.

The governed Command must atomically:

step evidence, prior Command/Attempt/Outcome records and provenance.

The expired worker cannot perform this transition. It remains fenced even if it later reconnects. A repeated identical recovery Command returns its durable result idempotently. A different decision under the same Command identity or an expected-revision mismatch is a conflict and mutates neither authoritative state nor dispatch metadata.

Quarantine is not retry, replay, completion or proof that a consequential Operation did not occur. It only converts an abandoned active lease into an explicit review state without erasing uncertainty.

Governed reconciliation decisions

reconciliation_required is a review state, not an implicit retry queue.

| Decision | Permitted source | Result | |---|---|---| | quarantine_expired | running + expired claimed | Atomically clears the expired lease and enters reconciliation_required. | | fail | reconciliation_required | Records an explicit terminal recovery Outcome and transitions execution/dispatch to failed; no Operation is replayed. | | resume_safe | reconciliation_required only after the safe-resume proof below | Records recovery evidence and transitions execution/dispatch to eligible; a later claim receives a fresh lease and token. | | reconcile_command | reconciliation_required with a persisted unresolved Command | Delegates to the existing CommandHandler::reconcile path. It does not resend the Command. The Workflow remains in reconciliation until the outcome is conclusive and a separate governed continuation is committed. |

Every decision uses the existing governed Command transaction, expected object revision, current authorization and dispatch coordination participant. The recovery evidence is generic addressable Command/Action Execution/Attempt/ Outcome/Provenance evidence linked to the original WorkflowExecution. A parallel recovery ledger, direct repository write, direct SQL mutation or replacement execution identity is prohibited.

Conflicting decisions are rejected when the execution revision, dispatch state, pinned identity, Business, current authority or decision preconditions do not match. A terminal succeeded, failed or cancelled execution cannot be recovered. A suspended execution cannot be made eligible by generic object update; it requires an explicitly defined future governed continuation.

Safe-resume proof

resume_safe is permitted only when the recovery evidence proves all of the following:

explicitly approved safe continuation whose idempotency contract is recorded.

current_node_id, current_node_revision and step_count are not proof of safety by themselves. A local command with an unknown or missing outcome remains reconciliation_required; it must never be replayed merely because the execution appears to point at that node. A known Command outcome is handled through CommandHandler::reconcile where applicable. A not-applied determination may permit a separately identified new Attempt only after fresh authority, dependency and expected-version checks; it is not an implicit repeat of the original Attempt.

Condition false remains a valid Boolean branch result. It selects the configured false_next continuation. Whether that continuation ends successfully, fails, waits or requires review is determined by the persisted Workflow Definition, not by the Boolean value itself. An evaluator false result must never be classified as a system failure merely because it is false.

Failure classification and recovery

| Condition | Classification | Permitted handling | |---|---|---| | Invalid Definition, unsupported node or deterministic validation rejection | Terminal or suspended according to the configured continuation | Record bounded error/evidence; no automatic retry. | | Authorization denial, stale revision or dependency mismatch | Rejected or suspended | Fail closed; re-evaluate current authority/dependencies before any later governed action. | | Known retryable infrastructure failure before a consequential Command commits | Retryable only through an explicit new Attempt and current preconditions | No implicit loop; preserve the failed Attempt and use governed continuation. | | Expired lease or process interruption | Abandoned active work | Old worker remains fenced; quarantine through workflow_reconcile; never infer success or replay. | | Unknown Command or external outcome | Unknown/Reconciliation | Use CommandHandler::reconcile; do not resend unsafe work. | | Valid Boolean false | Branch result | Follow false_next; do not convert it to execution failure. |

The current runtime implements the fencing, lease-bound finalization and bounded recovery Operation boundaries. The extension is source-implemented but remains deployment- and STAGING-verification-limited until the focused database-backed suite and authenticated staging evidence exist.

Dispatcher Pass — future capability, not current runtime

The repository does not contain bin/runtime-dispatch.php. The current bounded implementation invokes WorkflowExecutionRunner synchronously from the post-commit Event hook in the existing Command runtime. It is not a general worker, scheduler, queue or recovery loop. A failed post-commit dispatch is surfaced as an error, but the current hook does not reclaim an expired execution.

If a future bounded dispatcher is introduced, it must select only eligible rows, ordered by eligible_at ASC, workflow_execution_id ASC, and claim each row atomically under the database coordination boundary. If no eligible row exists, it must exit successfully with no state mutation. A pass counts one durable node visit/step attempt as one step, including a node that becomes waiting or terminal. Lease renewal does not consume a step.

At 100 processed steps, the future dispatcher must stop. If the execution still has continuation work, it must commit suspended / suspended dispatch state with an inspectable step_limit reason; it must not silently continue in the same pass or create another execution. Lease expiry during the pass fences subsequent writes. A later pass may process only work already made eligible by a governed transition; it must not re-eligibilize an expired execution, reset the step counter or create an implicit second pass.

Generic Step-Attempt Object

Every node visit is a generic addressable step-attempt object, independently inspectable and retained through revisions. A retry or new actual visit receives a new step-attempt identity; an existing attempt is never overwritten to conceal a prior try.

Minimum value/linkage:

The object is created before consequential node work. Its identity, execution/revision/node binding, start evidence and original inputs are immutable. Lifecycle changes append generic object revisions; terminal outcome evidence is retained and cannot be deleted or rewritten. pending/running are recoverable only according to the lease/reconciliation rules. completed and failed are terminal for that attempt. unknown and reconciliation_required require explicit reconciliation evidence before any safe continuation.

Node Semantics

`condition`

Resolve only declared bindings from authorized durable objects and the current pinned execution context. Evaluate through the existing bounded Policy expression language; no second expression language, eval, arbitrary code or AI interpretation is permitted. Recheck dependency revisions and current authority before evaluation.

true selects the declared true_next; false selects false_next. Unknown expression result, missing input, invalid dependency, or unavailable authorized input is not equivalent to false: the attempt records unknown/failure detail and the execution becomes suspended for review. The attempt stores inputs/dependency versions, expression result, selected continuation (if any), authorization context and Outcome before the execution transition.

`wait_for_event`

The node's validated configuration supplies an exact Event Type ID and a generic correlation descriptor. The runtime requires a finite, deterministic correlation descriptor containing the execution binding and one or more exact equality predicates over authorized object/revision references and/or configuration-approved scalar correlation values. The descriptor is interpreted by the owning workflow configuration; the generic runtime does not invent business fields or normalize Event payloads.

A match requires exact Event Type ID equality, all declared correlation predicates, the same authorized Business, a committed Event, and a valid pinned execution/wait registration. Event connectivity does not grant authority. The waiter records the descriptor, dependency versions, current node, wait-attempt identity and optional one-time UTC wake time before releasing its lease.

Nonmatching Events are ignored for this waiter and retained as ordinary Event history. Duplicate delivery or repeated matching Events cannot create another execution or another wait continuation; the wait registration is uniquely bound to the execution/node/attempt, and the first committed wake wins. A matching Event may wake each independently registered execution whose exact descriptor matches, but it cannot select any other execution.

The race between Event commit and waiter registration is closed by the same durable coordination boundary: if the Event commits first, waiter registration performs a bounded lookup against committed Event/index data before releasing; if the waiter commits first, the Event publication/wake path evaluates committed wait registrations before releasing. A wake changes the waiter to eligible; it does not execute a node while holding the Event transaction.

Only one-time UTC wake times are supported. No implicit timeout is applied. A workflow configuration may declare an explicit timeout outcome; its exact business meaning is delegated to that configuration, but the runtime records timeout as a distinct wake reason and never treats it as a matching Event. No recurrence, cron, local-time DST interpretation, fuzzy matching, broad unbounded scan, or arbitrary JSON-path matcher is permitted.

`request_approval`

The node creates a durable generic approval request/step attempt bound to the pinned WorkflowExecution, exact target object IDs/revisions, proposed operation, applicable Policy IDs/revisions, requester Principal, Business, and permitted reviewer scope. The requester and approver remain distinct where the applicable governance/configuration requires it. The request enters waiting and cannot execute the proposed operation merely because it exists.

An approval resolution must be an authorized governed Decision Command/Event whose exact binding matches the request identity, Business, target IDs/revisions, operation and Policy/dependency versions. The generic runtime defines this binding and authority boundary; the first bounded workflow configuration owns the business-specific Decision/Event payload, rationale fields and reviewer-scope details.

An authorized reviewer may produce one committed approved or rejected determination. Duplicate identical decisions are idempotent; conflicting later decisions do not overwrite the first committed determination and are retained/rejected according to normal Decision history. Unauthorized, expired, revoked, stale, or misbound decisions do not wake the execution. Approval expiry is not implicit: it exists only when the workflow configuration declares an expiry and resulting continuation.

Approval resolution commits Decision/Event evidence, reviewer authority, target/dependency versions and the selected continuation before changing the execution to eligible. Approval does not grant missing authority, bypass current type validation, or authorize a later local Command without a fresh commit-time recheck.

`local_command`

Resolve only declared workflow bindings and construct one stable Command envelope. The existing CommandHandler is the sole mutation authority. The interpreter does not call GenericObjectRepository or other repositories to mutate objects.

The Command includes server-supplied Principal, Business, operation, target IDs, expected versions, declared payload and stable identity. Before invocation, recheck current membership, grant, Policy, target visibility/type, approval/dependency bindings and expected versions. Persist step-attempt linkage to Command, ActionExecution, Attempt, Outcome and provenance.

Successful Command settlement advances to the declared continuation. Validation denial, authorization denial, stale version, deterministic rejection and deterministic failure remain explicit step/execution evidence; they do not silently retry. An unresolved Command result becomes unknown / reconciliation_required. Authorized reconciliation may settle the existing Command/Attempt or create only the explicitly permitted next evidence; it does not erase the unknown attempt or blindly repeat unsafe work.

`end`

Create and complete a step attempt and terminal Outcome under the valid lease. Set WorkflowExecution and dispatch state coherently to succeeded or the declared terminal failure mapping. Release the lease in the same durable transition. No continuation or additional node is executed.

Failure and Recovery

Under the current Stage 2 runtime, only already-eligible work is dispatchable; expired WorkflowExecution recovery is available only through the governed extension and is not automatic. The documented recovery extension may make a reconciled execution eligible only after the explicit safe-resume proof above. A local Command with no settled Outcome must first pass through reconciliation, and no recovery decision authorizes blind replay.

Cancellation

Cancellation is Command-mediated and uses the existing CommandHandler as the only mutation authority. A dedicated HTTP route is not required by this contract; if exposed, it must submit the registered cancellation Command through the existing authenticated Business/CSRF boundary. No client-supplied Principal, Business, worker, lease, or authority is accepted.

An authorized cancellation may transition eligible or waiting executions to cancelled before the next local Action. It competes transactionally with claim, wake and resume: the coordination boundary and lease token determine one winner, and the loser observes the committed state. Cancellation of running work is refused while a local Action is in progress unless an approved reconciliation path establishes that no unsafe work remains. Cancellation never deletes or rewrites step attempts, Commands, Effects, Events, Outcomes or provenance.

Persistence

Authoritative generic-object data:

Derived coordination data in workflow_dispatch:

| Field | Purpose | |---|---| | workflow_execution_id | PK/FK linking one coordination row to one generic WorkflowExecution. | | dispatch_state | Bounded discovery/claim projection; exact vocabulary is defined above and never overrides object state. | | eligible_at | Stable UTC ordering/wake eligibility time. | | lease_token | Opaque fresh fencing token for the current claim; nullable outside claimed. | | leased_by | Server-supplied technical worker identity; nullable outside claimed. | | lease_expires_at | UTC lease deadline; nullable outside claimed. | | step_count | Durable count of steps processed for the current dispatcher pass or approved accounting scope; used to enforce the 100-step bound. | | last_error_code | Bounded non-secret diagnostic code for dispatch/recovery inspection; detailed evidence remains generic objects. |

All additions require a forward migration after frozen 0007. No physical workflow-specific step table is permitted; generic objects provide semantic authority, while support columns provide bounded coordination/indexing only.

Security

The enforcement chain is:

authenticated Principal -> authorized Business context -> pinned WorkflowExecution -> current authority/dependencies -> node operation -> CommandHandler -> coherent evidence.

Membership, Business isolation, WorkflowExecution/subject visibility, current grants/Policies, approval scope, expected versions and dependency revisions are checked at the consequential node boundary. Technical worker identity is distinct from business Principal and configured Workflow Principal. A lease token proves only coordination ownership. Event connectivity, client payload, cached UI state and AI output never grant authority.

Concurrency Guarantees

UI Boundary

No generic workflow editor is part of 007C. If the bounded contract requires a presentation surface, expose only authorized execution status, current/waiting node, step/evidence history, suspension/error/reconciliation reason, approval decision action and cancellation action. All mutations use authenticated Business context, CSRF and CommandHandler. UI state is never authoritative.

Exclusions

007C excludes parallel branches/joins, recurrence, cron or general scheduler semantics, arbitrary timers, broker/queue infrastructure, unrestricted workers, integrations, external effects, AI execution, automatic retry of unknown external work, replay, compensation, migration/re-entry, and generic workflow editing.

Contract Quality Gate

Must be resolved in this generic contract

May be delegated to the first bounded workflow configuration

The workflow configuration may narrow these choices but may not weaken generic exact matching, authority, version, isolation, evidence, concurrency or no-AI guarantees.

Evidence-only limitations

No category-1 generic contract ambiguity remains in this approved record. Explicit project-owner approval and freeze are recorded by this status; runtime evidence remains outstanding.

Relationship to Section 13

Section 13 of docs/implementation/implementation-plan.md remains the planning source material and is not itself the implementation contract. This record makes its generic runtime guarantees explicit, incorporates the session decisions on generic step-attempt objects and delegated business schemas, and governs implementation once approved. Any conflict is resolved by canonical architecture and explicit approval of this record; no change to section 13 is required merely to create this contract.

Implementation Gate

007C contract explicitly approved and frozen -> only then AGENT implementation may begin.

Status Boundary

This contract remains the frozen normative authority for IDY-007C implementation requirements, including the exact five-target lease-bound finalization set. The bounded IDY-007 Slice 1 execution/finalization path is implemented and verified through the governed Business-owned workflow_dispatch Operation, OperationInvocationService, CommandHandler, conditional resource-claim fencing and fixed dispatch participant. The focused IDY-007 evidence is 62 tests / 279 assertions, including the governed recovery Operation regressions. This does not claim wake processing, expired-lease reclamation, retry/replay, richer automatic recovery or a general workflow runtime.