# AI Workflow Standard — Review and Proposed Formal Standard

**Document identifier:** AIWS-001  
**Title:** AI workflows — Governed execution, authority, evidence and interoperability  
**Edition:** 0.3
**Status:** Proposed standard / working draft for review  
**Date:** 7 September 2026  
**Basis:** Supplemental research dated 7 September 2026 and review of `deep-research-report.md`, titled *Workflow Standards for AI and Agentic Systems*, dated 4 September 2026.

This is an independently proposed standard. It has not been adopted, approved, or endorsed by ISO, IEC, OMG, NIST, AAIF, CNCF, or another standards organization. Its identifier is a working project identifier. An organization may adopt it through its own document-control process. External certification and interoperability with third-party runtimes have not been demonstrated. Companion TypeScript and Rust SDK tests establish only the explicitly documented finite-v1 implementation profile.

## How to use this document

Part A explains the review findings and recommended improvements. Part B contains the proposed normative standard. Annex A specifies assessment scenarios; Annexes B–E provide an example, adoption guidance, and sources; Annex F assigns assessment roles and Annex G describes implementation-profile boundaries. Recommendations and examples are distinguished from mandatory requirements. The original research report remains the research basis; this document supplies a new, assessable specification.

# Part A — Research-driven revision and recommendations

Edition 0.3 adds trigger admission, event handling and a normative node catalog to the research-driven edition 0.2. The new requirements distinguish occurrence receipt from authorization, require atomic deduplication/admission, preserve wait correlation and make graph execution obligations explicit.

Edition 0.2 incorporated the additional research in *AI-Workflow-Standards-Supplemental-Research.md*. The contribution is an integrated, assessable workflow contract built on existing authorization, execution, human-task, provenance, and assurance work. It is not a claim to have invented those foundations. Requirements below are proposed design decisions; cited research supports their rationale, not external endorsement.

| Revision | Research finding | Decision in edition 0.2 |
|---|---|---|
| Durable mission | Runtime continuation and authorization lifetime are different concepts. | Introduce Mission, ContractRevision, and ExecutionSegment; preserve cumulative accounting across runs. |
| Computable authority | RFC 9396 does not define comparison of arbitrary permission objects. | Require a versioned authority profile and three-result containment procedure. |
| Policy errors | An authorization engine can return Allow while reporting errors. | Required check errors block the affected dispatch; inspect diagnostics explicitly. |
| Revocation freshness | Cached validity can be stale. | Declare measurable freshness, clock tolerance, propagation, and in-flight boundaries. |
| Replay | Audit playback, recovery continuation, and new execution have different effects. | Name all three modes and prohibit implicit replacement of recorded decisions. |
| Parallel work | One run-level wait reason cannot represent concurrent human and service waits. | Persist independent wait records and explicit ALL/ANY joins. |
| Approval lifecycle | A UI event omits ownership, eligibility, consumption, and material action binding. | Add quorum/claim/reassignment rules and action fingerprints. |
| External effects | Outbox and retry facilities do not prove exactly-once business effects. | Require a durable admission boundary, target-specific guarantees, and conservative uncertainty accounting. |
| Evidence and acceptance | Evidence appraisal and accountable acceptance are distinct. | Add AcceptanceRecord and acceptance state; require current acceptance for verified success. |
| Conformance | Schema validity, runtime control, task quality, and operational assurance are different claims. | Assign every requirement to assessment roles and separate the four test tracks. |

The supplemental report contains the complete source analysis and limitations. Annex D retains the original source register and adds the primary references used for this revision. OAuth, PROV, SACM, SCXML, and human-task specifications are reuse candidates. Mission-bound OAuth and delegation-receipt drafts remain experimental alignment candidates. None is silently made a mandatory core dependency.

**Implementation recommendation.** Develop a language-neutral semantic test corpus, followed by native TypeScript and Rust SDKs that validate the same contract and produce the same control decisions. Keep authoring helpers separate from the credential-bearing execution boundary. SDK use alone cannot demonstrate deployment conformance. The companion *AIWS-TypeScript-Rust-SDK-Design.md* specifies the proposed modules, interfaces, failure cases, and release gates.

**Compatibility.** Edition 0.2 changes the metamodel, accounting scope, wait representation, success predicate, and replay contract. An edition 0.1 record is not automatically an edition 0.2 record. Existing requirement identifiers retain their subject; strengthened semantics and additions are listed in Annex E. The companion SDK release 0.2.0 supplies a candidate finite-v1 wire schema and independently implemented TypeScript/Rust libraries for edition 0.3. Its profile, coverage mapping and test report state what is implemented and what remains an application or deployment responsibility; this does not certify every requirement in this document. Edition 0.2 wire records must be explicitly reviewed and mapped before execution as edition 0.3; changing an edition label alone is not an approved migration.

# Part B — AIWS-001: Proposed formal standard

## 1 Scope

This standard specifies requirements for governing, executing, recording, and assessing AI workflows in which human, AI-agent, service, or deterministic-workflow participants perform coordinated work toward a declared outcome.

It applies to fixed and dynamically planned workflows, including long-running work and workflows with external effects. It specifies a semantic contract that may be implemented using existing orchestration engines and protocols.

It does not prescribe a model, prompt format, user interface, transport, orchestration product, memory database, or private reasoning representation. It does not establish domain-specific safety limits, determine legal obligations, or certify the substantive correctness of an AI model. Organizations supply applicable domain rules through controlled policies and criteria.

## 2 Normative language and precedence

**SHALL** identifies a mandatory requirement. **SHALL NOT** identifies a prohibition. **SHOULD** identifies a recommendation for which a documented justification may support an alternative. **MAY** identifies a permitted option.

Numbered requirements in Part B, the tables they explicitly incorporate, and Annexes A and F are normative. Part A, explanatory text, and Annexes B–E are informative. Supplemental paragraphs introduced with “As part of” and a numbered requirement identifier form part of that requirement. No external publication is a normative dependency of the core in this edition. A separately claimed binding must identify its own versioned normative dependencies.

**N-01 — Interpretation.** Claimants SHALL satisfy all mandatory requirements applicable to their declared role and enabled features. An example or implementation convenience SHALL NOT override a requirement. If two mandatory requirements cannot both be satisfied, the deployment SHALL stop affected work and report the conflict; it SHALL NOT silently choose a weaker interpretation.

## 3 Conformance scope

This standard distinguishes the following claims:

| Claim | Object assessed | Meaning |
|---|---|---|
| Definition | A versioned workflow definition and referenced policy package | The contract contains the required information and internally consistent constraints. |
| Core execution | An identified deployment boundary including runtime, policy enforcement, persistence, and required adapters | The deployment enforces applicable core behavior for its declared feature set. |
| Evidence export | A producer or consumer and a declared export format | Required evidence and control records can be exported or consumed with declared fidelity. |
| Binding | A versioned integration specification and its implementation | Mapping to a named external protocol preserves the declared AIWS semantics. |
| Experimental migration | An identified source/target runtime pair and format | Ownership and eligible execution state can be transferred under Clause 15. |

**C-01 — Claim contents.** A claimant SHALL state the AIWS edition, assessed role, deployment or artifact version, enabled features, supported limits, external dependencies, exclusions, assessment date, and test-evidence references. A definition-only claim SHALL NOT be presented as runtime conformance. A passing run SHALL NOT alone establish implementation-wide conformance.

**C-02 — Unsupported features.** A runtime SHALL reject definitions requiring unsupported semantic features before execution. Optional feature absence is permitted only when the definition does not require the feature and the runtime prevents its use. A binding or migration claim SHALL name the tested format and versions; no universal interchange claim is implied by core execution conformance.

**C-03 — Responsibility assignment.** Every claim SHALL assign each applicable obligation to a named component and responsible operator. Annex F supplies the minimum role allocation. A library that validates records MAY claim tested support for those checks; it SHALL NOT claim core execution conformance unless the assessed deployment includes effective dispatch enforcement, persistence, and adapters. Operational assurance SHALL include G-01, G-02, CH-01, and CH-02 and SHALL be reported separately from library behavior. Migration remains an experimental profile in this edition.

## 4 Terms, objects, and relationships

| Term | Definition and required relationship |
|---|---|
| Mission | Durable authorized objective, lineage, and cumulative resource-accounting container. It has one or more approved contract revisions and zero or more runs. |
| ContractRevision | Immutable approved combination of intent, definition revision, governing policy references, and authorized envelope within one mission. |
| Intent | The authorized outcome, constraints, success criteria, and acceptance policy pinned by a contract revision. |
| ExecutionSegment | Engine-specific continuation or recovery segment within one run; starting a segment does not create fresh authority, budget, or logical operations. |
| WorkflowDefinition | An immutable, versioned contract for permitted work and execution obligations. Each run pins exactly one contract revision and its definition revision. |
| Run | One execution instance within one mission and contract revision, with a unique identity and accountable owner. A run has zero or more plan revisions before activation and exactly one active plan revision during work dispatch. |
| Plan | A versioned strategy and task/dependency structure for achieving the intent. Fixed workflows also have a plan, which may be mechanically derived from their definition. |
| Task | An accountable unit of work within exactly one run. Each task has one responsible participant at a time, zero or one parent task, and zero or more dependencies. |
| Step | A logical operation within exactly one task. Its identity persists across retries. A changed intended effect creates a new step. |
| StepAttempt | One dispatch attempt for a step, with its own immutable identity and attempt number. |
| Participant | A human, AI agent, service, or deterministic workflow responsible for work. A participant's identity is distinct from its credentials. |
| Capability | A versioned operation contract, including accepted inputs, outputs, and effect classification. Discovery describes availability; it does not confer permission. |
| AuthorityGrant | A permission record with issuer, subject, scope, constraints, expiry, revocation state, and optional parent grant. |
| Approval | An attributable authorization decision for a specific action or explicitly bounded set of actions. Approval is subject to governing policy and does not automatically create broader authority. |
| Checkpoint | A consistent durable snapshot or reconstructable boundary sufficient to determine what can safely resume. |
| Artifact | Identified, versioned content produced or consumed by a workflow. |
| Evidence | Information with provenance that supports, contradicts, or leaves unresolved a specific criterion or control obligation. It may refer to one or more artifacts. |
| WaitCondition | Durable task-scoped condition with owner, type, correlation, deadline, satisfaction state, and join membership. |
| AcceptanceRecord | Attributable decision to accept, reject, or defer an assessed outcome against a pinned verification revision and acceptance policy. |
| VerificationRecord | An attributable assessment of a criterion using identified evidence, a method, and a verdict. |
| Event | An append-only record of an observable execution or control occurrence. Corrections are additional events. |
| Side effect | An externally observable change beyond internal planning or computation, including publication, communication, record mutation, and physical actuation. |
| Reconciliation | Establishing the external outcome of an uncertain operation using reliable external state or attestation. |
| Compensation | A separately authorized operation intended to counteract an earlier effect; it need not restore the original state completely. |

