Short answer: for media support tickets that include an image, keep classification, policy enforcement, and tenant cost accounting as three separate steps.
Send the image to a multimodal chat model with a strict JSON Schema, validate the returned object locally, and send invalid or uncertain cases to review.
The fallback is a queue, not a guess.
That design matters because a support agent is usually triaging a complaint, not publishing a photo.
The same upload might be evidence of a violent broadcast, a screenshot containing a hate symbol, or an ordinary account avatar.
A boolean called throws away the context that the agent needs.
Keep it boring.
How can a Node.js image moderation flow classify risky uploads without trusting JSON?
Start with a versioned taxonomy.
For this media workflow, I would keep , , and as separate observations, add , and retain a short evidence string.
The model describes what it can see; application code decides whether a ticket is visible, blocked, or waiting for a human.
This boundary also makes an eval harness useful: a prompt change can be tested independently from the enforcement policy.
The tempting shortcut is to ask for a sentence and search it for words.
It feels flexible in a notebook, then becomes difficult to replay: punctuation changes the parser, a missing category looks like a negative result, and a tenant's policy cannot be reconstructed from a free-form answer.
Typed output is not a safety decision, but it gives the rest of the pipeline a stable input.
Here is a deliberately small adapter.
The surrounding Node.js upload service can call the same contract from any language; the example keeps the model call behind an OpenAI-compatible chat client and uses environment variables for the concrete base URL and model.
It does not publish an upload merely because the response parses.
The production adapter still needs upload-size and MIME validation before the model call, access controls around stored images, and a timeout policy at the worker boundary.
A rate limit, empty response, or schema mismatch belongs on the same review path as visual uncertainty.
Avoid logging the image or sensitive ticket text into ordinary application logs.
Where do tenant cost visibility and moderation policy meet?
Per-tenant cost is a decision axis, not a reason to weaken the classifier.
Make one moderation record for each image attempt, keyed by tenant, ticket, policy version, model version, and request ID.
Record input and output token counts when the provider exposes them, plus latency, retry count, result status, and review outcome.
The resulting ledger answers questions that a monthly invoice cannot: which tenant sends the largest images, which policy creates the most reviews, and whether a prompt edit increased tokens without improving recall.
I keep the accounting record beside the decision record, but I don't let it choose the label.
A large customer may need a stricter review SLA; that is an operational rule, separate from whether an image contains violence.
Token counting can be estimated before launch with , then compared with the runtime usage fields.
Estimates are useful for experiments, not a substitute for the provider's measured usage.
Choice Helps with Cost or limitation to verify Multimodal chat plus a schema One adaptable interface for image evidence and a small typed result The application owns taxonomy, validation, and enforcement Dedicated moderation classifier A maintained safety taxonomy and a focused review workflow Its labels may not map cleanly to a media team's policy Self-hosted vision model Keeping images inside an organization's boundary The team owns serving, model updates, calibration, and evaluation Human-first triage Ambiguous context, appeals, and high-impact decisions Queue volume and response time need an explicit service target The catch is that a single cost metric can reward the wrong optimization.
Shrinking prompts may reduce token usage while increasing results and review