A weights hash pins nothing without a runtime hash. Five serving runtimes moved in twelve days, and one of their license files is now two licenses.

THE OPERATOR'S MAP · Chapter: Sovereign Stack · Episode 3 · 7 September 2026. The five chapters advance together each week — agent controls (Ship AI), the open-source stack (Sovereign Stack), governance (The AI Boardroom), evaluation (Beyond the Benchmark), physical AI (Twin & Machine). This chapter's Episodes 1 and 2 are linked at the foot of the piece.

The Operator's Map is a weekly series for the people who have to run AI rather than admire it — five chapters, one per domain, all advancing together each week. This chapter teaches the open-source AI stack: what it means to run models you download rather than rent, and what that obliges you to check. Last week: how to read a model card like a contract, and how to notice that the card is not the contract. This week: the layer underneath the model. The serving runtime's own license and its release notes, because the weights you pinned run inside software you did not pin. Every technical idea gets restated in plain terms as we go.

Why this reaches your desk. Somebody in your company has written the sentence we pinned the model into a risk register, a vendor questionnaire or a board paper, and the sentence is true of one file. Between 26 August and 7 September 2026 every major open-source serving runtime shipped a release that changed defaults, removed execution paths, switched kernels or deleted a response field, with no change to any model's weights: vLLM, TensorRT-LLM, SGLang, Ollama and llama.cpp. One of those runtimes' license files now carries a second license with a revenue test, inside a tree the badge calls Apache 2.0. The model you pinned is running inside software that moved five times while the register said it was still.

Terms that matter this episode

Picture the kitchen

Picture a recipe you have printed, signed and pinned to the wall. Every gram is specified. You have the recipe's fingerprint: a photograph of the page, dated, so nobody can swap a line. You are entitled to say the dish is pinned.

Now picture the kitchen you cook it in. You did not build the kitchen. The oven was replaced on Tuesday by a model that runs twelve degrees hotter at the same dial setting. The pans were swapped for a thinner gauge. The gas company changed the pressure at the main. The supplier who delivers the flour quietly substituted a different mill. The recipe on the wall did not change. The dish did.

And the cookbook the recipe came from carries a license on its inside cover, which you read carefully last week. It says nothing about the oven. The oven has its own paperwork, in a drawer you have never opened, and this fortnight a second contract was slipped into that drawer for one shelf of the kitchen, with a clause that switches on when your restaurant's revenue crosses a line.

That is the whole episode, framed as a kitchen so that it can be seen. Nothing in it is invented except the kitchen. Every substitution in it happened, dated, in the twelve days before this was written, and the rest of the piece is the ledger.

The two hashes

Here is the position, in the words I use when this comes up in a review: a weights hash pins nothing without a runtime hash. A "pinned" model changes behavior on a runtime upgrade with no weight change. Sovereignty is a stack property, and the runtime is the layer nobody signs for.

The reason that needs saying at all is that the industry has spent two years learning the first half of the discipline and calling it the whole. Episode 1 of this chapter argued for the content digest: resolve a model by its hash, not its name, because a name returns a family of near-identical files with different safety profiles. That argument has largely won. Serious teams now pin the weights file and record its digest in a model bill of materials.

Then they write vLLM in the next row and consider the job done.

The weights are one layer. Between the file you downloaded and the token your customer sees there are at least seven more, each with its own owner, its own contract and its own release cadence, and the hash you recorded reaches exactly none of them. The runtime chooses the attention kernel. The kernel library chooses the numerics. The runtime's scheduler chooses the batch size, which changes latency and, under memory pressure, changes which requests are served first. The runtime's response schema chooses which fields your application receives. The container image chooses which versions of all of the above are actually present at boot. Every one of those is a behavior of the model as your customer experiences it, and every one of them is decided by software you did not pin.

So there are two hashes. One is the weights digest, which everyone now records. The other is the digest of everything the weights run inside, which almost nobody records, because it is not one file and nobody is handed it at download. The rest of this piece is a ledger of what the second hash would have caught this fortnight, from the vLLM release of 26 August to the llama.cpp build of 7 September, had anyone been keeping it.

Who licenses the copy you actually serve

Before the ledger, one concept that the ledger depends on, because the artifact most teams pin is not the publisher's file at all.

