Skip to content
Regulayer™Human Control for AI
Book a live demo

The record format

What a record contains, and how anyone checks it.

A Regulayer™ record carries the fact of a decision, a cryptographic fingerprint of the material, and the identity of the person responsible. Never the material. Records are signed as they are written, and any change fails verification. The open verifier checks them with no call to us.

The record

The fact of the decision

What was decided, at what moment, in which surface. A review attested, a hold released, a seal applied, a halt taken.

The fingerprint of the material

The record proves these exact bytes were the ones decided about. The bytes themselves never move.

The identity of the person

Who is responsible for the decision, at the assurance level stated on the face of the record: declared by the signer, or accompanied by Presence evidence of a successful local check at the moment of sealing. A verified organisational identity requires the enrolment and key binding specified by the deployment.

The format version

An integer field named format sits inside the signed bytes; the current value is 1. A record missing the field verifies as version 0, forever. A verifier reports whether it supports the record’s version; a valid signature alone does not show that an older verifier understands a newer record.

The fields, exactly as they ship

A record is a single JSON object. The signature covers the canonical bytes of the receipt object. Inside the receipt object, the fields are these.

record_type

The kind of record, on the face of the record, so one kind can never pass as another.

format

The format version, an integer, currently 1, inside the signed bytes.

receipt_id

The identifier of this record.

size_bytes

The size of the material, in bytes.

declared_ai_use

What AI was used and for what, in the signer's own words.

ai_role

The part the tool played, from a fixed set of choices.

reviewer_name

The name of the person responsible, as they typed it.

review_attestation

The review statement, verbatim. This is the part the person signs.

review_checks

Which named checks the person carried out, stored in a fixed sorted order so the canonical form is stable on any machine.

evidence_level

The assurance level of the identity claim, stated on the face of the record.

timestamp_utc

The moment of sealing, in UTC.

time_basis

Where the time came from: self-asserted from the device clock, or witnessed by an independent authority.

tier

The product tier the record was sealed under.

seq

The sequence number of this record.

filename_sha256

A digest of the filename, so the name is bound without being disclosed.

// Illustrative values, shortened for the page. A real record carries full digests and signatures.
{
  "receipt": {
    "record_type": "ai_work_receipt",
    "format": 1,
    "receipt_id": "r-000042",
    "file_sha256": "9f2c...41ab",
    "file_sha3_256": "77d0...c93e",
    "size_bytes": 48213,
    "declared_ai_use": "Research summary and a first draft of section II",
    "ai_role": "drafting_assistant",
    "reviewer_name": "A. Sample",
    "review_attestation": "I personally read every case cited and checked each quotation against the source.",
    "review_checks": ["citations_pulled_and_read", "final_text_read_in_full", "quotations_checked"],
    "evidence_level": "declared",
    "timestamp_utc": "2026-08-04T15:11:02Z",
    "time_basis": "self_asserted",
    "tier": "standard",
    "seq": 42,
    "prev_receipt_sha256": "1be8...05f7",
    "filename_sha256": "6a91...d2c4"
  },
  "signing_public_key_b64": "...",
  "record_signature_b64": "...",
  "alg": "Ed25519"
}

How it is signed

Canonical form

Records are serialised in a fixed canonical form, so the same record always produces the same bytes. Verification recomputes those bytes exactly.

Signature

The signing key is generated on the machine where the record is made, on first run, and never leaves it.

Two classes of time, stated on the face

Self-asserted time, with no outbound call of any kind. Or witnessed time, where a single digest is timestamped by an independent authority. The verifier shows which class a record carries. Neither class ever sends the material.

Algorithm and preservation scope

Confirm the algorithms present in the record and supported by its verifier. The example on this page uses one classical signature scheme; it does not demonstrate a hybrid or post-quantum signature. Long-term retention needs a preservation and migration plan.

How anyone verifies it

Recompute the canonical bytes. Check the signature. Where witnessed time is present, check the timestamp token against the same digest. Every step is published mathematics. No account, no license, no service operated by us. Verification is a capability of the record itself, and it is free, permanently.

This page specifies the public profile of the format. Deployment profiles extend it under license, and the detail of specific surfaces travels under non-disclosure.

Check any record at the verifier. Free.

Or take the specimen with you: specimen-bundle.zip, a real sealed record made by the actual Sealer. Fingerprint 3914a56559306e844a8249b90c28f056692af9288eb06aaf25d2895de00c9262

Licensing begins with the problem, not the product.

Describe the system, what it decides, and what it would cost you to be unable to prove it. A written scope follows before any call.

Ways to begin:

A scoped pilot, inside your estate, on your machines. An architecture briefing, for your security function, one hour. The diligence pack: the record format and the estate, in writing. The problem itself, in your own words.

hello@regulayer.com