Versioning the Standard

The Workfile document format and the Standard are versioned separately. The Standard revision is 0.2.0 and defines both the versionless Workfile format and explicit format 1, with identical syntax and meaning.

Resolution and a conformance claim identify the exact Standard revision; a conformance claim also identifies support for versionless and any explicit format discriminators. Standard revisions use three nonnegative decimal components, major.minor.patch, with no leading zero except for zero itself.

The selected exact Standard revision determines the syntax and semantics of every pre-1.0 document; a format discriminator carries no compatibility promise across pre-1.0 minor revisions.

An implementation MUST identify every exact revision for which it claims conformance.

Omitting workfile selects the versionless format; it MUST NOT select the newest explicit format.

A standard-defined profile and wf.* capability has no independent version. It inherits the exact Standard revision that defines it.

An external capability or profile instead identifies its defining specification and immutable version. An implementation MUST NOT combine requirements for one standard profile or capability from different Standard revisions under one conformance claim.

An unknown explicit format discriminator, a recognized format used with a feature introduced by an unsupported Standard revision, or a missing implementation capability makes an otherwise valid document unsupported. Malformed use of a feature defined by a revision the implementation claims is invalid.

An implementation that cannot distinguish an unfamiliar addition from malformed syntax MUST report that it cannot establish conformance; it MUST NOT accept the document by ignoring the addition.

For an unknown name in a closed Standard namespace, including a bare filter name or wf.* operation, a diagnostic SHOULD explain that the name is unknown in the selected Standard revision or might be defined by a later revision. This advice does not change the required invalid, unsupported, or incomplete classification.

Selecting a Standard revision selects its Library edition.

Library artifacts MUST NOT be mixed across editions or independently versioned away from the selected Standard revision.

Obligations of the Standard

The obligations in this subsection govern Standard editors and publishers; they are not validator or executor implementation conformance obligations. Their requirement IDs provide editorial traceability. Registry allocations and implementation rules elsewhere remain applicable to implementations using the selected revision.

Publication and Registries

A separately published artifact is not part of the Standard merely because this specification refers to it; a normative dependency MUST be identified by an exact version or other immutable identifier.

A standard entry is allocated only by a Standard revision.

Within compatible revisions, an allocated name or code MUST NOT be removed, reused, or assigned a different meaning; an obsolete entry remains reserved.

A Standard revision MUST NOT publish different normative content under the same version.

Each standard wf.* capability MUST have one registry entry that states its complete normative requirements, its structural activation predicate if it has one, its prerequisites, and its applicable conformance cases.

Every Standard revision includes exactly one Standard Library edition carrying that exact revision, as defined under Versioning and Artifact Identity. Two Standard Library editions MUST NOT publish different content under the same exact Standard version and canonical artifact identity.

Requirement Identifiers

Each normative requirement has a stable requirement ID attached exactly once to its authoritative normative unit by a req: annotation. Other prose can refer to that requirement, but it MUST do so by cross-reference and MUST NOT restate the obligation using a requirement term.

A requirement ID MUST match [a-z][a-z0-9_]*(?:\.[a-z0-9][a-z0-9_-]*)+; matching is case-sensitive. Requirement IDs MUST be unique within a Standard revision.

When allocating a requirement ID in a revision, ordinary words MUST be separated with hyphens; an underscore is preserved only within the exact spelling of a Workfile construct, field, outcome, registered code, or other defined language token that the ID identifies. Allocation follows the requirement’s normative meaning, not a token-level match against spellings used elsewhere in the Standard.

The dotted hierarchy identifies the normative owner and subject, and the final segment identifies an independently referenceable normative proposition whose truth can affect document validity, execution behavior, a conformance claim, a registered language surface, or an explicit editorial or hosting responsibility. Grammar productions, registry allocations, defined outcomes, and value-domain boundaries can be such propositions even when they do not use a requirement term; rationale, connective explanation, and a restatement of another authoritative rule are not.

Editors MUST allocate one ID per coherent obligation, normally expressed in one sentence; grammar productions and meaningful registry allocations are also valid units. Different actors, applicability conditions, consequences, or independently useful conformance evidence can justify separate IDs within a sentence. Existing citations from different locations are not required. Shared wording alone does not justify merging obligations with different normative force or owners.

Requirement ownership follows the responsible function and subject, independently of chapter placement. Allocation has no target ID count; the checks under Requirement Ownership and the lifecycle rules below still apply when text moves.

An ID MUST NOT depend on source location, table position, list position, or another editorial-layout detail. The requirement ID set and every attachment are immutable within a published Standard revision.

Beginning with Standard 1.0.0, a later revision MUST retain an ID when its independently testable normative meaning is unchanged; editorial rewording, relocation, or a change to informative material does not justify a new ID.

A later revision MUST assign a new ID when it changes the independently testable normative meaning. When requirements split or merge, an existing ID can remain current only for one resulting requirement whose normative meaning is unchanged; every other resulting requirement receives a new ID.

A retired ID MUST NOT be reassigned or reused for another requirement.

Beginning with Standard 1.0.0, publishing each Standard revision MUST include an immutable transition record identifying IDs added, retained, retired, or replaced since the preceding revision and the replacement IDs, if any.

Revision Compatibility

A patch revision is compatible with its preceding revision.

Before 1.0.0, a minor revision can incompatibly change any document format, including the versionless Workfile format and an existing explicit Workfile format.

Before 1.0.0, a Standard revision MAY rename requirement IDs for coherence even when their independently testable normative meaning is unchanged, but it MUST log those renames in its revision history.

Beginning with 1.0.0, a minor revision is additive within each Workfile format it retains.

A Standard major revision can make incompatible changes.

Beginning with 1.0.0, a later Standard revision MAY extend an existing Workfile format only if every document valid under an earlier compatible revision retains its required validation and execution semantics.

An incompatible Workfile change requires a new explicit workfile discriminator.

Beginning with 1.0.0, later Standard revisions can extend the versionless format only under these compatibility rules and MUST preserve the meaning of existing unversioned documents. An incompatible document syntax or meaning then requires a new explicit format discriminator.

A Standard Library patch release MUST preserve compatibility: it MUST NOT remove or rename a connector, package, action, trigger, filter, field, or fault; add a required input; narrow an accepted type or domain; widen a promised result; weaken an operational promise; or change a previously conforming invocation from one value or outcome to another. It MAY add artifacts under namespaces already reserved by the preceding release, add operations or optional fields, add fixtures that confirm existing behavior, or make editorial descriptions consistent with existing behavior.

A change outside those bounds requires a non-patch Standard revision and MUST also satisfy the compatibility rules of the applicable manifest format.