It is a quantized copy. A 27-billion-parameter model in its published precision is a 53.8 GB file; the same model compressed to three bits per weight by a third party is 8.4 GB to 11.8 GB, per the uploader's own card. That smaller file is what fits the hardware you have. It was made by someone other than the publisher, with a tool the publisher did not write, and it is a materially different set of bytes with a materially different error profile.

So who licenses it? I read eight open-weight licenses on 7 September 2026 and searched each one for the word "quantiz." Not one of them contains it.

Read the pattern. The two things a deployer most commonly does to weights before serving them are quantize them and merge them. The thing publishers most commonly name in a derivative clause is distillation, which is the thing they most want to control, and even that appears in only two of eight. Quantization rides, if it rides at all, on "derivative works," a phrase every one of these documents uses and none defines for this purpose.

The people who make quantized copies have noticed, and they have settled on a convention rather than a clause. The unsloth GGUF of Qwen3.8-Flash-Next declares license_name: qwen-community-1.0 in its front matter, restating the upstream license. The ISTA-DASLab GGUF of Qwen3.8-27B says in prose: "These quantized weights inherit the license of the base model (Qwen3.8-27B)." That is the right instinct. It is also an assertion by the uploader about a document the uploader did not write, and it binds nobody.

One license does something the others do not, and it is the one that matters for this episode. The Kimi K3 license exempts from its model-as-a-service condition "any use of the Software accessed through Moonshot AI's official products or certified inference partners." Read that as a stack statement. The license names the inference operator as part of its compliance boundary. Who runs the runtime changes what the license requires of you. That is the first time in this series a model license has reached down a layer, and it is the shape every license will eventually take, because the runtime is where the model becomes a service.

The ledger: five runtimes, twelve days

Now the evidence. Five serving runtimes, each read at its own release record on 7 September 2026, with the publication timestamp taken from the project's API rather than the rendered page, because the page prints a day and a month and no year. In every row, the model's weights did not change. In every row, the model's behavior did.

Take the rows one at a time, because each one is a different kind of movement.

vLLM changed your API. A response field that clients parse was removed, and the project's own release note calls it a "breaking client change." If your application reads reasoning_content, it stopped reading it on 26 August, and nothing about the model changed. The same release doubled the default token budget per batch from 8192 to 16384. That is a scheduling default. Under load it changes which requests share a step, which changes tail latency, which changes whether your timeout fires. And it moved a quantization path out of the tree, so a bitsandbytes-quantized checkpoint that loaded on the previous version needs a plugin on this one.

TensorRT-LLM removed execution paths. A two-model speculative-decoding mode was retired. An attention variant was removed along with "its configuration surface," meaning the flags you set for it no longer exist. A backend was deprecated. These are release-candidate tags, which is worth pausing on: rc is what production images get built from when a team tracks the leading edge, and the leading edge deleted three things in one tag.

SGLang changed the numerics. This is the row I would put in front of a model-risk committee. On 5 September the runtime began routing a class of FP4 DeepSeek-V4 checkpoints to a different mixture-of-experts kernel, by default, on three GPU generations. A kernel is the code that does the arithmetic. Two kernels computing the same layer in reduced precision do not produce bit-identical results, and in a mixture-of-experts model the routing decisions sit on top of that arithmetic. The weights are pinned. The arithmetic underneath them was swapped. Whether your outputs moved is a question only your own test answers, and that is the point. The same release made a different cache structure the default for every configuration and turned three environment variables into warnings. And it pinned a third project's version as a hard floor: "FlashInfer 0.6.18 is required." The runtime's behavior now depends on the version of a library the runtime does not own.

Ollama grew its surface. Four releases in eleven days, the last of which added an integration with a closed desktop client. The record is a release note. I quote it because a local runtime that gains a path to a hosted client has changed its trust boundary, and a trust boundary is a behavior.

llama.cpp moved 140 times. I counted, from three hundred rows of the project's release API: 140 tagged builds published between 28 August and 7 September inclusive, thirteen on the first day and twenty-one on the last day of August. "We run llama.cpp" is a sentence. b10850 is a pin. A team that wrote the sentence in a register was, by the end of the window, running something with 140 opportunities to differ from what it wrote.

The license file is no longer one license

