Inkling's Weights Are Open. Its Model Family Tree Still Needs Evidence.

Thinking Machines released Inkling with downloadable weights and an Apache 2.0 licence. It also disclosed that other models helped generate early training data. Open weights improve checkpoint control. They do not give procurement a complete model family tree.

Inkling exposes a distinction regulated teams need to make. Thinking Machines Lab says it trained the model from scratch and released its full weights on 15 July 2026. It also says open-weight models, including Kimi K2.5, generated synthetic data used in the initial supervised fine-tuning bootstrap (Thinking Machines Lab).

Those statements are compatible. "Trained from scratch" addresses the starting checkpoint. It does not mean other models played no part in shaping the released weights.

Open weights improve your ability to obtain, inspect, pin and operate a checkpoint. They do not, by themselves, disclose every dataset, synthetic-data generator, evaluator, licence question or runtime dependency. Procurement needs a model family tree with evidence states, not a one-word openness label.

What did Inkling actually open?

Thinking Machines describes Inkling as a 66-layer, sparse Mixture-of-Experts model with 975 billion total parameters and 41 billion active. It accepts text, image and audio inputs, generates text, and supports a context window of up to one million tokens. The model card says the weights are downloadable and identifies the licence as Apache 2.0 (Inkling model card).

The official Hugging Face repository provides the checkpoint artefacts. That gives a team more control than an API-only release. You can pin a repository revision, calculate internal hashes, retain the checkpoint and choose an approved inference environment.

Do not translate that into "fully open source". The model card provides category-level training information, not a complete dataset inventory or reproducible training pipeline. It says training data came from publicly available sources, third-party-acquired material and synthetic or augmented data (Inkling model card). Thinking Machines' separate training-data document says it describes general company practices rather than an Inkling-specific dataset list (training-data documentation).

The terms also need more than one field. The model card identifies Apache 2.0, while a separate Model Acceptable Use Policy says it applies to model weights, parameters, associated materials and modified versions. Its current date is 15 July 2026 (Thinking Machines Model AUP). That is not a legal conclusion about how the documents interact. It is a reason for a qualified person to review the exact artefact and access route before approval.

Self-hosting is not trivial either. The vendor says the BF16 checkpoint needs at least 2 TB of aggregated VRAM, while the NVFP4 checkpoint needs at least 600 GB. Direct deployment also requires an inference framework and its dependencies, with the model card naming options including SGLang, vLLM, TokenSpeed, Unsloth and Hugging Face (Inkling model card). Open weights move control. They do not remove the supply chain.

How can a model trained from scratch still have ancestors?

Treat ancestry as an operation, not a vague association.

Thinking Machines says Inkling's Mixture-of-Experts design largely follows DeepSeek-V3. That is an architecture influence, not evidence that DeepSeek weights initialised Inkling. It also says an initial supervised fine-tuning bootstrap used synthetic data generated by open-weight models, including Kimi K2.5, and that the bootstrap accounted for a small fraction of compute. That is a disclosed weight-shaping data relationship, not evidence that Inkling was distilled from Kimi or that every upstream licence obligation automatically transfers (Inkling announcement).

The word "including" matters. Kimi K2.5 is named. Other generators are not. Record the disclosed class and open an evidence request. Do not invent the missing identities.

Build an Upstream Influence Register with one edge per operation:

1. Initialised from: the starting checkpoint, if any.
2. Generated, filtered or rewrote data: the model or system that shaped training material.
3. Graded or selected outputs: the judge, reward model or evaluator.
4. Architecture influence: a method or design adopted without weight inheritance.
5. Evaluation only: a model used for comparison that did not shape the checkpoint.
6. Runtime only: the framework, cloud, inference operator or gateway used after training.

Give each edge an evidence state:

Use this prompt to draft the register. A machine-learning owner must validate artefact identities, legal must review licence and terms questions, and security and risk owners must decide whether each gap is acceptable.

Using only [RELEASE_POST], [MODEL_CARD], [REPOSITORY], [AUP],
[TRAINING_DATA_DOCUMENT] and [UPSTREAM_SOURCES], build a lineage ledger
for [MODEL_NAME] at [REVISION].

For each edge, return:
- upstream artefact and exact version, only when evidenced
- operation connecting it to the target
- class: weight-shaping, indirect development, evaluation only or runtime
- primary evidence URL and short paraphrase
- evidence state: ANCHORED, BOUNDED or OPEN
- licence, data, security or resilience question
- human owner and reassessment trigger

Do not infer unnamed models, datasets, judges, filters or providers.
Separate missing evidence from a confirmed negative finding.

A June 2026 preprint called ModSleuth offers a useful method for distinguishing direct and indirect model dependencies and grounding each edge in public evidence. Its authors applied the method to four other model releases, not Inkling, and reconstructed the dependency graphs from public artefacts with source-grounded evidence (ModSleuth preprint). Applying its framing here is an editorial control technique, not a claim that the paper audited Inkling.

Add a Provenance Horizon to the register. State how many levels you traced, which frontier remains unresolved and why the tracing stopped. The family tree is an evidence-grounded lower bound, not a claim of completeness.

Then run an Evaluation Kinship Check. Ask whether a synthetic-data generator, reward model or judge shares ancestry with the model it evaluates. Shared ancestry does not invalidate an evaluation. It can create correlated blind spots that deserve independent human testing.

What should Australian financial-services teams map?

Keep model-production ancestry separate from deployment dependencies. The checkpoint's training history belongs in the Upstream Influence Register. Your selected inference framework, cloud, container image, GPU environment, fine-tuned adapter, operator and support provider belong in an implementation AIBOM or SBOM.

