Conformance

Conformance Cases and Requirement Traceability

Every conformance case MUST contain a requirements field whose value is a nonempty list of distinct requirement IDs. Each cited ID MUST exist and be current in the exact Standard revision tested by the case; family patterns, wildcards, and retired IDs are not citations.

A case MUST cite only requirements whose observable conformance behavior the case directly tests. When a cited requirement declares diagnostic metadata, the case tests that condition only if it asserts one of the declared codes in the applicable validation, expression-fault, or run-code expectation.

A conformance suite MUST support reporting or enumerating its cases by cited requirement ID.

A validation case can assert separate document-validity, resolved-validity, and deployment-support results using the format under Conformance Suite. The runner MUST compare every asserted result and reject a response that omits one. A validation case’s claim selectors MUST filter against the implementation’s actual claim without overriding it; supplied target capabilities and profiles MUST be assessed independently of that claim. An implementation running a validation case MUST use its supplied resolution and earlier-manifest comparison inputs as defined by that format, including an explicit absence of resolution input.

A validation case can assert warnings and their explained consequences using the suite’s structured observation format. The runner MUST find a matching observation for every asserted warning, including its requirement, source path, and every asserted explained consequence. Unasserted warnings and additional advice do not affect the case result. This format observes diagnostics; it does not prescribe production diagnostic wording or encoding.

An implementation running a trace case MUST use supplied agent scripts as its agent runtime inputs, as defined by the suite format. When a trace case asserts an output member, the runner MUST require that member to be present, including an expected null.

A run-record case can negotiate workfile.run-records/1 under the suite observation protocol; the adapter MUST report the requested run-record operations and the runner MUST reject missing, malformed, or inconsistent observations.

A trace case can request an ordered boundary timeline using the suite observation protocol. An adapter supporting that protocol MUST apply its controls and report complete observed work starts, state changes, delivery dispositions, and snapshots as defined by the format. The runner MUST compare every requested boundary, snapshot, retention assertion, and bounded event count, rejecting missing observations and forbidden intermediate changes.

Missing observation-protocol support MUST be reported as an untested applicable case, separately from exclusion by a Standard capability or profile claim, and MUST NOT count as a pass. Logical observation identities do not prescribe an engine journal or persistence representation.

An adapter supporting recovery and restart observations MUST report logical generations, authorized resolution decisions, and retained-state boundaries as defined by the suite observation protocol. A process-restart observation MUST identify actual replacement of an execution process and restoration from retained state; in-process reconstruction and mock transcripts do not establish process-restart evidence.

An adapter supporting history observations MUST apply each requested reconstruction, re-evaluation, continuation, and payload-reduction control and report the resulting retained state, evaluations, effects, and history decisions under the suite observation protocol. The runner MUST compare each requested operation separately, including its source identity, payload availability, refusal or divergence boundary, and permitted effects.

One case can cite several requirements, and one requirement can be cited by several cases. Citations are test-coverage metadata; the evidentiary limits of passing cases are defined under Capability Conformance.

Document Conformance

A document conforms as a Workfile, connector manifest, filter-package manifest, schema overlay, conformance claim, or run record when it satisfies the encoding rules for that document kind, identifies or unambiguously selects a version permitted for that document kind, and satisfies every normative structural and semantic requirement applicable to that kind in the identified Standard revision. Conformance of a source document does not assert that its external references resolve or that any particular deployment supports it.

A resolved document conforms when the source document conforms, every resolved dependency conforms to its applicable document format, and the complete resolved set satisfies all applicable cross-document requirements. An x- extension does not affect document conformance unless it violates the extension rules; no conformance claim can be based on semantics carried only by an x- key.

Document Validator Conformance

An implementation conforms as a Document Validator for a stated Standard revision and set of Workfile formats when it:

• accepts every conforming source Workfile whose complete document validity it can establish and rejects every source Workfile whose invalidity the document phase establishes, within its documented implementation limits;
• performs the complete parse and document phase for every document in those formats within its documented implementation limits;
• implements the serialization rules, source-document structure, expression parsing and source-available typing, and structural capability and profile inference;
• recognizes capability- and profile-gated syntax without reinterpreting it as base syntax; and
• emits the required document-phase classifications, incomplete results, codes, document identities, paths, and available source locations.