Last week's rule was that the license attaches to the model, not to the account, and it moves. This week the same rule reaches the runtime, with one addition nobody expected: the runtime's license file can contain more than one license.

Start with the badges. vLLM, SGLang and TensorRT-LLM each declare Apache License 2.0 at the top of their LICENSE files. llama.cpp and Ollama declare MIT, the former as "Copyright (c) 2023-2026 The ggml authors" at its file, the latter at its own. Permissive, all five. No obligation on any of them to keep a default stable, to keep a field in a response, or to tell you before a kernel changes. That is not a complaint. It is what permissive means, and it is why the control has to be yours.

Now open the TensorRT-LLM LICENSE file on the main branch, all the way down, as read on 7 September 2026. The Apache 2.0 text is there. Below it is a third-party section. It names the MIT License and the BSD 3-Clause License, which is ordinary. Then it names the "LTX-2 Community License Agreement," applying to the directory tensorrt_llm/_torch/visual_gen/models/ltx2/.

That agreement is a model license, for a video-generation model, and it carries a revenue gate. In its own words: "Entities with annual revenues of at least $10,000,000 (the "Commercial Entities") are required to obtain a paid commercial use license." Its definition of derivatives reaches "transfer of patterns of the weights, parameters, activations or output."

Read what that is. A serving runtime whose repository badge says Apache 2.0, whose index tag says Apache 2.0, and whose LICENSE file opens with Apache 2.0, ships a directory under a model license with a ten-million-dollar revenue test. If your company clears that line and your build includes that directory, you have an obligation that no badge, no index and no first page of any file would have shown you. The LICENSE file is no longer one license. It is a container for licenses, and the interesting one is at the bottom.

I want to be precise about what is and is not being said. The file is correctly drafted. It discloses exactly what it should, where a third-party notice belongs. Nothing about the project is being characterized. The finding is about a reading habit: the badge is a summary somebody else wrote, and the habit of reading the badge instead of the file is the same habit that last week read the card instead of the license. Grep the LICENSE file. The word to search for is not "Apache." It is "License Agreement," plural.

And the drift is inside families, not between vendors, at the model layer too. On 5 August Qwen3.8-27B shipped under apache-2.0; on 24 August Qwen3.8-Flash-Next shipped under the Qwen Community License 1.0, with its separate-license condition for a "Model as a Service or AI Work Assistant business." GLM-5.2 and GLM-5.3-Flash carry license: mit; GLM-5.3, published 25 August, carries a custom license under which a model-as-a-service operator whose "aggregate revenue of the Licensee and its affiliates exceeds 10 billion US dollars (or the equivalent in other currencies) in total over any consecutive 12 months" must pass a security review, and "The scope and method of the security review shall be reasonably determined by Z.AI." DeepSeek V4, published 31 August, is license: mit, where the V3 license had defined derivatives to include "distillation methods entailing the use of intermediate data representations." Same accounts, same month, different contracts, in both directions. "We use Qwen" is not a license position. "We use GLM" is not a license position. Neither is "we use vLLM," and the last of those is the one nobody thought to check.

Telemetry is a default, not a policy

One more layer before the regions, because it is the one that turns up in every sovereign deployment review and is almost never in the deployment standard.

The vLLM documentation says, in its own words: "vLLM collects anonymous usage data by default to help the engineering team better understand which hardware and model configurations are widely used." The same page gives three ways to turn it off: set VLLM_NO_USAGE_STATS=1, set DO_NOT_TRACK=1, or create the file ~/.config/vllm/do_not_track.

That is a well-documented, honest default with a clean opt-out, and it is exactly the kind of thing a sovereign build has to write down. A sovereign deployment is a claim that the model's operation does not leave a boundary. That claim is made in a policy document. The default is made in a configuration file. If the deployment standard does not name the opt-out, the policy says one thing and the running system does another, and the running system is the one the examiner can see.

Notice the shape of the control. It is not "does the runtime phone home." It is "which of our runtimes phone home by default, where is that written in our build, and when did we last test that it is off." Only the tested control counts. A line in a policy is an intention.

Four regions, one runtime

The sovereign lane is global by construction, and the runtime is the layer where every region's framing meets the same fact: the software is the same software everywhere, and nobody's framework reaches it.

