Who's behind this, and how to build one yourself
A short introduction to the person behind Dialectical Data, a look at the skillset it draws on, and — mainly — a generalized guide to building a similar system: one that visualizes data, automates its own research, validates what it publishes, and distributes it honestly through short-form video.
About the author
I'm Alex Mendoza. My hobbies live at the intersection of AI, data analytics, and systems and service automation — I like building things that do real research, reach a real conclusion, and then run themselves. Dialectical Data started as a way to put common beliefs on trial against actual data, and turned into an excuse to build the automation, visualization, and publishing pipeline described below.
Everything past this point is written as a generalized reference guide — not a description of this specific site, but a framework you can point at your own topic, your own data, and your own audience.
What's under the hood
The skillset a project like this actually draws on:
Data storytelling & visualization
Turning a hypothesis into a chart that argues its own case — clearly, honestly, without spin.
AI-assisted research
Using AI tools to gather, cross-check, and draft findings faster, while still tracing every claim back to a primary source.
Systems & pipeline automation
Wiring the research-to-publish process into a repeatable pipeline with real checkpoints, not a one-off script.
Front-end engineering
Building the site itself: component-driven pages, a token-based design system, layouts that hold up on any screen.
Short-form video production
Adapting a data story into a vertical video built for the platforms people actually watch it on.
published analyses
topic categories covered
distribution channels
The framework, in one breath
Validate a claim against real data, visualize it honestly, automate the pipeline that produces it, and distribute the finding through short-form video.
Everything below expands one of those four pillars — the six-phase pipeline is the spine of it, and the last two sections cover distribution in more detail.
How to build one: the six-phase pipeline
A generalized version of the pipeline this project runs on every analysis, from topic to publish:
Frame a testable claim
Pick a topic and write down the exact belief or comparison being tested — before looking at any data. Decide the shape: one belief resolved to a verdict, or several entities compared axis by axis. Writing it down first is what keeps the analysis from bending toward a conclusion later.
Plan the research
Map what data would actually prove or disprove the claim, note likely nuances and misconceptions ahead of time, and — if the output is going to be a short video — design the hook: the first few seconds that earn someone's attention before they scroll past.
Source & validate
Rate every candidate source by how reputable it is, confirm it is actually available and licensed for reuse, and write a one-line reason for using it. A weak source doesn't get quietly excluded later — it gets rejected here.
- Review gate — approve sources before gathering data
Gather & log
Pull the real data and keep a provenance trail of where every number came from. Any deviation from the plan gets logged, not smoothed over — a change in approach is part of the record, not something to hide.
Build & validate
Turn the data into an honest visual: labeled axes, stated uncertainty, a limitations section, and evidence against the claim actively sought out — not just evidence for it. A chart that only shows the flattering angle isn't finished yet.
- Review gate — approve before publishing
Publish & distribute
Ship the page, then adapt it into a short vertical video for wherever short attention spans live — reusing the same numbers rather than reinterpreting them for the video.
On gates and automation
The two review gates above are what keep an automated pipeline honest — a human (or an agent, self-approving against clearly written criteria) checks the work before it goes further, rather than letting a bad source or a misleading chart slide through unnoticed. Start with a real human at both gates. Once you trust the pipeline's judgment on a given kind of decision, those gates can be automated with explicit, written self-approval criteria — but that's an earned shortcut, not a starting point.
Where we post: from a finished page to a public video
Distribution isn't a separate afterthought — it's the last phase of the same pipeline:
Render
Generate a short vertical video from the finished page — the same numbers and verdict, restated for a 30–60 second attention span instead of a full page.
Host at a public URL
Most publishing APIs fetch the video themselves rather than accepting a direct upload, so the rendered file needs to be reachable at a stable public URL before the next step.
Call the platform's publishing API
Pass that URL, a caption, and metadata to the platform's own API — Instagram's Content Publishing API, the YouTube Data API for Shorts — and the platform pulls the file down and publishes it.
Both major short-form platforms work this way: they publish from a URL, not a direct file upload, which is why hosting the rendered video somewhere reachable comes before the API call. Start here if you're building the posting side:
Tools worth knowing
The official documentation behind every piece of this framework:
Astro
Content-collection framework this site is built on — file-drop pages, schema-enforced frontmatter.
MDX
Markdown with embedded components — how narrative prose and live charts share one document.
Observable Plot
Declarative charting for the standard-chart path — bars, lines, scatter, maps.
D3
Lower-level visualization primitives for bespoke, one-off "hero" chart moments.
GitHub Actions
CI/CD — every push to the main branch builds and deploys automatically.
Instagram Content Publishing API
Meta for Developers — how a hosted video gets posted to Instagram programmatically.
YouTube Data API
Google's API for uploading and publishing YouTube Shorts programmatically.
The point was never to be right. It was to build something that actually checks.
If you build your own version of this — a pipeline that tests a claim, visualizes the answer honestly, and ships it somewhere people will actually see it — that's the framework working as intended. What this one produces lives on the homepage.
Appendix: legal & sourcing notes
Trademarks & logos
Comparison analyses may display team, league, or brand logos (e.g. MLB club marks) to identify the entities being compared. These marks are the property of their respective owners. Dialectical Data is an independent, educational data-analysis project — it is not affiliated with, sponsored by, or endorsed by any team, league, or brand shown. Logos are used solely for identification and commentary, at the resolution needed for that purpose, not to imply endorsement or as the basis of any commercial product.
Data & methodology
Every analysis states the belief or question being tested before the data is examined, links every source it cites, and includes a methodology and limitations section. Conclusions follow the data, including when that means confirming a common belief or leaving a comparison mixed rather than declaring a single winner. Corrections are welcome — reach out via the links above.