{ "overt": "1.0.0", "subject": { "system": "your-model@production", "revision": "rev-04a1b2" }, "probe": { "family": "injection.indirect", "suite": "glacis.runtime-controls", "seed": 418 }, "verdict": "allowed", "policy": { "bundle": "iso-42001.baseline", "mapped_to": ["eu-ai-act:16", "soc2:cc7.2"] }, "witness": { "quorum": "3-of-3", "signature": "ed25519:9c4a…e11" }, "content_hash": "sha256:7f3e…d24b", "prev": "sha256:a1c0…8e9f" }
An open receipt format for runtime assurance proof.
OVERT-compatible receipts make runtime assurance evidence portable, tamper-evident, and review-ready. The format preserves proof of runtime events, control decisions, and verification data without requiring sensitive payloads to leave the customer environment.
§ i · definition
What OVERT is.
OVERT defines a compact, cryptographically sealed record — a receipt — that records the relevant runtime event, control decision, outcome, and verification data without exposing the sensitive payload. Each receipt is signed and chained to the previous one, so a history of decisions can be reviewed as a tamper-evident sequence.
The specification covers three things: the schema of the receipt itself, the signing semantics that produce it, and the verification rules any third party can use to check it. That is all. OVERT deliberately does not prescribe the model, the policy language, or the enforcement engine — only what gets recorded and how it can be trusted.
§ ii · rationale
Why an open standard.
Attestation is only useful if someone who does not trust the vendor can still verify the claim. A closed, vendor-specific format does not meet that bar — it asks auditors, regulators, and insurers to take the vendor’s word for it. An open specification removes that dependency: any conformant verifier, in any jurisdiction, can check a receipt without GLACIS in the loop.
OVERT is published under terms that allow anyone to implement it, including competitors. The value of a standard grows as more parties adopt it, and we would rather compete on the quality of the runtime than on the walls of the format.
§ iii · scope
What is in v1.0.
- Receipt schema. Required and optional fields covering subject, probe, verdict, policy, witness, content hash, and chain pointer — enough to replay an evaluation and verify its result.
- Witness semantics. Signing rules for producing a valid receipt, signature algorithm profile, and the conditions under which no receipt is written rather than a partial one.
- Verification rules. The exact checks a verifier must perform to accept a receipt as valid, including schema validation, signature verification, and chain integrity.
- Versioning and profiles. How OVERT evolves without breaking older receipts, and how industry-specific profiles layer on top (healthcare, financial services, medical devices).
§ iv · governance
GLACIS’s role.
GLACIS authored the initial draft of OVERT and maintains reference verification tooling. The specification itself is governed through the OVERT IPR policy published on overt.is, with contributions open to organizations that need portable runtime assurance evidence.
OVERT is the receipt format and verification layer behind Glacis. Runtime controls create the assurance. Signed receipts preserve the proof. OVERT makes that proof easier to verify and use.
§ iv · specimen
A receipt, read line by line.
Operational records can describe what happened. A receipt proves which controls ran. The same OVERT 1.0 structure can be verified across tools — tap any field to see how it’s validated.
The specification
The spec lives at overt.is.
The full specification, machine-readable schema, IPR policy, and versioned release notes are all published at overt.is. It opens in a new window — we trust you to find your way back.