Counting Every Classifier Execution in a Moderation Cascade

An anonymous moderation engagement separating model escalation, stage-execution cost and the quality evidence required for early exits.

The decision was which images needed another classifier

A content-moderation system sent images through a heavyweight ResNet classifier running on GPU infrastructure. Ampity's work on this anonymous engagement introduced a tiered approach: a lightweight CPU classifier handled the first decision, an intermediate model handled escalations, and a heavyweight classifier handled the remaining ambiguous inputs. Existing labeled material supported work on the lighter models.

The engineering decision was not simply whether a smaller model was cheaper to run. It was which inputs could stop at each stage without violating the moderation task's quality and latency requirements. An early exit changes the decision path, the work executed and the evidence needed to accept that path.

This case describes that scope and a way to review its economics. It does not claim a measured saving, preserved accuracy, throughput or delivery duration. The synthetic ledger below is a calculation aid, not a reconstruction of the customer's bill.

Keep the simple baseline in the comparison

Running the heavyweight model for every input supplied a simple execution path, but did not distinguish straightforward inputs from ambiguous ones. The team selected a cascade to make that distinction. It accepted additional model maintenance, routing and quality-review responsibilities in exchange for the possibility of avoiding later-stage work.

For another team, retaining the flat path remains a legitimate alternative when its operating cost is acceptable or labels cannot support an early-exit decision. A separate router that sends each image to exactly one model is another possible architecture. It needs its own routing evidence and must not be priced as though it were a sequential cascade.

The account establishes a light-to-heavy design, not the exact deployed thresholds, model revisions or error-handling rules. Those details matter before using any stage-cost estimate to make a production decision.

A confidence score is not a correctness result

Each exit needs an explicit decision rule: which model version ran, which label or score was produced, whether the input stopped or escalated, and what happened when a response was missing or unusable. The policy must also distinguish a confident safe decision from a confident violation decision. Neither should be inferred merely from a low processing cost.

Changing a classification threshold changes false positives and false negatives, as Google's threshold guidance explains. A high score does not establish that the decision was correct on the population being reviewed. Acceptance requires independently labeled examples and the moderation owner's definition of an unacceptable error.

Evaluate the paths separately. An aggregate accuracy value can conceal errors concentrated among early exits or a minority class. Google's precision and recall guidance explains why overall accuracy can be misleading with imbalanced classes. It does not supply a universal acceptance threshold for moderation.

Count stage executions, not only final destinations

Consider a clearly synthetic batch of 1,000 inputs. All run stage A, 400 continue to B, and 100 continue to C. Assume illustrative processing charges of 2, 10 and 30 budget units per 1,000 executions at the respective stages. These units are not provider prices, customer costs or a forecast.

The calculation is 1,000 × 2 / 1,000 + 400 × 10 / 1,000 + 100 × 30 / 1,000 = 9 units. There are 600 final exits at A, 300 at B and 100 at C. Pricing only those final exits produces 7.2 units, but omits earlier work on escalated inputs. That calculation describes a different execution assumption and understates this example's stage charges.

The ledger excludes orchestration, idle capacity, retries, storage and human review. It cannot establish total operating cost or savings against a baseline. Use the separate cost-per-completed-task model when the decision needs those wider costs and an accepted business outcome.

Join the cost record to the quality record

For a comparable review, attach a sanitized batch identifier, input population, model revisions and routing-policy revision to the stage counts. Count attempted executions and retries under the same cost convention. Record missing telemetry as UNKNOWN rather than treating an absent stage record as a free early exit.

Keep the evaluation record separate but joinable: reference-label provenance, the permitted sample, decisions at each exit, disagreements and unresolved labels. Different input populations or policy versions cannot establish an improvement merely because their average costs differ. A distribution change can alter both escalation volume and error rates.

Latency also follows the executed path. A final-stage input has already encountered earlier work. The account does not establish queueing, batching or parallelism settings, so adding isolated model runtimes would not establish the customer's request latency.

Review a path before changing its authority

Start with approved configuration and aggregate execution records supplied by their owners. Do not collect moderation payloads, adjust thresholds or run production classifications merely to complete this review. The quality owner should define the permitted labels, error categories and release decision; the platform owner should define the cost population and missing-data treatment.

Any later replay needs separate approval for an isolated target, permitted synthetic or otherwise approved data, scoped identity, inert moderation and notification receivers, and bounded cost. Stop if it can publish a decision or trigger a live customer action. Returning traffic to an older model does not undo moderation decisions already applied.

The next action is one reviewable batch: reconcile its stage executions, identify the matching quality record, and assign the first UNKNOWN to an owner. Hold a proposed early-exit change when its cost or quality path cannot be reconstructed. This produces a decision about the next review, not a claim that a cheaper route is ready to enforce moderation policy.

Technical reference

Google's classification-threshold and precision/recall documentation was checked on 18 October 2026 for the general evaluation mechanisms linked above. The worked budget units and batch counts are synthetic. These references do not establish this engagement's thresholds, execution distribution, billing or measured results.