Campaign pass workflow

A campaign pass is the unit of GTM work. It is implemented as a Temporal workflow so retries, application restarts, approval delays, and partial provider failures do not erase the execution state.

End-to-end flow

A live operator request is accepted only for an immutable live campaign version and only when the authenticated organization admin supplies an explicit live request. The API mints a bounded campaign.operator proof for that exact tenant, actor, and workflow command; the canonical action verifies the proof again inside the Fabric Platform mutation pipeline. Scheduled agents can initiate dry runs, but cannot manufacture this proof or launch live delivery. The standalone CLI is dry-run only.

Phase 1: learning

The workflow loads current signal weights and copy-variant performance. Learning happens before sensing so the current pass uses the most recent outcome evidence.

Phase 2: sensing

The selected signal adapter fetches market events. The store deduplicates stable source IDs, upserts accounts, and attaches contacts where available.

A provider retry can return the same event without creating duplicate work.

Phase 3: judging

For each account, the judge receives:

• new signals;
• prior signal history;
• touches and outcomes;
• ICP configuration;
• learned bucket weights.

It returns a bounded score, recommended play, and why now. Weak, off-ICP, or poorly timed accounts should receive a low score or no action.

Phase 4: drafting

The drafter receives the verdict, contact, and actual trigger. It writes a first touch or follow-up and persists it with pending status. The immutable record includes the prompt version, proof version, content hash, redraft-policy version, and one-based revision number.

A later pass cannot create a parallel approval for the same company, fact, and offer. An unresolved draft blocks a duplicate, and an approved draft permanently closes that opportunity. A rejected draft may be revised only when the prompt policy changed or the reviewer selected a copy/claim-related reason. The replacement must have a different content hash, and the platform permits at most three revisions. These are platform safety limits; a tenant prompt cannot override them.

Phase 5: awaiting approvals

The workflow publishes a queryable shortlist and pending draft IDs, then waits for approveDraft signals. This phase can last longer than the Databricks App process that created it.

V2 first persists the private decision in tenant-scoped Lakebase. Temporal receives only the compact decision reference:

{
	decisionId: string;
	draftId: string;
  approved: boolean;
	rejectionReasonId?: string;
	schemaVersion: 2;
}

Phase 6: resolving

Approved drafts run through action policy and delivery. Rejected or expired drafts are killed. The workflow records resolution for every pending ID before completing.

Dry versus live

The application starts dry passes. Live mode is a deliberate operator/deployment decision gated by staging:preflight and go-live-check.

Atomic live promotion

A campaign version moves from dry-run to live through the gtm.promote_campaign_live governed action, which clears dryRun and sets status: "active" in a single durable transition. The action requires a principal authorization proof whose subject binds it to this exact mutation (action ID plus a hash of the action parameters), so a proof minted for a different action or different parameters is rejected. The action also verifies the execution manifest hash, requires an active ICP, refuses an already-active version, and pauses any prior active version of the same campaign in the same transition. One gtm.campaign.promoted_live snapshot carries the whole change, so no observer can see a half-promoted state.

This action is human-governed and intentionally excluded from the external-agent catalog. Agents cannot promote a campaign to live delivery. Use campaign:preflight-live to verify readiness and obtain the manifest hash before authorizing promotion.

Failure and retry behavior

• Temporal retries retryable activities according to their activity policy.
• Stable signal and action identifiers prevent duplicated side effects.
• A worker restart resumes from durable workflow history.
• Missing approval never becomes implicit approval.
• Provider failures surface in the workflow rather than silently switching a live pass to another vendor.

Next: Human approvals, Governance, and Runtime architecture.