The United States. The current interagency model risk guidance, OCC Bulletin 2026-13, "Model Risk Management: Revised Guidance," April 17, 2026, with the parallel Federal Reserve designation SR 26-2, says: "Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance." It also says: "This guidance does not set forth enforceable standards or prescriptive requirements." Read those together, as a deferral rather than an exemption. No supervisor is currently going to tell a US bank which hash to record for its serving runtime. The obligations attached to the underlying action, to the loan decision or the customer disclosure the model touches, are exactly where they were. What was deferred is the specification of the control, which means the specification will be written against whatever the industry has already built. Out of scope is not out of risk.

The Gulf. The CBUAE Model Management Standards are in force on the Rulebook, read 7 September 2026, and their scope section says: "The MMS applies to all types of models employed by institutions to support decision-making." Table 1 of that standard lists "Artificial Intelligence" among the model types in scope. That inverts the US position: here AI is expressly inside a standard that binds. Now put this episode's question to it. The word in the standard is "model." The thing an examiner meets is weights inside a runtime inside a container, and the standard does not say where the model ends. Whether the runtime that swapped a kernel on 5 September is part of the "model" the standard governs is the seam, and I am not going to resolve it for a supervisor in a newsletter. I will say that a bank that has recorded the runtime hash can answer the question either way, and a bank that has not can answer it neither way. The browser read of that page on 7 September counted the word "must" 134 times; this is a standard, not a note. One layer over, the Dubai International Financial Centre's Regulation 10, enacted 1 September 2023, covers "Processing Personal Data through Autonomous and Semi-autonomous systems" and runs an accreditation and certification framework with named certification bodies. A certificate names a system. The question this episode leaves on the table for any certified deployment is which runtime hash the certificate was issued against, and whether the system after five runtime releases is still the system that was certified.

India. India publishes a compute ledger, and its banking regulator has drafted the sentence this episode needs. The IndiaAI compute capacity page, read in a browser on 7 September 2026, says the program's infrastructure features "18,000+ GPUs," that "India's Common Compute Capacity Crosses 34,000 GPUs," and that ten bidders were selected to supply accelerators, naming Intel Gaudi 2, AMD MI300X, NVIDIA H100, H200 and A100 and an AWS accelerator. Beneath that, its GPU Compute Allocation table lists, per applicant, the "No. of GPUs," the "Type Of GPUs," the "Service provider" and the "Subsidy Allocated," with A100, H100, H200, L4, L40S and MI300X visible in its rows; the compute portal itself carries a footer reading "Last Updated: 25-08-2026." That is a public, per-applicant record of which hardware ran, and it is more than most countries publish. Nobody publishes the runtime version and the kernel version that ran on those GPUs. The Reserve Bank of India's draft Guidance on Regulatory Principles for Model Risk Management, issued 24 June 2026 with comments closed 24 July and no final version on the regulator's notifications list as of 7 September, asks regulated entities for "enhanced controls for models with dynamic or automatic updates, including defining a clear scope of what can be updated automatically," and names "changes in model behaviour or capabilities resulting from provider-driven updates." Read that against the ledger above. A serving-runtime release is a provider-driven update that changes model behavior with no weight change, and the draft's own words reach it whether or not the drafters had the runtime in mind. It is a draft, and it is cited here as one. Beneath it sits the Digital Personal Data Protection Rules, 2025, Rule 13(3), notified 13 November 2025: "A Significant Data Fiduciary shall observe due diligence to verify that technical measures including algorithmic software adopted by it for hosting, display, uploading, modification, publishing, transmission, storage, updating or sharing of personal data processed by it are not likely to pose a risk to the rights of Data Principals." That rule comes into force eighteen months after publication, on 13 May 2027. "Algorithmic software" is not the weights. It is the whole stack. A significant data fiduciary that can show a weights hash and nothing else has verified one layer of the thing the rule names.

Canada. On 3 September 2026 the federal government published its "Responsible Data Centre Development Principles", opening from the observation that "Canada currently relies significantly on infrastructure and services based outside the country for the compute, cloud and data storage that power AI," and closing on the principle that "Data centres must bring strategic value to Canada." That is sovereignty framed as where the building is. It is a real framing and the right first move. It does not reach the runtime, which is where the building's behavior is decided, and which moved five times this fortnight regardless of where any building stood.