**M-01 — Identity and lineage.** The runtime SHALL assign unambiguous identities to runs, tasks, steps, attempts, grants, approvals, artifacts, evidence, and events within its declared namespace. References SHALL include the namespace where ambiguity is possible. Retries SHALL preserve the step and logical operation identities while creating new attempt identities. Parent-task and grant-parent relationships SHALL be acyclic.

**M-02 — Revisions.** The runtime SHALL preserve the definition, intent, plan, policy, capability, and artifact revisions applicable to every material action. Mutable references such as “latest” SHALL resolve to an identified revision before use. If an external provider does not disclose an immutable model revision, the runtime SHALL record the identifier supplied, invocation time, configuration, and the resulting reproducibility limitation.

**M-03 — Mission continuity.** The runtime SHALL preserve mission and contract lineage across runs, segments, delegation, recovery, and migration. Mission state SHALL be OPEN, SUSPENDED, or CLOSED. OPEN permits otherwise authorized admissions; SUSPENDED blocks ordinary new dispatch but MAY permit separately authorized bounded recovery; CLOSED permits no new dispatch. Closure SHALL require terminal runs, settled reservations, and no unresolved material effects. CLOSED SHALL be terminal; later assessments MAY append records, and corrective work SHALL use a linked newly authorized mission. Mission closure SHALL NOT imply verified success.

**M-04 — Segments.** Each segment SHALL identify its run, predecessor where present, engine identity, and durable ownership epoch. A new segment SHALL preserve operation identities, waits, budgets, approvals, and recorded decisions. Concurrent task workers MAY exist within a segment; they SHALL NOT acquire conflicting ownership of the same dispatch operation.

## 5 Accountability and admission

**G-01 — Roles.** The adopting organization SHALL identify a workflow owner, definition/policy approval authority, runtime operator, and verification authority. It SHALL document any combined roles and enforce separation where the workflow's approved risk policy requires independent approval or verification.

**G-02 — Risk assessment.** Before activation, the owner SHALL classify the workflow's consequences, affected parties and data, external effects, uncertainty, reversibility, and operating environment. The resulting versioned policy SHALL identify required gates, evidence quality, verifier independence, and escalation routes. Numeric model confidence alone SHALL NOT determine whether consequential work is authorized.

**G-03 — Admission.** The runtime SHALL validate the definition, referenced policy, participant eligibility, required capabilities, budgets, persistence availability, and verification arrangements before entering READY. Missing authority or unresolved required fields SHALL prevent dispatch. Rejection SHALL have a recorded reason.

## 6 Intent, definitions, and plans

**I-01 — Intent content.** The definition producer SHALL specify the desired outcome; in-scope and excluded work; stakeholder or business owner; required inputs and assumptions; prohibited actions; criterion identifiers; acceptance methods and thresholds; required evidence; verification authority; and handling of missing, conflicting, or inconclusive evidence. Every mandatory criterion SHALL be assessable by a defined machine check, human review method, or combination.

**I-02 — Stable contract.** Each run SHALL pin one approved mission contract revision. A material change to outcome, mandatory criteria, or definition constraints SHALL create an explicitly approved contract revision and a linked new run within the mission; the old run and pending work SHALL receive a recorded disposition. Unrelated objectives SHALL use a separately authorized linked mission. Segment rollover SHALL NOT change the contract. Grants and budget adjustments within the approved envelope MAY change through attributable control events without rewriting historical revisions. Creating a mission, run, or revision SHALL NOT implicitly replenish any applicable parent allocation.

**P-01 — Plan activation.** The runtime SHALL retain each proposed plan revision, its predecessor, proposer, change summary, affected tasks, and justification sufficient to explain the observable change. Before activation it SHALL validate authority, mandatory gates, dependencies, budgets, and consistency with the intent. Activation SHALL be atomic against the expected prior revision. A concurrent losing update SHALL be rejected or revalidated.

**P-02 — Dynamic work.** A participant SHALL create, decompose, reassign, or delegate tasks only where expressly permitted. Each created task SHALL trace to an intent criterion or necessary supporting control. The runtime SHALL enforce declared task-count, loop, delegation-depth, and termination limits. Removing a task from a plan SHALL NOT delete its history or cancel an external operation implicitly.

**P-03 — Dependency semantics.** Each plan SHALL specify task dependencies, join conditions, branch-selection rules, and the treatment of failed or canceled branches. Cycles SHALL use an explicit bounded loop construct or equivalent bounded iteration contract. A join SHALL NOT treat a skipped, failed, or merely dispatched branch as satisfying a successful-completion dependency.

## 7 Lifecycle and termination

**L-01 — Separate dimensions.** The runtime SHALL maintain execution, verification, and acceptance as separate run-state dimensions. Task execution SHALL follow the execution rules; task verification and acceptance are required where specified by the contract. Attempts and effects SHALL follow Clause 10. The transition table is normative; aggregate state rules in L-06 SHALL additionally apply.

The allowed execution transitions are:

| Current state | Permitted next states | Condition |
|---|---|---|
| CREATED | READY, REJECTED, CANCELED | Admission succeeds, fails, or is withdrawn before dispatch. |
| READY | RUNNING, WAITING, COMPLETED, PAUSED, CANCELED, FAILED | Dispatch begins, operator pauses/cancels, or a pre-dispatch failure occurs. |
| RUNNING | READY, WAITING, PAUSED, CANCELING, COMPLETED, FAILED | Work becomes runnable without an active worker, waits, dispatch is paused, cancellation starts, work finishes, or execution fails. |
| WAITING | READY, PAUSED, CANCELING, FAILED | Wait condition is satisfied and revalidated, pause/cancel occurs, or the wait fails. |
| PAUSED | READY, CANCELING, FAILED | Authorized resumption or disposition. |
| CANCELING | CANCELED, FAILED | Cancellation settles, or its controlled shutdown fails. |
| COMPLETED, FAILED, CANCELED, REJECTED | None | Execution is terminal. |

**L-02 — Wait and pause.** The runtime SHALL persist each WaitCondition independently, including task/run identity, INPUT/AUTHORIZATION/EXTERNAL/TIMER/RECONCILIATION type, owner, correlation, deadline, expected input revision, and pending/satisfied/expired/canceled status. Joins SHALL declare ALL or ANY over an identified condition set and the disposition of remaining conditions. Duplicate satisfaction SHALL be idempotent; stale or mismatched inputs SHALL NOT release work. PAUSED SHALL stop new dispatch without implying that in-flight work stopped. Satisfaction and resumption SHALL trigger fresh authority, policy, input, and budget checks.

**L-03 — Terminal execution.** COMPLETED SHALL mean that the plan's required execution obligations have finished and no required child work remains active. FAILED SHALL carry a cause and remaining-work disposition. Terminal execution SHALL never be reopened; additional work requires a linked new task within a nonterminal run, or a linked new run if the original run is terminal. A failed or canceled run may retain unresolved external effects, which SHALL remain visible in its effect ledger and be assigned to a reconciliation owner or linked recovery run.

**L-04 — Cancellation.** On an authorized cancellation request, the runtime SHALL stop new ordinary work, record the request, propagate cancellation to active children where supported, and track acknowledgments and unresolved effects. It SHALL publish its cancellation response limit. If shutdown cannot settle within that limit, it SHALL record FAILED with unresolved disposition rather than falsely reporting a successful cancellation. CANCELED SHALL NOT imply rollback.

**L-05 — Race handling.** The runtime SHALL serialize competing lifecycle transitions for each object using a durable revision or equivalent mechanism. Late or duplicate callbacks SHALL NOT regress terminal execution, duplicate an effect, or manufacture verification success. They MAY append evidence or resolve an effect record without reopening execution.

**L-06 — Parallel aggregation.** The runtime SHALL retain child states even when presenting an aggregate run state. Subject to terminal, cancellation, and pause precedence, a run with active work SHALL remain RUNNING even when another child waits. With no active work and eligible runnable work, it SHALL be READY; with neither active nor eligible runnable work and outstanding required waits, it SHALL be WAITING. An unsatisfied dependency without a satisfiable predecessor or wait SHALL cause a recorded failure, not an indefinite unexplained wait. COMPLETED SHALL require all required execution obligations to settle. Aggregate updates SHALL obey the transition table, including intermediate READY before dispatch after a wait.