A Document Validator is not required to resolve or validate external dependencies, establish resolved validity or deployment support, or perform content validation assigned to a capability it does not claim. It MUST report a result that depends on any such omitted work as incomplete and MUST NOT claim the corresponding validity or support result.

Core Validator Conformance

An implementation conforms as a Core Validator for a stated Standard revision and set of Workfile formats when it:

• accepts every conforming Workfile whose complete validity it can establish from supplied inputs, and rejects every Workfile whose invalidity its applicable phases establish, within its documented implementation limits;
• implements the serialization rules, the data model, expression parsing and typing, document and resolved validation, and capability and profile inference;
• accepts caller-supplied resolved manifests, filter packages, overlays, callees, templates, and other validation inputs in their applicable document formats;
• applies validation to the exact supplied contents and identities without requiring access to a proprietary catalog or execution service; and
• emits the required classifications, codes, document identities, paths, and available source locations under Diagnostics and Error Codes.

A Core Validator is not required to resolve artifacts from a catalog, configure connections, activate triggers, or execute a workflow. Offering any of those functions is subject to Requirement Ownership; it MUST NOT be presented as implied by a Core Validator claim.

Documented resource limits do not permit accepting an invalid document or rejecting a document as invalid when the correct result is unsupported or limit-exceeded.

Core Executor Conformance

An implementation conforms as a Core Executor only if it conforms as a Core Validator for the same Standard revision and Workfile formats. Within its documented resource limits, it MUST execute every valid, supported Workfile that activates no profile according to Execution Semantics, including the complete expression and built-in filter set, scope and binding rules, step policies, action dispatch under the Connector Execution Contract, and wf.wait behavior.

Before execution it MUST establish resolved validity and deployment support against the definition and dependencies the run will use. It MUST NOT execute an invalid or unsupported workflow.

A Core Executor MUST claim wf.composition and satisfy its execution contract. It MUST provide execution of the canonical time.now action under its Standard Library contract.

Core Executor conformance does not require initiation capabilities, other optional capabilities, profiles, other Standard Library actions or triggers, filter packages, or vendor connector implementations. In particular, time.schedule activation requires the independently claimable wf.scheduled-initiation capability; supporting time.now does not require a scheduler. Ordinary deployment connection and policy checks still apply.

Required Surface Index

This subsection is informative.

It introduces no requirement and does not replace the linked normative sections. A Core Executor’s required surface comprises the serialization rules and the Data Model; expression parsing, typing, evaluation, and the complete bare built-in filter set; Workfile structure, scopes, bindings, outputs, and base constructs other than capability- or profile-gated execution; step modifiers, retry, failure policy, composite timeouts, and Core Cancellation; resolution, pinning, diagnostics, and support classification; and action dispatch under the Connector Execution Contract, including dry-run and ambiguous outcomes.

Trigger declarations are base syntax, while their activation requires the inferred initiation capabilities. wf.call execution, including child-run, cancellation-propagation, and cross-run semantics, is required through the mandatory wf.composition claim; its static checks remain Core validation requirements. The canonical time.now action is also required. wf.render execution, Standard Library filter packages, initiation, durable execution, stateful workflows, and agents require their respective capability or profile claims.

Capability Conformance

Capability conformance is claimed independently for each registered capability and primary conformance target. The implementation MUST conform to every prerequisite and MUST satisfy all requirements in the capability’s defining section and registry entry.

Except where a capability requires Core Executor conformance, a Document Validator or Core Validator capability claim covers recognition, inference, and every static-validation behavior assigned to that capability in the validation phases applicable to the primary target. A Core Executor capability claim, or an implementation offering initiation under an initiation capability claim, additionally covers every operational behavior assigned to that function.

Parsing capability syntax, forwarding work to another service, or passing applicable conformance cases does not by itself establish capability conformance. Delegation is permitted, but the claiming implementation remains responsible for the behavior required at its boundary.

The Run Records Capability requires Core Executor conformance and cannot be claimed by a validator alone.

