Ground legacy wiki sections with citations

Author: alexeygrigorev

_wiki/analytics-engineering.md

@@ -187,15 +187,15 @@ these modeling decisions to growth and product work.
 His episode covers Looker
 reporting, dbt migration, product support, and A/B testing. It also covers
 retention analysis and marketing funnels
-([[podcast:from-marketing-to-analytics-engineering-sql-dbt-career-switch=>From Marketing to Analytics Engineering]],
+([[cite:from-marketing-to-analytics-engineering-sql-dbt-career-switch=>From Marketing to Analytics Engineering]],
 [[Product Analytics]]).
 
 The semantic layer is where analytics engineering becomes product work. A model
 is valuable when analysts and product teams can reuse a definition without
 copying business logic into new queries. Arpit Choudhury extends this from BI
 into activation. Tracking plans and warehouses need source awareness. BI
 analysis and reverse ETL need documented definitions
-([[podcast:data-led-growth-event-tracking-and-reverse-etl=>Data-Led Growth Stack]],
+([[cite:data-led-growth-event-tracking-and-reverse-etl=>Data-Led Growth Stack]],
 [[Data Product Management]]).
 
 The same semantic layer becomes the grounding layer for

_wiki/data-activation.md

@@ -42,12 +42,12 @@ walkthrough moves product events through tracking, warehousing, analytics, and
 activation. Support and sales teams use those signals in their own tools.
 Growth and product teams use them for onboarding and personalization
 ([[person:arpitchoudhury=>Arpit Choudhury]],
-[[podcast:data-led-growth-event-tracking-and-reverse-etl=>How to Build a Data-Led Growth Stack]]).
+[[cite:data-led-growth-event-tracking-and-reverse-etl=>How to Build a Data-Led Growth Stack]]).
 
 Caitlin Moorman's last-mile framing adds the adoption test. A dashboard, sync,
 or product surface hasn't done its job until someone uses it in a real decision
 ([[person:caitlinmoorman=>Caitlin Moorman]],
-[[podcast:last-mile-data-delivery-and-data-product-adoption-modern-data-stack=>Last-Mile Data Delivery]]).
+[[cite:last-mile-data-delivery-and-data-product-adoption-modern-data-stack=>Last-Mile Data Delivery]]).
 
 ## Activation As Last-Mile Delivery
 
@@ -76,19 +76,19 @@ customer data platforms come later. In that frame, activation is the point where
 product data improves support and sales. It also feeds personalization and
 onboarding
 ([[person:arpitchoudhury=>Arpit Choudhury]],
-[[podcast:data-led-growth-event-tracking-and-reverse-etl=>How to Build a Data-Led Growth Stack]]).
+[[cite:data-led-growth-event-tracking-and-reverse-etl=>How to Build a Data-Led Growth Stack]]).
 
 A [[modern data stack]] view starts from modeled warehouse outputs. In that
 frame, teams ask which modeled fields should leave analysis. The selected fields
 should support a business action ([[person:nataliekwong=>Natalie Kwong]],
-[[podcast:data-engineering-tools-modern-data-stack=>ETL vs ELT and the Modern Data Stack]]).
+[[cite:data-engineering-tools-modern-data-stack=>ETL vs ELT and the Modern Data Stack]]).
 
 A last-mile-delivery view holds that data work is unfinished until it reaches the
 decision point. It includes dashboards, experiments, meetings, and
 [[ai-powered-business-intelligence=>AI in Business Intelligence]] when BI answers
 reach the person making the decision. It also includes productized analytics,
 not only syncs into external tools ([[person:caitlinmoorman=>Caitlin Moorman]],
-[[podcast:last-mile-data-delivery-and-data-product-adoption-modern-data-stack=>Last-Mile Data Delivery]]).
+[[cite:last-mile-data-delivery-and-data-product-adoption-modern-data-stack=>Last-Mile Data Delivery]]).
 
 ## Reverse ETL As One Delivery Path
 

_wiki/data-engineer-roadmap.md

