Governed approvals

Approvals is the governed control point for prospect-facing work. Every draft created by a campaign pass is parked inside its running Temporal workflow until an authorized person, a campaign-scoped delegated agent, or the approval timer resolves it.

What an approval contains

The shortlist is a compact account table. A label such as Skip · 19/100 is a deterministic qualification decision—not a contact ID or contact count. Select any row to inspect the account; rows marked as needing review open a focused draft workspace.

Approval email uses the same operator language: company name, domain, human-readable play, and Qualification n/100. Canonical company IDs remain available in audit evidence but are never used as the email's account label.

The review workspace combines the decision context:

• account and contact;
• judge score and recommended play;
• observed trigger and why now reasoning;
• proposed subject and message body;
• owning Temporal workflow ID, available under Audit details;
• shortlist context for the surrounding campaign pass.

The primary views are:

• Draft — preview, edit, or compare the subject and body;
• Why this account — inspect the trigger, ICP fit, score dimensions, policy reasons, facts, and sources;
• Suggested play — inspect the selected offer and exact governed proof version;
• Audit details — inspect workflow, draft, policy, prompt, and content-hash lineage.

Use the trigger and account history as the standard of truth. The draft should make sense because of the evidence—not merely because it sounds polished.

Available decisions

Approve decision

Accepts the draft as written. In a dry-run pass the button explicitly states that no email will be sent. In a live pass it states that approval queues governed delivery; suppression, inbox ramp, daily cap, idempotency, and provider policy still run afterward. V2 first stores the actor and decision details in tenant-scoped Lakebase, then sends Temporal a compact decision ID and draft ID.

Approve edited

Use Edit for a full-width editor, Preview for the recipient-facing result, and Compare for current-versus-proposed copy. Approve edited persists the edited subject and body with the durable decision command so the audit history reflects what was actually approved. Message content and reviewer identity do not enter Temporal history.

Reject

Closes the pending draft and lets the workflow continue resolving the remaining queue. Select Reject first, then choose and confirm the reason. Rejection is an explicit outcome; it is preferable to leaving an unsuitable draft pending. A future pass may create a materially different revision only for a versioned prompt change or a copy/claim-related rejection. Unresolved and approved drafts cannot be redrafted, and the platform enforces a three-revision ceiling.

Approval does not bypass policy

After approval, the workflow still invokes the governed action pipeline:

authorized principal decision
  → action validation
  → suppression policy
  → inbox ramp and daily cap
  → idempotency check
  → delivery adapter
  → touch + audit event

An approved draft can still be blocked when the domain is suppressed, the inbox is not ready, the action was already performed, or required delivery configuration is missing.

Review checklist

Before approving, confirm:

• The account fits the intended ICP.
• The signal is recent, specific, and attributable.
• Why now is supported by the signal and history.
• The contact is relevant and the address is appropriate.
• The message quotes or clearly uses the real trigger.
• The draft does not invent metrics, relationships, or intent.
• The account is not suppressed and has not opted out.
• The wording is appropriate for a first touch or follow-up.

Example edit

Weak draft:

Subject: Transform your data strategy

We help innovative companies unlock AI and data value. Would you like to connect?

Trigger-grounded edit:

Subject: Your Director of Data Platform search

I noticed Northstar is hiring a Director of Data Platform in Austin. Teams making that hire often need
an operating model for shipping the first governed workloads while the platform group is still forming.
Would it be useful to compare the approach we use on Databricks?

The second version gives the recipient a verifiable reason for the message and a specific conversation.

Durable behavior

Closing the browser does not release or lose approvals. The queue is reconstructed by querying running tenant-prefixed workflows and loading their pending draft IDs from the durable store.

Agent decisions use the same queue. The gateway verifies the registered principal, exact campaign scope, grant expiration, workflow tenant/type, and draft binding before it stages the private decision and sends the compact signal to Temporal. The actor and resulting AssetEvents remain visible in the audit trail.

Next: Campaign pass, Governance, and Accounts.