31.1 The Governance Pillars

An AI system in sport must satisfy three governance pillars: epistemic truthfulness (the claims register), intellectual property safety (the license matrix), and athlete privacy (the consent boundary). This chapter is the third pillar's machinery — and the honesty contract that the whole book enforces. The license facts are measured (this chapter's lab scanned the environment); the rights analysis is source-backed; the economics are computed from the token dossier and flagged where they must be re-checked at print.

Governance fails in predictable ways. A club analyst scrapes a broadcast clip "for internal review" and the league's legal team arrives two seasons later. A startup ships a coaching SaaS on an AGPL detection model and discovers the §13 network clause during acquisition due diligence. A junior pickleball program posts pose overlays of fourteen-year-olds and a parent asks, correctly, who consented. None of these are engineering failures; all of them are deployment failures. The fix is not a policy PDF. It is a small set of mechanical controls — a dependency scan, a license matrix, a consent workflow, a risk register — that run in the same pipeline as the models themselves.

Both of this book's worked sports appear in every section, because the failure modes differ. The pickleball case (pb-003) is fixed-camera amateur footage: the club owns the camera, the players are members, and the governing risk is athlete privacy. The rugby league case (nrl-001) is broadcast PTZ footage: the league and its broadcast partners own the pictures, the data rights run through Stats Perform, and the governing risk is media rights. Governance is one discipline applied to two very different asset classes.

31.1b The Deployment Landscape: Edge vs Cloud vs Hybrid

Before any rights question can be answered, the system has to live somewhere. The deployment choice is not an infrastructure detail; it determines which licenses fire (AGPL §13 triggers on network serving), which privacy regime applies (data that never leaves the venue is a different problem from data egressed to a cloud API), and what the unit economics allow. There are three honest options.

Edge. The M4 Max pipeline this book is built on runs the full perception stack — YOLOv11s-class detection (4.2 ms), TrackNetV4 ball tracking (3.8 ms), BoT-SORT association and homography (3.2 ms), Fast SAM body kinematics (18.5 ms), and the TacticAI GNN (4.8 ms) — inside a measured 37.0 ms end-to-end envelope, with a 55.7 ms glass-to-glass latency including ingestion. That is sub-frame real-time: feedback lands on a court-side iPad before the next rally starts. Cost per match is \$0 at the margin because the hardware is already bought, and the privacy posture is maximal — the footage never leaves the building. For the pb-003 pickleball capture, this is the correct default: the club's members never appear on a third-party server, and the club's bandwidth bill is irrelevant.

Cloud. A frontier VLM analyzing an 80-minute rugby league match sampled at 2 FPS consumes roughly 258 tokens per frame — about 2.47 million input tokens per match — at an API cost of \$3.22 to \$13.80 per match depending on the model, with 1.2–4.5 second round-trip latencies. That profile rules out live in-game coaching, which needs sub-100 ms feedback during rallies and timeouts, but it is perfectly viable for post-match deep-dive: narrative generation, tactical summarization, the chapter 26 pipeline. Cloud is also where burst training belongs (Colab-class GPUs for the DEIM fine-tunes), because training is episodic and inference is forever.

Hybrid. The architecture the book actually ships: edge does perception and anything latency-bound (line calls, live overlays, court-side cues); cloud does language and anything quality-bound (post-match narrative, weekly coach digests, cross-match aggregation). The boundary is drawn by two numbers — the 100 ms live-feedback budget and the per-match token bill — and by one rule: identity-bearing media stays on the edge box; only derived data (tracks, events, metrics) egresses.

The M4 edge economics. The capital question answers itself quickly. A Mac Studio-class M4 Max is a one-time CAPEX of about \$3,199. Billed against GPT-4o-class cloud inference at \$6.45 per 80-minute match, the machine breaks even after 496 matches [verify at print]. For a pickleball academy processing 50 hours of court footage a week, payback arrives in under six weeks; for an NRL club analyzing a season of 24 regular-season matches plus training sessions, the edge box pays for itself inside two seasons even if cloud were used for nothing else. The deeper point is structural: token-priced cloud inference scales with usage, while edge inference scales with hardware count. A league analyzing thousands of matches a season is a hardware fleet problem, not an API bill.

31.2 The OSS Licensing Deep-Dive (W7.4 Lab, Measured)

The chapter's lab scanned the actual venv and emitted the matrix. The measured result: three AGPL carriers flagged in the installed environment — ultralytics 8.4.117, opencv-contrib-python 5.0.0.93, and opencv-python 5.0.0.93 — alongside a full license matrix for the stack's load-bearing components. The findings:

