Scheduled, External-Event, and Polling Initiation

This section defines three independent capabilities: wf.scheduled-initiation, wf.external-event-initiation, and wf.polling-initiation. They extend the base trigger syntax with the machinery that produces and retains trigger events.

An implementation can claim any subset and MUST satisfy the complete requirements of each capability it claims. For all three capabilities, the initiation implementation MUST assign a stable workflow identity whose scope includes every activation and run that can interact through the initiation rules.

A trigger binding is the resolved tuple of workflow identity, trigger entry or subscription, connector version, connection identity, evaluated configuration, deployment inputs, and applicable overlay. Activation MUST validate and fix that tuple before accepting events.

Changing any member requires a new activation and MUST NOT reinterpret an event already accepted by the old activation. An accepted event is one whose payload has passed manifest validation and whose delivery has been admitted for run-initiation or subscription processing, including guard, partition, queue, overlap, or batch processing where applicable.

Receipt alone is not acceptance. While the activation remains installed, the initiation implementation MUST retain enough identity, payload, ordering, suppression, subscription-delivery, and batching state to avoid silently losing or duplicating an accepted event across implementation restart.

For delivery to a wf.wait_for or state subscription, an external or poll event is matched only against subscriptions active when the event is accepted. If no active subscription matches, the event is not eligible for a subscription established later; that disposition consumes its delivery identity under the capability’s ordinary deduplication rule.

The initiation capability owns event acceptance, acceptance order, deduplication, and delivery to active subscriptions. The profile defining the subscription owns its activation, correlation, and selection semantics, and the Durable Execution Profile owns their persistence where durable continuation is required.

Batch Closure and Admission

A trigger’s batch declaration under Queueing, Overlap, and Batching can declare size and max_wait. The activated initiation capability closes and admits batches as follows.

When both are present, the first condition reached closes the batch. size is a maximum as well as a closing threshold.

max_wait is measured from acceptance of the first event in the batch; closure can occur later because of scheduling delay but MUST NOT occur earlier. A closed nonempty batch starts one run.

If the run cannot yet be admitted, the closed batch remains pending until admission or explicit operator disposition. A fault in a per-event trigger guard, queue key, partition key, or trigger projection starts no run.

For an external or polling event, the fault consumes the accepted delivery identity and MUST be retained as its disposition for the ordinary deduplication-retention period. For polling, this disposition permits cursor advancement.

For a scheduled occurrence, the fault suppresses that occurrence. The implementation MUST distinguish the fault from false suppression in any initiation record that it otherwise maintains.

Scheduled Initiation

wf.scheduled-initiation applies to a trigger whose manifest declares kind: schedule. Its configuration defines a sequence of intended occurrence instants.

The connector contract MUST make that sequence deterministic from the fixed configuration and recorded time-zone-data version. A configuration whose occurrence sequence cannot be evaluated is invalid at activation; a valid sequence with no future occurrence remains inactive.

Each intended instant identifies one logical occurrence for that trigger binding. An implementation MUST NOT initiate more than one run for an occurrence, including after restart.

The initiation implementation can begin the run after the intended instant because scheduling is not exact, but MUST NOT begin it before that instant. Delay does not move later intended instants or change their identities.

An initiation implementation MUST declare one missed-occurrence policy for each activation:

• skip discards occurrences whose instants passed while the activation was unable to schedule them.
• catch_up admits missed occurrences in increasing intended-instant order, subject to a declared finite catch-up bound.

The policy, every skipped or admitted missed occurrence, and the bound for catch_up MUST be recorded as initiation state. When the catch-up bound is exceeded, the initiation implementation MUST record the omitted range and require operator action or apply its documented overflow policy; it MUST NOT silently collapse several occurrences into one.

The trigger output supplies the payload for each occurrence and MUST be validated before acceptance. For the canonical time.schedule trigger, scheduled_at is the intended occurrence instant and fired_at is the actual instant at which the occurrence was admitted; both fields are required, including for delayed and catch_up occurrences. Schedule triggers have no manifest delivery_id; their occurrence identity is the intended instant together with the trigger binding.

Guards, queue_by, and overlap: skip are then applied under base rules. For batching, occurrences enter a batch in increasing intended-instant order, and each resulting payload list preserves that order.