## 8 Authority, delegation, and enforcement

**AU-01 — Grant content.** Each authority grant SHALL identify its issuer, subject, acting-on-behalf-of principal, run/task scope, permitted capabilities/actions/resources, data scope, destination or audience restrictions, validity period, revocation identifier, delegation permission/depth, and parent grant when delegated. Prohibitions and quantitative constraints SHALL remain explicit.

**AU-02 — Enforcement boundary.** The deployment SHALL enforce authority at a trusted dispatch boundary outside the participant's generated instructions. Every invocation, delegation, plan activation, controlled data disclosure, and consequential memory write SHALL be checked against the applicable policy and current authority. Missing permission SHALL deny the action. A planner SHALL NOT have a bypass path through a general-purpose shell, browser, sub-agent, or other capability.

**AU-03 — Attenuation.** For a delegated grant, the effective permissions SHALL be no broader than the intersection of the parent grant, issuer's delegable authority, child grant, and applicable policy. Delegation SHALL NOT extend expiry, increase depth, evade resource restrictions, or create a fresh aggregate budget. If scope containment cannot be established, delegation SHALL be denied.

**AU-04 — Policy precedence.** The definition SHALL identify authoritative policy sources and precedence. Applicable prohibitions SHALL override ordinary permission grants. An exception SHALL require an expressly permitted exception mechanism, named approver, scope, rationale, and expiry; it SHALL NOT waive an AIWS mandatory requirement while retaining a conformance claim for the affected behavior.

**AU-05 — Revocation.** The runtime SHALL revalidate grants at dispatch and on resumption. If required validity or revocation information is unavailable, affected dispatch SHALL stop. The deployment SHALL document its maximum revocation propagation delay. Revocation SHALL propagate to dependent grants, stop new affected work, and trigger recorded handling of in-flight actions. The record SHALL distinguish a prevented action from one already committed externally.

As part of AU-05, the deployment SHALL specify maximum accepted authorization-data age, revocation propagation bound, clock uncertainty, cache invalidation behavior, and the last enforceable dispatch boundary. Information exceeding the freshness bound SHALL block affected dispatch. Parent-child revocation dependencies SHALL be maintained explicitly; actor identity history alone is insufficient. Actions already accepted by an external target MAY require reconciliation or compensation; the deployment SHALL NOT claim their retrospective prevention.

**AU-06 — Remote enforcement.** Delegation SHALL have a verifiable enforcement arrangement covering the remote participant or a constrained gateway. A capability description or remote promise alone SHALL NOT establish authority containment. Where the boundary cannot enforce required restrictions, the runtime SHALL reject the delegation or limit it to a demonstrably enforceable subset.

**AU-07 — Authority profile.** Every grant SHALL name a versioned authority profile defining action/resource matching, audiences, quantities and units, time bounds, delegation, policy references, and containment. Its trusted deterministic comparison SHALL return CONTAINED, NOT_CONTAINED, or INDETERMINATE with diagnostic reasons. Only CONTAINED SHALL permit attenuation. Unsupported predicates, unresolved resource sets, or incompatible profiles SHALL NOT be treated as contained. Natural-language similarity, identity actor chains, and structural JSON subset tests SHALL NOT substitute for defined permission semantics.

**AU-08 — Mandatory policy diagnostics.** The deployment SHALL identify mandatory policy checks and their required inputs. An unavailable, malformed, errored, or indeterminate mandatory check SHALL block affected dispatch even when another check permits it. The boundary SHALL record diagnostics and distinguish DENY from INDETERMINATE; neither permits dispatch. A policy-engine integration SHALL document how native evaluation errors map to this rule.

## 9 Human approvals and resource limits

**H-01 — Approval record.** A required approval SHALL identify the approver and verified role; run, task, and logical operation or bounded scope; intended effect and target; material input/artifact revision; applicable policy revision; decision; timestamp; expiry; and reuse limit. The approval interface SHALL present the proposed effect, relevant evidence, and material uncertainty. A displayed button event or model-generated statement of approval SHALL NOT alone satisfy this requirement.

**H-02 — Approval validity.** Before dispatch, the runtime SHALL verify approval scope, validity, approver eligibility, and remaining uses. A material change to the approved action or content SHALL require renewed approval unless the original bounded authorization explicitly covers it. Consumption of a limited approval SHALL be atomic. Denial, silence, expiry, or timeout SHALL NOT be interpreted as approval.

**H-03 — Escalation.** Each approval gate SHALL define responsible roles, response deadline, escalation route, and timeout disposition. Escalation SHALL NOT silently expand authority. Low-impact work MAY use previously approved bounded authorization where policy permits it; the standard does not require a separate click for every operation.

**H-04 — Approval workflow and binding.** Approval policy SHALL define eligible roles, claim ownership where exclusive, quorum, separation rules, reassignment, withdrawal, and invalidation. Reassignment SHALL NOT preserve a no-longer-eligible vote silently. The approved action SHALL identify capability revision, target, material payload/artifact revisions, and preconditions using an unambiguous versioned fingerprint or equivalent immutable reference. Approval consumption SHALL bind atomically to a logical operation. Safe retries of that same approved operation SHALL NOT consume new operation uses unless policy explicitly counts attempts, but SHALL recheck current validity. A changed effect SHALL require a new operation and applicable approval. Bounded multi-operation approval SHALL track each consumed operation atomically.

**B-01 — Resource envelope.** The definition SHALL declare maximum elapsed time and limits applicable to its enabled operations, including attempts, task creation, delegation, tool calls, and financial or model consumption. Units, accounting scope, enforcement method, and exhaustion behavior SHALL be explicit. An irrelevant dimension MAY be marked not applicable with justification; an omitted limit SHALL NOT silently mean unlimited.

**B-02 — Aggregate enforcement.** The runtime SHALL reserve resources before dispatch and reconcile observed consumption. Mission-level consumption plus outstanding reservations SHALL remain within the authorized envelope, with run, task, and delegated allocations constrained beneath it without double counting. New runs, segments, or contract revisions SHALL NOT reset cumulative accounting. Unknown external liability SHALL retain its reservation or an explicitly recorded bounded exposure until reconciled; timeout alone SHALL NOT release it. If consumption cannot be strictly bounded, the policy SHALL define an exposure allowance and stop threshold, and the deployment SHALL disclose the hard-cap limitation.

**B-03 — Deadlines and cleanup.** The run deadline SHALL use elapsed wall-clock time including waits and pauses. Budget exhaustion or deadline expiry SHALL stop ordinary dispatch and invoke the declared disposition. Reconciliation, cancellation, and compensation MAY use a separately authorized, bounded reserve; the reserve SHALL NOT permit additional ordinary goal-seeking work.

As part of B-03, the mission SHALL additionally declare a cumulative elapsed deadline and any approved extension mechanism. Neither new runs nor recovery segments SHALL reset that deadline. An authorized extension SHALL preserve the earlier deadline and the approving decision in history.

## 10 Effects, attempts, retries, and compensation

**E-01 — Operation contract.** Each capability SHALL declare whether its intended operation has no domain side effect, is idempotent under specified conditions, is compensable, is irreversible, or has unknown effect behavior. These properties MAY overlap. The contract SHALL state preconditions, postconditions, external target, timeout, supported reconciliation method, and retry rules. Reads that disclose data SHALL also be subject to data authority even if they do not mutate the source.

**E-02 — Attempt and effect records.** The runtime SHALL record attempts as PREPARED, DISPATCHED, SUCCEEDED, FAILED, or UNKNOWN. An attempt whose dispatch or outcome is uncertain SHALL become UNKNOWN until reconciled. The logical operation's effect status SHALL be NOT_APPLICABLE, NOT_DISPATCHED, UNKNOWN, CONFIRMED_NOT_APPLIED, or CONFIRMED_APPLIED. Compensation status SHALL be recorded separately. A timeout SHALL NOT by itself establish CONFIRMED_NOT_APPLIED.

**E-03 — Durable dispatch.** Before an external effect is dispatched, the runtime SHALL durably record the intended operation, material request identity, authority decision, applicable approval, and budget reservation. It SHALL subsequently record dispatch and observed outcome. A crash between these boundaries SHALL trigger reconciliation or conservative UNKNOWN handling before retry.

**E-04 — Retry identity.** A retry SHALL create a new attempt under the same logical operation and preserve a stable idempotency key where the target supports one. The contract SHALL specify key scope, request fingerprint, validity window, and target duplicate-handling guarantee. Reuse of a key with a different intended effect SHALL be rejected. A request or message identifier SHALL NOT be presumed to provide idempotency.

As part of E-04, the contract SHALL also identify retention expiry, concurrent duplicate behavior, whether failed responses are cached, and what target evidence supports reconciliation. Adapters SHALL distinguish a cached response from independent proof of a newly applied effect.

**E-05 — Retry permission.** An automated retry SHALL require current authority, sufficient budget, an eligible error class, and either proof that the effect was not applied or a target guarantee that the repeated operation is safe under the applicable key and time window. Unknown, non-idempotent outcomes SHALL block automatic retry and require reconciliation or authorized recovery planning. A compensation procedure alone SHALL NOT justify retrying an uncertain operation.

**E-06 — Retry bounds.** Retry policy SHALL identify maximum attempts, delay/backoff rules, eligible errors, and total timeout. Validation failures and denied actions SHALL NOT be retried as transient failures without a relevant input or authority change. Expired idempotency windows SHALL trigger a fresh safety determination.

**E-07 — Compensation.** Compensation SHALL be represented as a separate authorized operation linked to the original effect, with its own budget, attempt history, approval requirements, ordering constraints, and verification. The runtime SHALL distinguish compensation succeeded, failed, partial, and unknown. Compensation SHALL NOT erase the original action or imply that irreversible consequences were undone.

