Editorial status, verified September 4, 2026: This article documents bridge scripts and a gated prototype workflow. It does not prove scheduled runs, recurring weekly delivery, or automatic proof-page refresh for every paying member. The current $30 subscription does not include a weekly report. For an athlete age 13–17, the athlete must assent and the parent or legal guardian must approve.
Two systems, one athlete. That is the whole idea. The Positive Mentions System can find and score what people say about someone online, while the Athlete Spotlight site factory can build a website. The prototype tested a guarded bridge between those separate systems.
The prototype uses a bridge with read-only access and human approval gates. This article documents what the code can render when configured; it does not establish automatic proof refresh or recurring member delivery. The site tooling cannot publish or write to the mentions database 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
An adult approves directly; ages 13–17 require athlete assent and guardian approval.
Code pathStep 2
Onboard the athlete
A person creates a consented pilot subject; no purchased digest is activated.
Human gate 1Step 3
Pilot collection run
The engine can collect, score, and export when an authorized run is scheduled.
Code pathStep 4
Render draft proof feed
pma_feed.py can pull eligible quotes into a DRAFT block.
Code pathStep 5
Review and publish
Read every quote, verify the source, push it live.
Human gates 3 + 4What the prototype connects, and why positive mentions matter
The assignment: test whether an athlete’s proof section could be prepared from the mentions knowledge base without letting automation publish or letting site tooling write to production data. The sources were the mentions engine, the site factory’s template kit, and a wiring contract written 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. They demonstrate a draft-rendering path; they do not prove that every member receives a recurring proof refresh.
How the loop runs, per athlete
The prototype workflow has five steps when an authorized run is executed. Routine weekly member delivery has not been proven.
- Prepare an authorized intake. An adult athlete must explicitly opt in. For an athlete age 13–17, the athlete must assent and the parent or legal guardian must approve before
onboard_map.pyconverts the intake into a pilot signup payload. - Create the pilot subject (human gate 1). A person submits the authorized payload. This creates a pilot subject; it does not activate a purchased recurring digest.
- Run collection when authorized. The engine can collect mentions across supported sources, score them with the marketability rubric, and export. Scheduler capability is not evidence that every member receives a weekly run.
- Render a draft proof feed.
pma_feed.pycan pull eligible quotes into a machine-readable feed and a website-ready testimonials block marked DRAFT. A person still has to review and publish it. - 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 are defined in the contract: adult-athlete approval or, for ages 13–17, documented athlete assent and parent/legal-guardian approval; site-package review; quote review; and live publish. Nothing in the prototype auto-publishes, auto-emails, or writes to the mentions database.
The design decisions
Read-only in the tested code path. The bridge opens a configured SQLite database in read-only mode, which blocks writes through that connection. This is code-level evidence, not proof of a live production integration or recurring member delivery.
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. The tooling favors isolation over speed.
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 |
| Pilot proof-feed render, if authorized and scheduled | seconds per run | 30 to 60 min of manual review per authorized run | ~$0 (keyless, local) | $17 to $35 per authorized run at $35/hr |
The second row estimates the planned operating model. It is not evidence of routine paid-member delivery.
What the agent did, and what a human owns
Code capability: convert an authorized intake to a pilot payload, pull eligible quotes, render a draft feed and website block, restyle cards to the site’s design tokens, and scrub em dashes by construction.
Human required: approval from the adult athlete or, for an athlete age 13–17, documented athlete assent and parent/legal-guardian approval (gate 1); site-package review (gate 2); source verification for every quote (gate 3); and publication through a logged-in session (gate 4). Any profile or promotional image must be authorized for this use; public availability or re-hosting alone is not consent.
What the implementation used
Inputs reviewed for the prototype included the mentions engine’s usable-row predicate and database layout, the testimonial-card shape, the template kit’s proof pattern, and the intake schema. Outputs included the wiring contract, two bridge scripts, the fixture feed, and builder tests. Token use was not measured; see the cost section for the documented estimates.
How it scores against our own gate
This published revision is a dated prototype note, not a live-delivery case study. It carries explicit product-status and consent requirements. Any future promotional imagery or outcome proof requires recorded permission and source verification before it is added.
What the prototype demonstrates, and what remains
The prototype bridge can prepare a draft proof block for a configured Athlete Spotlight website, and the planned mentions half of the weekly findability report is designed to use the same engine; recurring customer delivery remains on the roadmap. 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.
The $30 subscription includes the managed site, hosting, HTTPS, a standard new .com under the published Terms, baseline entity markup, and one approved content request per paid month. Unused requests do not roll over. It does not currently include an automated recurring proof refresh or weekly report; follow the public roadmap for launch status.
Dunking and business are the same game. The collection run, scoring, review gates, and source check come before any approved quote can appear on a live site.
Internal prototype build, documented July 2, 2026.
Originally published .