Open-weight models have become strong enough that much of the industry now runs on them. The Stanford AI Index 2025 reported that the gap between open-weight and closed models on some benchmarks fell from 8% to 1.7% in a single year. For the people who build these models, that success brings a problem. Once the weights are released, the builder has almost no visibility into how they are served, by whom, under what terms, or whether the thing called by their model's name is their model at all.
This article covers what model builders should expect from the infrastructure that serves their work, and why those expectations are best met by infrastructure that is itself open.
"Open" covers a range of licences
Openness in models comes in degrees. The Open Source Initiative's Open Source AI Definition 1.0, released in October 2024, asks for the freedom to use, study, modify and share. It also requires detailed information about training data, the full code used to train and run the system, and the parameters. Many popular "open" models do not meet that definition. They are open-weight, released under custom licences with conditions.
Those conditions are real obligations. The Llama 3.1 Community License, for example, requires anyone who distributes the materials or a product or service containing them to "prominently display 'Built with Llama'". Licensees whose products had more than 700 million monthly active users on the release date must request a separate licence from Meta. Other families add acceptable-use policies, territory limits, revenue thresholds or non-commercial clauses.
A serving platform that treats every model as "open, therefore anything goes" breaks these terms at scale. One that records each licence's conditions with the model and enforces them in the serving path respects them at scale.
Provenance: which weights actually ran
The first thing a builder needs is assurance that what is served under their model's name is their model. Substitution is easy and tempting: a heavier quantisation, a smaller sibling, a fine-tune with different behaviour, or a corrupted download. Users cannot tell from the outside, and the builder takes the blame for poor output.
Three mechanisms close this gap.
Pinned manifests. Every file of a model is listed with its size and cryptographic hashes, fixed to a specific commit at its origin, and combined into a single Merkle root. A node that loads a file whose bytes differ from the manifest refuses to serve it.
Independent corroboration. A manifest is trusted when several independent observers report the same hashes from several independent origins, such as the builder itself, a model hub commit and storage providers. A contradicting observation is kept as a signed, attributable conflict rather than discarded.
Per-response binding. Each response carries a receipt, signed by the serving machine, that names the model hash and engine it ran. Weight substitution then becomes provable from a single response.
Licences enforced in the serving path
Licence terms belong in the model's catalogue entry, in machine-readable form. Four behaviours follow from that:
- Tiered admission. Permissive models load freely. Models with attribution or custom commercial terms require the operator to accept them explicitly, and non-commercial models require a separate opt-in.
- Paid-serving flags. A model whose licence restricts serving for pay is only ever served free of charge.
- Composite licences. When the weights carry several licences, such as a text encoder under its own terms beside the main checkpoint, the most restrictive tier applies, and every licence must be accepted.
- Conditions travel with the model. Display duties, revenue thresholds, required authorisations and territory limits are returned with the catalogue entry, so the apps built on top can meet them.
Gated models without a central gatekeeper
Many strong checkpoints are gated: the builder requires each user to accept the licence before downloading. On a centralised hub the hub enforces the gate. On a peer-to-peer network, weights move between machines, and the gate has to move with them.
The rule that works is simple. A node fetches gated weights only after its operator accepts the licence. It fetches them only from other nodes whose operators have also accepted it, as recorded in each node's signed endpoint record. And it never passes licence-bound bytes to a node that has not accepted. The builder's gate then holds across the whole network, not just at the first download.
Attribution and the EU's GPAI rules
In the EU, the AI Act's obligations for providers of general-purpose AI models have applied since 2 August 2025, and the Commission's enforcement powers, including fines, since 2 August 2026, as the Commission's guidelines page sets out. The guidelines clarify the conditions under which open-source providers are exempt from certain obligations. The voluntary GPAI Code of Practice, published on 10 July 2025, covers transparency and copyright for all GPAI providers, and safety and security for models with systemic risk.
For builders, documentation passed downstream only works if the downstream infrastructure keeps it attached to the weights. A catalogue entry that carries the licence, the source commit and the builder's own signed attestation of what they released does exactly that.
What this means for open-model builders
Ask the platforms that serve your models four questions. Can a user prove which of your weights produced a response? Are your licence conditions recorded and enforced, or only linked to? Does your gate hold after the first download? Can you sign your own attestation of what you released, so that what others observe can be checked against it? Infrastructure that answers yes protects both your reputation and your terms.
Where Tenzro fits
Tenzro is an open network where machines sell AI work using open models. It is live in preview, and governance decides the steps to testnet and mainnet. It does not ship models of its own: every model it serves is a third-party checkpoint. What is built:
- A signed catalogue. Entries record the engine family, the licence and its tier, whether the weights are gated, and the SHA-256 of every file, fixed to a commit at the origin. They are signed by bonded catalogue publishers. Files whose bytes do not match are refused. If two trusted publishers describe the same model differently, neither version is served.
- Provenance manifests. Per-file SHA-256 and BLAKE3 hashes form a BLAKE3 Merkle root. A manifest is verified when at least two observers across at least two origins agree. Origins include the model's creator signing under its own identity.
- Licence enforcement. Licence tiers gate registration, conditions are returned with the entry, the most restrictive tier applies to composite licences, and models whose licence restricts paid serving are served only free of charge.
- Gated weights. Operators accept a licence explicitly. Gated bytes move only between nodes whose signed records list that acceptance, and they are fetched from other nodes by content hash, never from the origin.
- Receipts. Each response's signed receipt names the catalogued model hash and engine.
Call-chain attribution on settlements names the app, agent and tool behind a payment. A dedicated per-call share for model builders is not part of the current documentation.