**E-08 — Delivery claims.** A deployment SHALL state its delivery and deduplication guarantees separately from its business-effect guarantees. An “exactly once” business-effect claim SHALL identify the participating transactional or target enforcement mechanism and its failure assumptions. Transport success alone SHALL NOT support that claim.

**E-09 — Admission consistency.** The dispatch boundary SHALL durably and consistently bind the operation, attempt, applicable decision revisions, approval consumption, resource reservation, and ownership epoch before issuing an execution permit. Concurrent admissions SHALL NOT double-consume or over-allocate these records. A permit SHALL be operation-scoped, bounded in validity, and checked at the dispatch boundary against current control state. Persistence failure SHALL prevent permission issuance. This internal transaction SHALL NOT be represented as atomic with an unrelated external target. A lost external acknowledgment SHALL trigger E-02 and E-05 regardless of outbox or transport delivery status.

## 11 Durability, recovery, and replay

**D-01 — Recoverable control state.** Before acknowledging an accepted control transition, the runtime SHALL persist sufficient information to reconstruct it after process failure. Recoverable state SHALL include object revisions, active plan, task/dependency status, attempts and effects, waits/timers, grants and approvals, consumed budgets and reservations, required context references, evidence references, and the event cursor.

**D-02 — Recovery behavior.** Recovery SHALL reconstruct accepted control state, detect prepared or dispatched operations without definitive results, and revalidate authority and dependencies before new dispatch. Required waits SHALL survive restart. If state integrity or an essential reference cannot be established, the runtime SHALL enter controlled failure or reconciliation rather than guess.

**D-03 — Executor ownership.** The deployment SHALL prevent a stale or duplicate executor from dispatching as the current owner, using fencing or an equivalent checked mechanism at dispatch. It SHALL declare the failure domain against which this holds, including process crash and any claimed host or storage failure protection. Process durability SHALL NOT be represented as regional disaster recovery without additional evidence.

**D-04 — Replay modes.** The runtime SHALL distinguish AUDIT_PLAYBACK, RECOVERY_CONTINUATION, and NEW_EXECUTION. Audit playback SHALL reconstruct recorded history without fresh model, tool, or external calls. Recovery continuation SHALL reconstruct accepted decisions, reconcile uncertain operations, and only then dispatch eligible pending work under current controls within the existing run, optionally in a new segment. New execution SHALL create a linked run with explicitly admitted work and preserved mission accounting. No mode SHALL silently substitute a new model response for a recorded historical decision. The deterministic recovery controller MAY host nondeterministic activities whose accepted outputs are recorded; identical fresh model output is not required.

## 12 Context, data, memory, and trust boundaries

**X-01 — Data provenance.** Material inputs, tool results, retrieved documents, and memory used in decisions SHALL carry source references, revisions or capture times, trust classification, and access restrictions sufficient to determine permitted use. The runtime SHALL distinguish policy/instructions from untrusted task data and SHALL NOT promote retrieved text or tool output into authority merely because a model follows it.

**X-02 — Context handoff.** Before participant replacement or context compaction, the runtime SHALL retain or reconstruct the intent and definition revisions, applicable constraints, active task obligations, unresolved issues, relevant evidence references, and current authority. A natural-language summary SHALL NOT replace authoritative grant, approval, budget, or effect records. Missing mandatory context SHALL block affected work pending restoration.

**X-03 — Data protection.** The owner SHALL specify permitted data sources, destinations, audiences, retention, and access roles. The deployment SHALL enforce these restrictions across tool calls, delegation, evidence export, and memory writes. Credentials SHALL use protected references and SHALL NOT be copied into ordinary checkpoints or telemetry. Cross-tenant use SHALL require explicit authority and isolation controls.

**X-04 — Memory and conflict.** Persistent memory updates SHALL have a defined write authority, provenance, retention policy, and correction mechanism. Conflicting authoritative inputs SHALL be resolved by declared precedence or escalated; the runtime SHALL NOT choose a convenient source silently. The system SHALL record which source version governed the decision.

**X-05 — Minimization.** Evidence and event retention SHALL preserve required accountability with the minimum authorized sensitive content. Authorized deletion or redaction SHALL leave a protected disposition record where permitted, and SHALL identify any verification claim that can no longer be substantiated. Append-only control history does not require indefinite retention of raw personal content.

## 13 Evidence and verified outcomes

**V-01 — Evidence record.** Evidence SHALL identify the criterion or control obligation addressed, source/producer, collection method and time, artifact revision or external receipt, scope, integrity mechanism, sensitivity, and validity limits. The verifier SHALL be able to access the evidence under authorized conditions. A content hash proves integrity relative to that hash; it SHALL NOT be treated as proof of truth or authorship by itself.

**V-02 — Criterion assessment.** Each mandatory criterion SHALL receive an attributable verdict of PASS, FAIL, or INCONCLUSIVE under its predefined method and threshold. The verification record SHALL identify assessor, method/version, evidence, assessment time, and any independence requirement. Agent self-report SHALL NOT satisfy a criterion requiring independent verification. Repeating the same producing agent under another name SHALL NOT satisfy a separation-of-duties requirement.

**V-03 — Verification lifecycle.** Run verification state SHALL be maintained independently as NOT_STARTED, PENDING, PASSED, FAILED, INCONCLUSIVE, or INVALIDATED. It SHALL start as NOT_STARTED and move to PENDING when assessment begins. PENDING SHALL resolve to PASSED, FAILED, or INCONCLUSIVE. FAILED, INCONCLUSIVE, or INVALIDATED MAY move to PENDING for a new recorded assessment. A previously PASSED result whose basis becomes invalid SHALL move to INVALIDATED before reassessment. Previous verdicts SHALL remain in history.

**V-04 — Verified-success predicate.** A run SHALL be reported as verified successful only when execution is COMPLETED, verification is PASSED with a current PASS for every mandatory criterion, acceptance is currently ACCEPTED for that verification revision, required approval/control obligations are satisfied, required child work has settled, no material effect remains UNKNOWN, and no unresolved conformance violation undermines acceptance. Acceptance of a deviation SHALL remain a distinct disposition and SHALL NOT convert a failed mandatory criterion into PASS. A past action approval SHALL be evaluated as a historical control obligation; its ordinary later expiry alone does not undo a valid historical dispatch.

**V-05 — Revoked or stale evidence.** If evidence is contradicted, altered, revoked, or expires under the acceptance policy, the runtime SHALL record the finding, invalidate affected acceptance where warranted, notify the designated owner through the configured workflow mechanism, and initiate the specified review. A terminal execution record SHALL remain unchanged.

**V-06 — Probabilistic assessment.** Where acceptance uses statistical or model-based evaluation, the definition SHALL specify the evaluation set or sampling procedure, evaluator/configuration, threshold, aggregation rule, and treatment of variability and unavailable results. Claimed statistical confidence SHALL have a documented calculation. Successful workflow controls SHALL NOT be advertised as proof of general model accuracy.

**V-07 — Acceptance decision.** Acceptance state SHALL be NOT_REQUESTED, PENDING, ACCEPTED, REJECTED, DEFERRED, or INVALIDATED. An acceptance request SHALL enter PENDING; its decision SHALL be ACCEPTED, REJECTED, or DEFERRED. Reassessment SHALL create a new PENDING decision preserving history; a no-longer-valid ACCEPTED decision SHALL first become INVALIDATED. Each decision SHALL identify the accountable authority, scope, verification revision, supporting and conflicting evidence, policy revision, rationale, timestamp, and validity limits. Automatic acceptance MAY use an explicitly authorized versioned policy. Action approval, verification, acceptance, and mission closure SHALL NOT be substituted for one another. Evidence invalidation SHALL propagate to dependent acceptance records where their validity is affected.

**V-08 — Evidence support.** Verification records SHALL state which evidence supports or contradicts each criterion, the assessment rationale, material assumptions, and unresolved limitations. The representation MAY use a provenance or assurance graph. Neither a graph edge, signature, content digest, nor an attestation appraisal alone SHALL establish that a substantive criterion is true; the declared assessment method and acceptance authority remain required.

## 14 Execution records and observability

**O-01 — Event envelope.** Each required control event SHALL include event identity, event type, run/object references, object revision or sequence, recorded time, actor, causal/correlation references where applicable, and applicable policy/definition revisions. The runtime SHALL maintain an unambiguous committed order for state transitions of each object; wall-clock timestamps alone SHALL NOT determine causality.

**O-02 — Required events.** The runtime SHALL record admission decisions, plan activations, task creation/delegation, authority decisions and revocations, approval requests and decisions, resource-limit decisions, material capability invocations and outcomes, mission/contract changes, segment changes, waits/resumptions, cancellation, reconciliation, compensation, evidence assessment, acceptance decisions/invalidation, and terminal dispositions. Corrections SHALL append a new event referring to the corrected record.

**O-03 — Decision transparency.** Material decisions SHALL record decision class—deterministic, human, model-mediated, or delegated—together with material input references, applicable rule or configuration, chosen action, and observable justification. Disclosure of hidden chain-of-thought SHALL NOT be required for conformance.

**O-04 — Ledger integrity.** The deployment SHALL protect authoritative control records against unauthorized modification and detect integrity failures using a documented mechanism. Required control records SHALL NOT be sampled away. Telemetry MAY be sampled or exported to OpenTelemetry, but SHALL preserve correlation to the authoritative records where available and SHALL NOT be represented as a complete ledger when incomplete.

## 15 Export, bindings, and optional migration

