How is a sealed model-card different from a standard AI model card?

Traditional model cards (as in Mitchell et al., 2019, or Hugging Face's format) are documentation intended for ethics and transparency review, stored as static, unsigned metadata files separate from any downstream output. A sealed model-card is canonicalized, hashed, and cryptographically bound - via its hash - into the specific verdict's Byzantine Fault-Tolerant-signed sealed receipt, so it functions as chain-of-custody evidence rather than documentation.

What happens if the language model provider deprecates the exact model version later?

The system checks a registry of model deprecations and annotates the model-card with a deprecation flag. If the recorded model version has since been deprecated, the verdict's evidentiary value from the model-output side is signaled as historical-only - the model output itself cannot be re-run - but the deterministic-floor portion of the verdict, described in Claim 31, remains fully valid and replayable.

What fields does a model-card record?

At minimum: provider identifier, model identifier, model version string, system-prompt hash, and sampling parameters including temperature and seed, plus a timestamp of invocation. Where available, it also records the model fingerprint published by certain providers as a per-response identifier, along with the provider's own response identifier and response timestamp.

Model-Card Sealing System

Executive Summary

Language-model providers change models constantly - new versions, silent weight updates, deprecations - without necessarily changing the model's public identifier. A compliance verdict produced under one specific model configuration can become unreproducible six months later simply because the model behind it no longer exists in that exact form. JIL Sovereign's model-card sealing system closes that gap by cryptographically binding the exact model identity used in a verdict into the verdict's own tamper-evident receipt, rather than leaving it as a separate, unsigned documentation artifact.

For every language-model invocation contributing to a compliance verdict, a model-card constructor records provider identifier, model identifier, provider-published model version string, model fingerprint where available, system-prompt hash, and a sampling-parameter set (temperature, seed, top_p, top_k, max_tokens), together with the invocation timestamp. The card is canonicalized to sorted-key JSON, hashed with SHA-256, and the hash is folded into the verdict's reproducibility manifest, which is signed by a Byzantine Fault-Tolerant quorum as part of the sealed receipt.

Core Innovation: A structured model-card is canonicalized, hashed, and bound - not merely stored alongside, but cryptographically bound via hash - into a Byzantine Fault-Tolerant-signed verdict receipt, so a third party can confirm exactly which model configuration produced any AI-mediated compliance verdict, even years later.

Problem Statement

Traditional model cards (Mitchell et al., 2019) and their descendants (Hugging Face's model-card format, provider-published system cards) document a model's behavior, training data, and intended use for ethics and transparency review. They are static metadata files, not embedded in any downstream output, and carry no cryptographic binding to a specific verdict a particular invocation produced. Provider-side conveniences - OpenAI's system_fingerprint, Anthropic's response metadata - supply a single useful field each, but neither constitutes a complete provenance pipeline on its own, and neither is bound into an evidentiary receipt.

Software supply-chain signing tools (Sigstore, cosign) sign build artifacts; SLSA provides provenance for software builds. Both are built for a different object - a compiled artifact - and neither embeds model identity into a downstream verdict receipt the way a compliance chain-of-custody requirement demands.

Distinct fields in the preferred model-card schema

SHA-256

Hash primitive binding the card to the receipt

902(14)

FRE rule the chain-of-custody binding targets

Why Existing Approaches Fall Short

Mitchell et al. / Hugging Face model cards: documentary artifacts for ethics review, not signed into any downstream evidentiary output.
OpenAI system_fingerprint / Anthropic response metadata: each supplies one useful field, not a full sealing pipeline.
Sigstore / cosign: signs model or software artifacts directly; does not embed model identity into a downstream verdict receipt.
SLSA: supply-chain provenance for software builds, not for language-model-mediated verdicts.

Technical Architecture

Model-Card Schema

Field	Description
`provider`	Provider identifier (e.g., the API vendor).
`model` / `model_version`	Model identifier and provider-published version string.
`model_fingerprint`	Per-response model identifier where the provider publishes one; may be null.
`system_prompt_hash`	SHA-256 hash of the exact system prompt used.
`sampling.*`	Temperature, seed, top_p, top_k, max_tokens.
`invoked_at`	RFC 3339 timestamp of the invocation.
`provider_response_id` / `provider_response_timestamp`	Identifiers returned by the provider for that specific response.

Construction and Sealing Flow

Immediately after each language-model invocation, the model-card constructor collects the configuration values used and the response metadata returned. The canonicalization module emits the card as JSON with sorted keys and no extraneous whitespace; the hashing module computes a SHA-256 digest. The invocation log stores the canonical JSON and its hash as an append-only record, exported as part of the engagement's evidentiary bundle at close. The reproducibility-manifest writer includes the model-card hash alongside the input-data, deterministic-floor, parameter, and gate-log hashes already in the manifest (see Claim 26), and the Byzantine Fault-Tolerant signing module signs the complete manifest into the sealed receipt.

Deprecation Handling and Multi-Invocation Verdicts

The system checks a registry of model deprecations and annotates the card with a deprecation flag. If the recorded model version has since been deprecated by the provider, the verdict's evidentiary value is signaled as historical-only for the model-output portion, while the deterministic-floor portion of the verdict (Claim 31) remains fully replayable regardless. Where a single verdict is touched by multiple language-model invocations, the system seals a list of model-cards - one per invocation - itself canonicalized and hashed for inclusion in the manifest.

Composable with Claims 26 and 31: the model-card hash produced here is one of the seven hash classes in Claim 26's reproducibility manifest, and every card corresponds to an invocation governed by Claim 31's numeric drift guard.

Prior Art Differentiation

Approach	Cryptographically bound to verdict	BFT-quorum signed	Deprecation-aware	Multi-invocation support
Mitchell et al. / HF model cards	No	No	No	No
OpenAI system_fingerprint	No	No	No	No
Sigstore / cosign	Signs artifact, not verdict	No	No	No
SLSA	Software builds only	No	No	No
JIL Sovereign	Yes, hash embedded in receipt	Yes	Yes	Yes, list-of-cards

The defensible combination is embedding a multi-field, canonicalized, hashed model-card directly into a Byzantine Fault-Tolerant-signed verdict receipt - prior model-card art is documentary and unsigned; prior artifact-signing tools do not bind model identity to a downstream compliance verdict.

Patent Claim

Independent Claim 32: A model-card sealing system for compliance verdicts mediated by a language model, comprising: a model-card constructor configured to produce, for each language-model invocation contributing to a compliance verdict, a structured model-card record comprising at least a provider identifier, a model identifier, a model version string published by the provider, a system-prompt hash, a sampling parameter set comprising at least temperature and seed, and a timestamp of invocation; a canonicalization module configured to emit the model-card record in a deterministic encoding; a hashing module configured to compute a cryptographic hash of the canonicalized model-card record; a reproducibility-manifest writer configured to include the cryptographic hash of the model-card in a reproducibility manifest of a sealed receipt issued for the compliance verdict; and a Byzantine Fault-Tolerant signing module configured to sign the reproducibility manifest by a quorum of validator nodes; wherein a third-party verifier holding the sealed receipt and the canonical model-card can recompute the cryptographic hash and confirm that the verdict was produced under the recorded model configuration.