The AGPL consequence in full: the §13 network clause (serving the model over a network releases your source) + the Ultralytics FAQ position (fine-tuned weights inherit AGPL; Pro plan is not a commercial exemption). This matters more for vision than for ordinary software because vision models are almost always deployed as APIs, hosted endpoints, or edge runtimes queried by other systems — precisely the fact pattern §13 was written to catch. The derivative-work line for ML is genuinely unsettled in court: whether fine-tuned weights derive from base weights, whether a training script derives from training code, and whether an application importing an AGPL model is a combined work are all open questions. But the licensor reads its license broadly, the existence of a paid Enterprise tier is the market signal for how broadly, and the uncertainty itself fails legal review before it fails technically. The book's verdict: choose the license at model-selection time, not deploy time — the C08 chapter made this decision first; this chapter audits it.

The permissive path. RF-DETR (Nano–Large) is Apache-2.0 end to end, matches or beats YOLO on accuracy/latency, and exports to ONNX/TensorRT — the book's default commercial-safe recommendation for both the pickleball detector and the rugby ball/player detector. RT-DETR, D-FINE, and the DEIM training recipe (which cuts DETR convergence time by up to 50% per the paper) are Apache-2.0 as well, giving a clean training path for custom fine-tunes. The two caveats the scan teaches: RF-DETR XL/2XL sit behind the PML-1.0 platform license (the constructors refuse to load unless accept_platform_model_license=True is passed — a license gate enforced in code), and DEIMv2's DINOv3 backbones carry Meta's custom DINOv3 license, not Apache [verify whether those terms propagate to downstream weights]. The book's discipline: pick permissive, and treat "we only use the weights, not the code" as a question for counsel, not an engineering shortcut.

31.2b The License Decision Tree

The checklist the lab script automates, printable as-is. Run it against every component before it enters the pipeline, not after:

1. Is the component AGPL-3.0 or GPL-family?
   ├─ Yes → Are you shipping a product/service over a network?
   │   ├─ Yes → Open-source everything under AGPL, buy commercial, or replace.
   │   └─ No (pure internal research, no distribution) → obligations may not fire; check counsel.
   └─ No → continue.
2. Is the component Apache 2.0 / MIT / BSD?
   ├─ Yes → Keep attribution notices; proprietary shipping is fine.
   └─ No → continue.
3. Custom platform license (PML-1.0, DINOv3, Deci weights)?
   ├─ Yes → Verify platform agreement and acceptance flag before use.
   └─ No → continue.
4. Are the weights redistributable? (SMPL-X, registration-gated checkpoints)
   ├─ Yes → Include license and attribution.
   └─ No → Do not bundle; the user downloads separately.

Heuristic actions for the scanner: AGPL-3.0 served over a network → legal_review or replace; Apache/MIT/BSD → keep with attribution check; custom platform licenses → buy_license if the platform agreement is active; unknown or absent license → legal_review. pip-licenses or a small parser over pip show is all the machinery required — the lab's script is under fifty lines and runs in CI on every dependency change.

31.3 Media Rights: Book vs Product

Media rights separate into two assets that are contracted independently: event data (who did what, when) and footage (the pictures). Licensing one never grants the other. The verified reality in both sports:

• Rugby league (NRL): official data runs through Stats Perform (Opta brand), the NRL's data partner for more than a decade, collecting roughly 14,000 data points per match and feeding broadcasters, media, sponsors, and team analysts. Video and performance analysis run through Hudl's multi-year ARLC renewal covering NRL, NRLW, State of Origin, and the pathway competitions — the footage lives on Hudl and is governed by league and club agreements, not by the broadcast deal. Broadcast pictures themselves sit with the league's television partners (free-to-air and subscription), and the neighboring AFL's A\$4.5 billion 2025–2031 deal with Seven and Foxtel shows the scale of what leagues protect: a 2025 dispute over behind-the-goals footage aired on a rival network triggered a formal AFL review of broadcast rights. Footage is a core revenue asset and is policed like one.
• Pickleball (PPA/MLP): professional media is controlled by Pickleball Inc., distributed mainly through Pickleball TV (a joint venture with Tennis Channel) plus limited barter windows; as of 2026 there is no full-scale rights-fee national television deal, though executives expect one within 1–2 years. The G0.5 decision encodes the consequence: labels are CC-BY-4.0, frames are NOT redistributable.
• Book vs product: the book cites and describes the broadcast footage (the NRL GF highlights case); the fair-use/fair-dealing analysis separates the practitioner reference from the commercial product. A product must license the footage.
• The rule that never changes: frames are not redistributable without rights; the book publishes metadata, hashes, and the analysis — never the identity-bearing media.

Fair use is a defense, not a plan. It is raised after a claim, not granted in advance. The factors that strengthen a book's position are transformative purpose (tactical annotation, data visualization, teaching), small proportion (a single frame from a multi-hour broadcast), no market substitution (the book is not a substitute for watching the match), and the factual nature of a sporting event. The factors that weaken it: commercial publication of the book, taking the most valuable moment (the game-deciding try is the most licensable clip in the match), and unedited reposting — a voiceover alone is usually insufficient; spoken analysis plus diagrams plus data overlays is much stronger. The operational split: one annotated frame from a grand-final try with a tactical overlay is likely defensible as commentary; a 30-second highlight clip of the match-winning play is a licensing transaction; a generated data visualization from licensed event data is fine under the data license; an auto-compiled highlight reel from broadcast footage is not allowed at any scale without a clip-licensing agreement.

