Validation Model and Capabilities

This section defines validation results, diagnostic reporting, and capability requirements across document forms and operations. Requirements for particular documents, constructs, capabilities, and profiles remain applicable.

Static Validation

Static validation distinguishes three results:

• Document validity is determined from one source document without resolving external dependencies. It includes Serialization, the document’s structural rules, locally resolvable names and references, and every type or expression rule that Static Facts permits validation to determine from that document.
• Resolved validity is determined from the document and the exact manifests, filter packages, overlays, callees, templates, Standard Library artifacts, and other dependencies selected for it. It includes reference, signature, type, schema, call-graph, namespace, version, digest, and cross-document checks.
• Deployment support determines whether a target deployment can run the Workfile using the required definition and dependencies. It includes available connections and scopes, implementation limits, supported Standard revisions, inferred capabilities and profiles, and every other prerequisite expressly assigned to deployment validation.

A violation of document or resolved validity is a validation error and makes the applicable document invalid. A support failure does not itself make a document invalid. A validator MUST report a known support failure as unsupported even when missing or unusable dependency content prevents establishing resolved validity. Checks whose required inputs or usable dependency contents are unavailable remain incomplete; an incomplete result MUST NOT obscure an independently established invalid or unsupported condition.

A validator MUST NOT report unsupported syntax or a missing dependency as valid merely because the target lacks the feature needed to examine it. When a structurally activated capability assigns content validation to its validator claim, a validator that does not claim that capability MUST report the applicable document-validity or resolved-validity result as incomplete, identify the required capability, and MUST NOT report the unexamined content as valid or invalid.

A validator MUST NOT classify an otherwise valid document as invalid solely because the target lacks an implementation capability, connection, credential scope, runtime, or resource required to use it.

Validation Ownership

For the selected Standard revision, validators MUST perform all source-document checks for standard capability and profile syntax, including structure, names, scopes, expressions, declarations, and literal domains, in their applicable phases regardless of their own optional claims; the sole exception is content validation expressly assigned to wf.template-rendering. Core Validators MUST also perform the corresponding resolved-dependency checks with supplied inputs, including contracts reached through capability- or profile-gated constructs. The Capability Registry and Profile Conformance identify these checks and the template exception.

A validator MUST assess its own validation capabilities separately from the target deployment’s execution capabilities and profiles. An absent execution claim on the validator does not omit a base check; an absent template-validation claim affects only checks requiring template content. A template in a callee or profile-gated body has the same validation ownership as a template in a root step list. Independent results and unavailable inputs follow Static Validation.

Static Facts

For validity classification, a validator MUST use only facts established by source syntax and literal forms; declarations, schemas, signatures, and resolved dependency contracts; the structural type-inference and assignability rules of this specification; and checks that a provision expressly requires for a literal argument or value. A validator MUST NOT evaluate expressions, constant-fold operators or filters, propagate constant values through references, infer reachability from expression values, or perform path-sensitive narrowing except for the literal guard form expressly defined under Static Nullability or analysis expressly defined by a construct.

Additional analysis MAY produce warnings or support optimization, but MUST NOT change document validity, resolved validity, deployment support, or the required diagnostic code. A failure in the runtime domain of an otherwise valid expression remains an evaluation fault even when all its operands are literals, unless a provision expressly classifies that literal condition as a validation error.

Every condition classified for validation by these static-fact rules MUST be reported in the applicable phase and MUST NOT be deferred to execution. An executor or initiation implementation MUST complete all applicable validation phases successfully against the same resolved dependency set and deployment configuration that the run will use before activating a trigger, starting a run, or performing an action.

A change to any behavior-affecting validation input requires validation of the resulting deployment or resolved workflow before use.

Validation Phases

Validation proceeds conceptually in the following order. An implementation MAY combine phases or execute independent checks concurrently, provided that it produces the same classification and required diagnostics.

1. Parse and document phase. Parse the source under the serialization rules, identify its document kind and targeted format or manifest version, and perform document-validity checks that require no external dependency.
2. Resolution phase. Resolve every reference needed by the document, including recursive Workfile dependencies, and fix the identity and content of each result. Resolution failures use the classifications and codes under Resolution and Pinning, which also prohibits substitution.
3. Resolved-validation phase. Validate the document and all resolved dependencies as one definition, including each dependency’s own document conformance and all cross-document requirements. The validator MUST infer the complete set of structurally required profiles and capabilities during this phase.
4. Deployment phase. Determine whether the target supports the selected Standard revision and Workfile format, every inferred profile and capability, the resolved artifacts, the required connections and scopes established from declarations and resolved dependencies, and applicable documented implementation limits. Failure in this phase is an unsupported-target result unless a provision expressly classifies it otherwise.

