SponsorLint

Inspiration

Sponsored creator integrations look simple until one tiny mistake forces another revision.

A creator can record a perfectly good segment and still miss a required product name, say 70% instead of 73%, forget a campaign URL, use wording the sponsor explicitly prohibited, or place a call-to-action in the wrong part of the video.

The problem is that sponsor briefs are written for humans, but checking a finished video against them is still mostly manual: open the brief, scrub through the recording, compare every requirement, and hope nothing was missed.

We wanted to turn that brief into something executable.

A sponsor brief is a contract. SponsorLint makes it executable.

What it does

SponsorLint is pre-flight QA for sponsored YouTube integrations.

The workflow is deliberately split into three trust boundaries:

AI proposes → You approve → Code enforces.

Upload a sponsor brief as PDF, Markdown, text, or pasted copy.
Gemini converts the brief into a structured proposed specification.
Every extracted rule includes the literal source sentence it came from.
The creator reviews, edits, adds, or deletes rules before approval.
Upload the recorded sponsor segment.
faster-whisper produces a timestamped transcript.
SponsorLint runs deterministic validators against the approved specification.
The creator gets a timestamped evidence report with a readiness state:
- DO NOT SEND
- REVIEW
- SPONSOR READY

The LLM never sees the transcript and never decides whether a sponsor cut passes.

Verification is deterministic.

What SponsorLint checks

SponsorLint currently supports six executable requirement types:

MUST_SAY — required phrases or product names
MUST_NOT_SAY — prohibited wording
EXACT_VALUE — exact discounts, values, or codes
MUST_DISCLOSE — sponsorship disclosure
DURATION — required integration length
URL_OR_CTA — campaign URLs, promo codes, and calls-to-action

Some requirements cannot honestly be verified from audio, such as whether a product interface stayed visible for five seconds.

SponsorLint does not pretend otherwise.

Those requirements are surfaced as human review items, and unresolved manual checks keep the final state at REVIEW.

The demo

Our sample campaign intentionally contains subtle mistakes.

In the first cut:

the creator says 70% instead of the required 73%
Shield Mode is never mentioned
the prohibited phrase completely anonymous is used

SponsorLint produces:

4 / 7 automated requirements passed → DO NOT SEND

The corrected version fixes those lines and produces:

7 / 7 automated requirements passed

If the remaining visual requirement has not been manually confirmed, SponsorLint still stops at REVIEW rather than inventing certainty.

That fail-closed behavior is intentional.

How we built it

SponsorLint is built around a strict separation between probabilistic extraction and deterministic enforcement.

Brief compiler

The compiler uses the Gemini API with structured output to propose a Pydantic-backed specification.

The model only sees the sponsor brief.

Every generated requirement must contain a source quote that literally occurs in the submitted brief. Invented citations are rejected rather than silently trusted.

The creator must then approve the specification before verification.

Media pipeline

Recorded MP4s are processed with:

ffprobe for authoritative media duration
faster-whisper base.en for timestamped transcription

Our real-media validation used raw Whisper output with no transcript cleanup.

Deterministic verifier

After approval, there are zero LLM calls during verification.

The verifier uses explicit normalization and six deterministic validator types. Numbers, URLs, promo codes, disclosures, duration windows, and required/prohibited phrases are checked independently and produce structured evidence.

A finding can therefore explain:

what was expected
what was detected
where it occurred
the relevant transcript evidence
the source sentence from the original sponsor brief

Web application

The judge-facing workflow is built with:

FastAPI
Jinja templates
vanilla JavaScript
Pydantic
Python

We intentionally kept the architecture lightweight instead of turning it into a large SaaS platform.

Challenges we faced

Speech recognition is messy

Whisper may produce digits in one sentence and number words in another.

For example:

73%, 73 percent, and seventy-three percent

need to represent the same expected value without allowing 70% to pass.

URLs create a different problem: fuzzy matching is dangerous because aegisvpn.com/alex and another URL are not “close enough” — one is simply wrong.

SponsorLint therefore uses different normalization strategies for human language and identifiers.

False passes are more dangerous than false failures

For this product, incorrectly approving a broken sponsor read is worse than asking a creator to review something uncertain.

That shaped the verifier.

Ambiguous cases are routed to REVIEW instead of being optimistically accepted.

The human approval boundary matters

We did not want an LLM to silently transform a vague sentence like “near the beginning” into an arbitrary number.

During our live Gemini compilation, qualitative placement rules were surfaced for human review. We explicitly approved the first/last 15-second thresholds before they became enforceable rules.

That interaction became one of the central ideas behind SponsorLint.