Australia's joint AI and machine-learning supply-chain guidance says organisations should seek full visibility, maintain an AI Bill of Materials and Software Bill of Materials or equivalent, perform supplier due diligence and verify model versions throughout the lifecycle (ASD's ACSC). It is security guidance, not certification and not an APRA safe harbour. It is also the same evidence-first posture the EU's GPAI enforcement regime is pressing onto providers from the other side.

For APRA-regulated entities, the current CPS 230 determination has been in force since 1 July 2026. It covers technology, data and change risks, operational interdependencies and the management of service providers and relevant fourth parties (APRA CPS 230). Downloading a checkpoint does not automatically make Thinking Machines or every upstream model a material service provider. The arrangement, use and materiality need human assessment.

CPS 234 treats software, hardware and data as information assets and requires controls and testing proportionate to criticality, sensitivity, threats and lifecycle stage (APRA CPS 234). The practical artefacts are the exact checkpoint revision and hash, serving-stack versions, access controls, approved use, test results, monitoring, rollback copy and accountable owners. Verifying which model version actually served the work is the runtime half of the same discipline. A public model card can support that work. It cannot establish compliance.

Consider a fictional bank trialling Inkling to assist compliance analysts with first-pass policy comparisons. The sandbox record uses [MODEL_REVISION], [CHECKPOINT_HASH], [INFERENCE_OPERATOR], [HOSTING_REGION] and [SERVING_STACK_VERSION]. Test inputs are synthetic. A compliance analyst verifies every comparison before it enters work, and no model output decides customer treatment.

The bank's lineage ledger marks Kimi K2.5 as an ANCHORED synthetic-data generator for the initial supervised fine-tuning bootstrap. It marks other open-weight generators as BOUNDED. It records the exact pretraining datasets and the identities of any post-training judges as OPEN. This is a fictional worked example, not evidence that a bank has deployed Inkling.

Use this prompt to test whether the ancestry evidence is sufficient for a proposed use. Machine-learning, legal, security, procurement and business owners must review the result before approval.

Assess [PROPOSED_USE] using only [APPROVED_EVIDENCE_PACK].

Separate:
1. exact checkpoint, revision and release identity
2. starting checkpoint or supported from-scratch claim
3. named and unnamed synthetic-data generators
4. filters, rewriters, reward models and judges
5. architecture influence separated from weight-shaping relationships
6. licence, terms and unresolved upstream questions
7. the declared Provenance Horizon and remaining OPEN edges

For each item return SUPPORTED, PARTLY_SUPPORTED,
UNSUPPORTED or EVIDENCE_MISSING.

Identify which gaps could block, condition or leave unchanged the proposed use.
Draft the questions requiring qualified human review.
Do not make the approval decision.

A model card can support a bounded approval. It cannot support a claim of complete ancestry where material edges remain OPEN. Narrow accuracy is stronger than a sweeping provenance claim.

Do this Monday

1. Pin the artefact. Record the official repository, checkpoint format, revision, internal hash, licence source and Model AUP capture date.
2. Map the disclosed edges. Separate weight initialisation, synthetic-data generation, architecture influence, evaluation and runtime. Never turn resemblance into ancestry.
3. Mark the horizon. Use ANCHORED, BOUNDED and OPEN, then assign every material evidence request to a named owner and due date.
4. Split the two supply chains. Maintain the training family tree separately from the implementation AIBOM covering frameworks, images, infrastructure, operators and patches.
5. Test the evidence threshold and the work. Decide which ancestry gaps block, condition or do not affect the proposed use, then run organisation-specific tests with synthetic or de-identified data and human acceptance.

Bottom line

Inkling's open weights give you meaningful control over the checkpoint, but not a complete account of what shaped it. Thinking Machines disclosed one named synthetic-data generator, an architecture influence and several broader source classes. Turn those disclosures and gaps into an evidence-state family tree with a declared provenance horizon. Keep deployment controls separate, and let qualified people decide whether the remaining evidence is sufficient for the proposed use.

This article is general information and education only. It is not legal, compliance, financial or professional advice. Obligations vary by organisation and circumstance. Verify current requirements against the primary sources cited and seek advice specific to your situation.

References

1. Thinking Machines Lab, "Inkling: Our Open-Weights Model": https://thinkingmachines.ai/news/introducing-inkling/
2. Thinking Machines Lab, "Inkling Model Card": https://thinkingmachines.ai/model-card/inkling/
3. Thinking Machines Lab, official Inkling repository: https://huggingface.co/thinkingmachines/Inkling
4. Thinking Machines Lab, "Model Acceptable Use Policy": https://thinkingmachines.ai/model-acceptable-use-policy/
5. Thinking Machines Lab, "Training Data Documentation": https://thinkingmachines.ai/training-data-documentation/
6. Adhikesaven, Sun and Min, "Which Models Are Our Models Built On? Auditing Invisible Dependencies in Modern LLMs": https://arxiv.org/abs/2606.12385
7. Australian Signals Directorate's Australian Cyber Security Centre, "Artificial intelligence and machine learning: Supply chain risks and mitigations": https://www.cyber.gov.au/business-government/secure-design/artificial-intelligence/artificial-intelligence-and-machine-learning-supply-chain-risks-and-mitigations
8. APRA, "CPS 230 Operational Risk Management": https://www.apra.gov.au/standards/cps-230
9. APRA, "CPS 234 Information Security": https://www.apra.gov.au/standards/cps-234