@@ -217,7 +217,7 @@ Once the first pipeline runs, learn where data should land and why. Start with
 storage and transformation patterns before memorizing product names.
 
 [[person:nataliekwong=>Natalie Kwong]] gives the clearest introduction in
-[[podcast:data-engineering-tools-modern-data-stack=>ETL vs ELT and Modern Data Engineering]],
+[[cite:data-engineering-tools-modern-data-stack=>ETL vs ELT and Modern Data Engineering]],
 covering ETL and ELT's flexibility. She also covers transformations from type
 casting to SQL joins and the distinction between data marts, warehouses, and raw
 ingestion layers. She frames lake versus warehouse as an architecture choice.
@@ -306,14 +306,14 @@ the work. They should be able to read the SQL and Python, run the tests, and
 ask why each tradeoff fits the consumer.
 
 Jeff Katz's
-[[podcast:get-data-engineering-job-prep-and-interview=>Data Engineering Job Prep and Interview Guide]]
+[[cite:get-data-engineering-job-prep-and-interview=>Data Engineering Job Prep and Interview Guide]]
 asks for readable code, visible SQL and Python depth, and tests. Slawomir
 Tulski's
-[[podcast:s23e06-data-engineer-career-in-2026-roles-specializations-and-what-companies-look-for=>Data Engineer Career in 2026]]
+[[cite:s23e06-data-engineer-career-in-2026-roles-specializations-and-what-companies-look-for=>Data Engineer Career in 2026]]
 pushes outcome framing and a small end-to-end platform, even when the
 implementation is simple. [[person:mehdiouazza=>Mehdi OUAZZA]] recommends
 writing and open-source work in
-[[podcast:scaling-data-engineering-teams-self-service-platforms=>Scale Data Engineering Teams]],
+[[cite:scaling-data-engineering-teams-self-service-platforms=>Scale Data Engineering Teams]],
 because public explanations can create feedback and make work visible.
 
 At this stage, check reviewability before choosing more projects. The roadmap

_wiki/data-roles.md

@@ -380,8 +380,8 @@ or quality checks, then document the schema and make reruns inspectable.
 [[person:jeffkatz=>Jeff Katz]] emphasizes SQL, Python,
 and cloud fundamentals in his data engineering career and job-prep episodes.
 Docker and Airflow also appear there, along with warehouses
