Make score threshold boundaries explicit before routing brand signals

A threshold policy often looks obvious until a score lands exactly on the boundary. One team reads “accept above 80”; another implements “accept at least 80.” The difference becomes a production argument unless the policy is explicit. A deterministic gate is useful when you already have scores and want a reproducible bucket assignment, with each decision tied to the threshold values used.

I maintain the us-brand-signal-confidence-gate 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 Confidence Gate consumes supplied integer scores; it does not produce or calibrate them. The accepted range for normalizedSignal is 1–100, rather than a floating-point probability between zero and one. Both threshold values use that same integer range, and the review threshold must be strictly lower than the accept threshold. The example intentionally puts its single signal exactly at the accept boundary.

{
  "schemaVersion": "1.1",
  "thresholds": {
    "acceptThreshold": 80,
    "reviewThreshold": 50,
    "thresholdOrder": "accept_gt_review"
  },
  "rows": [
    {
      "signalId": "sig-1",
      "normalizedSignal": 80
    }
  ]
}

With accept 80 and review 50, a supplied score of 80 belongs to the accepted bucket. A score of 79 belongs to review; 50 also belongs to review, and 49 belongs to rejected. These are contract-derived expectations for illustrative variations, not cloud run results from this article. The comparisons are inclusive at the lower boundary of accepted and review.

The thresholdOrder value declares the required relationship between the two thresholds. Reversing them, setting them equal, or silently converting a probability such as 0.8 into an integer would change or invalidate the intended policy. Perform any upstream score normalization explicitly and record that transformation before submitting rows to the gate. Otherwise a cleanly generated result can still encode the wrong business rule.

Read acceptedIds, reviewIds, and rejectedIds alongside each decision's outcome and reason code. The counts provide a consistency check for a submitted batch. Up to 100 rows are accepted with unique printable ASCII signal IDs; input and report caps are 96 KiB and 64 KiB. All valid rows remain represented rather than being truncated to the first few matches.

Rows are sorted by signal ID for canonical computation. Input, row, bucket-list, and result digests have different scopes. Version 1.1 adds a decision envelope that changes the result representation, so preserve the schema version in your audit record. Do not compare a legacy result digest to the newer envelope and interpret the difference as a changed score.

Use a policy table owned by the team that accepts the consequence of a bucket assignment. Record who chose the thresholds, when the policy applies, and which upstream score definition it expects. The Actor only evaluates the provided policy. An accepted ID is not independent evidence of a trustworthy source, legal eligibility, customer interest, or a profitable lead.

Before connecting a downstream action, have the reviewer inspect a small set of boundary cases on paper and compare the actual returned decision records when they choose to run them. Include the exact threshold values with any export. If a later policy uses 85 instead of 80, keep that as a new documented policy rather than rewriting the meaning of earlier accepted results. The fixed decision confidence field also has a different purpose from each supplied score.

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.