Cryptographic governance evidence for Thinking Machines Inkling deployments. Open-weight, fine-tunable, and witnessable from Day 0.
Who this is for: AI engineers, MLOps teams, and compliance officers deploying Thinking Machines Inkling in production. No adapter required. Works with any OpenAI-compatible serving framework.
Released July 15, 2026. 975 billion parameters (mixture-of-experts, 41B active). Open-weight under Apache 2.0. Available on Hugging Face. vLLM Day-0 support with full feature parity (LoRA, speculative decoding, tensor/pipeline parallelism).
Inkling is positioned as a starting point for enterprise customization, not a finished product. Thinking Machines' Tinker platform enables organizations to fine-tune Inkling for their specific use cases. This creates a governance challenge: the fine-tuned model is different from the base model, and enterprises must prove that both the base deployment and any customizations meet regulatory requirements.
Open-weight models under Apache 2.0 shift compliance responsibility from the model provider to the deployer. Thinking Machines distributes the weights. You own the governance evidence.
Inkling serves through standard inference frameworks, all of which expose OpenAI-compatible APIs:
| Framework | Command / Config | SWT3 Compatibility |
|---|---|---|
| vLLM | vllm serve thinkingmachines/Inkling | Native (OpenAI-compatible) |
| SGLang | python -m sglang.launch_server --model thinkingmachines/Inkling | Native (OpenAI-compatible) |
| Ollama | ollama run inkling | Native (OpenAI-compatible) |
| llama.cpp | GGUF quants via Unsloth | Native (OpenAI-compatible) |
| Hosted APIs | Together, Fireworks, Modal, Databricks, Baseten | Native (OpenAI-compatible) |
All paths produce identical SWT3 Witness Anchors. Your compliance evidence is infrastructure-agnostic.
from swt3_ai import SWT3Witnessfrom openai import OpenAIwitness = SWT3Witness(api_key="axm_...", tenant="YOUR_TENANT")# Inkling on vLLM (or any OpenAI-compatible endpoint)client = witness.wrap(OpenAI(base_url="http://gpu-cluster:8000/v1"))response = client.chat.completions.create( model="thinkingmachines/Inkling", messages=[{"role": "user", "content": "Summarize Q2 earnings"}])# Anchor minted: AI-INF.1 with model hash, latency, token counts
import { SWT3Witness } from '@tenova/swt3-ai';import OpenAI from 'openai';const witness = new SWT3Witness({ apiKey: 'axm_...', tenant: 'YOUR_TENANT' });const client = witness.wrapOpenAI( new OpenAI({ apiKey: 'dummy', baseURL: 'http://gpu-cluster:8000/v1' }));const response = await client.chat.completions.create({ model: 'thinkingmachines/Inkling', messages: [{ role: 'user', content: 'Summarize Q2 earnings' }]});// Anchor minted: AI-INF.1 with model hash, latency, token counts
When enterprises customize Inkling via Tinker or direct fine-tuning, the model weights change. AI-MDL.5 witnesses the model weight hash before and after fine-tuning, creating an immutable record that the base model was known-good and that the fine-tuned variant can be traced back to its origin. This is critical for EU AI Act Art. 15 (accuracy, robustness) and NIST AI RMF MANAGE 1.3 (deployment integrity).
# Witness the base model weights before fine-tuningwitness.witness_model_weights( model_path="/models/inkling-base", model_id="thinkingmachines/Inkling", version="1.0.0")# After fine-tuning via Tinkerwitness.witness_model_weights( model_path="/models/inkling-finance-v1", model_id="inkling-finance-v1", version="1.0.0-ft", parent_model="thinkingmachines/Inkling")
When replacing an existing model with Inkling (or upgrading Inkling versions), AI-ASSESS.1 witnesses the champion-challenger evaluation. This proves the replacement decision was based on structured evaluation, not ad hoc.
The lifecycle chain captures the full evaluation arc: start with an AI-ASSESS.1 INITIATED anchor (evaluation begins), add MONITORING anchors during A/B testing to record comparative metrics, and close with a RESOLVED anchor (decision made, model deployed or rejected). The shared cycle ID links all anchors into a single auditable sequence.
EU AI Act GPAI obligations enforce August 2, 2026. Inkling qualifies as a GPAI model (975B parameters, trained on 45T tokens). Deployers must provide:
For full mapping, see the EU AI Act August 2026 Checklist and the GPAI Code of Practice Mapping.
What Inkling does: Generates text from multimodal inputs (text, image, audio) via MoE architecture (41B active parameters per query).
What SWT3 witnesses: Model identifier hash, input/output token counts, latency, provider endpoint.
AI-INF.1 anchors prove which model version produced which output. For fine-tuned Inkling variants, the model hash distinguishes base from customized.
What Inkling does: Base weights are downloaded from Hugging Face. Enterprises fine-tune via Tinker or custom training.
What SWT3 witnesses: SHA-256 hash of model weights file, model version, parent model lineage.
Compare the model hash in AI-MDL.5 anchors against the published Hugging Face hash for thinkingmachines/Inkling. Any mismatch indicates the model has been modified. The parent_model field traces fine-tuned variants back to the base.
What Inkling does: Serves as either the champion (incumbent) or challenger (replacement candidate) in model evaluation.
What SWT3 witnesses: Lifecycle chain tracking evaluation from INITIATED through MONITORING to RESOLVED. Captures baseline model, challenger model, evaluation criteria, sample size, statistical significance.
The lifecycle chain proves model replacement followed a structured evaluation process. Missing RESOLVED anchors indicate incomplete assessments.
What Inkling does: Applies safety filters and content moderation during inference.
What SWT3 witnesses: Whether safety filters were active during each inference, filter configuration hash.
AI-GRD.1 with factor_b = 1 confirms guardrails were active. Inkling's open-weight nature means guardrails are the deployer's responsibility, making this evidence critical.
What Inkling does: Model behavior may drift after fine-tuning or as input distributions change in production.
What SWT3 witnesses: Drift threshold configuration, breach magnitude, affected populations, consequence severity.
For fine-tuned Inkling variants, drift monitoring is essential. AI-DRIFT.2 proves the deployer actively monitors for behavioral changes with consequence-aware thresholds.
| Examiner Question | Where to Look |
|---|---|
| Which model version produced this output? | AI-INF.1 anchor, model identifier hash |
| Was the model fine-tuned from the base? | AI-MDL.5 parent_model field, weight hash comparison |
| Was a structured evaluation performed before deployment? | AI-ASSESS.1 lifecycle chain |
| Are safety filters active? | AI-GRD.1 factor_b (1 = active, 0 = inactive) |
| Is the model being monitored for drift? | AI-DRIFT.2 anchors with threshold and severity |
| Does this meet GPAI obligations? | Combined AI-INF.1 + AI-MDL.5 + AI-DRIFT.2 evidence chain |
Full SDK documentation: sovereign.tenova.io/docs
Create a free account: sovereign.tenova.io/signup