This is the public witness for one of Gentian's three product capabilities: a presence-bound record for an answer. Check it offline, against a public key you hold. The verifier states its own limits as fields in its output, so the boundary of the claim travels with the record instead of living in our marketing.
The repository linked below holds a real signed record of an AI response, and a tampered copy of the same record. Verify both on your own machine. The first passes. The second refuses, and tells you why.
No account, no form, no email address. No GPU or network connection. The verifier is included; no additional cybiont software or service is required.
Run it
Clone the repository, or use Download ZIP on the repository page. Then, from inside it:
$ cd device-presence-bound-v1
$ python3 standalone_verify.py valid
{"terminal_status":"PASSED","device_presence_profile":"DEVICE_PRESENCE_BOUND",
"device_locality_claim":false,"workload_execution_claim":false,
"performance_claim":false,"vendor_code_used":false,
"device_certificate_revocation_status":"NOT_COLLECTED",
"signing_key_revocation_status":"NOT_COLLECTED",
"nvidia_spdm_measurement_blocks":52, …} # exit 0
$ python3 standalone_verify.py tampered
{"refusal_code":"PAYLOAD_DIGEST_MISMATCH","terminal_status":"REFUSED"} # exit 2
The only things you install are Python 3 and cryptography. The verifier is a single readable
Python file in the repository; it imports nothing else, and it uses no cybiont library. That is the
"vendor_code_used": false field above, and you can confirm it by reading the file.
Note what the rest of that output is. The boundary of the claim comes back as fields —
workload_execution_claim, device_locality_claim, performance_claim are all false, and both
revocation statuses say NOT_COLLECTED. You are told what this does not cover by the tool, in
machine-readable form, before you have read a word of our prose.
Get the records and the verifier → · Clone or Download ZIP. No account, no form.
The verifier source and both signed records live in one public repository, cybiont/device-presence-bound-record, under the MIT licence. You can read every line before you run it.
Why the failing one matters more
valid/ is a byte-exact sealed record from a real vLLM response on stock, non-confidential NVIDIA
Blackwell hardware.
tampered/ is that same bundle with the response text changed — and then made internally
consistent: the receipt was updated to describe the new text, and the package manifest was
recomputed to match. Everything a forger controls has been made to agree.
It still refuses, because the signature binds the response payload and that cannot be reproduced without the key. A record that verifies proves nothing on its own. A record that verifies beside one that refuses, for a named reason, is the part you can rely on.
What a pass establishes
That fresh authenticated evidence from an enrolled NVIDIA device authorised the signature over this response, and that the record still verifies after the device and signing process are gone.
What it does not establish
The verifier prints its own limits as data, so you are told them by the tool rather than by us:
- It does not prove the GPU executed the response, or that the device was physically local.
- Firmware measurements were not appraised. Certificate revocation was not checked.
- Presence is established at a moment, not continuously.
- No performance property is claimed.
The model, input and response fields are signed commitments. They are not execution attestation.
For compliance and internal audit
The package demonstrates one bounded control: an independently checkable integrity record for an AI request and response. It can form part of an audit trail and an internal control system, but it does not by itself establish retention, access-control, model-governance, or regulatory compliance.
- Traceability: the signed commitments identify the recorded model, input, and response.
- Audit trail: the valid and negative-control bundles give a reviewer a repeatable test and a named refusal reason.
- Record integrity: later payload changes are detectable; operational retention and availability remain the deployer's responsibility.
- Internal control: the control has explicit claims, limits, and acceptance behaviour that an auditor can evaluate and rely on within the agreed scope.
What it needs from you
Nothing beyond an existing NVIDIA serving stack is needed for this witness: no secured enclave, hardware change, special mode, or re-platforming. A customer pilot must separately agree record custody, retention, trust coordinates, and key ownership; this public package does not establish a production custody model. Within its stated boundary, it is a control an auditor can evaluate and rely on.
If you want to see it running against your own workload, that is a bounded paid pilot: one workflow, named devices, agreed claims, and acceptance criteria written down in advance.