Rio de Janeiro's "Own LLM" Looks Like a Merge: What to Read Between the Lines

Rio de Janeiro's "Own LLM" Looks Like a Merge: What to Read Between the Lines Back in 2015, when I was just starting to wrap my head around Docker, something similar happened to me — smaller scale, but same flavor: someone in a forum showed off "their microservices stack" and it turned out to be the official Spring example repository with the package names swapped out. Nothing illegal, but definitely not "theirs." I think about that moment every single time an institutional tech announcement shows up with the phrase "developed in-house" and the seams are clearly showing. The news spread fast: Rio de Janeiro presented an LLM they called "their own" or locally produced, and the technical read from the community is that it could be a merge — or a fine-tune on top of — an already existing base model. I'm not going to speculate about intentions or politics. What I care about is the technical question underneath: how do you tell the difference between a model actually trained from scratch and a derived one, and why does that distinction matter when deciding whether to use something like this in production? My thesis: the real problem isn't that a municipality oversold something in a press release. The problem is that most technical teams don't have a minimum protocol for validating what a vendor — government or private — claims about a model they're about to integrate. And that has concrete consequences around licensing, privacy, reproducibility, and long-term support. A merge in the LLM context isn't just copying weights. There are documented techniques — SLERP, TIES, DARE, among others — that combine the weights of two or more models to get blended capabilities. Tools like mergekit (open source, verifiable) make this reproducible on commodity GPU. The core point: a merged model inherits the license of its base model. If the base is LLaMA 3 (Meta), the LLaMA Community License applies. If it's Mistral under Apache 2.0, you have more freedom but there are still conditions. Presenting the result as "our model" without disclosing the lineage doesn't automatically violate anything, but it can create legal and technical commitments that the team integrating it never anticipated. What the technical community detected — based on the public discussion available — are signatures that merged models tend to leave behind: patterns in the weights, responses with identifiable characteristics of the base model, tokenization behaviors that don't match a from-scratch training run. It's not definitive forensic evidence, but it's enough signal to demand more information before integrating. I use Ollama for local testing and Claude Code for architecture assistance. When I'm evaluating whether a model is worth the integration time — whether it comes from a vendor, a municipality, or an arXiv paper — I run through this checklist before writing a single line of code: # 1. Check the model card: is there a public Model Card with training data? # If there's no Model Card, the model has no documented technical contract. # 2. Test with Ollama locally before depending on an external API ollama pull model-name # 3. Diagnostic query: ask the model to describe its base architecture # (merged models often "know" where they came from if not instructed otherwise) ollama run model-name "What base model were you trained or fine-tuned on?" # 4. Check tokenizer config: an identical tokenizer to a known model is a strong signal # On Hugging Face: tokenizer_config.json → "tokenizer_class" and vocabulary cat ~/.ollama/models/.../tokenizer_config.json | grep tokenizer_class # 5. Search for the model on Hugging Face with the declared architecture # If weights match a public hash, there's traceable lineage Clear cut-off criteria: Signal What it indicates Action No Model Card Minimum transparency missing Request documentation before continuing Tokenizer identical to known model Likely derived Not a blocker, but demand license confirmation "Brand" behaviors from base model Merge or fine-tune without sufficient system instruction Evaluate with edge prompts before integrating License not declared Real legal risk Blocker until clarified No public checkpoint Not reproducible Vendor dependency with no fallback This checklist isn't original to me — it comes from standard model evaluation practice that any team working with LLMs should have documented. 1. "If it works well in the demo, that's enough." 2. "The license is the vendor's problem." ai.meta.com/llama/license — read it before integrating, not after. 3. "It's open source, so it's free." The architecture mistake here is the same one I see in other technical decision contexts: choosing based on the vendor's name instead of the documented technical contract. If you want to see how I think through that kind of layered decision, the post on decision trees for authentication tokens follows the same logic: explicit criteria before choosing the tool. Not every institutional model is suspicious. There are legitimate and useful cases. The question is when the validation effort is worth it versus when it's better to walk away: Dig deep if: The model handles sensitive user or citizen data The integration implies dependency on an API with no public SLA The model will make automated decisions (classification, moderation, scoring) No accessible technical documentation exists before integration Use with caution but no hard block if: It's for non-critical internal assistance (drafting documents, summaries) You have a local fallback with Ollama or access to an alternative model The Model Card exists even if it's basic and the license is declared Walk away immediately if: No Model Card, no declared license, no publicly verifiable checkpoint The vendor can't answer what base model they used What this Rio de Janeiro case illuminates is that third scenario: announcement with no accessible technical documentation. It's not necessarily malicious — there can be legitimate restrictions — but from an integration standpoint, a model with no documented lineage is a black box with hidden costs. This connects to something I already wrote about schema validation: when data comes in without an explicit contract, errors show up at runtime at the worst possible moment. Models are the same: the missing documentation doesn't bite you in the demo, it bites you in production three months later. I want to be clear about the limits of this analysis: There's no publicly verifiable evidence that Rio de Janeiro's model violates any specific license. The technical discussion points to similarities, not proven infractions. I don't know whether the municipality has private agreements with the base model's provider that permit the use and the way they presented it. A merge can be technically legitimate and valuable: many production models are fine-tunes or merges of base models. The problem isn't the technique — it's the lack of transparency about it. Model signatures aren't forensics: the patterns the community identifies are signals, not proof. An expert at the original provider with access to the weights could say much more. What can be concluded: if a technical team integrates this model — or any similar institutional model — without a public Model Card, they're taking on technical and legal risk without sufficient information. That's an architecture decision, not a moral judgment. For a deeper look at how I structure external dependency decisions in general, the post on Prisma and when to go below the ORM uses the same framework: knowing when the abstraction is enough and when you need to look underneath. What exactly is an LLM "merge"? Is a merged model necessarily lower quality? How can I verify locally whether a model is derived from another? Does this affect projects using local models with Ollama? What happens if the base model is Apache 2.0 and the derivative is presented as "theirs"? Do I need to know all of this to use an LLM in a small project? I don't think the Rio de Janeiro case is unique or especially egregious compared to other institutional tech announcements. What I do think is that it exposes a real gap: most technical teams integrating LLMs don't have a lineage validation protocol. They improvise it or skip it entirely. My practical recommendation is simple: before integrating any external model — from any source — run through the five-point checklist I described above. It won't take you more than an hour. What can take weeks is discovering that the model you put in production has a license restriction you never saw coming. The Rio de Janeiro case is a good early warning that institutional hype around LLMs is going to produce more situations like this. It's worth having the protocol ready before it lands on your doorstep. If you want to see how I apply the same "what's under the abstraction" criterion in other parts of the stack, the post on MCP and portable tools across models hits exactly that problem: not depending on a single vendor without understanding the technical contract you're signing. This article was originally published on juanchi.dev