Constant SYSTEM_FINGERPRINT 

pub const SYSTEM_FINGERPRINT: &str = "memra-0.125.0-8bda6bbfc513";

Backend-config fingerprint: memra-<crate version>-<content id>, baked by build.rs from the crate version plus a digest of the workspace’s compiled inputs. Together with seed, responses are checkable for determinism across deploys — the OpenAI system_fingerprint contract.

It is derived from file CONTENT, not from git history, and that is the whole point:

• It cannot degrade to a label. The old form was concat!("memra-", <git sha>), and a git failure inside darklanes’ release container silently baked the literal unknown. Prod served system_fingerprint: memra-unknown to every request for a deploy generation, which also meant darklanes’ tools/check-claim-builds.mjs --live had nothing to verify published performance pins against. See build.rs for the receipt chain.
• It survives a history rewrite. Rewriting commits changes every SHA while the bytes of the tree stay put, so a fingerprint quoted in a published claim, a research receipt, or a customer’s own response keeps naming the same build afterwards.

Deliberately NOT in the value: a build timestamp. Two builds of the same source must produce the same fingerprint, because check-claim-builds compares it for EQUALITY against a published pin and a per-rebuild value would churn every pin. Build time is an artifact-registry fact (the filename and the file’s mtime), not an identity.