Build a review queue without turning a priority into an executed action

I maintain this Actor. This is an AI-assisted technical walkthrough checked against the installed source contract.

A priority score can make a queue look operational before anyone has checked its evidence or owner. I want the proposed action, recorded source context, conflicts, confidence gaps, and human responsibility in the same review object. A neatly sorted row should not imply that a message was sent or a system was changed.

US Brand Action Queue reduces bounded buyer-supplied signal rows into one deterministic prioritized review queue. The commercial result is one complete Dataset report, rather than one paid result per submitted signal. It retains rule traces and evidence context while keeping consequential execution outside the product.

Begin with the explicit demo boundary

The input below is the Actor's synthetic demonstration. It describes a product-launch observation at example.com, carries a buyer-supplied team owner, and explicitly selects mode demo. It is useful for understanding the input shape and proposed review object. Demo processing is not proof that a real source was verified, a production queue was delivered, or an owner accepted responsibility. Demo mode does not disable billing: a cloud execution can still incur the start event and delivered-report charge.

The source URL, attribution object, confidence, and severity are supplied fields. A source status named verified_by_source is still an upstream assertion in this workflow. The queue does not independently visit that source or decide whether the asserted attribution is correct.

The owner object names a merchandising team in the demonstration. That label can guide review, but it does not establish account access, consent, assignment acceptance, or authority to act. Resolve the real operational owner in your team process before promoting an item into a task someone is expected to execute.

Make review instructions actionable

For each proposed action, a reviewer should be able to locate the source record, see what rule contributed to the priority, inspect conflicting observations, and understand any confidence gap. A high priority with weak evidence can be a reason to investigate promptly; it does not make the evidence stronger.

Keep the explicit scoredAt timestamp with the input. A rebuilt report based on the same frozen observation set should not be presented as a fresh external check. If the evidence window changes, prepare the corresponding authorized input and retain the relationship to the earlier queue.

Use the deterministic queue as a handoff artifact for a person or an existing internal workflow. Compare the proposed action with your organization's playbook, check whether another teammate already handled it, and decide how to record acceptance. Avoid wiring a sender directly to a queue row merely because the payload is structured.

Separate the stages in reporting

A prepared queue, an assigned task, an executed action, a delivered message, and an accepted outcome are different states. This Actor reaches the preparation stage. It does not contact people, modify a CRM, enrich entities, or verify destination-system permissions.

The Dataset report and KVS OUTPUT receipt answer complementary questions: what was proposed, and what the current run actually delivered and charged. Preserve both when troubleshooting an ambiguous execution. Deterministic business content does not create cross-run billing idempotency.

The useful result is a compact review queue whose priorities can be explained and whose remaining human decisions are visible. The team still owns the source checks, assignment, execution, and outcome evidence.

Input and execution boundary

Save this workflow-specific contract example as input.json. This is a synthetic contract example for the workflow described above; it does not assert a real observed business event.

{
  "schemaVersion": "1.1",
  "requestId": "action-queue-demo-001",
  "scoredAt": "2026-08-05T00:00:00Z",
  "items": [
    {
      "entityId": "example.com",
      "brandName": "Example Brand",
      "legalName": null,
      "domain": "example.com",
      "ticker": null,
      "cik": null,
      "aliases": [],
      "country": "US",
      "sourceEntityIds": [
        "demo:example.com"
      ],
      "eventType": "product_launch",
      "eventId": "demo-launch-001",
      "observedAt": "2026-08-04T10:00:00Z",
      "effectiveAt": "2026-08-04T10:00:00Z",
      "sourceName": "synthetic_demo",
      "sourceUrl": "https://example.com/launch",
      "sourceRecordId": "demo-launch-001",
      "evidence": {
        "facts": {
          "productName": "Example product"
        },
        "excerpt": "Synthetic demo evidence.",
        "additionalUrls": []
      },
      "confidence": 0.9,
      "severity": "high",
      "state": "active",
      "dedupeKey": "synthetic_demo|example.com|product_launch|demo-launch-001",
      "attribution": {
        "status": "verified_by_source",
        "proofType": "exact-domain",
        "proofValue": "example.com",
        "sourceEntityId": "demo:example.com"
      },
      "owner": {
        "ownerType": "team",
        "ownerId": "merchandising",
        "label": "Merchandising",
        "source": "customer"
      },
      "analysisStatus": "not_requested",
      "demoFixture": true
    }
  ],
  "options": {
    "mode": "demo",
    "maxItems": 10,
    "maxActions": 10,
    "includeResolved": true,
    "explanation": "off"
  }
}

A deliberate cloud execution can use the following asynchronous request. It creates a new run and may incur charges; this walkthrough did not execute it.

curl --request POST \
  'https://api.apify.com/v2/acts/zinin~us-brand-action-queue/runs?build=0.2.1&timeout=180&maxTotalChargeUsd=0.10' \
  --header "Authorization: Bearer $APIFY_TOKEN" \
  --header 'Content-Type: application/json' \
  --data-binary @input.json

Save the returned run ID. Check that existing run before retrying after a client timeout, then inspect its terminal status, Dataset, and KVS OUTPUT. A timeout in the caller does not cancel a server run. The charge ceiling bounds the request; it does not guarantee delivery or remove the start event. The build selector pins the observed build number, while the run's actual build ID should be retained for provenance.

Price and reproducibility

On 19 October 2026, the observed FREE-plan rates are $0.005 for the automatic start event and $0.02 per complete delivered report. The platform can count start events according to allocated memory. Other subscription tiers differ. Verify the current Actor page before purchasing a run; optional external services, where enabled, are separate.

This article uses the installed 0.2.1 source contract and saved public input shape, checked on the stated date. The arithmetic examples are explanatory, not fresh cloud acceptance, customer activity, or evidence of revenue. Preserve your input, actual build ID, observation boundary, and terminal receipt when adapting the workflow.