How model release tracking works at Neuricon

Why tracking is a pipeline problem

AI releases don't arrive through one channel. A model drops on a Friday night via a weights repo, the announcement lands on a social account, the technical details hide in a PDF, and the license terms sit in a separate repository. By Monday, three different benchmarks claim three different scores.

Neuricon exists because keeping up with this by hand stopped being feasible around 2024. This article explains how our own tracking pipeline works — the same pipeline that feeds the news wire and the archive.

Stage 1: Spotting

We monitor a fixed set of primary sources: official model hubs, vendor changelogs, arXiv listings, GitHub releases from known labs, and package registries. Each source has a poller tuned to its rhythm — hubs get checked hourly, social channels stream continuously.

A candidate release is anything that looks like a new artifact: new weights, a new API model ID, a version bump with eval numbers attached.

Stage 2: Deduplication

The same release surfaces five times through five channels. We merge candidates using a fingerprint of model family, parameter count, license, and release date. When two candidates conflict — different parameter counts, say — both are kept and flagged for human review rather than silently merged.

False merges are worse than duplicates. A duplicate is clutter; a false merge is misinformation.

Stage 3: Summarization

Each merged release gets a structured summary: what it is, what changed versus the previous version, the headline eval numbers with their sources, licensing, and where to get it. Summaries are drafted by models and reviewed by humans before they hit the wire. The review queue is the whole product, honestly — raw model output about model releases is turtles all the way down.

Stage 4: Taxonomy and archive

Every item is tagged into the Neuricon taxonomy — model, tool, or agent, plus finer tags like inference, evals, or open-weights. Tags are what make the archive searchable months later, when you need "that 7B MoE from October" and can't remember its name.

The archive is append-only. Releases get corrected, never rewritten — each correction is itself a dated entry. When you're making build decisions against this data, you want the history, not just the latest headline.

What this means for you

If you rely on Neuricon to stay current, two practical notes:

1. Check the source links. Every summary links to primary sources. For anything load-bearing — a migration, a purchase — read the original.
2. Use the archive, not just the wire. The wire tells you what happened today. The archive tells you how we got here, which is usually the more useful question.