China-origin weights, as a market fact. The most consequential license facts in this window come from that side of the catalog, and so does the most instructive card. DeepSeek V4's card, published 31 August, gives deployment recipes for exactly two runtimes, vLLM and SGLang. That is a model card naming the software it expects to run inside, which is more than most cards do, and it is also a card asserting a layer it does not license, six days before one of those two runtimes changed the default kernel for its FP4 checkpoints. That is the record, cited, with nothing said about any publisher. It is also the reason the control has to be a hash rather than an origin filter. You do not build a serious open stack in 2026 by refusing a region's weights. You build one by fingerprinting whatever runs them.

The worked artifact: the obligation map from download to token

This is the object to take to work. Eight upstream layers and one of yours, in the order the bytes travel. For each: who licenses it, what changed in the window to 7 September 2026, what you must pin by hash, what you must grep in the file rather than read from a badge, and whether it phones home by default. The weights hash covers the first three rows. Everything below that is a control you own and, until this fortnight, probably did not know you owned.

The map, in full

Where a container image's composition matters, the companion piece on the Hugging Face composition record, Every component in the chain, carries the longer argument about what a dependency graph is and why most teams have not drawn theirs. This map is the runtime slice of it.

The derivative-status decision tree, as text

For any artifact you are about to serve:

1. Is it the publisher's own file, at the publisher's own revision? If yes, the license is the license. Read the file anyway, all the way to the bottom, and hash it.
2. If it is a quantized, converted or merged copy, does the upstream license define derivatives? If it uses a generic "derivative works" phrase with no mention of quantization, which is every one of Llama 4, Qwen Community 1.0, GLM-5.3, Kimi K3 and the Mistral Research License, then the copy is covered by that phrase if by anything, and the conditions attached to "the Software or its derivative works" travel with it. Record the clause. If the license names distillation and synthetic-data training, as the Gemma terms and the DeepSeek V3 license do, then the publisher has told you what it cares about, and a quantized copy is still on the generic branch. If the license is plain MIT, as DeepSeek V4 is, there is no definition to argue about and the permissive grant covers the copy.
3. Who serves it? If the license keys a condition to the inference operator, as Kimi K3 does with "certified inference partners," then the runtime layer is inside the license boundary and the answer to "who runs the runtime" changes your obligations. Record the operator.
4. Every exit ends the same way. Open the LICENSE file in the repository you pulled from, decide which clause covers the copy, and write the decision down beside the copy's hash and the runtime's hash. Only the tested control counts, and a license decision is tested the first time someone disagrees with it.

The move

The habit this episode is trying to break is small and specific. It is writing a version name where a hash belongs.

The replacement habit is equally small. Beside every weights digest in the model bill of materials from Episode 1, four more digests: the runtime's tag and commit, the kernel library's version, the container image's digest, and the hash of the runtime's LICENSE file at that tag. Beside the license decision from Episode 2, one more line: which clause covers the quantized copy, and who serves it. And one test, run before and after every runtime change: the same fixed prompts, the same fixed sampling, the outputs diffed. Not because the outputs must be identical. Because if they moved, you want to have been the one who found out.

That is an afternoon's work per deployment the first time and an hour per runtime release afterward. It gets harder to find as the number of runtimes rises, which is the same asymmetry as every control worth having, and the same reason to build it while the stack is small.

What makes this urgent rather than tidy is the cadence. A model's weights change when the publisher ships a new model. A runtime changes every few days, and in one case 140 times in eleven. The layer that moves fastest is the layer with no hash in the register.

Episode 1 said the scarce thing was the record of what the model was. Episode 2 said it was the record of what you agreed to when you took it. Episode 3 says the third part: the record of what the model ran inside, on the day it answered.

What would make me wrong

The window is twelve days, chosen because it is the fortnight before publication. If the same five projects were quiet for the next twelve, the ledger would look like a burst rather than a cadence. I doubt it, on the evidence of the llama.cpp per-day counts, but I have one window, not a time series.

A default change is not an output change. The SGLang kernel switch is recorded as what the release note says: a default moved. Whether any specific checkpoint's outputs moved is a test I did not run, because the test is yours to run on your checkpoint. If every FP4 DeepSeek-V4 deployment on those three GPU generations produced bit-identical outputs before and after, the row would still be true and the alarm would be quieter.