**EX-01 — Evidence export.** An evidence-export producer SHALL supply a manifest containing its AIWS edition and export-format version, definition/policy revisions, object identities, mission/contract/segment lineage, execution, verification and acceptance states, plan lineage, material effects, authority and approval records or authorized references, evidence manifest, event ordering, and declared omissions. Restricted content MAY be referenced rather than embedded. A consumer SHALL validate required fields, integrity, and accessible dependencies and report missing evidence without inventing it.

**EX-02 — Semantic loss.** A producer or consumer SHALL report semantic loss caused by conversion, redaction, unavailable references, or unsupported features. Unknown mandatory fields or extensions SHALL cause rejection before execution or acceptance of an unsupported conformance claim. Optional extensions MAY be ignored only where doing so cannot alter required behavior, and their omission SHALL be disclosed.

**BI-01 — Binding contract.** A claimed binding SHALL identify external specification versions, required extensions, identity correlations, state/error mappings, authorization responsibility, timeout/cancellation semantics, duplicate handling, artifact/evidence mapping, and unsupported cases. The binding SHALL preserve AIWS obligations without redefining the external protocol's terminal states. Required guarantees absent from the protocol SHALL be supplied by a declared enforcement component or the binding SHALL reject the operation.

**MG-01 — Eligibility.** A migration implementation SHALL declare which checkpoint boundaries and features are transferable. Before transfer it SHALL validate compatible semantics, integrity, accessible data, external handles, credentials provisioned separately, current policies, and target enforcement. Nonportable or in-flight effects SHALL be reconciled, fenced, or explicitly excluded before cutover. Unsupported transfer SHALL fail without target dispatch.

**MG-02 — Ownership transfer.** Migration SHALL establish a durable cutover record and enforce a single dispatch owner. The source SHALL be fenced before target dispatch begins. The target SHALL acknowledge imported state and revalidate authority. If transfer fails, the source SHALL resume only after establishing that the target cannot dispatch. A network partition SHALL NOT produce two authorized owners.

**MG-03 — Preservation.** Transfer SHALL preserve identities, lineage, state, effects, consumed approvals, budgets, waits, verification records, and relevant context references. It SHALL NOT renew expired authority, reset budgets, resurrect terminal work, or rerun completed effects. A replacement workflow started from exported information SHALL be identified as a new linked run unless these migration requirements are met.

## 16 Assessment and conformance reporting

**T-01 — Requirement matrix.** The assessor SHALL enumerate every requirement applicable to the claimed role, including feature-specific conditions. Each SHALL have an evidence reference and PASS, FAIL, or NOT_APPLICABLE verdict. NOT_APPLICABLE SHALL include a rationale linked to an explicitly excluded feature or role; mandatory core behavior SHALL NOT be waived through this label.

**T-02 — Scenario execution.** A core execution assessment SHALL execute all applicable Annex A scenarios, including negative and crash cases, in a controlled environment. Definition-only assessments SHALL inspect the required records and logical consistency. Binding, export, and migration assessments SHALL include their corresponding scenarios. A claimed unsupported feature SHALL be tested for rejection rather than merely omitted.

**T-03 — Report content.** The conformance report SHALL identify implementation and configuration, deployment boundary, features and limits, test versions, inputs, injected failures, observable records, results, and unresolved defects. A failed mandatory requirement SHALL invalidate the corresponding claim until corrected and reassessed. Assessment results SHALL distinguish a test pass, a self-declaration, and independent assessment; this draft creates no certification body.

**T-04 — Interoperability evidence.** A cross-runtime interoperability claim SHALL include at least two independently implemented runtimes or adapters appropriate to the claim, the same declared contract, and observable evidence that required semantics are preserved. Results SHALL be assessed against allowed behavior and invariants, not identical generated text or task order. Shared code paths and test limitations SHALL be disclosed.

**T-05 — Separate assessment tracks.** Reports SHALL separate control conformance, domain outcome quality, adversarial robustness, and interoperability results. Where a numbered requirement contains multiple mandatory assertions, the assessor SHALL enumerate and evaluate each assertion before assigning PASS to the requirement. Passing semantic fixtures SHALL NOT establish resilience of the actual storage, identity, network, or credential boundary; applicable deployment failure-injection tests remain required.

## 17 Adoption and change control

**CH-01 — Controlled adoption.** An adopting organization SHALL issue a controlled adoption record naming the approved edition, accountable owner, scope, effective date, implemented profiles, and review interval. It SHALL define incident reporting, suspension of affected workflows, corrective action, and reassessment following material failures.

**CH-02 — Material changes.** Changes to the runtime, model configuration, capability contracts, policies, binding versions, evidence methods, or persistence behavior SHALL undergo an impact assessment. Affected requirements and scenarios SHALL be reassessed before the changed deployment retains its prior conformance claim.

**CH-03 — Specification maintenance.** A maintainer publishing a later AIWS edition SHALL retain revision history and publish change rationale, compatibility impact, migration guidance, and disposition of received technical comments. Stable published requirement identifiers SHALL NOT be silently reassigned to different obligations. A future ratification claim SHALL identify the actual approving body and decision record.

## 18 Trigger admission and event handling

A TriggerDefinition is an immutable rule connecting an occurrence to requested work. Event receipt, trigger admission, run creation, and actual operation dispatch are distinct control decisions. A trigger is not an authority grant. Supported trigger kinds are MANUAL, SCHEDULED, EVENT, RESOURCE_CHANGE, CONDITION, WORKFLOW_LIFECYCLE, and EXTERNAL_RESPONSE. These are semantic categories; transport and vendor choice are binding concerns.

**TR-01 — Trigger contract.** A trigger producer SHALL identify its namespace/id/revision, owner, permitted source and event types, input schema, deterministic filter, target definition/contract revision, start-run or resume-wait action, authority/policy references, validity interval, event-age limit, duplicate policy, rate/concurrency bounds, and failure disposition. The runtime SHALL reject unsupported requirements before activation. A request to change an authorized contract SHALL enter the existing controlled approval process rather than altering it through a trigger payload.

**TR-02 — Source and authorization.** The receiving boundary SHALL authenticate or otherwise establish the source's declared trust level, validate input, and record the source assertion and its verification mechanism. Event data SHALL NOT select a more privileged grant, target, principal, or policy outside the trigger contract. Trigger admission and resumed dispatch SHALL each satisfy current authority, policy, budget, and expiry checks. A source string or signed event alone SHALL NOT authorize business work.

**TR-03 — Identity and duplicates.** The runtime SHALL identify an occurrence by source namespace plus event identity, scoped to the trigger revision. Duplicate delivery with the same material content SHALL return its recorded disposition during the declared retention horizon. Reuse with conflicting content SHALL be rejected. Durable deduplication and the admitted start/resume mutation SHALL commit atomically or use an equivalently demonstrated mechanism. Event receipt acknowledgments SHALL distinguish durable receipt from admitted execution. This requirement SHALL NOT be advertised as exactly-once external effects.

**TR-04 — Time and schedules.** A scheduled trigger SHALL declare time basis, schedule revision, missed-occurrence policy, catch-up limit, and overlap policy. Local civil-time schedules SHALL additionally define time zone, daylight-saving gaps and repetitions, and calendar interpretation. Occurrence identity SHALL reflect the scheduled slot rather than delivery time. Late, expired, future-dated beyond declared tolerance, and out-of-order occurrences SHALL have explicit dispositions. A runtime MAY support only UTC fixed-interval schedules if it rejects unsupported calendar expressions.

**TR-05 — Conditions and storms.** Condition triggers SHALL declare edge versus level behavior, state scope, reset behavior, and sampling/evaluation interval. Rate and concurrency accounting SHALL include competing deliveries. Debouncing, batching, or coalescing SHALL be declared and SHALL preserve occurrence lineage and the effects of omissions. Workflow-to-workflow triggers SHALL enforce bounded causal depth or another demonstrated cycle/recursion limit.

**TR-06 — Resume correlation.** Resume triggers SHALL identify the existing run, wait owner, correlation token, expected input/approval revision, deadline, and whether the response is consumable once. A duplicate response SHALL NOT release work twice. Mismatched, stale, or expired responses SHALL NOT create replacement work silently. A terminal run SHALL remain terminal; additional work requires a separately admitted linked run.

**TR-07 — Failure and replay.** Trigger delivery retries SHALL preserve occurrence identity. Rejected or deferred admission SHALL record a reason and an attributable retry/escalation disposition. Audit playback SHALL NOT refire triggers. Recovery SHALL restore accepted trigger dispositions and condition/rate state. Reprocessing as new work SHALL be explicitly identified and authorized; clearing a deduplication cache SHALL NOT constitute such authorization.

## 19 Node contracts and execution semantics

A node is a versioned unit in a workflow graph. Node identity is distinct from task, logical operation, and attempt identities; bindings SHALL state the mapping. The following node catalog is normative for implementations claiming the corresponding feature. A runtime need not enable every node kind, but SHALL reject definitions requiring an unsupported kind under C-02.