A Document Validator MUST perform the first phase. A Core Validator MUST be capable of all checks in the first and third phases when the caller supplies the resolution inputs those checks require.

The Core Validator boundary concerning catalogs and deployment credentials is defined under Core Validator Conformance. When required resolution or deployment input was not supplied, or required capability-owned validation is not claimed, a Core Validator MUST report the corresponding validation result as incomplete and MUST NOT claim validity, resolved validity, or deployment support that depends on the missing input or validation capability.

Failure in one phase does not require an implementation to continue checks whose preconditions are absent or unsafe. The validator SHOULD report independent errors discoverable without speculation. A validator MUST NOT invent a cascade of diagnostics by assuming the shape, type, or contents of a dependency that failed to parse or resolve.

Diagnostics and Error Codes

Each reported validation error or unsupported-target condition MUST contain a registered stable error code, the phase or classification, the kind and identity of the affected document, and a path identifying the smallest applicable structural location.

Diagnostic Code Assignment

Unless a more specific provision assigns a code, the following table is authoritative:

Condition class	Code
Malformed, reserved, duplicate, or shadowing declaration	document.name
Missing or out-of-scope reference inside a present definition, including a binding, statically declared path, schema, state, branch, output, or member of a conforming selected manifest	document.reference
Required definition-owned artifact that cannot be resolved	dependency.unresolved
Resolved artifact that violates its own format or a cross-document contract	dependency.invalid
Missing, conflicting, mutually exclusive, duplicate, unknown, or wrongly shaped structural member	document.structure
Incomplete, contradictory, prohibited, non-exhaustive, or unbounded control-flow declaration	document.control
Statically incompatible type or constraint, including a literal outside a declared value domain	document.type
Template-specific static condition assigned by the template rules	document.template
Division or integer division by zero, overflow, non-finite numeric result, or unsupported numeric domain at runtime	fault.arithmetic
Wrong runtime kind or constraint, failed enum membership or materialization, required on null, invalid dynamic index, or non-boolean guard	fault.type
Receiver, argument, or arity rejected at runtime because json prevented static signature checking	fault.filter_signature
Failed dynamic parse, pattern, format, time-zone, or other filter-defined operation	fault.expression
Failure intrinsic to template evaluation or rendering	fault.template
Literal violating a lexical grammar	syntax.expression

A fault raised while evaluating an embedded template expression or filter retains its more specific fault.* code and is not replaced with fault.template. Template-tag recognition, block structure, include containment, variable-supply, variable-use, partial-context, partial-nesting, and part-name derivation use document.template as assigned by the template rules.

For a parsed source document it MUST also identify the source location; for an input supplied only as an abstract value, a path is sufficient. A diagnostic caused by a resolved dependency MUST identify that dependency and MUST NOT attribute the condition solely to the referring Workfile.

Diagnostic wording, formatting, ordering, severity labels beyond the required invalid-or-unsupported classification, and the reporting of additional non-normative advice are implementation-defined. Such presentation MUST NOT obscure or replace a required code.

Implementations MAY report multiple occurrences under one diagnostic only when the diagnostic identifies every affected path, and MUST NOT merge conditions having different registered codes. A warning identifies a condition that does not affect validity, resolved validity, or deployment support.

A warning has no registered error code and MUST be distinguishable from a validation error and an unsupported-target condition.

Runtime faults and action outcomes are not validation diagnostics. A condition determined before execution uses its registered validation or support code even if the same underlying incompatibility could otherwise be encountered at run time.

Unknown vendor diagnostic codes MAY be preserved and displayed, but MUST NOT be reinterpreted as Standard codes.

Required and Recommended Warnings

This subsection is informative.

This index summarizes the warning situations defined elsewhere; the cited requirements remain authoritative. Emission and explanation can have different strengths. Warnings do not change validation classification (requirement diagnostic.warning.no-classification-effect), and have no registered error code and remain distinguishable from errors and unsupported-target conditions (requirement diagnostic.warning.classification). “Not specified” means no separate explanation obligation is defined.