-([[podcast:data-engineering-career-path-and-skills=>Build a Data Engineering Career]],
-[[podcast:get-data-engineering-job-prep-and-interview=>Data Engineering Job Prep]],
+([[cite:data-engineering-career-path-and-skills=>Build a Data Engineering Career]],
+[[cite:get-data-engineering-job-prep-and-interview=>Data Engineering Job Prep]],
 [[Data Engineering Portfolio Projects]]).
 For cold-start candidates choosing this role,
 [[how-to-become-a-data-engineer-with-no-experience=>becoming a data engineer with no experience]]
@@ -404,7 +404,7 @@ deployment path.
 
 Ben Wilson's production ML discussion and
 [[person:nadianahar=>Nadia Nahar]]'s
-[[podcast:software-engineering-for-machine-learning=>Software Engineering for ML]]
+[[cite:software-engineering-for-machine-learning=>Software Engineering for ML]]
 both make requirements and modular code part of ML engineering evidence. Tests
 and deployment gaps matter too
 ([[Machine Learning Portfolio Projects]]).

_wiki/freelance-data-and-ml-careers.md

@@ -71,14 +71,14 @@ The adjacent solo-business path is
 ## Practice-Building Starts With Proof
 
 Orell's first freelance signal came through a contact from his startup period.
-In [[podcast:from-academic-research-to-data-engineering-freelancing=>From Academic Research to Lean Data Consulting]],
+In [[cite:from-academic-research-to-data-engineering-freelancing=>From Academic Research to Lean Data Consulting]],
 a previous contact returned with a small paid consulting request. The project
 mattered because it proved that his startup and data-platform skills had
 market value even after the company didn't work out. He then focused on quality
 delivery. Networking, LinkedIn sharing, and referrals became part of the same
 practice ([[person:orellgarten=>Orell Garten]]).
 
-Pastor's proof began smaller and earlier. In [[podcast:nonlinear-path-to-machine-learning-freelancing-and-public-learning=>From Medicine to Machine Learning]],
+Pastor's proof began smaller and earlier. In [[cite:nonlinear-path-to-machine-learning-freelancing-and-public-learning=>From Medicine to Machine Learning]],
 he describes signing up for Upwork. His first small payment came from helping
 with a statistics problem. Those projects pushed him from SPSS into Excel and R.
 Later client work demanded Python.

_wiki/leadership.md

@@ -597,7 +597,7 @@ leadership because the team needs explicit standards and owners.
 At executive scope, leadership turns data work into a strategy that other
 leaders can act on. [[person:marcodesa=>Marco De Sa]]
 describes the [[chief-data-officer-role=>Chief Data Officer role]] in
-[[podcast:chief-data-officer-data-strategy-and-org-design=>Mastering the Chief Data Officer Role]]
+[[cite:chief-data-officer-data-strategy-and-org-design=>Mastering the Chief Data Officer Role]]
 as data strategy and governance. The role also covers AI direction and team
 design. It includes preparation for future products.
 

_wiki/machine-learning.md

@@ -300,14 +300,14 @@ decision.
 
 Teams need to know what a model can and can't support before they automate a
 decision. In
-[[podcast:interpretable-machine-learning=>Interpretable Machine Learning]],
+[[cite:interpretable-machine-learning=>Interpretable Machine Learning]],
 [[person:christophmolnar=>Christoph Molnar]] presents
 interpretability as a way to debug models and understand feature effects. The
 episode also covers uncertainty communication, transparent models, and post-hoc
 explanations. SHAP and conformal prediction provide concrete methods.
 
 Governance extends that trust work beyond a single explanation. In
-[[podcast:software-engineering-for-machine-learning=>Software Engineering for ML]],
+[[cite:software-engineering-for-machine-learning=>Software Engineering for ML]],
 Nadia connects model cards, datasheets, and checklists to responsible ML
 products. Explainability requirements belong in that work too. For deeper
 treatment of fairness, privacy, and security, use

_wiki/mlops-architecture.md

@@ -112,12 +112,12 @@ becomes the shared memory of those records.
 Experiment tracking replaces spreadsheet run logs with transparent model history.
 Metadata and lineage connect to [[reproducibility]], artifacts, and tracking
 ([[person:simonstiebellehner=>Simon Stiebellehner]],
-[[podcast:building-production-ml-platform-and-mlops-team=>Building Production ML Platforms]]).
+[[cite:building-production-ml-platform-and-mlops-team=>Building Production ML Platforms]]).
 
 The same requirement broadens to CI, repository structure, parameterization, and
 testing. It also covers data versioning plus traceability
 ([[person:raphaelhoogvliets=>Raphaël Hoogvliets]],
-[[podcast:mlops-at-scale-reproducibility-adoption=>MLOps at Scale]]).
+[[cite:mlops-at-scale-reproducibility-adoption=>MLOps at Scale]]).
 A simple architectural test applies. Another person should be able to locate the
 run inputs and rerun or look at the result. They should also understand why the
 artifact is eligible or ineligible for promotion.
@@ -215,12 +215,12 @@ Monitoring starts from production behavior and model behavior, then ties
 observability back to ETL/data pipelines. Summary profiles can support monitoring
 without moving every raw row into the monitoring system
 ([[person:dannyleybzon=>Danny Leybzon]],
-[[podcast:mlops-model-monitoring-data-observability=>MLOps Architect Guide]]).
+[[cite:mlops-model-monitoring-data-observability=>MLOps Architect Guide]]).
 
 On the maintenance side, production models need monitoring for data drift and
 concept drift. They also need an explicit maintenance path
 ([[person:thomives=>Thom Ives]],
-[[podcast:feature-engineering-model-monitoring-and-data-governance=>Feature Engineering, Model Monitoring, and Data Governance]]).
+[[cite:feature-engineering-model-monitoring-and-data-governance=>Feature Engineering, Model Monitoring, and Data Governance]]).
 Avoid automatic retraining until the architecture names the signal, owner, and
 comparison rule. It should also name approval state and rollback path.
 