31.3b The NRL Broadcast Rights Case

The concrete question a club analyst asks: the match was on the broadcast — can the club use that footage for analysis? The answer demonstrates why the two-layer rights structure matters. The broadcast feed (the pictures produced by the league's free-to-air and subscription television partners) is the broadcasters' licensed product; a club capturing the telecast and cutting it into an analysis package is reusing someone else's licensed asset, and redistributing any of it — even internally-branded clips on a public channel — is a rights violation. The club's legitimate path is the second layer: the Hudl-hosted footage and Opta event data the club receives under the ARLC performance-analysis agreements, which exist precisely so clubs do not need the broadcast feed. In other words, a club can analyze the match, but not from the broadcast — it analyzes from the league-sanctioned video and data feeds, and it licenses anything it wants to publish [verify the operative clauses of the current ARLC/Hudl agreement before relying on this in a product].

The pickleball mirror is instructive: PPA/MLP footage has no Hudl-equivalent club layer because professional pickleball's media structure is younger and centralized under Pickleball Inc.; a pro pickleball analyst has fewer sanctioned video sources than an NRL analyst, which is exactly why the book's pickleball pipeline is built on self-captured club footage instead. The rights structure you operate under determines the capture architecture you build.

31.3c Data Provenance: Where the Footage Came From

Every asset in this book carries a provenance chain, because a rights answer is only as good as the record of where the media originated. The pb-003 pickleball set: club-mounted fixed cameras, club-owned recordings, players covered by the club's consent workflow, sessions hashed (SHA-256 per source clip) at ingest, and labels derived from those hashes — so a released label row can always be traced back to its exact source clip without the clip itself ever leaving the club. The nrl-001 rugby league set: broadcast footage used as reference material only — cited, described, and analyzed, never vendored or redistributed; the derived artifacts (event tables, tracking re-annotations, tactical diagrams) are the publishable layer. Provenance is what makes the G0.5 release rule auditable: labels CC-BY-4.0, frame indices plus source-clip hashes for verification, frames themselves withheld. If you cannot state, for every clip in your pipeline, who recorded it, who owns it, and who consented to it, the clip does not enter the pipeline.

31.4 Athlete Data Rights

Biometrics are the sensitive category: joint angles, 3D meshes, HR traces, gait — all of it — under GDPR Article 9 (EU) and the Australian Privacy Act's sensitive-information class. Under APP 3, an entity may collect sensitive information only with consent and only where reasonably necessary for its functions; the employee-records exemption does not reliably cover biometric collection, which is why "the player is our employee" is not a privacy answer. The athlete's right to understand is the operant requirement: what is analyzed, for what purpose, retained for how long, and who can see it.

The rugby league reference is the 2023–2027 NRL Collective Bargaining Agreement, which was negotiated partly over player data: the RLPA's dispute FAQ stated that the league had sought to assert ownership over player data and to use or sell it without informed consent, and the signed CBA responded with clarification of player property rights and mandated entry/exit medicals. The CBA makes consent structural — but the practitioner's duty is to make the analysis comprehensible, not just to collect a signature. The structural problem the CBA does not solve: consent inside an employer-athlete relationship is often not freely given. A "consent" checkbox under a power imbalance is a fiction; the honest design is purpose-specific consent, transparent retention, and independent oversight, with contractual data-rights clauses doing the work a click-through cannot.

The face lane is off for the amateur case: face recognition carries the NIST FRVT 10–100× demographic false-positive differentials (the error is not evenly distributed) and the structural consent failure (club/employer power imbalance means the athlete cannot freely refuse). For the pb-003 pickleball footage the default is blur or skip: jersey numbers or anonymous player IDs for tracking, faces blurred in any published frame, minors covered by parental consent. For the pro case (an NRL squad in a Hudl environment): consent is managed, purpose-bound, and revocable — and the default remains no faces unless the analysis requires them and the consent is explicit, with a documented DPIA for any high-risk processing.

The release rule: the label dataset is personal data (subjects' appearance, location, play patterns). The pb-003 pattern — labels CC-BY-4.0, frames not redistributable, no faces — is the model for every release in this space.

• Biometrics = sensitive data: GDPR Art 9 (EU) / Australian Privacy Act (sensitive-information class) — joint angles, 3D meshes, HR, all of it.
• The face lane is off: no face recognition in amateur footage (the NIST FRVT 10–100× demographic false-positive differentials + the structural consent failure: club/employer power imbalance).
• Sports-specific: NRL CBA consent frameworks for pro teams; the athlete's right to understand what is analyzed.

31.4b The Consent Template

A minimal consent form has nine fields, each of which exists because a real failure mode demanded it:

The secondary-use row is where amateur clubs most often fail: the season's highlight reel, the model-training contribution, and the coaching review are three different purposes and need three different consents. A pickleball club contributing labels to a shared dataset needs the "AI training / research" line signed by every identifiable player; an NRL pathway program exporting GPS traces to a vendor needs the same. Treat every identifiable athlete as a data subject whose consent is explicit, specific, and revocable.

31.5 NIST AI RMF and the Risk Register

The NIST AI Risk Management Framework 1.0 is voluntary and structured around four functions: Govern, Map, Measure, Manage. For a sport-analytics product the mapping is direct. Govern: who approves high-risk use cases, model procurement, athlete-data policy, and the no-medical-advice boundary. Map: the inventory of models (detection, tracking, pose, ball tracking, VLM, LLM), data sources, deployment contexts (a live pickleball line call versus a post-match rugby review are different risk classes), and impacted stakeholders (athletes, referees, coaches, fans). Measure: validation metrics per component — HOTA and IDF1 for tracking, homography RMSE for calibration, keypoint confidence for pose, ball-detection precision, VLM hallucination rate — plus human-in-the-loop checks. Manage: incident response, rollback plans, vendor escalation, and the re-audit cadence.

The register itself is a living table with a unique ID, likelihood and impact scores, inherent and residual risk, controls, a named owner, and a review date. This chapter's lab ships the starter rows:

Two worked extensions show the register growing. Pickleball: a live line-call overlay at a club tournament — likelihood 3, impact 5, inherent 15 — controlled by a human-in-the-loop challenge rule, a confidence threshold, model version pinning, and the chapter 14 multi-view σ gate; residual 6, owned by the product safety lead. Rugby league: a VLM-generated tactical explanation shown to a player — likelihood 4, impact 3, inherent 12 — controlled by the generator-critic loop, confidence gating, and a human coach reviewing before delivery; residual 5, owned by the ML lead. Every system that affects a match decision, a coaching intervention, or a medical impression needs a named owner, an override path, and a rollback plan; the register is the operational record of who is accountable when the model is wrong. Review weekly during development, monthly in production, and ad-hoc after any incident, model update, or new data source.

31.6 Vendor Lock-In: The Open-Formats Answer

The PB Vision partner-API pattern (OAuth + analytics-return) vs PlaySight's closed data — the book's answer is the one-spine + open formats (kloppy/EPTS export, chapter 17): your data stays queryable regardless of which vendor you use for capture. PB Vision is the model to copy: an adapter boundary that lets users bring their own footage and take their own analytics back out — not fully open, but portable. PlaySight is the cautionary case: fixed multi-camera SmartCourt infrastructure with footage stored on PlaySight's proprietary cloud, no general public API for automated export of raw video or deep analytics, and access through PlaySight's own apps or select partners. The lock-in is partly physical: the cameras are embedded in the facility, so switching vendors is a construction project, not a software migration.

The portability test is four questions, answerable today:

1. Can you export your raw data and model weights in an open format today?
   ├─ Yes → You own the spine; the vendor is replaceable.
   └─ No → You are building on someone else's land.
2. Does the vendor offer an API, or only a dashboard?
   ├─ API → Portability is possible with effort.
   └─ Dashboard only → You are a data tenant.
3. Is inference self-hosted or vendor-hosted?
   ├─ Self-hosted (M4 Max, Colab, on-prem) → You control the pipeline.
   └─ Vendor cloud → Check egress, terms, and model-license gates.
4. Can the same pipeline run on a second vendor's hardware without code changes?
   ├─ Yes → You have a genuine abstraction layer.
   └─ No → Lock-in is a future migration cost.

A closed data store is the lock-in; the spine is the exit. For the pickleball club this means the pb-003 captures live on club storage as MP4 plus CSV/JSON annotations, not inside a vendor dashboard. For the NRL analyst it means every Hudl-derived artifact is also exported to kloppy-compatible tables, so a change of video vendor does not orphan a decade of analysis history.

31.7 The No-Medical-Advice Boundary

The config's legal disclaimer applies mechanically: "not legal, financial, medical, or professional advice. It does not diagnose athletes." The chapter's red lines: never diagnose from monocular kinematics (C11 — sagittal-plane angles, CoM height, and calibrated joint angular velocities are defensible from single-camera video; ground-reaction forces, joint torques, and injury-risk probabilities are not); never prescribe injury rehab or return-to-play protocols (C29 — the coaching layer suggests drills and constraints, never rehabilitation progressions); never gate athletes on screening scores (the Bath 68% sensitivity means a third of at-risk athletes pass the screen). The standard disclaimer text — derived from the terms of the AI fitness platforms — belongs in every coaching product:

The coaching feedback, training plans, and analytics provided by this system are generated by artificial intelligence for informational and fitness-coaching purposes only. They do not constitute medical advice, diagnosis, or treatment. The AI cannot physically assess you, observe your form in a clinical setting, or account for your full injury history. Always consult a qualified healthcare professional before acting on any recommendation.

But the boundary is a system behavior, not a Terms-of-Service paragraph. Build it as a hard guardrail in the agent's output filter (not a soft prompt), a logged audit point (every blocked medical-advice attempt is recorded for safety review), and an escalation path (a human coach or medical reviewer unlocks anything that could read as diagnosis or prescription). A pickleball coaching agent that observes a player's knee valgus in the pb-003 overlays may say "knee flexion angle is X degrees relative to the calibrated court" — it may not say "you have patellar tendinopathy risk." An NRL workload dashboard may flag an ACWR spike — it may not clear a player to train. Computable is not the same as permissible, and the boundary is drawn at measurement time, not publication.

31.8 The Pickleball Worked Case: The G0.5 Decision

The clearest legal case in this book is the dataset contribution: the pb-003 labels are CC-BY-4.0 (the analysis is yours), but the frames are NOT redistributable (PPA broadcast rights for pro footage; athlete privacy for club footage). The book publishes: the labels, the frame indices, the source-clip SHA-256, and the analysis — never the frames themselves. This single decision models every rights question in the book: what belongs to the copyright holder, what belongs to the analyst, and how you split them in a release.

The pickleball club case in full. The club owns the camera — that part is easy: a camera mounted by the venue on its own wall records on the club's storage, and the raw recording is the club's asset. The harder question is the subjects. The players are identifiable data subjects: their appearance, movement patterns, and (in the pb-003 footage) their faces are personal data. The club's ownership of the recording does not grant the right to publish the players; that right comes from the consent workflow of §31.4b, signed per player, with parental consent for minors, and with the secondary-use line covering any dataset contribution or model training. The operational result is the three-way split in the figure: labels out (CC-BY-4.0), hashes out (verification without exposure), frames locked. A member who revokes consent triggers removal of their rows from future releases and blurring in any re-published analysis — which is why the provenance hashes of §31.3c matter: you can only honor revocation if you can trace every derived artifact back to its source clip.

The rugby league contrast closes the loop: the NRL analyst never faces the club-camera question because the club does not own the pictures — the league's media stack does — and the analyst's consent problem is contractual (the CBA) rather than ad-hoc. Two sports, two ownership structures, one discipline: name the owner, name the data subject, name the consent, and publish only what all three permit.

31.9 The Governance Recipe

1. Dependency scan (the W7.4 script) for AGPL/GPL carriers — measured here: ultralytics 8.4.117 and the two OpenCV 5.0.0.93 wheels flagged in the working venv.
2. License matrix per model (the C31 table at selection time, not deploy time).
3. Risk register per deployment (the 4 rows above are the starters; grow it per use case).
4. Media rights: cite-only for broadcast; license for product; provenance hash per source clip.
5. Consent: nine-field template, no faces, biometrics = sensitive, revocation wired to the provenance chain.
6. Deployment split by the two numbers: 100 ms live budget and per-match token bill; identity-bearing media stays on the edge.
7. No-medical-advice guardrail as output filter + logged audit point, tested with adversarial prompts.
8. Re-audit on every version bump (licenses move — the RF-DETR+ split and the DEIMv2 backbone question are the cautionary cases).

Before any model goes live, the checklist is binary: license scan passed; provenance documented and consent verified or faces anonymized; risk register populated and reviewed; the no-medical-advice guardrail adversarially tested; override and rollback documented; human-in-the-loop approval on match-decision outputs; and the 30-day export test — can your data and models leave the vendor within a month? Governance becomes real only when it is automated. The license matrix script and the risk register are the two minimum viable controls: one prevents IP surprises, the other prevents harm surprises.

31.9b The Use-Case Library I: Rights & Economics of Deployment

The ten use cases below convert this chapter's governance machinery into the decisions a club, academy, or product team actually faces, organized into three categories: rights & economics of deployment (UC 01–04), athlete rights & privacy (UC 05–07), and supply chain & operations (UC 08–10). Each case states the practical problem, the mechanism with its cost math, a figure, a pickleball and a rugby league application, and the payoff. Evidence labels follow the book's contract: measured (this chapter's lab), source-backed (named source), or [verify] (practitioner estimate or price to re-check at print).

UC 01 — Club Video Rights: The NRL Broadcast Trap

The problem: the match was on television, so the analyst assumes the club can cut the telecast into a review package. It cannot. The mechanism is the two-layer rights structure of §31.3b — broadcast pictures are the broadcasters' licensed product, while the club's lawful path is the Hudl/ARLC footage layer plus Stats Perform's ~14,000 event data points per match. The math is asymmetric: a clip-licensing conversation for broadcast footage runs to a per-clip fee and a negotiation cycle measured in weeks [verify — league-specific], while the sanctioned club layer is already paid for inside the ARLC agreement. The cost of getting it wrong is not a fine schedule; it is a takedown plus a damaged league relationship.

Pickleball application. There is no Hudl-equivalent in amateur pickleball: the club's own fixed camera is simultaneously the capture layer and the rights layer, so the "which layer may I use" question collapses into the consent question of UC 05. PPA/MLP pro footage, by contrast, is Pickleball Inc. property — treat it like the broadcast layer: cite, never cut.

Rugby league application. Route every analysis request through the Hudl/Opta layers; if a broadcast moment is genuinely needed (the grand-final try as a teaching still), transform it — annotation, diagram, data overlay — and cite it, per the fair-use analysis of §31.3.

Payoff. The analyst keeps working instead of lawyering: one routing rule ("which layer?") replaces a legal review per clip.

UC 02 — Pickleball Club Recording Rights

The problem: a club mounts a camera, records a season, and only later asks who may publish what. The mechanism is the three-way split of §31.8: the club owns the recording, the players own their identifiability, and the release separates into labels out (CC-BY-4.0), hashes out (SHA-256 provenance), frames locked. The math is the admin overhead: a nine-field consent form costs roughly 10 minutes per player — about 7 staff-hours for a 40-member roster, once per season — against the alternative cost of a full dataset takedown and re-collection if one parent objects after publication.

Pickleball application. pb-003 in full: club-mounted cameras, per-player signed consent, parental consent for juniors, frames never leave club storage, labels released with source-clip hashes so any row traces back without the clip egressing.

Rugby league application. An NRL club filming its own opposed sessions owns those pictures outright (they are not broadcast product), but player identifiability still runs through the CBA consent framework — the three-way split is identical, only the consent instrument changes.

Payoff. A publishable dataset with a defensible provenance chain, at the cost of one afternoon of paperwork per season.

UC 03 — AGPL vs Apache: The YOLO/RF-DETR Decision

The problem: the detector that tops the hobby benchmarks is AGPL-3.0, and the product team discovers it at acquisition due diligence, not at model selection. The mechanism is §13: serving an AGPL model over a network triggers source release for the whole combined work, and the licensor reads fine-tuned weights as covered. The math, from this chapter's measured scan: the working venv carries three AGPL packages (ultralytics 8.4.117, opencv-contrib-python 5.0.0.93, opencv-python 5.0.0.93). The escape routes price out as: Ultralytics Enterprise license [verify at print — quote-based], full AGPL source release (usually fatal to a closed product), or migration to RF-DETR (Apache-2.0, ONNX/TensorRT export, accuracy-equivalent) at roughly two engineer-days for a drop-in detector swap [verify — practitioner estimate]. Migration is almost always the cheapest cell in that table.

Pickleball application. The pb-003 detector fine-tune runs the DEIM recipe on an Apache base, so the club's coaching app can be sold or open-sourced on the club's own terms — the license is a choice, not a surprise.

Rugby league application. The nrl-001 broadcast detector is the highest-stakes model in the book's stack (26 players, live line-of-scrimmage calls feeding C28); it is precisely the model an acquirer would audit first, and it sits on the Apache path for that reason.

Payoff. A detector decision made at selection time costs engineer-days; made at due-diligence time it costs the deal.

UC 04 — Edge vs Cloud: The M4 Economics

The problem: cloud inference is priced per token and per match, so a successful season is a growing bill; edge hardware is priced once. The mechanism is the hybrid split of §31.1b — perception local (37.0 ms end-to-end, 55.7 ms glass-to-glass, measured), language remote. The math: the M4 Max box at \$3,199 CAPEX against \$6.45 per 80-minute match of cloud VLM inference breaks even at 496 matches [verify at print]; a pickleball academy processing 50 court-hours a week crosses inside six weeks, and an NRL club analyzing 24 regular-season matches plus training crosses inside two seasons. Below break-even the cloud is cheaper in cash; above it, every marginal match is free — and identity-bearing frames never leave the building at any volume.

Pickleball application. The academy default is edge-only: member footage never egresses, the per-match marginal cost is zero, and live dink-feedback cues stay inside the 100 ms budget.

Rugby league application. The club runs hybrid: live sideline perception on the edge box during training, cloud VLM for the weekly tactical digest on Hudl-derived artifacts — only tracks and events cross the boundary, never frames.

Payoff. The deployment choice stops being an opinion: two numbers (100 ms budget, per-match token bill) and one rule (identity stays local) decide it.

31.9c The Use-Case Library II: Athlete Rights & Privacy

UC 05 — The Athlete Consent Flow

The problem: consent collected as a single season-start checkbox cannot support the three different purposes (coaching review, highlights, dataset contribution) a club actually uses footage for. The mechanism is the five-stage flow of §31.4 — collect, inform, sign, process (no faces), revoke — with the nine-field template of §31.4b binding each purpose separately. The math is revocation cost: with the SHA-256 provenance chain of §31.3c, withdrawing one athlete is an O(their labels) deletion — hash-indexed rows drop out of the released dataset without touching anyone else's data. Without provenance, revocation is an O(everything) re-collection.

Pickleball application. The club's season workflow: forms at registration, the AI-training secondary-use line signed before any label leaves the building, revocation honored by hash-indexed deletion from the published dataset.

Rugby league application. The NRL squad's consent is contractual (the 2023–2027 CBA clarified player property rights after the RLPA dispute), but the practitioner's duty is the same: the player must be able to say what is measured, why, and for how long — and to refuse without selection consequences, which is the part a checkbox cannot deliver.

Payoff. Revocable consent is the difference between a dataset and a liability: the loop back is the load-bearing stage.

UC 06 — Data Retention: How Long to Keep the Footage

The problem: clubs keep everything forever because deletion feels like waste, and discover the cost when a subject requests erasure across three seasons of unsorted drives. The mechanism is a retention schedule bound to the consent form's retention field: delete after season, after departure, or after a fixed period — enforced by the provenance chain, not by memory. The math is storage plus risk: 1080p30 club footage runs about 8 GB per hour, so a 50-hour week is ~400 GB and a kept-forever academy accumulates ~20 TB per year [verify — bitrate-dependent]; a delete-after-season policy caps that at one NAS drive, and every retained hour beyond its purpose is breach surface with zero analytical value.

Pickleball application. pb-003 policy: raw clips live one season on club storage, derived labels persist (they are the publishable asset), and a season-end script deletes footage whose consent period has lapsed — logged, not manual.

Rugby league application. The analyst's local exports of Hudl artifacts inherit the agreement's retention terms; the CBA's mandated entry/exit medicals set the pattern for medical-adjacent data — retained for a defined purpose, then gone.

Payoff. Retention is a clock with a purpose attached, not a hoard: what you delete on schedule can never breach.

UC 07 — Facial Recognition: The Ethical Line

The problem: "we already have the video — can we auto-tag players by face?" is technically trivial and ethically indefensible in the amateur case. The mechanism is §31.4's face lane: NIST FRVT measured demographic false-positive differentials of 10–100× mean the error lands unevenly on the athletes least likely to be believed when they dispute it, and the club/employer power imbalance means refusal is not free. The math is expected harm: at even a 0.1% false-match rate across 200 members, the system manufactures false identifications on a schedule, each one carrying reputational cost to the wrongly matched athlete and none to the operator — an asymmetry no accuracy improvement fully closes for non-consenting subjects.

Pickleball application. pb-003 default is blur-or-skip: tracking keys on jersey number or anonymous ID, published frames blur faces, and no face template is ever built from club footage.

Rugby league application. Inside an NRL Hudl environment a managed face pipeline is conceivable — explicit consent, DPIA, revocable — but the book's pipeline deliberately never builds one: broadcast tracking runs on detection plus jersey-plus-pose association (C08/C09), not identity recognition.

Payoff. The line is cheap to hold and expensive to cross: anonymous IDs answer every coaching question the face would have answered.

31.9d The Use-Case Library III: Supply Chain & Operations

UC 08 — Model License Propagation: Fine-Tuning AGPL

The problem: the team fine-tunes an AGPL detector on its own footage and assumes the new weights are theirs. The licensor's position (Ultralytics FAQ) is that fine-tuned weights inherit AGPL — the license propagates through training, not just through code import. The mechanism is the propagation chain: base weights → fine-tuned weights → served API, with §13 firing at the last hop. The math is the retraining premium as insurance: the DEIM recipe cuts DETR convergence time by up to 50% (source-backed, the DEIM paper), so re-deriving the club's detector on an Apache base is measured in Colab-days [verify — dataset-dependent], which is trivially cheaper than open-sourcing the product or buying out of the license after the fact. The derivative-work question is legally unsettled — treat the licensor's broad reading as the planning assumption, not the court's.

Pickleball application. The academy's ball detector, fine-tuned on pb-003 labels, is rebuilt on the Apache path the day the coaching app charges its first dollar — the labels (CC-BY-4.0, club-owned) port cleanly; only the base weights change.

Rugby league application. Any NRL-facing analytics product fine-tunes on Apache bases from day one, because the moment a club pays for the product the AGPL question stops being academic.

Payoff. License propagation is one-directional and invisible until it is expensive: retrain early, while it costs GPU-hours instead of legal hours.

UC 09 — The Deploy Checklist

The problem: governance fails at the seam between "the model works" and "the system is live" — every control in this chapter exists, but nobody ran them in order. The mechanism is §31.9's binary gate: license scan passed, provenance documented, consent verified or faces anonymized, risk register populated, no-medical-advice guardrail adversarially tested, override and rollback documented, human approval on match-decision outputs, and the 30-day export test. The math is automation cost: the license scanner is under fifty lines over pip show and runs in CI on every dependency change; the full checklist is a one-hour ceremony per release [verify — practitioner estimate] against the alternative of discovering any single gate's failure in production, where each maps to a known incident class (takedown, breach, wrong call, medical misread).

Pickleball application. The club tournament deployment: scan, consent audit against the roster, risk register row for the live overlay, guardrail test, referee override drilled before round one.

Rugby league application. The match-week deployment adds the league layer: every artifact crossing from Hudl into the club's spine carries its rights metadata, and the export test proves the club could leave its video vendor inside a month.

Payoff. Governance becomes real only when automated — the checklist turns this entire chapter into one hour per release.

UC 10 — Incident Response: The Mislabeled Line Call

The problem: the live line-call overlay calls a ball out that was in, the clip is on social media before the match ends, and the question arrives: who is accountable? The mechanism is the risk register's R-01 row operated as a loop — detect (confidence gate plus the C14 multi-view σ bound), contain (human-in-the-loop challenge rule overrides the model), rollback (model version pinning returns the last known-good), review (the incident log records input clip hash, model version, confidence, and the human decision). The math: inherent risk 3 × 5 = 15 drops to residual 6 under those controls — a 60% risk reduction bought with a challenge rule and a version pin [verify — register scores are the lab's calibrated judgment, not actuarial data]. The residual never reaches zero, which is why the accountability chain (who trained, who deployed, who can override) is named before the first live call, not after the first wrong one.

Pickleball application. Club tournament: the overlay is advisory, the referee's challenge window is the containment, and a mislabeled call triggers rollback to the pinned model version plus a register review within 48 hours.

Rugby league application. The analogue is R-03: a hallucinated VLM tactical explanation reaches a player — the generator-critic gate and human coach review are the containment, and the incident log feeds the next fine-tune's hard-negative set (C25).

Payoff. The wrong call is survivable when the loop exists: detect, override, roll back, learn — with a named owner at every arrow.

What this adds to the pipeline. UC 01–02 close the capture layer that feeds C08 (detection) and C09 (tracking) with lawful footage; UC 03 and UC 08 fix the license bases for every model trained in C08–C16; UC 04 is the economic frame for the C28 cockpit's edge deployment; UC 05–07 govern every athlete-facing artifact in C11 (pose) and C29 (coaching); UC 09–10 are the operational wrapper for anything that touches a match decision — the line between a demo and a deployment.

31.10 Sources

• AGPL-3.0 text + Ultralytics FAQ (docs.ultralytics.com/help/contributing); Roboflow, "Why AGPL-3.0 Is a Risk for Computer Vision Teams" (blog.roboflow.com); PML-1.0 (roboflow.com/platform-model-license-1-0); SAM License (Meta, Nov 2025); DEIM (github.com/Intellindust-AI-Lab/DEIM, arxiv.org/abs/2412.04234) — read 2026-08-30.
• Stats Perform, "Ten Years as Official NRL Data Provider" (statsperform.com); Hudl/ARLC renewal (hudl.com, 2026-01-29); AFL A\$4.5b broadcast deal (afl.com.au; abc.net.au, 2022-09-06); AFL broadcast-rights review (tvblackbox.com.au, 2025-07-30); Pickleball Inc. / Pickleball TV structure (sportsbusinessjournal.com, 2026-08-28; pickleball.com); fair-use framing (autoclip.dev; sportiq.org).
• GDPR Art 9; Australian Privacy Act 1988 + OAIC APP 3 guidance and OAIC facial-recognition risk guide; NIST AI RMF 1.0 (nist.gov); RLPA CBA dispute FAQ + NRL/RLPA long-form CBA announcement (2024-04-04); athlete data sovereignty (pmc.ncbi.nlm.nih.gov/articles/PMC12745375).
• Vendor lock-in: PB Vision partner API (pb.vision/apps); PlaySight product-intelligence report (sgx.studio); Playbypoint and KINEXON integrations. Disclaimer pattern: Moku Coach, SEMIPRO, Coach AI, Training Sparq terms.
• Token economics and edge hardware: Token Unit Economics and Edge Neural Hardware in Sports dossier (258 tokens/frame; 2.47M tokens/match; 55.7 ms glass-to-glass; \$3,199 CAPEX; 496-match break-even [verify at print]).
• Lab: lab/w7_lab_deployment.py → experiments/c31-deployment/outputs/metrics.json (measured scan flagged ultralytics 8.4.117, opencv-contrib-python 5.0.0.93, opencv-python 5.0.0.93; license matrix and 4-row risk register emitted).