| Node kind | Required semantic behavior |
|---|---|
| TASK | Perform declared work with executionKind AGENT, FUNCTION, TOOL, or HUMAN; consequential operations pass the same dispatch boundary. |
| DECISION | Evaluate a declared predicate or recorded assessed result; retain the selected route and decision basis. |
| FORK | Enable the declared branches without duplicating authority or aggregate budgets. |
| JOIN | Apply an explicit ALL, ANY, or profile-defined quorum rule over identified branch obligations; declare remaining-branch disposition. |
| LOOP | Repeat an identified body with stable iteration lineage, maximum iterations, deadline, and explicit exit predicate. |
| WAIT | Retain a typed, owned condition and correlated resumption as specified in L-02. |
| APPROVAL | Invoke H-01–H-04 and bind authorization to the material action; node completion alone is not permission for changed work. |
| SUBWORKFLOW | Admit a linked child under attenuated authority and shared accounting; distinguish synchronous join from explicitly detached work. |
| VERIFICATION | Assess declared criteria against attributable evidence under V-01–V-03 and V-06/V-08. |
| ACCEPTANCE | Record the authorized decision against a particular verification revision under V-07. |
| RECONCILIATION | Establish an uncertain operation's external disposition using declared reliable evidence. |
| COMPENSATION | Execute a separately authorized operation linked to its original effect under E-07. |
| END | Declare execution disposition without manufacturing verification, acceptance, rollback, or successful compensation. |

**ND-01 — Common contract.** A node SHALL declare identity/revision, kind, dependencies, required/optional disposition, material input/output schemas or versioned references, responsibility, authority and budget scope, timeout, retry/error policy, and evidence obligations. Implementations MAY inherit explicit defaults from the approved definition; omitted values SHALL NOT imply unrestricted behavior. A Start symbol MAY be a visual entry marker but SHALL NOT replace trigger admission.

**ND-02 — Graph validation.** Before activation, the runtime SHALL validate unique identities, references, reachability, input/output compatibility, dependency rules, and required terminal paths. Cycles SHALL be represented by an explicitly bounded loop construct or an equally assessable profile; accidental graph cycles SHALL be rejected. Activation SHALL be atomic against the expected previous plan revision and preserve the original contract's mandatory gates.

**ND-03 — Branches and joins.** Decision selection and branch activation SHALL be recorded. A skipped branch SHALL NOT masquerade as completed work or satisfy a required criterion. Join membership SHALL be explicit. ANY/quorum joins SHALL define whether unselected work continues, is canceled, or is excluded before dispatch; already-applied effects remain accountable. A waiting branch SHALL NOT hide a concurrently active branch in the aggregate state.

**ND-04 — Node control boundary.** Node executors SHALL receive only the declared context, operation permissions, and result-write authority. Node output, completion tokens, hook output, and exception handlers SHALL NOT bypass mandatory gates. Model-mediated decisions SHALL retain the accepted result for recovery without requiring reproduction of a fresh model response. Side-effect-free control nodes SHALL NOT obtain implicit write credentials.

**ND-05 — Failures and completion.** Retry, timeout, cancellation, and error routing SHALL preserve logical operation identity, effect uncertainty, budget accounting, and required child disposition. Node completion SHALL validate its output and declared evidence obligations. A generic completion command SHALL NOT substitute for the linked approval, verification, acceptance, reconciliation, or compensation record. Run completion SHALL require settlement of all required node execution obligations.

**ND-06 — Context and capabilities.** A binding SHALL declare capability/model versions, session/context continuity, artifact provenance, and isolation boundaries. A fresh context or provider fallback SHALL NOT reset authority, approved inputs, costs, or evidence requirements. Repository/worktree isolation MAY protect code changes but SHALL NOT be represented as a credential or network authorization boundary without additional enforcement.

# Annex A — Conformance scenarios (normative)

These scenarios specify minimum behavioral assertions. They are a test specification, not a claim that an executable harness has been supplied or run. Implementations may use simulated models and external systems; failure injection must make dispatch, commit, and acknowledgment separately observable.

For each case, the assessor shall retain the definition/configuration, initial state, stimulus, resulting state and events, evidence of prevented or applied external effects, and the pass/fail result. Additional tests are required wherever these scenarios do not cover an applicable requirement.

| ID | Setup and stimulus | Required observation | Main requirements |
|---|---|---|---|
| AT-01 | Submit a definition without an assessable mandatory criterion, then a complete definition. | First submission cannot dispatch; second reaches READY when other gates pass. | G-03, I-01 |
| AT-02 | Execute a bounded fixed workflow with all checks and evidence passing. | COMPLETED execution, PASSED verification, and ACCEPTED acceptance are distinct records; only their valid combination satisfies verified success. | L-01, V-04 |
| AT-03 | Produce an artifact but omit required independent evidence. | Execution may complete; verification remains pending or resolves INCONCLUSIVE, with no verified-success claim. | V-01–V-04 |
| AT-04 | Propose an in-envelope plan revision, then a revision deleting a mandatory gate. | First can activate after checks; second is rejected with the previous plan intact. | P-01–P-03 |
| AT-05 | Concurrently activate two revisions based on the same predecessor. | One commits; the other is rejected or revalidated; no mixed plan governs dispatch. | P-01 |
| AT-06 | Delegate a read-only task and request child write permission, extended expiry, or a reset budget. | Expanded delegation is denied; valid attenuated delegation preserves aggregate restrictions. | AU-01–AU-03, B-02 |
| AT-07 | Revoke a parent grant while a child waits; then satisfy the wait. | No newly unauthorized dispatch occurs after applicable revocation propagation; in-flight disposition is explicit. | AU-05, L-02 |
| AT-08 | Approve artifact revision A, replace it materially with B, and dispatch; also replay a consumed approval. | Changed or consumed approval cannot authorize the action. | H-01, H-02 |
| AT-09 | Let an approval expire or time out without response. | Gate follows its escalation/disposition rule; no implied approval. | H-02, H-03 |
| AT-10 | Two branches reserve more than the remaining aggregate budget. | Combined admitted reservations remain within the authorized envelope; exhaustion invokes policy. | B-01–B-03 |
| AT-11 | External target commits an operation; lose the response and crash the runtime. | Operation is UNKNOWN on recovery; no unsafe resend; reconciliation or valid target deduplication determines disposition. | E-02–E-05, D-01, D-02 |
| AT-12 | Retry a safely idempotent operation, then reuse its key with a changed request or after guarantee expiry. | Valid retry preserves operation identity with a new attempt; changed or expired-key case is blocked pending safety determination. | M-01, E-04–E-06 |
| AT-13 | Commit an effect and run compensation that only partially succeeds. | Original effect remains recorded; partial compensation is visible; workflow does not claim full restoration. | E-07, V-04 |
| AT-14 | Crash during INPUT, AUTHORIZATION, and TIMER wait conditions; restart. | Wait owner, deadline, correlation, budget, and approvals survive; resume revalidates restrictions. | L-02, D-01, D-02 |
| AT-15 | Restore a checkpoint and attempt dispatch from the previous executor. | Stale executor is fenced; only current owner can dispatch. | D-03 |
| AT-16 | Cancel during an external operation and deliver late/duplicate callbacks. | New ordinary work stops; callbacks do not reopen terminal execution or duplicate effects; unknown effects retain an owner. | L-03–L-05 |
| AT-17 | Audit-replay a run containing a model decision and an external write. | Historical decision is reconstructed; no fresh model call or external write occurs. | D-04 |
| AT-18 | Supply a retrieved instruction to bypass approvals or disclose another tenant's data. | Data cannot expand authority; prohibited action/disclosure is blocked by the enforcement boundary. | AU-02, X-01, X-03 |
| AT-19 | Compact context or replace an agent while an effect is uncertain and a constraint is active. | Authoritative constraints, effect state, and approvals survive; a summary cannot reset them. | X-02 |
| AT-20 | Alter, revoke, or expire evidence supporting an accepted run. | Affected verification becomes INVALIDATED where required; original terminal execution and earlier verdict remain in history. | V-03, V-05 |
| AT-21 | Present the producing agent as its own independent verifier under a new display name. | Independence check fails when policy requires separation. | G-01, V-02 |
| AT-22 | Export/import a record with an unknown mandatory extension, missing evidence, or redacted approval. | Consumer reports semantic loss or rejects unsupported acceptance; it does not infer a pass. | EX-01, EX-02 |
| AT-23 | Map a remote completed task to the parent while parent evidence remains unmet. | Remote execution completion is preserved; parent verified success is withheld. | BI-01, V-04 |
| AT-24 | Transfer a supported checkpoint; partition the network during cutover. | At most one dispatch owner; failed transfer cannot silently restart both runtimes. | MG-01–MG-03 |
| AT-25 | Transfer a checkpoint with consumed budget, expired grant, and completed effect. | Target preserves consumption, denies expired authority, and does not rerun the effect. | MG-03 |
| AT-26 | Execute two different permitted plans for one intent on independent implementations. | Both preserve mandatory gates, effect constraints, evidence obligations, and terminal semantics; different text/order is allowed. | T-04 |
| AT-27 | Disable a declared optional feature and submit a definition requiring it. | Admission rejects it before dispatch; report identifies feature as unsupported. | C-02 |
| AT-28 | Fail ledger persistence before acknowledging a control transition; sample all optional telemetry. | Unpersisted transition is not acknowledged as accepted; required ledger records remain complete despite telemetry sampling. | D-01, O-02, O-04 |
| AT-29 | Exhaust ordinary budget while reconciliation remains necessary. | Ordinary work stops; only separately authorized bounded recovery work uses the reserve. | B-03 |
| AT-30 | Reach a loop/delegation bound and deliver an event satisfying only part of a join. | Bound is enforced; incomplete join does not release dependent work. | P-02, P-03 |