External Event Initiation

wf.external-event-initiation applies to a trigger whose manifest declares kind: external. It accepts events delivered by an external producer or transport.

Protocol, endpoint, authentication, and acknowledgement representation are connector or deployment concerns. The implementation MUST validate the complete payload, including its manifest-declared delivery_id, before acceptance.

Within one trigger binding, the delivery-id value identifies one logical event. The first accepted delivery fixes its payload; a later delivery with the same identity MUST NOT start another run or replace that payload.

A conflicting payload for an accepted identity MUST be recorded as an initiation error. Deduplication state MUST be retained from acceptance until the associated event is suppressed or its run reaches a terminal outcome, and then for a deployment-declared nonnegative retention period.

For a batched event, the associated run is the batch’s run. Expiry permits a later delivery to be treated as new and MUST be documented; it does not alter an existing run.

An implementation that acknowledges delivery MUST do so only after it has retained enough state to reproduce the accepted, suppressed, queued, or batched disposition after its supported restart. A payload that cannot be validated starts no run and is not ordinary guard suppression.

The implementation MUST record the validation failure when it has sufficient identity to do so; acknowledgement, rejection, or quarantine of such an unprocessable delivery is deployment policy. Accepted events are ordered by acceptance for queue_by and within each batch partition.

when is evaluated before overlap and batching. A false guard and overlap: skip each consume the accepted delivery identity and leave it deduplicated rather than eligible for redelivery.

Polling Initiation

wf.polling-initiation applies to a trigger whose manifest declares kind: poll. The initiation implementation invokes the resolved poll implementation at a configured cadence.

Cadence, backoff after poll failure, and operator controls are deployment configuration unless declared as trigger inputs; they do not enter workflow scope. A polling trigger owns an opaque cursor for each trigger binding.

The cursor MUST distinguish the upstream position from which polling will resume and MUST NOT be exposed as a Workfile value. The implementation MAY let an operator inspect or set it for backfill or recovery, but it MUST record such a change and apply it only to later polls.

Each returned item is a candidate event whose payload and delivery_id are validated exactly as for external initiation. Deduplication uses the same identity scope and retention rule.

Items are accepted in the stable order returned by the poll contract; that order governs queues and batch payloads. If the poll contract does not promise stable order, the initiation implementation MUST still obtain stable delivery identities from the poll implementation, and no order across separate poll responses is portable beyond their acceptance order.

The cursor MUST advance atomically with retained disposition of every item before the new cursor position. A crash can cause a fetch to repeat, but MUST NOT cause an accepted item to start a second run or cause an undisposed item to be skipped.

A poll failure does not itself start a run and MUST NOT advance the cursor past work whose disposition was not retained. An invalid item is unprocessable and starts no run.

The implementation MUST either hold the cursor at that item for operator action or retain an explicit quarantine disposition before advancing past it. It MUST NOT silently skip it.

Guard suppression and overlap: skip are valid dispositions and permit advancement. For cursor advancement, an item in an open batch uses the retained-disposition rule above; the batch and its closing deadline MUST survive the capability’s documented restart behavior.

Inferred Capability Requirements

Capability requirements are inferred independently for every resolved trigger entry:

Manifest kind	Required capability
schedule	wf.scheduled-initiation
external	wf.external-event-initiation
poll	wf.polling-initiation

Use of the trigger is the complete activation predicate; a Workfile MUST NOT declare these requirements separately. A multiple-trigger workflow requires the union even if one entry rarely or never fires.

Batching, queueing, guards, and overlap do not change which initiation capability is required. A Core Validator first validates trigger syntax and the resolved manifest contract without regard to target support.

An unknown kind, missing delivery identity, invalid payload declaration, invalid configuration, or invalid combination of trigger keys is an invalid document or dependency. If the Workfile is otherwise valid but the target deployment does not claim every inferred capability, Capabilities classifies it as unsupported and prohibits activation.

A diagnostic MUST identify each unsupported capability and trigger entry. Claiming an initiation capability asserts support for its activation, validation, acceptance, ordering, suppression, deduplication, batching, subscription-delivery, and restart requirements.

Merely parsing the trigger or forwarding it to a scheduler, webhook service, polling service, or suspended-run executor is not capability conformance.