Group signal IDs deterministically without creating extra cloud jobs

A reviewer asks for signals grouped by severity. It is tempting to turn that request into several cloud jobs, separate storage locations, and a new delivery mechanism. Often the first useful artifact is smaller: one report listing the members of each logical group, with stable identifiers and counts. That lets the reviewer inspect the partition before anyone adds operational consequences.

I maintain the us-brand-signal-batch-splitter Actor. This walkthrough describes its published build 0.2.2, inspected on 16 October 2026. The example below is synthetic and reviewed against that contract; it was not executed for this article. AI-assisted drafting was followed by a separate factual and editorial review.

Despite its name, this Batch Splitter groups supplied rows by a declared field. It does not divide a list into arbitrary chunks of a requested size. Supported grouping modes are brand, eventType, severity, and analysisStatus. This complete five-field example chooses severity and uses the allowed unknown label. That label is a supplied enum value, not an inferred absence or an automatically assigned risk level.

{
  "schemaVersion": "1.1",
  "groupingMode": "severity",
  "rows": [
    {
      "signalId": "sig-1",
      "brandName": "Example Brand",
      "eventType": "other",
      "severity": "unknown",
      "analysisStatus": "unreviewed"
    }
  ]
}

The example belongs to one group whose key reflects the submitted severity. A multirow packet produces group entries containing their member signal IDs, counts, and group digests. It does not create another Dataset store or start a child Actor run for each group. If your pipeline needs actual fan-out, define and authorize that downstream behavior separately.

Case-sensitive labels matter. Brand grouping uses the submitted brand text; it does not resolve aliases or decide that differently spelled names identify one company. Event type, severity, and analysis status use closed enums. Normalize your source data intentionally before submitting it, and preserve that normalization rule with the packet. Otherwise a technically consistent grouping can still reflect inconsistent upstream labels.

Check totalRows, groupCount, and the sum of group member counts. Follow a few signal IDs back to the input. The report uses sorted group keys and sorted member IDs, while input signal IDs are also canonicalized in ASCII order. Each group digest binds its particular group, and the overall result digest binds the report contract. These are reproducibility aids over supplied data, not proof of good segmentation.

Input accepts 1–100 rows with unique signal IDs and a closed set of five ASCII fields. The canonical input cap is 64 KiB; the report cap is 48 KiB, with a separate receipt bound. Invalid or oversized packets fail rather than dropping the least convenient group. A downstream consumer should keep that failure distinct from a legitimate report with a small number of groups.

Use the grouping report to prepare a review queue: record the grouping mode, display a count next to each key, and let the reviewer inspect the member IDs. Keep the original packet available so a group label never becomes the only surviving evidence about a row. If a reviewer changes a label, regenerate a new explicitly versioned packet rather than editing only the displayed count.

The Actor does not assign business priority or verify brand identity. Its fixed decision-confidence field concerns the deterministic grouping operation, not whether a severity assessment is correct. That boundary makes the result useful as an intermediate artifact: the grouping rule is inspectable, its members are traceable, and any eventual assignment or delivery remains a separate step with a named owner and its own acceptance evidence.

On the observed FREE pricing tier, one result-found event costs $0.01 for the complete useful report or plan, rather than each input row. FREE is the tier name, not a promise of free execution. Automatic Actor-start pricing is also present at $0.005 per GB, with a minimum of one event. Check the Actor page and your account tier before running; this is not a fixed total invoice, and a failed or repeated run may still incur applicable charges.

To try this deliberately, open the Actor page, select build 0.2.2, and submit the JSON as input. Set an explicit spending ceiling appropriate to your account; for example, $0.05 is a ceiling, not a quoted run price or a guarantee of a delivered report. Save the returned run ID and verify its immutable build ID. A local timeout does not cancel the remote run: inspect that same run before considering another attempt. Read the completed run's Dataset report and its separate OUTPUT receipt together; structural output is not independent source verification.