| AT-31 | Continue a run in a new engine segment and open a revised-contract run. | Mission consumption, reservations, effects, and authority limits persist; no automatic reset. | M-03, M-04, I-02, B-02, B-03 |
| AT-32 | Compare grants with unsupported resource predicates or incompatible profiles. | Comparison is INDETERMINATE and delegation is denied. | AU-07 |
| AT-33 | Permit rule passes while a mandatory policy check errors. | Dispatch is blocked with diagnostics despite the permit. | AU-08 |
| AT-34 | Use stale cached grant validity after revocation or authority outage. | Freshness limit is enforced; no new permit after the declared boundary. | AU-05 |
| AT-35 | Keep one branch active while two others wait; satisfy an ANY join twice. | Aggregate stays RUNNING while active; joined work releases once and remaining-condition disposition is recorded. | L-02, L-06 |
| AT-36 | Reassign an approval, invalidate a quorum vote, and change a material target. | Eligibility/quorum rechecked; altered operation cannot use old approval. | H-04 |
| AT-37 | Crash at reservation, permit, external commit, and acknowledgment boundaries. | No over-allocation or duplicate consumption; ambiguous effect retains bounded exposure and recovery disposition. | E-09, E-02, B-02 |
| AT-38 | Run identical history in each of the three replay modes. | Audit makes no calls; recovery uses recorded decisions before pending dispatch; new work has a new run identity. | D-04 |
| AT-39 | Complete and verify a run before acceptance, then accept and invalidate its evidence. | No initial verified success; valid acceptance permits it; dependent invalidation withdraws it without reopening execution. | V-04, V-07, V-08 |
| AT-40 | Suspend a mission with in-flight work; attempt closure while effects are unknown. | Ordinary new dispatch stops; closure is rejected until required settlement; closure alone never implies success. | M-03 |
| AT-41 | Declare a validator-only component as a full deployment; omit a mandatory subassertion. | Claim is rejected or narrowed; whole-requirement PASS is withheld. | C-03, T-05 |

| AT-42 | Deliver an identical occurrence concurrently twice, then reuse its identity with changed content. | One admitted mutation; stable duplicate disposition; conflicting content rejected. | TR-02, TR-03 |
| AT-43 | Spoof an event source and request a different target/grant in its data. | Source/policy checks reject affected work; payload cannot broaden authority. | TR-01, TR-02 |
| AT-44 | Crash between event receipt and run admission, then redeliver. | Acknowledgment semantics are accurate; recovery does not create duplicate runs. | TR-03, TR-07 |
| AT-45 | Miss several schedule slots, including a declared civil-time discontinuity where supported. | Declared catch-up/skip policy and limits apply; scheduled identities remain stable; unsupported calendars reject. | TR-04 |
| AT-46 | Hold a condition true across repeated samples, reset it, and cross again. | Edge/level behavior, reset state, rate bounds, and occurrence lineage match the contract. | TR-05 |
| AT-47 | Trigger a workflow cycle and simultaneous admissions above a bound. | Causal/concurrency limits block excess work without resetting budgets. | TR-05 |
| AT-48 | Replay, duplicate, expire, and miscorrelate an external response. | At most one valid wait satisfaction; no terminal reopening or silent replacement run. | TR-06, TR-07 |
| AT-49 | Admit a graph with missing dependencies, duplicate ids, an accidental cycle, or unsupported node kind. | Definition rejected before any dispatch. | ND-01, ND-02, C-02 |
| AT-50 | Run a decision/fork/join graph with one skipped and one waiting branch. | Selected lineage persists; join semantics are correct; skipped work provides no fabricated evidence. | ND-03 |
| AT-51 | Submit fabricated completion for an approval, verification, or acceptance node. | Corresponding authorized record remains required. | ND-04, ND-05 |
| AT-52 | Reach a loop bound and replace context/provider during recovery. | No extra iteration or budget reset; accepted decisions and constraints persist. | ND-05, ND-06 |

# Annex B — EH&S corrective-action example (informative)

This example illustrates the semantic contract; it is not a regulatory procedure or an executable interchange document. Its thresholds are project choices to be set by the adopting organization.

**Intent:** Produce and obtain authorized acceptance of a corrective-action package for a reported machine-guarding deficiency. Physical implementation and approval to return equipment to service are separately assigned human responsibilities.

| Contract element | Example declaration |
|---|---|
| In-scope work | Collect approved inspection records; draft corrective actions; request engineering review; assemble evidence; update the designated case record after approval. |
| Prohibitions | Agent may not operate equipment, bypass safeguards, attest that a physical inspection occurred, or authorize equipment use. |
| Mandatory criteria | Issue identity confirmed; proposed action reviewed by designated engineering authority; implementation evidence supplied by an authorized person; effectiveness assessment accepted by designated verifier. |
| Participant authority | Investigator agent can read approved records and draft. Human engineering reviewer evaluates the proposal. Authorized personnel perform and attest physical work. Designated verifier assesses evidence. |
| Plan variability | Agent may request more records or expert review within limits; it may not remove implementation evidence or independent acceptance criteria. |
| External write | Case update uses a version precondition and target-supported deduplication where available. On timeout, reconcile the record before retry. |
| Approval scope | Approval identifies the exact proposed case update and evidence revisions, with an expiry and permitted-use count. |
| Resource envelope | Illustrative: 8 elapsed hours of agent workflow time, 100 capability calls, 2 delegation levels, and separately limited recovery work. Longer physical implementation requires a deliberately longer workflow deadline or a linked later run. |
| Completion | Drafting alone is not case closure. The workflow may finish producing a package while acceptance remains pending or inconclusive. |

An illustrative result after physical implementation evidence is missing:

```json
{
  "exampleOnly": true,
  "runId": "example:run:guarding-17",
  "executionState": "COMPLETED",
  "verificationState": "INCONCLUSIVE",
  "acceptanceState": "DEFERRED",
  "missionId": "example:mission:guarding-17",
  "contractRevision": "example:contract:guarding-17:1",
  "verifiedSuccessful": false,
  "criterionResults": [
    {"criterionId": "issue-identified", "verdict": "PASS"},
    {"criterionId": "engineering-reviewed", "verdict": "PASS"},
    {"criterionId": "implementation-evidenced", "verdict": "INCONCLUSIVE"},
    {"criterionId": "effectiveness-accepted", "verdict": "INCONCLUSIVE"}
  ],
  "disposition": "Await authorized implementation evidence and assessment"
}
```

This result is valid only if the completed plan's work was assembling and assessing the available package. If obtaining implementation evidence remains an active required task, execution remains WAITING instead of COMPLETED. The definition must make that boundary explicit.

# Annex C — Adoption and development guidance (informative)

## C.1 Suggested first implementation

Start with one bounded document-review or corrective-action workflow. Implement the definition contract, dispatch authorization, approval binding, durable effect records, and criterion-based verification together. Use a simulated external write target that can commit an update while dropping its acknowledgment; this exposes failures that an ordinary successful demo will miss.

Select one existing runtime after evaluating its enforcement, persistence, and adapter boundaries. Prefer an existing orchestration language and test kit where they can meet the contract. Do not begin by implementing every protocol binding or moving live runs between unrelated runtimes.

## C.2 Release gates

| Gate | Evidence needed to advance |
|---|---|
| Semantic review | Resolve terminology, lifecycle, authority, effect handling, and assessor comments. Confirm that requirements have an identifiable responsible party. |
| Controlled pilot | One deployment demonstrates all applicable core requirements and passes its scenario assessment; limitations are published. |
| Interchange candidate | Publish a versioned schema, extension rules, field-level mapping, sample records, validator, and invalid examples for the selected exchange claim. |
| Binding candidate | Publish and test one versioned binding; include unsupported semantics and adapter enforcement responsibilities. |
| Interoperability candidate | Two independent implementations preserve the same core invariants in successful, denied, duplicate, crash, and recovery cases. |
| Publication readiness | Resolve material defects; stabilize requirement identifiers; establish document ownership, licensing/IP policy, public comment disposition, and compatibility rules. |
| External submission | Select a willing standards venue and follow its actual contribution and approval process. Acceptance is a future decision by that venue. |

## C.3 Minimum adoption record

An organization adopting this draft would complete the following record:

| Field | Required entry |
|---|---|
| Adopted document | AIWS-001, edition 0.3, including any controlled organizational profile |
| Owner and approval | Named accountable owner; approval authority; approval record |
| Effective date and review interval | Organization-selected dates |
| Scope | Named workflows, environments, participating systems, and data boundaries |
| Claims | Definition, core execution, evidence export, and any tested bindings/migration |
| Feature declaration | Fixed/dynamic plans, delegation, external effects, independent verification, supported limits |
| Policy package | Risk assessment; authority; approvals; budgets; data policy; evidence methods |
| Assessment | Requirement matrix; test report; unresolved limitations; assessor identity |
| Change and incident process | Suspension authority, corrective-action owner, and reassessment triggers |

## C.4 Proposed integration strategy

These are design candidates, not normative bindings delivered by this edition.

| Existing specification family | Candidate reuse | Additional AIWS obligation |
|---|---|---|
| BPMN / CMMN / DMN | Business process, case structure, and deterministic decisions | Intent/evidence contract and governed dynamic changes |
| Open Workflow | Execution constructs and reusable conformance patterns | Authority and outcome enforcement at the selected runtime boundary |
| MCP | Tool and context access | Versioned extension requirements, dispatch authorization, effect reconciliation |
| A2A | Remote task interaction | Parent-child lineage, attenuated authority, binding-specific resend guarantees |
| AG-UI | Human-facing interaction events | Attributable, scoped, expiring approval records |
| OpenTelemetry | Operational traces and metrics | Complete, protected authoritative control ledger |
| Arazzo / OpenAPI / AsyncAPI | API workflow and interface descriptions | Workflow intent, authority, and external-effect obligations |
| Agent Spec / OASF | Agent configuration and capability descriptions | Enforced eligibility and semantic mapping; declared capability does not grant authority |

# Annex D — Sources and review boundary (informative)

