Choose first-match or all-matches routing before attaching any sender

Suppose one signal matches both an urgent-review rule and a broad catch-all rule. Should it receive one route or both? That question belongs in the routing contract before anyone attaches a notification sender. An inspectable route plan lets you resolve rule order, overlaps, and unmatched records while the outcome is still a set of labels rather than an external action.

I maintain the us-brand-signal-rule-router 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.

The Rule Router takes supplied signals, ordered rules, and a mode. firstMatch chooses the first matching rule; allMatches retains matches in rule order. Match bounds are inclusive and null fields are wildcards. The example uses one complete signal and one wildcard rule. All nullable match fields still need to be present. Its observation timestamp includes UTC milliseconds, as this contract requires.

{
  "schemaVersion": "1.1",
  "mode": "firstMatch",
  "signals": [
    {
      "signalId": "sig-1",
      "brandName": "Example Brand",
      "eventType": "other",
      "severity": "low",
      "confidence": 0.5,
      "sourceName": "Synthetic note",
      "country": "US",
      "analysisStatus": "unreviewed",
      "observedAt": "2026-10-01T08:00:00.000Z"
    }
  ],
  "rules": [
    {
      "ruleId": "rule-1",
      "routeId": "review-1",
      "eventType": null,
      "severity": null,
      "confidenceMin": null,
      "confidenceMax": null,
      "sourceName": null,
      "country": null,
      "analysisStatus": null
    }
  ]
}

The planned route is the buyer-defined label review-1. There is no destination URL, credential, or expression in this input. To reason about overlap, imagine placing a more specific rule before that wildcard. In first-match mode, the earlier matching rule prevents the catch-all from also being selected. In all-matches mode, both matching route labels can remain. These are contract-derived scenarios, not executed integration tests.

Rule ordering therefore belongs in your policy history. Reordering a rule list can change the first-match result even if every individual predicate is unchanged. The input digest preserves that semantic ordering. Signal ordering can be canonicalized separately, so do not assume all arrays in a deterministic JSON contract can safely be sorted without changing meaning.

Inspect each signal's matchedRouteIds, the unmatchedSignalIds collection, routeCounts, and warnings. An unmatched signal needs an explicit team policy: retain it for review, correct the packet, or adjust the documented rules. The router does not choose that business response. It accepts 1–50 signals and 1–20 rules with unique signal, rule, and route identifiers. Identifiers cannot be all digits.

This Actor's supplied confidence field is a number between zero and one, with limited decimal precision. That differs from the integer 1–100 input used by the separate Confidence Gate. Connecting the two requires a deliberate, documented conversion. The router does not calibrate scores, discover source provenance, or evaluate arbitrary code, regexes, or expressions.

Treat the output as a policy preview. Review the matching labels with the team that owns the eventual action, then keep the exact rules and mode alongside the returned plan. If a separate sender is later authorized, it should receive only reviewed route decisions and maintain its own delivery receipts. A route count is not a count of delivered messages.

The fixed decision-confidence value in the report describes a bounded computation over unverified input; it is not a measured routing success rate. The 256 KiB input and receipt limits also make this a small-packet tool. Oversize or invalid packets should return to the integration layer for a documented fix rather than being treated as an empty route plan. In particular, second-only timestamps must be corrected upstream instead of silently gaining invented milliseconds in a report.

On the observed FREE pricing tier, one result-found event costs $0.02 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.