The TensorRT-LLM finding is about a reading habit, not a drafting error. The third-party section is where a third-party license belongs. If the project splits that directory into a separate package, the finding evaporates and should. It is a claim about a file on a date, checkable by anyone who scrolls.

Eight licenses is a sample. I searched eight for "quantiz." A ninth might name it. The tree does not depend on the ratio; it depends on the copy most teams serve being covered, if at all, by a clause written for something else, which holds unless a major license starts defining quantization explicitly. I would welcome that.

"We use vLLM" may be a hash in your shop already. Some teams pin the image digest and the commit and diff outputs on every bump. If that is you, this episode is describing your neighbors. The obligation map still tells you which rows your neighbors are missing.

What to ask your team

1. For every model we call pinned, what is pinned: the weights file only, or the runtime tag, the kernel library version and the container image digest beside it?
2. Which of our serving runtimes shipped a release in the last fourteen days, and who read the breaking-changes section?
3. Who has read the third-party section at the bottom of each runtime's LICENSE file, and does any of it carry a revenue or user threshold we would cross?
4. For every quantized copy we serve, which clause of which license did we decide covers it, and where is that decision written?
5. Which of our runtimes send usage data by default, where in our build is the opt-out set, and when did we last test that it is off?

The series

This is Episode 3 of The Operator's Map — a weekly series in five chapters, advancing together: Ship AI teaches agent controls, Sovereign Stack the open-source stack, The AI Boardroom governance, Beyond the Benchmark evaluation, Twin & Machine physical AI. All five of this week's episodes share one sentence: only the tested control counts. A revocation you timed, a license you grepped, a finding graded by the rule's own text, a parity run you can read when it fails, an acceptance test you specified. Next week, this chapter teaches you to know your own composition: the dependency graph is the security posture, and most teams have never drawn theirs. Subscribe to follow the map as it fills in.

Cut in verification, and why

• "llama.cpp shipped 140+ builds" as an estimate. Replaced by a count: 300 API rows pulled, 140 releases published between 28 August and 7 September inclusive, per-day counts in the research brief. The integer is derived, not estimated.
• Any claim that the SGLang kernel default changed a specific deployment's outputs. The record says a default changed for a class of checkpoints on three GPU generations. The effect on any given checkpoint is the reader's test. Cut as an outcome claim, kept as a default-change claim.
• Any container-image digest observed to change in the window. Not measured. The container row is a rule, pin by digest and never by tag, not a dated finding. Cut as a dated claim.
• "TensorRT-LLM's badge is wrong." The badge says Apache 2.0 and the tree is Apache 2.0. The finding is narrower: the LICENSE file carries a second agreement for one directory with a revenue gate, and a reader of the badge never sees it. Narrowed. Nothing is said about the project.
• The IndiaAI "10,000+ GPUs" figure. Present in the compute portal's page source inside an HTML comment; it does not render. Cut. The figures the text carries, "18,000+ GPUs" and "Crosses 34,000 GPUs," are the ones the hub page renders, read in a browser.
• A "this week" claim for the DPDP Rules. The ministry's site rendered empty in the browser session and serves an HTML shell to the fetcher; the Rule 13(3) text was read from a PDF copy of the Gazette notification. The text cites the notification and the rule number and makes no claim about the ministry's page this week. Held, marked for browser re-read.
• The Gulf AI guidance note of 11 February 2026 and the Qatar central bank guideline. Neither reached in the browser session. Not cited. The Gulf anchor is the in-force standard and the DIFC regulation, both read.
• A DPDP "12 May 2027" date carried in an older register. Thirteen November 2025 plus eighteen months is 13 May 2027. Corrected.
• Sovereign-program primaries for India, Saudi Arabia and the UAE in the window. Not reachable (HTTP 403, rejected fetch, empty JavaScript shells). Not claimed. The region anchors rest on the in-force CBUAE standard, the IndiaAI portal and the DPDP rule, each read today.
• The CBUAE standard's issue date. Present in the estate's register; not printed on the fetched page. The text says "in force" and does not date the issue.
• Any reading of Ollama's ChatGPT Desktop line as a judgment about the project. It is a release note, quoted as a record of an integration surface growing toward a closed client, and nothing more.