Aggregate signal counts without presenting submitted confidence as accuracy

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

A signal dashboard often mixes two different quantities: how many rows arrived and how confident their producer claimed to be. Counting the rows is straightforward. Treating the average confidence as observed accuracy is a separate claim that requires labeled outcomes.

US Brand Signal Metrics Aggregator keeps this step bounded. It accepts one to 100 signal rows with a unique signal ID, event type, severity, source name, integer confidence basis points, and active or resolved status. The categories are closed enums. A misspelled category is an input defect to fix rather than a new dashboard bucket to quietly create.

Start with three explicit observations

The synthetic input below has one product launch, one price change, and one review observation. Two rows are active and one is resolved. The submitted confidence values are 9200, 7600, and 4800 basis points. Their average is 7200 basis points, or 72 percent on the submitted scale.

That arithmetic tells us the mean of three supplied values. It does not show that 72 percent of the observations are correct, that the upstream scores are calibrated, or that a 9200 row should trigger an automated decision. Preserve the scoring method and validation evidence outside this aggregate when those questions matter.

The source labels in the example are also supplied strings. Two rows attributed to a retail monitor do not establish two independent sources. They may originate from the same collection process or even the same underlying page. A count by source label is useful for tracing an export, provided its meaning stays visible.

Reconcile the complete export

Before accepting the report, compare the overall row count with the count in your input ledger. Reconcile the event, severity, and status counts independently. Explicit zero buckets are useful because they distinguish a supported category with no observations from a category that the schema does not recognize.

If an upstream job sends a duplicate signal ID, repair the export or its identity rule. Giving a duplicate a new ID just to pass validation changes the denominator. A valid unique ID is necessary for deterministic processing, but it does not prove that the underlying event is unique.

A useful operations review might ask why the proportion of resolved observations changed between two weekly exports. Keep the observation window and upstream inclusion rule with both exports. This Actor computes one submitted report; it does not maintain a historical baseline or establish that different weeks cover the same population.

For a team handoff, attach the input hash, report, source-label dictionary, and definition of confidence. Note any upstream scoring change before comparing averages. A change from an expert rubric to a model score can make a trend line discontinuous even when both systems emit integers in the same range.

The outcome is a reproducible count report and a clearly labeled mean of submitted confidence. Measured correctness remains a separate evaluation against independently established outcomes.

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",
  "rows": [
    {
      "signalId": "nike-launch-001",
      "eventType": "product_launch",
      "severity": "high",
      "sourceName": "Brand newsroom",
      "confidenceBps": 9200,
      "status": "active"
    },
    {
      "signalId": "nike-price-001",
      "eventType": "price_change",
      "severity": "medium",
      "sourceName": "Retail monitor",
      "confidenceBps": 7600,
      "status": "resolved"
    },
    {
      "signalId": "nike-review-001",
      "eventType": "review",
      "severity": "low",
      "sourceName": "Retail monitor",
      "confidenceBps": 4800,
      "status": "active"
    }
  ]
}

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-metrics-aggregator/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.