Model Identity, Licensing, and Provenance

Name the exact object under review

A provider name or model family is not a deployable identity. Separate the AI system from its architecture, weights, tokenizer, configuration, prompt or chat template, adapters, quantization, inference runtime, dependencies, and surrounding application. Each component can have a different publisher, version, license, security boundary, and failure mode.

Write the deployment object as an explicit tuple: publisher and repository, immutable revision, artifact filenames and digests, base-model lineage, derivative or adapter identity, quantization method and parameters, tokenizer, prompt template, runtime and version, and intended deployment shape. If any required element is unresolved, the artifact is not ready to promote.

Distinguish downloadable, open-weight, and Open Source AI claims

Downloadable weights may be described as open-weight even when their terms restrict use, modification, redistribution, users, fields, scale, or outputs. Public access does not by itself establish permission, source transparency, reproducibility, safety, support, or the freedoms associated with Open Source.

The Open Source Initiative's Open Source AI Definition version 1.0 evaluates freedoms to use, study, modify, and share, together with access to the preferred form for modification. Use the exact cited definition when making an Open Source AI claim. Otherwise describe only what the evidence establishes, such as publicly downloadable weights under named terms.

Review all applicable terms as one decision

Collect the license text from the immutable revision, repository terms, acceptable-use policy, model card, notices, attribution requirements, base-model terms, dataset or adapter obligations, and any deployment or distribution conditions. Record the retrieved version and date. A short metadata label is an index, not a substitute for reading the controlling text.

Map the intended use against permissions and obligations: internal or external use, commercial use, modification, fine-tuning, generated-output terms, redistribution, hosting an API, sharing derivatives, attribution, notice preservation, downstream restrictions, geographic or user limits, and termination. Route ambiguity and consequential interpretations to an authorized legal or policy reviewer; a curriculum or model output is not legal approval.

Trace lineage and preserve evidence gaps

Model cards can describe intended uses, limitations, datasets, training details, base models, evaluation results, licenses, and library compatibility. Treat each field as a claim to verify, not a guarantee. Follow base-model, fine-tune, adapter, merge, conversion, and quantization links until the proposed artifact's ancestry and material transformations are understood.

Record missing training-data information, unclear derivative lineage, absent evaluations, incompatible versions, unverified publishers, and contradictory terms as explicit gaps. Do not fill a gap with an assumption or a generated explanation. Decide whether to stop, request evidence, isolate an experiment, choose another artifact, or accept a bounded residual risk through the authorized review process.

Issue a dated, expiring, and reversible decision

The adoption record should identify the exact artifact tuple, intended uses, prohibited uses, applicable terms, required notices, lineage, evidence sources, unresolved gaps, reviewers, approval scope, decision date, and expiry or re-review triggers. Separate technical recommendation, security review, legal or policy approval, and operational acceptance so one signature is not mistaken for every authority.

Re-review when the publisher, repository, revision, license, acceptable-use policy, base model, adapter, quantization, tokenizer, prompt template, runtime, deployment audience, distribution method, or use case changes. Preserve the rejected candidate and reasons so a future operator can explain why the deployed artifact was chosen.

Practice activity

Build an artifact identity and terms decision

Choose a low-risk candidate model repository without downloading or executing its artifacts.
Record publisher, repository, immutable revision, base-model lineage, derivative type, listed license, model-card claims, intended use, runtime expectation, and every unresolved identity field.
Retrieve the controlling license and related terms from the pinned revision or authoritative publisher source, then map the proposed use to permissions, obligations, restrictions, and required review.
Label each statement as directly evidenced, inferred, unknown, or requiring authorized legal or policy interpretation.
Write a decision of approve for isolated evaluation, reject, or hold for evidence. Include expiry conditions and the exact events that require re-review.

What to produce

A model identity tuple containing an immutable revision and the material components required for deployment.
A terms matrix linking each permission or obligation to its source and proposed use.
A lineage map with explicit gaps, reviewer boundaries, disposition, and re-review triggers.

Reflect before continuing

Which missing fact would most change your decision, and why would assuming it be less defensible than stopping or requesting evidence?

Model Identity, Licensing, and Provenance

You will be able to

Name the exact object under review

Distinguish downloadable, open-weight, and Open Source AI claims

Review all applicable terms as one decision

Trace lineage and preserve evidence gaps

Issue a dated, expiring, and reversible decision

Build an artifact identity and terms decision

What to produce

Reflect before continuing

Sources and verification

Make it stick.