Automated Publisher Approval: From Days to Seconds

Every publisher application that sits in your queue is a small, quiet cost. The good partner you kept waiting three days signs with a faster network instead. The fraudster you didn't have time to vet gets a live tracking link. And your team burns another afternoon opening the same handful of tabs — the applicant's website, a blocklist lookup, a privacy-policy check — to make a decision they'll make identically a hundred more times this month. Manual review feels careful. At any real volume, it's just a bottleneck wearing a lab coat.

The honest diagnosis: reviewing applications by hand does not scale, and throwing a large language model at the problem isn't automatically the cure either. What you actually want is a decision that is fast, consistent, explainable, and cheap — with the option to bring in heavier machinery only when a case genuinely calls for it. That's exactly how publisher approval works in TrackingMD.

The default is a deterministic rules engine, not AI

Let's clear up the most important point first, because most platforms get the marketing backwards. The shipped default evaluator in TrackingMD is a deterministic rules engine. It runs at zero cost per evaluation, it never calls a paid model, and it produces the same decision every time it sees the same evidence. AI evaluation exists — but it is strictly opt-in, something you switch on deliberately with an API key. Out of the box, no application is ever sent to a third-party model.

That default is set at the platform level. The evaluation strategy resolves to deterministic unless an environment explicitly overrides it, and the override is a single setting, APPROVAL_EVALUATION_STRATEGY. Leave it alone and you get the fast, free, fully explainable path.

Why lead with deterministic rather than AI? Three reasons that matter to anyone running a program at scale:

• Cost. Every evaluation is free. You can screen ten applicants or ten thousand without watching a metered bill climb.
• Consistency. A rules engine doesn't have an off day. The same site, reputation signals, and criteria always yield the same score — which is what you want when a rejected applicant asks why.
• Explainability. Every decision comes with its receipts: which checks passed, which failed, which couldn't be determined, and the evidence behind each. No black box, no "the model felt uneasy about it."

How the deterministic engine actually decides

When an application comes in, the engine does two things: it gathers evidence about the applicant, then it scores that evidence against your criteria.

Enrichment first. The engine performs a single, safety-guarded fetch of the applicant's website and pairs it with reputation lookups — threat analysis, blocklist checks, and domain signals — then caches that compact profile so repeated evaluations of the same site share one fetch. This is deliberately conservative: the fetch runs behind an SSRF guard that rejects non-public addresses, caps the response size, limits redirects, and times out quickly. An applicant who submits a private or malicious URL doesn't get to poke around your infrastructure; the attempt is simply recorded as "could not be safely fetched" and handled downstream.

Then the checks run. The engine ships with a library of built-in checks, each aimed at a common gate every program cares about:

• Site reachable — is there actually a live site behind the application?
• Privacy policy — does the site show the compliance basics you'd expect from a legitimate partner?
• Prohibited content — does the domain trip a threat blocklist or heuristic for malware, phishing, scams, or other content you won't run?
• Domain reputation — what do reputation signals say about the domain?
• Niche relevance — does the applicant's content line up with your program?
• Audience size — is there a real audience, or an empty shell?

Here's the part that makes it yours rather than a fixed template: you define your own approval criteria, and the engine maps each criterion to the first built-in check whose intent matches it. A criterion that no built-in check covers isn't guessed at — it resolves to unclear and is set aside for a human. Nothing gets a fabricated pass just to keep the pipeline moving.

Scoring you can defend

Each check returns one of three verdicts — pass, fail, or unclear — along with a plain-language reason and the evidence behind it. The scorer then turns those verdicts into a confidence score from 0 to 100.

The clever, conservative bit is how "unclear" is handled. Unclear criteria are excluded from both sides of the math — they neither help nor hurt the score. Confidence is simply the share of resolved criteria that passed. But there's a floor: if too few of your criteria resolved to a definite pass or fail (by default, fewer than half), the engine refuses to make an automatic call at all and routes the application to review — no matter how the raw number looks. A high score built on two answered criteria and six shrugs is not a decision you'd want made for you, so it isn't.

From there, two thresholds you control decide the outcome:

Both thresholds are configurable per organization, so a program that wants to auto-approve aggressively and one that wants to hand-check anything short of perfect can share the same engine with different dials. The whole thing runs in seconds, and every evaluation is stamped with the engine version that produced it, so a decision made today can be understood — and audited — months from now.

A few guardrails run quietly around all of this: a rejected applicant who reapplies within a day gets the existing decision rather than a fresh burn, and if there are no active criteria to score against, the application politely falls back to manual review instead of guessing.

When to layer in optional AI

The rules engine handles the clear-cut majority — the obvious approvals and the obvious rejections — in an instant. What's left is the genuinely ambiguous middle, and that's where you might choose to bring in a language model.

Turning it on is deliberate: set APPROVAL_EVALUATION_STRATEGY to the AI path and supply a provider API key. TrackingMD supports a primary provider with an automatic fallback, so a momentary outage on one doesn't strand your queue. Crucially, the AI path only activates when it's actually configured — if the strategy is enabled but no key is present, evaluations fall back to manual review rather than firing off a doomed request. AI is an addition to the funnel, never a silent dependency.

The right mental model is triage. Let the free, deterministic engine clear the volume it's built for. Reserve the paid model for the borderline cases where nuanced judgment earns its cost — and keep a human in the loop on anything the system honestly can't resolve.

The shift worth making

Manual review turns your team into a rate limiter on your own growth. Swapping it for a deterministic engine doesn't mean surrendering judgment to a machine you can't question — it means encoding the judgment you already apply into checks that run in seconds, explain themselves, and cost nothing to run. Approvals stop being a queue and start being a policy. The days-to-seconds gap you close isn't just an efficiency stat; it's every good partner you'll stop losing to a slower answer, and every bad one you'll catch before they ever send a click. Set your criteria, tune your thresholds, and let the fast path do the obvious work — so your people spend their attention only where it actually changes the outcome.