Conformance and Requirement Language
Normative and Informative Content
Section titled “Normative and Informative Content”The Standard comprises this specification, the Standard Library, the conformance suite, and the machine-readable schemas published for its exact revision.
Except where identified as informative, this specification is normative. The abstract, introduction, goals, design principles, prior art, examples, notes, diagrams, and sections explicitly marked informative provide explanation and do not state or alter conformance requirements. If informative content conflicts with a normative requirement, the normative requirement governs and the informative content is defective. Formal grammars and registries are normative only where this specification expressly says so.
The prose requirements of this specification are authoritative over the Standard Library, conformance suite, and machine-readable schemas. A disagreement with the prose is a defect in the other artifact and does not create or change a requirement.
The conformance suite’s case format and requirement-citation rules are normative. Its cases provide evidence of conformance and do not state or alter requirements.
Passing every applicable conformance case is necessary but not sufficient for a conformance claim. A case that disagrees with this specification is defective under the prose-authority rules above.
Standard publication and requirement-ID maintenance are governed by Obligations of the Standard.
External Normative Dependencies
Section titled “External Normative Dependencies”Unicode Version
Section titled “Unicode Version”Unicode-dependent behavior in the Standard uses The Unicode Standard, Version 17.0.0, including that version’s Unicode Character Database.
White_Space and Cased mean the properties with those names in that database.
Simple uppercase and lowercase mapping and simple case folding mean the default locale-independent simple mappings of that version, without tailoring.
ECMAScript Edition
Section titled “ECMAScript Edition”Number::toString means the abstract operation in ECMA-262, 16th edition (June 2025), section 6.1.6.1.20, with radix 10, as published at https://ecma-international.org/wp-content/uploads/ECMA-262_16th_edition_june_2025.pdf.
HTML Snapshot
Section titled “HTML Snapshot”The optional html filter package uses the WHATWG HTML Review Draft for July 2026 at https://html.spec.whatwg.org/review-drafts/2026-07/ for HTML parsing and character-reference decoding.
This immutable snapshot includes the named-character-reference table and the rules for numeric character references. The dependency applies to implementations of that package; Core does not require an HTML parser.
Requirement Terms
Section titled “Requirement Terms”The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this specification are to be interpreted as described in BCP 14, RFC 2119 and RFC 8174, when, and only when, they appear in all capitals.
The words “can” and “cannot” state the presence or absence of a capability. They do not grant or withhold permission and are not requirement terms.
Specified, Implementation-Defined, and Unspecified Behavior
Section titled “Specified, Implementation-Defined, and Unspecified Behavior”Where this specification uses the following terms:
- Specified behavior is behavior fixed by a normative requirement. Every conforming implementation to which the requirement applies MUST provide that behavior.
- Implementation-defined behavior is a choice expressly left to an implementation. The implementation MUST document its choice and comply with any constraints stated by this specification.
- Unspecified behavior is a choice among outcomes permitted by this specification. An implementation need not document its choice, make the same choice on each occurrence, or make the same choice as another conforming implementation.
A matter outside the scope of this specification is not, for that reason alone, implementation-defined or unspecified behavior. This specification imposes no documentation requirement on an out-of-scope internal choice unless a normative provision expressly does so.
This specification fixes behavior that affects portable logical outcomes. It leaves behavior implementation-defined when users need to discover an implementation’s choice, and unspecified only when portable workflows cannot depend on the choice.
Valid Workfiles MUST produce a specified result or one of an expressly permitted set of results; invalid documents and runtime faults are handled as defined by the applicable normative provisions.
Implementation-Defined Choices Index
Section titled “Implementation-Defined Choices Index”This subsection is informative.
The following index identifies expressly implementation-defined choices and the function responsible for documenting them. The documentation reference in Conformance Claims covers applicable choices. Resource Limits separately defines documentation of limits; unspecified scheduling variation and out-of-scope internals acquire no documentation obligation from this index.
| Choice | Responsible function | Authoritative section |
|---|---|---|
Human-readable error text, including error.message |
Implementation producing the error | Error Classification; Names and reserved bindings |
| Cancellation reason | Executor | Core Cancellation; Durable Cancellation |
| Run-record retention, observation opportunity, visibility scope, and workflow identity continuity | Executor claiming wf.run-records |
Run Records Capability |
| Overlay diagnostic wording | Validator checking overlays | Overlay Validation |
| Resolver ordering, cache layout, lock-file syntax, and internal persistence | Implementation resolving dependencies | Resolution and Pinning |
| Agent token-counting method | Implementation resolving the agent | wf.agent |
| Diagnostic wording, formatting, ordering, additional severity labels, and non-normative advice | Implementation reporting validation or support diagnostics | Diagnostics and Error Codes |
Requirement Ownership
Section titled “Requirement Ownership”Document constraints govern the named Workfile, manifest, package manifest, overlay, or claim; a validator MUST check those constraints in the phases and document formats covered by its target, subject to the validation ownership rules under Static Validation.
An implementation offering catalog resolution, connection management, initiation, execution, or history operations MUST satisfy the requirements assigned to each function it performs, including when that function is delegated. This does not require a validator to offer those functions; see Core Validator Conformance. Deployment configuration is input to the responsible implementation, not a separate conformance target.
An implementation executing a connector action, trigger, or package filter MUST use an implementation that fulfills the selected artifact’s operational promises. Format validation checks declarations and static consistency; it does not prove operational promises such as effects, idempotency, determinism, or purity. Requirements on connector or filter behavior apply at the executing implementation’s boundary, including delegated components.