OVERT 1.1 · Public standard

Portable operational evidence anyone can independently check.

OVERT defines how a signed record describes a covered AI action, the fields and identities involved, what the control claimed and what was reported, so another tool can check that the record is intact and where it came from. What a record does and doesn’t establish is set out beside the specimen below.

Read the full standard Why it matters ↓

§ i · definition

What OVERT is.

OVERT defines a compact, signed record, which the specification calls a receipt, that captures a covered runtime event, the control decision, the reported outcome, and the data needed to verify it. A receipt profile can leave sensitive payload fields out. Each receipt is signed and can be chained to the one before it, so the sequence can be checked for later changes.

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.

§ ii · rationale

Why an open standard.

Attestation is only useful if someone who doesn’t trust the vendor can still check the claim. A closed, vendor-specific format doesn’t meet that bar. It asks auditors, regulators, and insurers to take the vendor’s word for it, which is the position they were trying to get out of. An open specification removes that dependency: any conformant verifier, in any jurisdiction, can check a record without Glacis in the loop.

OVERT is published under terms that let anyone implement it, including competitors. A standard is worth more the more parties adopt it, and we’d rather compete on the quality of the runtime than on the format.

§ iii · scope

What is in v1.1.

Receipt schema. Required and optional fields covering subject, evidence hashes, runtime signals, reported control outcomes, attestation, and chain position.
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).

Version 1.1, released 11 June 2026, moves the framework and regulatory crosswalks into an informative companion volume and adds a normative Annex G covering local evidence retrieval, an HTTP transport binding for cross-boundary attestation, and automated auditor discovery. The standard also now states its versioning and errata policy.

Spec · overt.is / v1.1.0·June 2026

§ 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 evidence.

OVERT defines portable attestation and verification profiles. Glacis can emit records that reference OVERT concepts, and can follow a registered OVERT profile where one is set up. What an outsider can check from a given record depends on its schema, who signed it, and what the verifier returns.

§ v · specimen

A record, read line by line.

This Glacis record carries a signature over what the control reported and the fields it covered, and references OVERT 1.1. It isn’t the closed-schema Protocol Profile 1.0 receipt the normative specification defines. The verifier confirms the record is intact, shows which key signed it and what it links to, and reads back the decision it recorded. It doesn’t tell you whether the note was clinically correct, whether every encounter was captured, or whether the system is safe or compliant, and it can’t confirm that events happened the way the record says. Tap a field to see what the verifier checks.

DEMONSTRATION RECORDGlacis schema v2.0 / OVERT reference 1.1.0 signed & countersigned

{
  "receipt_version": "2.0",
  "overt_version": "1.1.0",
  "id": "glc_receipt_019765f0…a8f135",
  "timestamp": "2026-06-11T09:14:02.317Z",
  "methodology_version": "1.0.0",
  "demonstration_note": "Demonstration workflow data. …",
  "subject": {
    "organization_id": "org_example_health",
    "deployment_id": "dep_clinical_scribe_prod",
    "workflow": "ambient-scribe-draft-note",
    "model": "claude-sonnet-4-6",
    "provider": "anthropic"
  },
  "evidence": {
    "input_hash": "31ee…8981",
    "output_hash": "157c…a161"
  },
  "signals": {
    "binary_hash": "8445…913f",
    "network_state_hash": "02d0…be42",
    "epoch_token": "1781082842317",
    "context_window_hash": "ed1f…9d7e",
    "composite_hash": "64a7…2626"
  },
  "controls": {
    "guardrail_action": "allow",
    "nonconformity_score": 0,
    "rules_evaluated": 14,
    "rules_triggered": 0,
    "policy_mode": "enforce",
    "phi_egress_check": "pass"
  },
  "attestation": {
    "operator_signature": "10ca…150b",
    "operator_public_key": "9c8e…23d8",
    "witness_signature": "9994…4901",
    "witness_public_key": "7c03…39a5",
    "previous_receipt_hash": "genesis",
    "chain_position": 1
  }
}

Marginalia: reader’s notes

Tap a highlighted field to jump to its note.

OVERT version

OVERT 1.1 is a public, versioned spec, released 11 June 2026. A conformant verifier can check the required fields and integrity rules; the Proof Gap white paper explains why a record like this matters to an outside reviewer.

Spec · overt.is / v1.1.0

Demonstration note

The record labels itself: the workflow data is illustrative. The cryptography is real; every signature and hash here verifies in your browser.

Field · demonstration_note

System under governance

Identifies the organization, deployment, workflow, and exact model this record covers. Records issued against a different deployment aren’t interchangeable.

Field · subject

Evidence hashes

SHA-256 fingerprints of the input and output this record declares. It carries hashes rather than the content itself, so anyone holding the originals can check that they match. Whether the content crossed some other boundary, through the model, telemetry or storage around it, is outside what the record covers.

Field · evidence

Runtime signals

Fingerprints of the declared enforcing binary, network state, and context window, committed to one composite hash. They tie those reported values together; on their own they don’t show which build and configuration were live.

Field · signals

Control outcome

What the runtime control decided: 14 rules evaluated, none triggered, the action allowed in enforce mode, and the PHI egress check recorded as pass.

Field · controls

Dual attestation

This record carries an operator signature plus a witness countersignature from a Glacis-run service, both Ed25519, over the same canonical record, with an inclusion proof. If the signed bytes change, verification fails. Because the witness is a Glacis service, the second signature doesn’t on its own show that an independent party was involved.

Field · attestation

Chain pointer

Each record can commit to the hash of the one before it. This one is position 1, the start of its chain. Removing or altering a record in the middle shows up when a later link, checkpoint, or external anchor has been kept; the chain on its own won’t show that records were cut from the end or that the whole chain was rebuilt.

Field · attestation.previous_receipt_hash

Verify a record

This exact record, full hashes and all, verifies in your browser.

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. This page is a summary. If you’re writing a verifier, or working out what to ask a vendor to hand over, read the specification itself.

Open overt.is Talk to us

Navigate

Solutions