An unlisted capability has no conformance claim; prerequisite omissions follow Capabilities, and separate target deployment assessment follows Validation Ownership.

Profile Conformance

A profile extends, and does not replace or weaken, its stated underlying requirements. An implementation conforms to a profile only when it satisfies those requirements, every prerequisite profile, every capability the profile requires, and all requirements in the profile for the targets it claims.

When a profile’s activation predicate is satisfied, the Workfile requires that profile even if the affected path is not executed. A conforming validator MUST recognize the predicate. Its profile syntax and static-contract checks are base validation under Validation Ownership. When the target deployment lacks the required profile, the implementation assessing support MUST classify the document as unsupported. A validator MUST NOT reinterpret profile syntax as base constructs.

Profile claims are relative to the primary target: validator claims cover applicable static-validation phases; operational claims require Core Executor conformance and cover the profile’s execution or history operations.

Profile	Base validator checks	Additional profile-owned validation	Operational prerequisite
Stateful Workflow	State declarations, state scopes, initial and transition targets, accepts/into typing, routes, final-state reachability, resolved subscriptions and correlation.	None.	Core Executor; inferred initiation capabilities for subscriptions.
Durable Execution	Wait, recovery, reconciliation, and undo declarations, scopes and types, bounds, and resolved trigger, result, effects, and idempotency contracts.	None.	Core Executor; inferred capabilities for the constructs used.
Replay	No additional Workfile syntax or activation predicate; applicable Durable checks remain.	None for Workfile static validation. History integrity, pins, and operation compatibility are checks by the implementation performing a requested history operation.	Core Executor and Durable Execution Profile.

The table assigns no template-content checks to a profile; the wf.template-rendering requirement follows any template use through Validation Ownership.

An implementation MUST list each supported profile explicitly; support for a prerequisite profile does not imply support for a profile that extends it.

Conformance Claims

A conformance claim is a document using the serialization rules containing the following closed top-level map; x- keys remain permitted under Extensions and Forward Compatibility:

Key	Type	Requirement
conformance	int	REQUIRED. The conformance-claim format version; this revision defines 1.
implementation	map	REQUIRED. Contains the required strings name and version.
standard	string	REQUIRED. The exact Standard revision.
formats	list of strings	REQUIRED. The supported Workfile formats: versionless and decimal strings for explicit format discriminators.
targets	list of strings	REQUIRED. The claimed conformance targets, including exactly one primary target from document-validator, core-validator, and core-executor.
capabilities	list of strings	OPTIONAL. Exact registered capability names; absence means none.
profiles	list of strings	OPTIONAL. Exact profile names; absence means none.
documentation	string	REQUIRED. A stable reference to the implementation limits and implementation-defined choices required by the claim (see the Implementation-Defined Choices Index).

All lists MUST contain distinct values. A claim MUST use the registered name of each target, capability, and profile.

A vendor capability name MUST include its defining specification and immutable version in the capability registry entry to which the claim refers. The implementation map is closed except for x- keys.

A conformance claim MUST identify whether the implementation conforms as a Document Validator, Core Validator, or Core Executor and MUST identify every additional manifest format, capability, and profile for which it claims conformance. A claim MUST NOT imply support for an item that is absent, collapse distinct capability or profile names into an implementation-defined bundle, or claim an item without all of its prerequisites.

Claims are additive: conformance to one target, capability, or profile says nothing about an unlisted one. A claim applies only to the identified implementation version and configuration; a behavior-affecting change requires a new or amended claim.

Use of the Workfile Name

The name Workfile identifies this specification and documents and implementations related to it. A document MAY be called a Workfile only if it conforms to the Workfile document format.

An implementation MAY be described as a Workfile Validator, Workfile Executor, or Workfile implementation only together with a conformance claim that makes the applicable target, Standard revision, format version, capabilities, and profiles available. Software that consumes, produces, translates, or resembles Workfile documents but does not make a conformance claim MAY describe itself as Workfile-compatible or as having Workfile import or export support, provided that it does not imply conformance and identifies the supported subset or extension.

Use of the name does not imply certification, endorsement, interoperability beyond the stated claim, or conformance of vendor connectors and other unclaimed components.