Situation	Emission	Explanation
Interpolation surrounded only by whitespace	SHOULD — requirement diagnostic.warning.interpolation-whitespace	Not specified; the surrounding whitespace makes this string interpolation.
Unused supplied template variable	SHOULD — requirement template.variable-unused	Not specified.
Compact value map with an immediate unprefixed construct-name key	SHOULD — requirement diagnostic.warning.compact-value	Not specified.
Explicit wf.value	SHOULD NOT issue the compact-value warning — requirement diagnostic.warning.explicit-value	Not applicable.
String-subject route without explicit else	SHOULD — requirement diagnostic.warning.route-implicit-else	SHOULD explain that an unmatched value succeeds with an empty branch — requirement diagnostic.warning.route-implicit-else.
Action-source iteration with integer max and a body that can dispatch write effects	SHOULD — requirement diagnostic.warning.action-source-max-writes	SHOULD explain that the limit can fail after iterations have completed external effects — requirement diagnostic.warning.action-source-max-consequence.
Omitted stop result makes a normal-completion key nullable relative to its non-null type in the join of all other result shapes	SHOULD — requirement diagnostic.warning.stop-empty-result	SHOULD explain the nullability change — requirement diagnostic.warning.stop-empty-result.
Static facts establish a write action with idempotency: none and omitted/abort ambiguity policy under step, iteration, or branch continuation in the same Workfile	MUST — requirement diagnostic.warning.unsafe-continuation-required	MUST explain that ambiguity bypasses continuation and terminates the run, identify on_unknown: fail as the remedy for ordinary catch/on_fail/enclosing policy, and explain that this choice does not establish whether the write occurred — requirements diagnostic.warning.ambiguity-consequence-required, diagnostic.warning.ambiguity-fail-remedy, and diagnostic.warning.ambiguity-effect-uncertain.
Same continuation context, but inherent or fixed-key idempotency permits safe reissue and effective policy allows only one attempt	SHOULD — requirement diagnostic.warning.safe-reissue-budget	SHOULD distinguish lack of retry authorization from lack of safe idempotency — requirement diagnostic.warning.safe-reissue-budget.
Durable Workfile with omitted on_unknown for a write action declaring idempotency: none	SHOULD — requirement diagnostic.warning.durable-implicit-terminate	SHOULD explain that unresolved ambiguity defaults to abort — requirement diagnostic.warning.durable-implicit-terminate-explanation.

Capabilities

Capability Declaration

An implementation declares support for a capability by its registered name and the Standard revision or external specification version under which support is claimed. A declaration is a conformance claim: the implementation MUST satisfy every requirement assigned to that capability for each conformance target to which the declaration applies.

The meaning of a declared capability MUST NOT depend on an undisclosed vendor mode.

A capability can be independently implemented and claimed; a collection of requirements that is meaningful only as an execution class or that changes the semantics of several base constructs MUST be defined as a profile instead. Capability names beginning with wf. are reserved to this specification.

A capability defined elsewhere MUST use a namespace controlled by its defining specification and MUST identify that specification by an immutable version. An implementation MUST NOT claim a prerequisite capability implicitly: every prerequisite MUST also appear in its conformance claim, whether required directly or through a claimed profile.

Capability Validation

A validator MUST infer required capabilities from the Workfile’s structure and exact resolved dependencies according to the activation predicates in this specification and the applicable registries. Inference is structural: it applies whether or not a step is reached, a guard is true, a trigger fires, or a deployment expects the feature to be used.

The required set is the transitive closure of directly activated capabilities and their prerequisites. A Workfile MUST NOT be required to repeat an inferred standard capability in a separate declaration.

If a future or external specification defines an explicit capability declaration, that declaration supplements inference and MUST NOT suppress a requirement activated by structure. Malformed use of a capability-defined feature, an unknown capability in a position whose vocabulary is closed, or an unsatisfied normative prerequisite within a document is invalid.

A valid resolved Workfile for which the target does not claim an inferred capability or one of its implementation prerequisites is unsupported by that target. The implementation determining deployment support MUST identify each missing capability and SHOULD identify the structural locations that activated it. An initiation implementation or executor MUST NOT activate the workflow’s triggers or begin a run while any required capability is missing.