Two systems, one athlete. That is the whole idea. My Positive Mentions System, built by Cam Hazzard and developed with Dennis Yu, finds and scores what people say about someone online. The Athlete Spotlight site factory builds their website. For weeks they ran side by side without talking to each other, which meant the best quotes about an athlete sat in a database while their proof page waited for someone to copy and paste.
So I wired them together, once, the safe way. This is how positive mentions now flow into an athlete’s website, read-only, human-gated, with zero copy and paste. It is the retention loop behind an Athlete Spotlight site, and it is built so the site tooling can never touch, break, or publish anything on its own.
Two systems, one athlete: the wiring loop
Four human gates. Read-only at the database. Zero copy and paste.
Step 1
Intake once
One intake form drives both systems. No re-typing.
AutoStep 2
Onboard the athlete
A person creates the subject and turns on the weekly digest.
Human gate 1Step 3
Weekly sweeps
Engine collects, scores, exports. The factory adds nothing.
AutoStep 4
Refresh proof feed
pma_feed.py (read-only) pulls ad-ready quotes into a DRAFT block.
AutoStep 5
Review and publish
Read every quote, verify the source, push it live.
Human gates 3 + 4What I connected, and why positive mentions matter
The assignment: make an athlete’s proof section refresh from the mentions knowledge base automatically, without ever letting automation publish, and without letting the site tooling anywhere near production data it could break. The sources were the production mentions engine (a permanent local database), the site factory’s template kit, and a wiring contract I wrote first.
The deliverable was two small bridge scripts, pma_feed.py (286 lines) and onboard_map.py (154 lines), shipped with the site factory on 2026-07-02. The goal category is the retention loop: a proof page that stays current on its own is the reason an athlete keeps their site, and positive mentions are the raw material.
How the loop runs, per athlete
In steady state, the loop is five steps and it repeats every week.
- Intake once. A paying athlete’s intake form drives everything. If they opted in,
onboard_map.pyconverts the intake into the mentions engine’s signup payload. One form, two systems, zero re-typing. - Onboard once (human gate 1). A person pipes that payload into the engine’s front door, because it creates the subject and enables the consent-gated weekly digest. Never automation.
- Weekly sweeps (automatic). The engine’s existing scheduler collects mentions across YouTube, Reddit, news, and podcasts, scores them with the marketability rubric, and exports. The factory adds nothing here.
- Refresh the proof feed.
pma_feed.pypulls the current ad-ready quotes into the athlete’s site package: a machine-readable feed plus a website-ready testimonials block, marked DRAFT in its own header. - Review and publish (human gates 3 and 4). A person reads every quote, verifies attribution at the source URL, trims platform openers, then pushes the reviewed block to the live page through a logged-in session.
Four human gates total, written into the contract as a table: onboarding consent, site-package review, quote review, and the live publish. Nothing in the loop auto-publishes, auto-emails, or writes to the mentions database.
The calls I’d defend
Read-only at the database level, not by promise. The bridge opens the mentions database with SQLite’s read-only mode. It cannot write, create, or migrate the database even if I ship a bug. The factory reads production; it never touches it.
Only usable rows leave the database. The filter is the same marketability-over-sentiment rule the digest and the activation tools use. One gate, shared everywhere. “Fire episode!” is data; it is never a deliverable. The research pile and hidden rows never reach an athlete-facing surface.
A synthetic pilot that can’t leak. The pipeline test athlete is fictional, so a fixture flag loads a clearly synthetic feed and never touches the database at all, and the onboarding script refuses fixtures outright. The fake athlete can never be onboarded into the real engine. I would rather the tooling be paranoid than fast.
DRAFT stamped into the output itself. The testimonials block carries a DRAFT header comment, so even the file tells you it has not passed review yet. The verify-before-publish rule applies before any top-tier quote goes live.
What it cost, honestly
Honest label: no token receipt exists for this build (the metrics extractor is still an open gap), so these are documented estimates.
| Task | Agent time (est.) | Human time (est.) | Agent cost (est.) | Human cost (est.) |
|---|---|---|---|---|
| Wiring contract plus 2 bridge scripts (440 lines) plus fixture and tests | ~2 hours of session time | 2 to 3 days for a developer | low single-digit dollars in tokens | $560 to $840 at $35/hr |
| Per-athlete proof refresh, ongoing | seconds per run | 30 to 60 min of manual quote hunting, weekly | ~$0 (keyless, local) | $17 to $35 per week at $35/hr |
The ongoing row is the real product. The one-time build is cheap; the compounding save is weekly, per athlete, forever.
What the agent did, and what a human owns
Autonomous: converting intake to the onboarding payload, pulling ad-ready quotes, rendering the feed and the website block, restyling cards to the site’s design tokens, and scrubbing em dashes by construction.
Human required: onboarding consent (gate 1), reviewing the site package (gate 2), verifying every quote’s attribution at its source URL (gate 3), and pushing the block live through a logged-in browser session (gate 4). Also profile photos: real ones, re-hosted, never hotlinked.
What the agent read
Read: the mentions engine’s usable-row predicate and database layout, the testimonial card shape I adapted, the template kit’s proof pattern, and the intake schema. Written: the wiring contract, the two bridge scripts, the fixture feed, and builder tests. Tokens: not measured (see the cost section). Voice profile: applied to this write-up, not needed for the scripts.
How it scores against our own gate
This article ran through the same 18-step gate we use on client work. Passing now: first sentence under 10 words, zero banned words, zero em dashes, contractions throughout, real numbers with estimates labeled, and the canonical parent linked (the Positive Mentions System). Still needs a human: the featured image (a screenshot of the rendered proof section is the obvious pick), Cam’s fact pass, and a live link check. Showing that list is the point of a meta article.
See it live, and get started
The proof loop lives inside every Athlete Spotlight website, and the mentions half of the weekly AI report runs on the same engine. This is one of three meta articles on that build; a companion covers how the report’s site-health half was built. The whole thing operationalizes the Perform stage of the Content Factory.
When you are ready, get started for $30 per month and your proof page starts refreshing from real, verified mentions once your site is live.
Dunking and business are the same game. You do the reps where nobody is watching (the sweeps, the scoring, the gates), so the highlight, a coach’s quote on your site, verified and current, looks effortless.
Built by Cam Hazzard, developed with Dennis Yu.