substrate_id field.
It is evidence for your own audit. If you later learn that an SDK release or one of your dependencies was compromised, you can find the checkpoints that ran on it, and so the agent decisions to review.
What is recorded
Each integrity checkpoint stores these fields:provider and model are always present. The other two are optional.
The four collapse forms
substrate_id takes one of four shapes, depending on which optional fields are present:
The separator is
:. The @ inside <sdk@ver> belongs to the SDK identifier (for example @anthropic-ai/sdk@0.65.0).
The two optional headers
Without
X-Mnemom-Sdk-Version, the gateway reads the SDK from the User-Agent for these SDKs: anthropic-sdk-python, anthropic-sdk-typescript, @anthropic-ai/sdk, openai-python, openai-node, google-genai-python and google-cloud-aiplatform. For any other client, sdk_version is null unless you send the header.
Only the hash is sent. Your lockfile never leaves your environment. The lockfile-hash opt-in guide shows how to compute the hash and set both headers.
Reading it back
substrate_id and its parts are returned with each checkpoint:
What it is not
- Not signed. The fingerprint is stored with the checkpoint but is not part of the checkpoint’s signed payload. See integrity checkpoints for what the signature covers.
- Not a detector. Mnemom does not compare fingerprints across customers or raise supply-chain alerts from them. The fingerprint tells you what ran; deciding whether that stack was compromised is up to you and your other tooling.
- Not a replacement for package provenance. Verify the packages you install with SLSA provenance, Sigstore and dependency scanning. See supply-chain trust.
See also
- Lockfile-hash opt-in — computing the hash and setting the headers
- Supply-chain trust — verifying Mnemom’s own packages
- Integrity checkpoints — the record the fingerprint is stored on