The schema
What a receipt must contain — subject, evidence hashes, runtime signals, control outcomes, attestation, and chain position.
OVERT 1.1 · public standard
An open receipt format for runtime assurance proof.
OVERT‑compatible receipts make runtime assurance evidence portable, tamper‑evident, and review‑ready — and the format is published so that anyone can implement it, including our competitors.
Spec · overt.is · v1.1.0 · released 11 June 2026
§ i · definition
What OVERT is.
OVERT defines a compact, cryptographically sealed record — a receipt — that captures 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 reads as a tamper‑evident sequence.
The signing semantics
The rules that produce a valid receipt, the signature algorithm profile, and when no receipt is written rather than a partial one.
The verification rules
The exact checks any third party performs to accept a receipt — schema validation, signature verification, chain integrity.
§ 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.
The value of a standard grows as more parties adopt it. We would rather compete on the quality of the runtime than on the walls of the format.
§ iii · scope
What is in v1.1.
Normative
- Receipt schema — required and optional fields, enough to replay an evaluation and verify its result
- Witness semantics — signing rules and the conditions under which no receipt is written
- Verification rules — the checks a verifier must perform to accept a receipt as valid
- Versioning — how OVERT evolves without breaking older receipts
- Annex G — local evidence retrieval, an HTTP transport binding for cross‑boundary attestation, and automated auditor discovery
Informative companion
- Framework and regulatory crosswalks, moved out of the normative text in v1.1
- Industry profiles layered on top — healthcare, financial services, medical devices
- Versioning and errata policy, now stated in the standard itself
§ iv · specimen
A receipt, read line by line.
Operational records can describe what happened. A receipt proves which controls ran. The rows below follow the OVERT 1.1 structure of a real demonstration receipt — the workflow data is demonstration data; the cryptography is real.
Evidence record · OVERT 1.1
Signed & countersigned
Subject
Organization, deployment, workflow, and exact model this receipt covers
Bound
Evidence
SHA‑256 fingerprints of the exact input and output — hashes, never content
Hashed
Controls
14 rules evaluated, 0 triggered; action allowed in enforce mode
Allow
Attestation
Operator signature, witness countersignature, and chain position
Ed25519
Chain
Carries the hash of the previous receipt — change one byte and the chain breaks
Append‑only
The full JSON, with every field checked live in your browser, is on the verifier. Read it with real signatures →
§ v · 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.
Runtime controls create the assurance. Signed receipts preserve the proof. OVERT makes that proof easier to verify and use — whether or not Glacis is in the room.