Kaggle as a publishing loop

The forcing function for a parallel research arm is not the work plan. It's the publishing surface. A private repo, no matter how well organized, doesn't actually force you to ship. A public platform does. That is the whole reason Parley publishes to Kaggle and not to GitHub.

I made the choice early, before any code. The Parley brief commits to one notebook per month, public, on Kaggle. The commitment was deliberate. A repo I control privately would have given me permission to slip a month and never tell anyone. A Kaggle profile that already has notebooks on it does not.

The claim

A public publishing platform is a discipline lever the way a private repo is not. The mechanism is plain: when a stranger can see whether you shipped, the cost of not shipping has a face on it. A repo nobody reads costs you nothing when it goes silent. A profile with five published notebooks and a six-month gap looks like exactly what it is.

This is not about audience for its own sake. The arm doesn't need traffic. The arm needs the rail that stops a side project from quietly becoming a non-project. Public publishing is the cheapest rail I've found.

Why Kaggle specifically

I picked Kaggle over the alternatives for three concrete reasons, in order.

First, the datasets sit inside the platform. The Google ASL Signs dataset I'm working with on the first notebooks is hosted natively. No download-and-stage step. No fork-and-cite. A Kaggle notebook attaches the dataset by name and runs against it directly, which removes the most boring kind of friction from a side project — the kind that gives you an excuse to put the laptop down.

Second, the audience for applied CV work is already there. People who care about pose estimation, landmark models, or temporal classification read Kaggle notebooks the way researchers read arXiv preprints. The comment-and-upvote loop is a real feedback channel. A notebook that gets read by twelve practitioners is more useful than a blog post that gets read by twelve hundred drive-by readers, because the twelve will tell you when your evaluation harness is wrong.

Third, the platform versions everything. Notebooks, attached datasets, and the kernel state they ran against are all versioned in place. When a finding from notebook 02 gets contradicted by notebook 03, the citation back to the earlier version is a permalink. That is what an honest applied research practice looks like — you can show your work and your wrong turns. Most blog stacks make that hard.

The alternatives I considered and cut

A GitHub repo was the obvious default. I have several. None of them have ever forced me to publish anything on a schedule. A repo is a place to store work, not a place to commit to a cadence. Cut.

A personal blog was next. Substack or Ghost or whatever else. The reason it doesn't work for this is that a blog post about a CV notebook is one step removed from the notebook itself. You write the notebook, then you write a post about the notebook, then you publish the post. Two artifacts, two friction surfaces. The notebook itself doesn't run in front of the reader. For a research arm where the runnable artifact IS the work, you want the platform that displays runnable artifacts. Cut.

arXiv crossed my mind for about ten minutes. Wrong format. arXiv is for finished papers with formal structure, not for applied iteration where the second notebook contradicts the first. Submitting monthly iterations to arXiv would be a category error and the moderation queue would catch it. Cut.

Substack again, in a different framing — as a notebook-companion newsletter. I'm doing that with TruPath Labs already, and that's the right surface for synthesis and operator essays. It is the wrong surface for code that needs to run against a dataset in front of a reader. The two don't substitute for each other.

How to use Kaggle without medal-chasing

The Parley brief has a block called "What success does NOT look like," and the first item in that block is Kaggle medals. That line is load-bearing. Without it, the gravity of the platform pulls toward leaderboard chasing within about three weeks. The competition formats are designed to be addictive. They will eat the arm if you let them.

What I optimize for instead: a reputation for honest applied research. That means a notebook that reports a negative result is a successful notebook. A notebook that documents a failure mode in a published model is a successful notebook. A notebook that hits 60% accuracy and explains why honestly is more valuable to the arm than one that hits 90% with leakage in the eval split. The Parley roadmap is built around four specific research questions, not four competition standings.

The practical version of this is a self-rule I run before publishing: if the notebook would change shape because there was a leaderboard, the notebook is being written for the wrong reader. Rewrite or scrap.

On research substrate, briefly

The synthesis layer that sits behind the published notebooks (wiki pages, an index, NotebookLM notebooks) is its own discipline. I won't restate it here. The two-layer model — source notebooks plus a synthesis wiki — and the three operations (ingest, query, lint) belong in their own chapter. For an arm with a public publishing loop, the substrate is what lets each new notebook absorb the prior ones without re-reading three months of work.

One paragraph in plain language: I drop research into the substrate as I find it, the synthesis layer compresses it into focused wiki pages, and the next notebook reads three pages instead of forty transcripts. The substrate is independent of which platform you publish to. Kaggle is the publishing loop; the substrate is the prep.

Apply this

Pick your publishing loop today. Open a tab. Pick a platform where, when you skip a month, somebody outside your head will notice.

If your current loop is a private repo, that is not a publishing loop. Pick a public one. The criteria are simple: the runnable artifact you produce should display natively on the platform, the platform should attract readers who actually evaluate the kind of work you do, and the cost of going silent should be visible.

Write the platform commitment into your project brief in the same block as the cadence. One notebook per month, on Kaggle. One post per week, on the public blog. One demo per quarter, on the project's YouTube channel. The specific surface matters less than the fact that it is named and public.

Then publish the first one before you change your mind.