Compose a severity brief with an explicit snapshot clock

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

A daily brief needs a clear clock. The time an automation ran and the timestamp the analyst chose for the snapshot are different facts. If those values are mixed, a reproduced brief can appear to contain newly observed evidence even when it was rebuilt from the same frozen rows.

US Brand Signal Brief Composer takes one explicit snapshot timestamp, one title, and one to 50 unique event rows. Each row has an event ID, uppercase severity, source label, summary text, and active or resolved status. It composes a deterministic report with four severity sections. It does not fetch source material or use an LLM to rewrite the observations.

Read the example as supplied claims

The synthetic input below contains a HIGH product announcement summary and a MEDIUM price-change summary. The title and source labels are supplied demonstration strings. They do not establish current activity by the named brand. The explicit snapshotAt value is also supplied; it is not a fresh collection timestamp.

The Actor uses snapshotAt as generatedAt in the report. Rebuilding the same snapshot should therefore remain anchored to the same declared time. If you want a new observation period, prepare a new input with the appropriate evidence and timestamp rather than treating a repeated execution as a new source check.

Severity values are the closed uppercase categories CRITICAL, HIGH, MEDIUM, and LOW. The report retains all four sections, including empty ones. Within the projections, deterministic ordering makes it possible to compare output without attributing meaning to accidental input order.

Separate presentation from editorial judgment

The composer organizes the severity already assigned upstream. It does not establish that HIGH is justified, resolve conflicts between sources, or turn a short summary into verified evidence. A useful upstream record should retain the source material and the reviewer responsible for the severity assignment.

The report includes event projections, severity counts, top-event ID lists, and unique supplied source labels. A top-event list is a compact navigation aid based on the contract's ordering. It is not a model's independent ranking of commercial significance. Keep the associated source records accessible through your own event ledger.

If two events share an ID, repair the upstream export. A deterministic brief depends on stable identity; changing an ID to evade a collision can make the same underlying observation appear as two separate events. Similarly, editing summary text changes the content being bound into the report even when the business event ID stays the same.

Review before distribution

For an operations handoff, inspect one event in each occupied severity section. Check its wording against the source evidence, verify active versus resolved state, and confirm that the snapshot timestamp matches the intended review period. Then decide who should receive the brief using your normal communication process.

The Actor produces a structured brief, not a sent message. Keeping composition and distribution as separate steps makes the remaining work visible: source verification, editorial approval, recipient selection, and actual delivery each need their own 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",
  "snapshotAt": "2026-08-05T00:00:00Z",
  "title": "Nike US signal brief",
  "rows": [
    {
      "eventId": "nike-launch-001",
      "severity": "HIGH",
      "sourceName": "Brand newsroom",
      "summary": "New running product announced",
      "status": "active"
    },
    {
      "eventId": "nike-price-001",
      "severity": "MEDIUM",
      "sourceName": "Retail monitor",
      "summary": "List price changed for a tracked SKU",
      "status": "resolved"
    }
  ]
}

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-signal-brief-composer/runs?build=0.2.2&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.01 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.2 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.