Model identity pin

cryptographic evidence

Each L12 entry binds the exact provider + model + version that decided.

What it is

The modelIdentity field on every L12 entry records {provider, model, version}: e.g. {provider: 'anthropic', model: 'claude-sonnet-4-5', version: '20250929'}. Pinned to the specific call, not just to the spec configuration.

Why bind per-entry, not just to the spec? Because providers can silently update models behind a model-family name. claude-sonnet-4-5 in March 2026 isn't the same weights as claude-sonnet-4-5 in July 2026 unless the version field is pinned. The substrate forces the version into the spec + records it per call.

This is the structural answer to 'which model decided this specific decision?'. A regulator can ask the question and get a per-entry answer; the operator can isolate behaviour to specific model versions for incident analysis.

What it guarantees

Per-decision identification of model provider + model + version.
Detection of model swaps via specHash changes.
Granularity to isolate behaviour by model version for incident reconstruction.

What it does NOT guarantee

Honest limits. Every primitive has them.

That the upstream provider's version-string actually corresponds to specific weights — providers can mismatch the version label vs the weights; this is a contractual question between operator + provider.
Inference-time non-determinism if the model uses temperature > 0 or has otherwise non-deterministic decoding.

Regulations that engage this kind

EU AI Act Art. 11 + Annex IV

Technical documentation including model versions

EU AI Act Art. 53

GPAI downstream-operator information flow

Sectors that rely on this kind

Related evidence kinds

Spec hash commitment

Every L12 entry includes a SHA-256 of the active RuntimeAISpec, making silent spec drift detectable.

L12 receipt chain

Hash-chained, Ed25519-signed log of every LLM-in-the-loop decision a Promethean-built product makes.

FAQ

What if our LLM provider rotates the model under a stable name?

Two responses. First: pin the version field in your spec (e.g. claude-sonnet-4-5-20250929 rather than just claude-sonnet-4-5). Most providers offer pinned versions. Second: when you knowingly upgrade, change the spec — which changes the spec hash — so the chain shows the transition. If you discover an unannounced provider-side upgrade, that's a contractual issue with the provider, and the substrate gives you the evidence to raise it.