@@ -231,7 +231,7 @@ to someone who can choose the right response.
 On the human-centered side, live test sets and small A/B tests support
 monitoring, alongside root-cause debugging and feedback channels
 ([[person:linaweichbrodt=>Lina Weichbrodt]],
-[[podcast:human-centered-mlops-and-model-monitoring=>Human-Centered MLOps]]).
+[[cite:human-centered-mlops-and-model-monitoring=>Human-Centered MLOps]]).
 A monitoring architecture is stronger when it supports incident response, not
 only dashboards.
 

_wiki/mlops-engineer.md

@@ -119,28 +119,28 @@ An MLOps engineer owns the accountable work that keeps the model path usable.
 - Make experiments recoverable by setting the repository, dependency, and run
   recording habits that let another person look at a result
   ([[Reproducibility]] and
-  [[podcast:mlops-at-scale-reproducibility-adoption=>MLOps at Scale]]).
+  [[cite:mlops-at-scale-reproducibility-adoption=>MLOps at Scale]]).
 - Keep model handoff usable by making ownership, evaluation, approval, and
   rollback context visible at promotion time
   ([[Model Registry]],
-  [[podcast:building-production-ml-platform-and-mlops-team=>Building Production ML Platforms]]).
+  [[cite:building-production-ml-platform-and-mlops-team=>Building Production ML Platforms]]).
 - Standardize CI/CD, packaging, tests, repository layout, dependency
   management, and deployment checks so releases don't depend on manual handoffs
-  ([[podcast:pragmatic-and-standardized-mlops=>Pragmatic and Standardized MLOps]],
+  ([[cite:pragmatic-and-standardized-mlops=>Pragmatic and Standardized MLOps]],
   [[ci-cd=>CI/CD]]).
 - Keep monitoring actionable by tying service health, input quality, prediction
   behavior, feedback, and incident response to someone who can act
   ([[Model Monitoring]],
-  [[podcast:human-centered-mlops-and-model-monitoring=>Human-Centered MLOps]]).
+  [[cite:human-centered-mlops-and-model-monitoring=>Human-Centered MLOps]]).
 - Maintain reusable templates, deployment guides, logging standards, support
   paths, and self-service workflows where repeated team pain justifies platform
   work
   ([[ML Platforms]],
-  [[podcast:mlops-at-scale-reproducibility-adoption=>MLOps at Scale]]).
+  [[cite:mlops-at-scale-reproducibility-adoption=>MLOps at Scale]]).
 - Maintain lineage, access control, validation, approvals, retention, and audit
   trails when the domain requires governance
   ([[Governance]],
-  [[podcast:mlops-and-ml-engineering-in-finance=>MLOps in Finance]]).
+  [[cite:mlops-and-ml-engineering-in-finance=>MLOps in Finance]]).
 
 ## Skills
 

_wiki/open-source-portfolio-evidence.md

@@ -57,9 +57,9 @@ DataTalks.Club hiring discussions show the same evaluator need. Reviewers want
 projects that prove Python, SQL, code organization, and tests. They also look
 for ownership and defensible technical claims
 ([[person:jeffkatz=>Jeff Katz]] in
-[[podcast:get-data-engineering-job-prep-and-interview=>Data Engineering Job Prep]],
+[[cite:get-data-engineering-job-prep-and-interview=>Data Engineering Job Prep]],
 [[person:nicksingh=>Nick Singh]] in
-[[podcast:data-interview-behavioral-and-portfolio-prep-guide=>Ace Data Interviews]]).
+[[cite:data-interview-behavioral-and-portfolio-prep-guide=>Ace Data Interviews]]).
 
 ## Maintainer Feedback and Review Trail