Primary sources were accessed on 7 September 2026. Links to `latest`, `main`, or draft pages are mutable; implementers must pin the actual revision before claiming a binding. The sources below support the narrow landscape observations in Part A. The normative AIWS requirements are original proposed design requirements, not statements that the cited organizations already impose them.

| Source | Primary reference | Use in this review |
|---|---|---|
| S0 | Supplied `deep-research-report.md`, *Workflow Standards for AI and Agentic Systems*, 4 September 2026 | Complete research basis and design proposal reviewed. |
| S1 | [AAIF Workflows & Process Integration charter](https://github.com/aaif/wg-workflows-and-process-integration/blob/main/charter/charter.md) | Scope, dependencies, work products, and distinction between primary artifacts and stretch-goal specifications. |
| S2 | [A2A Protocol specification](https://a2a-protocol.org/latest/specification/) — sections on idempotency, task states, and bindings | Terminal versus interrupted states; optional send-message idempotency; protocol boundary. |
| S3 | [MCP specification, 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28) | Stateless core, per-request capability negotiation, and optional extensions. |
| S4 | [Open Workflow Specification repository](https://github.com/open-workflow-specification/specification) | Existing DSL, runtimes, and conformance test kit. |
| S5 | [AG-UI draft specification](https://docs.ag-ui.com/spec/draft) | Human-facing protocol scope and draft status. |
| S6 | [OpenTelemetry GenAI agent spans](https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/gen-ai-agent-spans.md) | Observability integration context. |
| S7 | [NIST AI Agent Standards Initiative](https://www.nist.gov/artificial-intelligence/ai-agent-standards-initiative) | Institutional initiative and identity/authorization context. |
| S8 | [Arazzo specification](https://spec.openapis.org/arazzo/latest.html) | API workflow integration context; inspected page identifies v1.1.0. |
| S9 | [OMG CMMN 1.1](https://www.omg.org/spec/CMMN/1.1/About-CMMN) | Adaptive case-management prior art. |

Historical release dates, the report's complete protocol portfolio, and every matrix rating were not independently reverified. This draft avoids making its core conformance obligations depend on those claims. No runtime conformance tests were executed as part of authoring this document; Annex A defines the tests an implementation must subsequently perform.

**Revision record:** Edition 0.1 — initial reviewed draft. Edition 0.2 — research-driven revision of mission continuity, authority comparison/errors/freshness, waits, approvals, dispatch consistency, replay, acceptance, and assessment roles. Edition 0.3 — adds TR-01–TR-07, ND-01–ND-06 and AT-42–AT-52; introduces trigger and node assessment roles. Companion SDK profile tests have been run; they do not constitute a full deployment conformance assessment.


# Annex E — Edition transition and research references (informative)

For an edition 0.1 import, create an explicitly mapped mission and contract revision, preserving original run and operation identities. Carry consumption and unsettled reservations forward; do not invent missing approval, authority, or evidence. A missing acceptance decision becomes NOT_REQUESTED, never ACCEPTED. Convert each old single wait into a WaitCondition and inspect concurrent work for omitted waits. Classify replay entrypoints into the three named modes. Reassess authority profiles, policy diagnostics, freshness, and dispatch consistency before enabling edition 0.2 execution. Preserve the original edition and conversion report; incomplete conversion supports archival viewing, not an unsupported execution claim.

Strengthened requirements include I-02, L-01/L-02, AU-05, B-02/B-03, E-04, D-04, V-04, EX-01, and O-02. New requirements are C-03, M-03/M-04, L-06, AU-07/AU-08, H-04, E-09, V-07/V-08, and T-05. AT-31 through AT-41 extend the original scenarios. Execution transition additions support aggregate READY/WAITING and zero-work completion; they do not reopen terminal states.

| Primary source | Design use |
|---|---|
| [RFC 8693](https://www.rfc-editor.org/rfc/rfc8693.html), [RFC 9396](https://www.rfc-editor.org/rfc/rfc9396.html) | Delegation identity versus authorization; profile-specific permission comparison. |
| [RFC 7009](https://www.rfc-editor.org/rfc/rfc7009.html), [RFC 7662](https://www.rfc-editor.org/rfc/rfc7662.html) | Revocation and introspection-cache freshness. |
| [Cedar authorization](https://docs.cedarpolicy.com/auth/authorization.html) | Explicit mandatory-check diagnostic handling. |
| [Temporal workflow definition](https://docs.temporal.io/workflow-definition), [activity definition](https://docs.temporal.io/activity-definition) | Recorded decisions and deterministic recovery around nondeterministic work. |
| [Stripe idempotency](https://docs.stripe.com/api/idempotent_requests), [AWS transactional outbox](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/transactional-outbox.html) | Target-specific retry contracts and internal/external transaction boundary. |
| [WS-HumanTask 1.1](https://docs.oasis-open.org/bpel4people/ws-humantask-1.1-spec-cs-01.html), [OWASP transaction authorization](https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html) | Approval ownership and binding to material actions. |
| [W3C PROV-O](https://www.w3.org/TR/prov-o/), [OMG SACM 2.3](https://www.omg.org/spec/SACM/2.3/PDF), [RFC 9334](https://www.rfc-editor.org/rfc/rfc9334.html) | Evidence provenance, support rationale, appraisal and acceptance separation. |
| [W3C SCXML](https://www.w3.org/TR/scxml/), [W3C specification guidelines](https://www.w3.org/TR/qaframe-spec/) | Parallel-state semantics and scoped conformance assertions. |
| [Mission-bound authorization draft](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-mission/) | Experimental comparison, not a core dependency or adopted standard. |

# Annex F — Minimum role allocation (normative)

Roles are D: definition/policy producer; R: integrated runtime and dispatch boundary; E: evidence producer/consumer and verifier/acceptance service as applicable; B: binding implementer; M: migration pair; A: assessor; O: adopting operator; S: specification maintainer. A deployment may combine roles but SHALL retain their obligations. Multiple roles in a row indicate shared obligations: the assessment SHALL attribute the individual mandatory assertions to their executing party. A component that cannot fulfill a dependent obligation SHALL identify the integrating component; it cannot silently mark that obligation inapplicable.

| Requirements | Minimum responsible roles |
|---|---|
| N-01, C-01–C-03 | All claimants and A |
| M-01–M-04 | R; D supplies immutable definition/contract identity |
| G-01, G-02 | O; D captures approved policy |
| G-03 | R |
| I-01 | D |
| I-02, P-01–P-03 | R; D declares envelope and dependency rules |
| L-01–L-06 | R |
| AU-01–AU-08 | R; D/O specify authoritative policy and profiles |
| H-01–H-04 | R; D/O define eligibility and approval policy |
| B-01–B-03 | D declares limits; R enforces; O authorizes allocations |
| E-01–E-09 | R and relevant B; D supplies capability contracts |
| D-01–D-04 | R |
| X-01–X-05 | R/E for controlled handling; O for data policy |
| V-01–V-08 | E and R; D/O specify methods and acceptance authority |
| O-01–O-04 | R and record-producing E/B |
| EX-01, EX-02 | E; R validates executable imports |
| BI-01 | B with integrating R |
| MG-01–MG-03 | M with source/target R; only if claimed |
| T-01–T-05 | A and assessed claimant |
| CH-01, CH-02 | O and affected component owners |
| CH-03 | S |
| TR-01–TR-07 | D declares trigger contract; R enforces admission/deduplication; B authenticates and normalizes sources; O authorizes policy |
| ND-01–ND-06 | D supplies graph/node contracts; R and B enforce execution; E supplies evidence assessment where required |

Feature exclusions apply only under C-02. A core execution claim includes its required external services inside the assessed responsibility boundary, even if those services are separate products. An assessment SHALL expand ranges and produce a row for every applicable requirement and its mandatory subassertions.


# Annex G — Companion implementation profile (informative)

SDK release 0.2.0 provides native TypeScript and Rust implementations targeting edition 0.3 under the finite-v1 profile. Both include checked command records, pure semantic reduction, native SQLite stores, trusted coordinator interfaces, trigger admission, fixed UTC schedules and the 13 node kinds. The source package includes the shared schema, executable examples, shared scenarios, persistence tests, a coverage mapping and a test report.

Profile choices include exact finite authority sets, integer accounting units, immutable per-mission contracts, explicit ALL/ANY joins, bounded loop constructs, local JSON schemas and conservative UNKNOWN-effect accounting. The default node material shape is a JSON object unless an explicit schema narrows it. Context, authority, budget, deadline, responsibility and evidence obligations may be explicitly inherited from an approved enclosing definition; absence must never be interpreted as a grant of unrestricted behavior.

The finite-v1 library is not a hosted ingress service. Authentication of event producers, durable disposition of rejected deliveries, transport acknowledgments, domain input compatibility, authoritative assessment, subworkflow parent/authority mapping and provider/environment enforcement remain declared binding responsibilities. The coordinator has no permissive authorization default. A successful local shape check or state transition is insufficient evidence for these responsibilities.

The release does not claim calendar cron/DST support, arbitrary authorization-policy comparison, live cross-runtime migration, external exactly-once effects or built-in adapters for every provider. Unsupported requirements must be rejected before execution. An organization adopting this profile must assess its complete composed deployment against all applicable requirements, including the controls supplied outside the SDK.

Archon's pinned workflow implementation informed the review of graph preflight, structured output handoffs, bounded context loops, separate outcome state and atomic gate resolution. These are reuse recommendations, not incorporation of Archon's wire schema or a finding that Archon conforms to AIWS. See the companion `ARCHON-RECOMMENDATIONS.md` for source links, priorities and important differences.