Tag: Athlete Spotlight

  • The Athlete Spotlight User Journey: Checkout to Live Site

    Athlete Spotlight turns a $30 per month sign-up into a real personal brand website on the athlete’s own domain, built from everything findable about them, delivered with an honest audit, and improved every week after that. This article is the full map of that journey: what the athlete does, what our agents do, and where a human has to step in, from the checkout screen to the change request they send us six months later.

    We are writing this down for two reasons. First, so every athlete knows exactly what they are buying and what happens next, with no two-month silence and no surprise reveal. Second, so our own team and our agents follow one standard. Each time we onboard an athlete, that run gets documented as its own case study with real numbers attached (sales, traffic, rankings, and the weekly report). This is the standard those case studies point back to.

    What the Athlete Spotlight journey is

    The journey is the end-to-end path an athlete travels with us: they find the site, pay through our Keap checkout, buy their own domain, hand us their content and story, and our system builds their WordPress site from that plus everything already published about them online. We deliver the site alongside an audit, then keep improving it through a change-request loop and a weekly AI report.

    It is one journey, but it has honest edges. Some steps run today with no human babysitting. Others are drafted and being wired in. We name both, because a standard that pretends everything is automated would be a standard nobody could trust. The gaps below are the build order, not a disclaimer.

    The whole thing sits inside the Content Factory methodology (Produce, Process, Post, Promote, with Perform as the measurement loop). The site is the entity home; the weekly report is the Perform stage made systematic for one athlete.

    Step 1: Discover and decide

    The athlete lands on theathletespotlight.com. They see the roster (real athletes, including the lighthouse example, camhazzard.com), the What’s Included breakdown, and the price: $30 per month, no contract. Many arrive through a figurehead’s referral code, which applies 20% off (for example, code CAM), with a 50/50 revenue split behind the scenes.

    The one thing this step still needs is the promo video. A short clip from an athlete explaining what Athlete Spotlight does is committed and not yet recorded. Until it exists, the page leans on the roster and the written What’s Included section to make the case.

    State: LIVE (page and roster), with the promo video still to record.

    Step 2: Checkout

    Checkout runs through Keap today. The athlete clicks Get Started, lands on the Keap checkout for the Athlete Spotlight product ($30 per month), and if they came through a figurehead code, the 20% discount applies. Keap generates the order and the receipt, and the order lands in a queue. Parents are welcome to check out on an athlete’s behalf, which matters because a large share of our audience is 14 to 18 years old and their guardians decide and pay.

    Here is the first honest gap. Today, nothing automated fires the moment payment clears. The athlete pays, and the next move is manual. The fix is a post-payment thank-you page or email that routes the athlete straight into intake (step 3). We are reusing an existing Keap campaign pattern for this rather than building a parallel automation, so the work is coordination, not net-new plumbing.

    State: LIVE (checkout), WIRING (the automatic hand-off to intake).

    Step 3: Intake

    Right after checkout we collect what the site is built from: name, sport, position or class year, location (sport plus location feed the network-linking strategy), social handles, five to ten best clips as links, photos, the athlete’s story in their own words, and proof (stats, awards, camps, coaches, press, sponsorships). We also capture the goal persona, because a recruit and a sponsorship-seeker get a different site emphasis. The canonical field set lives in the intake schema the site factory reads from.

    The story fields are collected in the athlete’s own first-person voice and rendered close to verbatim. We do not rewrite a 16-year-old’s story into corporate copy. The open question here is the surface: a form, an email reply, or a DM-style capture. Dennis’s guidance is blunt and correct: young adults will not email. A form is the near-term answer; a DM-style surface comes later.

    State: WIRING (spec is done: 43 fields, required set, and hand-off format; it drops into the post-payment Keap flow).

    Step 4: Domain

    The athlete buys their own domain, roughly $12 a year at any registrar. Owning the domain matters: the SEO value and the entity home live on an asset the athlete controls, not on a subdomain we lease to them. We reply with the four nameservers to paste into their registrar’s DNS settings, the same process the team has run hundreds of times.

    The draft nameserver email is written (registrar steps, a generic fallback, placeholder nameserver values, and a short how-to video link). Two things stay open: who sends it, and the actual per-athlete nameserver values, which come from provisioning once a hosted zone exists for that athlete.

    State: LIVE (the process is proven), WIRING (the email template’s sender and the per-athlete values).

    Step 5: Build and audit

    This is the machine. The order, the intake, and the domain come together into a provisioning decision, and the site gets built on the company platform (WordPress, provisioned through BlitzAdmin, the company’s site builder). The system builds from the intake AND from everything findable about the athlete online, and it runs an audit at the same time. This is the Dunk Camp pattern: deliver the site and the authority audit together, not weeks apart.

    Our tooling plugs in here. The site factory template kit supplies the nine-section homepage and the full page set. Entity schema (a Person record and per-page schema types) tells Google and AI engines who the athlete is. A QA gate blocks the build on real problems (banned words, unresolved template tokens, missing alt text, broken internal links, stale hand-coded blog cards). The Rank Math loop lifts every page toward the green score. The positive-mentions feed supplies the proof section. The site standard behind this step is its own article: how we build an athlete personal brand website documents the nine-section homepage, the page set, the schema, and the QA gate in full.

    The open seam is the exact hand-off between BlitzAdmin provisioning and our site-factory content pipeline. Cam now has a BlitzAdmin login and the mapping of that seam is the next investigation.

    State: LIVE (the site factory tooling, the audit pattern, the QA gate, the Rank Math loop), WIRING (the BlitzAdmin provisioning hand-off).

    Step 6: Delivery

    We send a delivery message: congratulations, here is your site, here is your audit, and here is what to know. Crucially, this message sets the expectation that the athlete will want changes, and shows them exactly how to ask. It also carries the fix-at-the-source coaching, because the site reflects the internet: if a bio or a photo is wrong on a source platform, it should be corrected there too, not just on the site.

    The delivery email draft is done (site link, audit, fix-at-the-source coaching, the change-request path, and the referral hook). One wording decision stays open: the athlete-level referral split. The 20% off with figurehead codes is confirmed; the percentage a regular athlete earns for a referral is not, so the copy stays vague on that until Cam and Dennis lock it.

    State: WIRING (draft done; referral-split wording pending).

    Step 7: Changes and ongoing value

    This is the retention loop, and it is what makes $30 a month worth paying past month one.

    Change requests. The athlete logs into theathletespotlight.com with a username and password and types what they want changed; an agent monitors the queue and executes on their site. This login does not exist yet. Dennis calls it easy to build, and it is a pattern people already understand. The v1 fallback that works today is simple: the athlete replies to the delivery email, and we make the change. The spec for the real login (a WordPress-native login, a request form, a queue, and an agent monitor) is written and estimated at under half a day to build.

    The weekly AI report. This one is built. Every week the athlete gets one branded email covering both halves of their presence: what people said about them (new mentions, the best ad-ready quote, a game plan) and how their site is doing (uptime, speed, Core Web Vitals, SSL health, and search basics, with week-over-week movement and up to three concrete actions). Where we have a live connection, it shows real numbers; where we do not, it says “not yet connected” instead of inventing one. The report standard is its own article: the athlete weekly AI report documents its scope.

    Positive mentions keep flowing. New praise about the athlete keeps landing on the What People Are Saying page as it is found and approved. This runs on the Positive Mentions System, built by Cam Hazzard and developed with Dennis Yu.

    Define the conversion. For an athlete, the sale is fuzzy: a sponsor inquiry, a training-program sale, a recruiting contact. Part of ongoing value is defining that conversion up front so the weekly report measures a real business result, not vanity follower counts.

    State: LIVE (weekly report and mentions loop), WIRING (the change-request login; email reply works today).

    The gaps list, as a build order

    Being honest about the journey means publishing the gaps, in the order we are closing them:

    1. Post-payment intake routing (Keap thank-you page or email routes to the intake form).
    2. The nameserver-instructions email template (sender assigned, per-athlete values wired).
    3. The BlitzAdmin hand-off (how our content pipeline feeds the provisioned WordPress site).
    4. The customer login and change-request queue on theathletespotlight.com, with an agent monitoring it.
    5. A DM-style feedback surface (later; email-first v1 is acceptable).
    6. The athlete conversion definition for the weekly report’s MAA section.

    None of these blocks the core promise. An athlete can buy today, get a site, get an audit, get a weekly report, and get changes made by email reply. The gaps are what turn a good manual delivery into a hands-off one.

    Who this journey is for

    • Young athletes (14 to 18) chasing college offers with little or no online presence. Their parents usually decide and pay, which is why checkout allows a guardian and why the domain is the athlete’s own asset.
    • Athletes and athletic creators chasing sponsorships who already have content but no real web home. An Instagram page with a few hundred followers is not authority; an ownable, indexable site is the link you send a sponsor.

    The lighthouse example is camhazzard.com, which ranks number one for “Cam Hazzard.” It is the proof that this journey ends somewhere real.

    Related frameworks

    Get started

    The full breakdown of what is included lives on the Athlete Spotlight package page. When you are ready, get started for $30 per month and the journey above begins at step one. Parents are welcome to check out on an athlete’s behalf.

    Third-party validation

    Athlete Spotlight is built on the same personal-brand methodology that Dennis Yu and BlitzMetrics use for their clients, adapted for the athlete vertical. The lighthouse site, camhazzard.com, ranks number one for its owner’s name and is the primary case study. Dylan Haugen (dylan-haugen.com) is a second live athlete build on the same standard. As each athlete is onboarded, that execution is documented as a meta article with real analytics (traffic, rankings, and the weekly report), so the proof accumulates in public rather than sitting in a testimonial.

  • How We Synced PRISM to Dennis’s Skill Packs

    Dennis handed me 250 skills. I had 21. On 2026-07-08 I downloaded Dennis Yu’s two skill packs, a 239-task library and a personal-brand agent pack, and diffed them line by line against my own operating system: 21 local skills and 24 canon frameworks, last synced to his live site on July 2.

    The surprise was not what I was missing. It was what the skill packs were missing. The downloaded packs still taught rules Dennis’s own live site retired months ago. That turned a simple import job into something better: a sync with an authority ruling, sync to the source, not the artifact.

    Reconciling the skill packs without vandalizing either side

    The assignment: reconcile Dennis’s downloadable skill packs with my system without vandalizing either. The sources were all 11 personal-brand pack files plus its README, roughly 120 of the 239 task-library skills read in full (every personal-branding, SEO-architecture, dollar-a-day, and thank-you-machine file, plus the key content-factory and website-QA files), both manifests, and the local counterpart for each.

    The goal category is the anti-reinventing-the-wheel discipline Dennis asked for on the July 7 call: ask for the latest skill packs before building anything. So before I built the athlete pack, I made sure I was building on his newest thinking, not a stale copy of it.

    How the sync ran, step by step

    1. Download and map. Both packs into a scratchpad, and a map file recording where every skill lives.
    2. Diff. A six-section comparison: what is new in the packs, where the packs beat the local system, where the local system beats the packs, the athlete-vertical candidates, the canon gap (I hold 24 frameworks, the registry lists 27), and a ranked list of sync actions.
    3. Rule on authority. When sources conflict, the order is Dennis’s live articles first, his downloaded packs second, the local system third. The packs are snapshots; the site is the master. One deliberate exception: the no-em-dash rule is local policy by design and never gets synced away.
    4. Execute the adoptions. Ten imports, same day, each new file carrying its source path and a “Dennis Yu / BlitzMetrics, adapted” attribution.
    5. Refuse the stale rules. Four pack teachings did not come in, because the live site supersedes them.
    6. Give first. The diff itself became a gift: a drafted note to Dennis flagging that his shipping packs contradict his live site in those four spots, plus a broken starter-zip link I found on the way.

    The ten adoptions included the agent operating layer, an AI-search-visibility skill, a personal-brand strategist, a 30-point mention rubric folded into my Positive Mentions System (built by Cam Hazzard, developed with Dennis Yu), four Dollar a Day patches, a recursive self-improvement QA pass, and about two dozen new website-QA checks. The four refusals: the Rank Math 70-plus threshold (live guidance is 81-plus green), the first-link-only anchor rule (retired on the entity-linking page), the Link Whisper install step (AI agents replaced it), and the 8-section homepage (the newer pattern is 9 sections with a dynamic blog loop).

    The calls I’d defend

    Live site beats the packs, even though the packs are “official.” Newest published Dennis is the master. Without that ruling I would have imported a 70-plus Rank Math threshold my own July 2 sync had already retired. Freshness is a property of sources, not of formats.

    Patch, don’t rewrite. Existing skills got cross-referenced additions, not wholesale replacement. Anti-vandalism applies to your own repo too.

    Don’t guess the missing canon. The packs cite hubs suggesting three frameworks I do not hold. Instead of inventing them, the action is to get the source repo invite and read the real list of 27.

    Defer the shiny thing. The athlete-vertical pack build was the obvious next product, and I explicitly did not build it in this session. Sync first, build second, per Dennis’s own layers: strategy, then local prototype, then cloud.

    What it cost, honestly

    Honest label: no token receipt (the metrics extractor is still an open gap), so these are documented estimates. The reading volume is the honest driver: about 120 of 239 task files read in full, not skimmed, because the whole point was catching contradictions.

    TaskAgent time (est.)Human time (est.)Agent cost (est.)Human cost (est.)
    Read ~131 pack files plus local counterparts, write the diff and mapone long session3 to 4 days of careful readinga few dollars in tokens$840 to $1,120 at $35/hr
    Execute 10 adoptions plus supersession notes~1 to 2 hours of session time1 to 2 dayslow single-digit dollars$280 to $560

    What the agent did, and what a human owns

    Autonomous: reading both packs completely, diffing against local files, drafting the authority ruling for approval, executing the imports with source attribution, and writing the supersession notes inline.

    Human required: the authority ruling itself was Cam’s call, made explicitly on 2026-07-08. Sending the give-first note to Dennis is Cam’s send. The source-repo invite is a human ask. And the deferred athlete-pack build waits for a human green light.

    What the agent read

    Pack files read: all 11 personal-brand pack files plus README, about 120 of 239 task-library skills, and both manifests. Local files read: the 21 skills, the relevant canon, and the July 2 live-site sync records. Live-site fetches: a delegation skill that was in neither pack, plus spot-verifications of entity linking and Rank Math guidance. Tokens: not measured. Voice profile: applied to this write-up.

    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, and all counts traceable to the diff and sync records. Still needs a human: the featured image (the diff’s summary table is a candidate screenshot), Cam’s fact pass, and confirmation that Dennis is fine with the pack-contradiction findings going public. That last one is a real gate, not a formality.

    Put the synced system on your Claude

    The whole point of the sync was to keep the method current, then hand it to athletes. You can put the Athlete Spotlight system on your own Claude in about a minute, free Claude included. This is one of three meta articles on the wider build; the others cover how the weekly report’s site-health half was built and how positive mentions were wired into athlete sites.

    The lesson I keep coming back to: don’t sync to the artifact, sync to the source. The packs were the map; the live site was the territory. And when your teacher’s own materials drift behind his newest thinking, catching it and handing it back is the best thank-you there is.

    Built by Cam Hazzard, developed with Dennis Yu.

  • How I Connected Positive Mentions to Athlete Sites

    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.

    What 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.

    1. Intake once. A paying athlete’s intake form drives everything. If they opted in, onboard_map.py converts the intake into the mentions engine’s signup payload. One form, two systems, zero re-typing.
    2. 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.
    3. 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.
    4. Refresh the proof feed. pma_feed.py pulls 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.
    5. 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.

    TaskAgent 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 time2 to 3 days for a developerlow single-digit dollars in tokens$560 to $840 at $35/hr
    Per-athlete proof refresh, ongoingseconds per run30 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.

  • How I Built the Weekly AI Report

    My mentions agent already sent a weekly email. It told an athlete what people said about them that week: new mentions, the one ad-ready quote, a game plan. Good, but half a report. An athlete’s presence online is two things, what people say about you and how your site is doing. So I built the second half, and this is the story of the weekly AI report, version one.

    This is the build behind the promise on every Athlete Spotlight weekly report: your site and your mentions, what changed and what to do next. It is part of my Positive Mentions System, built by Cam Hazzard and developed with Dennis Yu, and it runs on the MAA framework (Metrics, Analysis, Action). Here is exactly how the second half got built, with the real numbers and the honest gaps.

    What the weekly AI report needed

    The assignment was easy to say and easy to get wrong: add a “your site this week” section to the existing mentions digest without touching the email safety rails. The source material was the production digest engine (digest.py) and the MAA framework from canon. The deliverable shipped as one new module, site_signals.py, 455 lines of Python, wired into the digest and committed on 2026-07-02.

    The goal category is the honest one: a client deliverable, and the part of an Athlete Spotlight subscription that makes it worth renewing. A report that reads like a person wrote it, that a 16-year-old athlete’s parent can understand, and that never says anything we did not measure.

    How I built it, step by step

    First rule I set: free APIs only. That is a standing constraint in my system (no billing), and it forced honest engineering instead of buying a dashboard. The section collects six signal families, all real numbers.

    1. Site status: up or down, the actual HTTP status code, and response time in milliseconds, from a plain stdlib fetch with no key.
    2. Uptime over the last 7 days: from UptimeRobot’s free API, the monitor matched by hostname.
    3. Speed score out of 100, plus LCP and CLS: from Google PageSpeed Insights on mobile.
    4. SSL certificate: days until renewal, read straight off a TLS handshake.
    5. Search basics: does the homepage have a title tag and JSON-LD structured data.
    6. Week-over-week deltas on all of it, computed against a history file capped at the last 60 snapshots.

    Then the MAA shape from the framework. Metrics are the numbers above. Analysis is one short rule-based paragraph that names the weakest area and the week-over-week movement. Action is up to three concrete items, and the first one always targets the weakest signal, in a fixed priority order: site down beats SSL trouble beats slow responses beats uptime slips beats speed beats search basics.

    The safe test path matters as much as the feature. A --render-only flag writes the full HTML preview and never sends, never stamps the send date, and never writes to the history file. Previews cannot skew next week’s deltas, so I can check a report before an athlete ever sees it.

    The calls I’d defend

    Three decisions in this build I would defend to anyone.

    A 403 is not “down.” Bot protection returns 403s all day. The report states the real HTTP code the site returned instead of crying outage, and when the failure is on our side of the network, it retries once, then says “check inconclusive this week.” It never invents a confirmed outage.

    Opt-in per athlete, byte-identical otherwise. The section only renders when an athlete’s config has both a site URL and the report switch on. Without both keys, the digest output is byte-identical to the old behavior, verified by diff at build time. Existing subjects felt nothing.

    Don’t claim what we can’t measure. Google Search Console queries, clicks, and traffic need the owner’s OAuth per site. There is no free keyless path, so the report says “not yet connected” instead of faking it. The sales-copy guardrail is written into the module’s own docs: here is what is honest to say, here is what is not yet.

    What it cost, honestly

    Honest label first: I do not have a token receipt for this build. The session metrics extractor is still an open gap in my system, so the numbers below are documented estimates, not measured figures.

    TaskAgent time (est.)Human time (est.)Agent cost (est.)Human cost (est.)
    Design and build site_signals.py (455 lines) plus digest wiring~2 to 3 hours of session time2 to 3 days for a developerlow single-digit dollars in tokens$560 to $840 at $35/hr

    Running cost is the part I like: $0. Every API in the report is free tier. The two optional keys (UptimeRobot and PageSpeed) are free accounts, and the HTTP, SSL, and search-basics checks need no key at all.

    What the agent did, and what a human owns

    Autonomous: collecting every signal, computing deltas against history, writing the analysis paragraph and the three actions, rendering the branded email, and previewing safely. Also failing gracefully, so a dead API can never block the mentions half of the report.

    Human required: consent. Emailing is gated exactly like before (a real recipient plus an explicit send). Connecting UptimeRobot monitors and any future Search Console OAuth are owner actions. And the report is generated as a file first, so nothing auto-publishes anywhere.

    What the agent read

    Production code read: the digest engine, the mentions knowledge-base layer, and the subject config contract. Canon loaded: the MAA framework and the no-em-dash rule (every generated line is scrubbed by construction). External docs: the UptimeRobot API v2 and PageSpeed Insights references. Tokens: not measured (see the cost section). Voice profile: not needed for the build, applied to this write-up.

    How it scores against our own gate

    This article ran through the same 18-step article gate we use on client work. What passes now: first sentence under 10 words, zero banned AI words, zero em dashes, contractions throughout, real numbers with estimates labeled as estimates, and the canonical parent linked (the Positive Mentions System, built by Cam Hazzard and developed with Dennis Yu). What still needs a human: the featured image, a final fact pass by Cam, and live cross-link verification after publish. That honesty is the point of a meta article: show the work, including the parts a person still owns.

    See the standard, and get started

    The live standard this build serves is The Athlete Weekly AI Report, the article that defines what every Athlete Spotlight report is built to. This meta article is one of three documenting that build; the next covers how positive mentions were wired into athlete sites.

    When you are ready, get started for $30 per month and the weekly report starts once your site is live. Parents are welcome to check out on an athlete’s behalf.

    The takeaway is the same one I keep coming back to: be so good they can’t ignore you, and be honest enough that they trust you when they look. A report built on numbers nobody had to pay for, that never says anything we didn’t measure, earns that trust.

    Built by Cam Hazzard, developed with Dennis Yu.